Cómo usar Claude en gestión de producto: PRDs, feedback y priorización

No necesitas un curso largo para empezar a usar bien Claude en el trabajo de product manager. Tres lecciones gratuitas cubren los hábitos específicos que describe esta página, en el orden en que se construyen unas sobre otras.

Empieza con El contexto es todo, del curso Prompting Estratégico, una lección de cinco minutos sobre el único hábito que separa un borrador de PRD utilizable de relleno genérico: darle a Claude el planteamiento real del problema, la investigación y las restricciones en lugar de un pedido de una línea.

A partir de ahí, Investigación y pensamiento, en Domina lo Esencial (siete minutos), cubre cómo trabajar con Claude en análisis estructurado, la misma habilidad que hace útil la síntesis de feedback y la investigación competitiva en lugar de vagas.

Termina con Prompts avanzados: premortems, steelmanning y red-teaming, también en Domina lo Esencial (siete minutos). Esta es la lección detrás de la prueba de presión para la priorización: pedirle a Claude que argumente en contra de tu propia inclinación antes de que lo haga un stakeholder. Juntas, estas tres lecciones son un camino más rápido hacia un buen resultado de product manager que el ensayo y error en una ventana de chat en blanco.

La mayor parte del trabajo de product manager ocurre en conversación simple con Claude, lo que el curso Tres Modos llama chat y co-work. Claude AI: Chat que piensa (siete minutos) cubre el modo más rápido: una sola pregunta o pedido de borrador, útil para una sección rápida de PRD o un resumen puntual de feedback.

Claude Co-work: tu compañero de pensamiento (seis minutos) cubre el modo donde realmente vive la mayor parte del trabajo de product manager: una conversación extendida de ida y vuelta donde iteras sobre un documento, cuestionas un borrador y dejas que Claude retenga el contexto de todo lo que ya discutieron.

Un grupo menor de product managers también recurre a Claude Code: Programa con palabras (seis minutos), el tercer modo, cuando necesitan leer directamente un código base para entender una restricción técnica de primera mano en lugar de depender de la paráfrasis de un ingeniero. Esa es una habilidad genuinamente distinta del trabajo en lenguaje simple de arriba, y la mayoría de los product managers nunca la necesitan para obtener valor de Claude.

La palanca más importante es darle a Claude contexto real en lugar de un prompt vago. "Redacta un PRD para una funcionalidad de notificaciones" produce relleno genérico. Pegar tu investigación de usuarios real, las restricciones técnicas que tu equipo mencionó en el standup y un ejemplo de PRD que le gusta a tu equipo produce algo que realmente puedes editar, no algo para descartar.

La misma regla aplica a la investigación competitiva y a la priorización. Claude no puede decirte qué es realmente cierto sobre los precios actuales de un competidor o el uso real de tu producto. Si le pides que estructure un análisis a fondo, dale lo que realmente has observado. Las entradas vagas producen resultados que suenan convincentes pero no son confiables.

Iterar en la misma conversación es mejor que empezar de cero cada vez. Si un borrador de PRD no da en el blanco, dile a Claude específicamente qué está mal y deja que lo revise, en lugar de reescribir el prompt desde el principio. Claude retiene el contexto de lo que ya discutieron dentro de una conversación, que es de donde viene buena parte del ahorro de tiempo.

Claude no conoce a tus usuarios, tu mercado ni la tolerancia al riesgo de tu empresa a menos que se lo digas. Un marco de priorización es tan bueno como las entradas que le das, y Claude producirá con gusto una recomendación que suena convincente a partir de poco contexto. Trata su resultado como una opinión estructurada a la que reaccionar, no como un veredicto.

Tampoco puede decirte qué es realmente cierto sobre el uso de tu producto o el estado actual de tus competidores. Claude es fuerte en organizar y razonar sobre información que tú aportas; no es una herramienta de investigación en vivo que trae datos actuales por su cuenta.

Ten cuidado con lo que pegas. El feedback sin procesar de usuarios, las transcripciones de entrevistas y los tickets de soporte a menudo contienen detalles identificables de clientes reales. Quita nombres e identificadores de cuenta donde puedas antes de pegar un lote de feedback en una conversación, del mismo modo en que manejarías esos datos en cualquier otra herramienta.

La síntesis que produce Claude debería revisarse contra el material original antes de que llegue a stakeholders, clientes o ingeniería, del mismo modo en que revisarías el resumen de un analista junior. Esto importa más cuando la síntesis de feedback alimenta una decisión con un costo real, como sacar una funcionalidad o reprioritizar un trimestre.