El espacio de trabajo con IA para product managers: specs, investigación y narrativa en una sola herramienta

Dónde encaja la IA de verdad en la semana de un PM

La gestión de producto son cuatro trabajos distintos que comparten un calendario. Lees mucho (feedback, tickets, transcripciones, exportes de analítica), escribes mucho (specs, actualizaciones, briefs), analizas un poco (funnels, cohortes, resultados de encuestas) y persuades todo el tiempo. Cada una de esas tareas premia a un modelo distinto, por eso una sola suscripción de IA cubre más o menos dos tercios del trabajo y deja el resto sintiéndose como una pelea.

Tarea del PM	Mejor modelo	Por qué
Narrativa del PRD, planteamientos del problema, actualizaciones de producto	Claude	Sostiene un argumento largo, escribe prosa que un ingeniero de verdad va a leer
Categorización de feedback, agrupación de tickets, extracción estructurada	GPT	Fiable en formatos de salida estrictos y etiquetas de categoría consistentes
Investigación de discovery, análisis de competidores, contexto de mercado	Gemini	Lo mejor en material web reciente, devuelve fuentes que puedes abrir
Transcripciones largas, decks de investigación, informes de 100 páginas	Gemini	Ventana de contexto de 1M de tokens, así que todo el corpus cabe en una sola pasada
Crítica del spec y búsqueda de casos límite	Cualquier modelo que no haya escrito el spec	Un lector independiente detecta lo que el autor no puede

Nada de esto reemplaza el criterio sobre qué construir. Comprime la distancia entre tener los insumos y tener algo escrito, que es donde la mayoría de las semanas de un PM realmente pierden tiempo. El cambio entre modelos también sale barato: en Whizi Pro un mensaje de Claude Sonnet 5 gasta 10 créditos de una asignación mensual de 2.000 créditos, una extracción con GPT-5.6 Luna gasta 1, y Gemini 3.7 Flash lee transcripciones a 2 créditos por mensaje.

Escribir un PRD que un ingeniero no te devuelva

La mayoría de los specs escritos con IA fallan en lo mismo: describen una funcionalidad en lugar de una decisión. Ingeniería no necesita un párrafo sobre por qué le importa al cliente. Necesita los estados, los casos límite y qué pasa cuando la llamada falla. Pide eso explícitamente y el resultado cambia de carácter.

Prompt: primero el planteamiento del problema

Escribe la sección de planteamiento del problema de un PRD. Evidencia que tengo: [pega tickets de soporte, analítica, citas de entrevistas]. No propongas una solución. Devuelve: quién tiene el problema, con qué frecuencia, qué hace ahora mismo en su lugar, qué le cuesta, y qué esperaríamos que cambiara si se resolviera. Marca cualquier afirmación no respaldada por la evidencia que pegué como ASSUMPTION.

Prompt: el cuerpo del spec

Convierte esto en una especificación para un equipo de ingeniería. Funcionalidad: [descripción]. Estados de usuario a cubrir: [lista]. Devuelve: historias de usuario con criterios de aceptación, cada estado incluyendo vacío, cargando, error y permiso denegado, el comportamiento cuando una dependencia no está disponible, eventos de analítica con sus propiedades, y preguntas abiertas. No inventes requisitos que no indiqué. Enumera cualquier cosa que hayas tenido que asumir en una sección aparte al final.

Prompt: la pasada de crítica

Actúa como un ingeniero senior revisando este spec antes de la estimación. Enumera solo los problemas: comportamiento indefinido, estados faltantes, requisitos que se contradicen, trabajo de migración oculto, y cualquier cosa que vaya a generar una pregunta de seguimiento en el refinamiento. No reescribas el spec.

Ejecuta ese tercer prompt en un modelo que no haya escrito el spec. De forma fiable saca a la luz las tres preguntas que tu equipo plantearía de todos modos en el refinamiento, y responderlas de antemano es la diferencia entre una sesión de grooming de 20 minutos y una de 50.

Convertir feedback en bruto en algo que puedas priorizar

La tarea de IA de mayor palanca en la gestión de producto no es escribir. Es leer 400 piezas de feedback en una forma sobre la que puedas actuar. Hecho a mano es medio día. Hecho bien con un modelo son 20 minutos, y la calidad depende casi por completo de si obligas a usar categorías estables.

Prompt: primera pasada de categorización

Aquí tienes feedback de clientes en bruto. Agrúpalo en temas. Para cada tema devuelve: una etiqueta, el número de elementos, la severidad implícita en el lenguaje, una cita textual representativa copiada exactamente, y si el tema es un bug, una capacidad faltante, un problema de usabilidad o un desajuste de expectativas. No combines temas que tengan causas raíz distintas aunque el lenguaje sea parecido. No parafrasees citas. Feedback: [pega].

Prompt: segunda pasada contra una taxonomía fija

Reclasifica el mismo feedback usando solo estas categorías: [pega tu taxonomía existente]. Cualquier cosa que no encaje va a SIN CLASIFICAR con una explicación. Devuelve una tabla de categoría, número y porcentaje.

La estructura de dos pasadas importa. La primera pasada te dice qué hay realmente en los datos. La segunda hace que el resultado sea comparable con el trimestre anterior, que es lo que lo vuelve útil en una conversación de priorización y no solo interesante.

Qué pedir	Qué obtienes	Para qué sirve
Temas con conteos	Una lista ordenada de áreas problemáticas	Insumo de roadmap, planificación trimestral
Solo citas textuales	Lenguaje del cliente sin editar	Copy, posicionamiento, persuasión ejecutiva
Reparto de severidad y frecuencia	Un 2x2 de dolor contra volumen	Decidir qué arreglar primero
Contradicciones	Dónde los segmentos quieren cosas opuestas	Detectar un falso consenso a tiempo

Esa última fila merece un prompt fijo: ¿Dónde en este feedback distintos usuarios quieren cosas incompatibles? Nombra los segmentos y el trade off. Una lista de temas aplana el desacuerdo, y el desacuerdo suele ser lo más útil de los datos.

Discovery, competidores y la investigación para la que nunca hay tiempo

Discovery es el trabajo que se recorta primero cuando un lanzamiento va tarde, justo cuando una mala decisión es más cara. El escaneo asistido por modelos no reemplaza hablar con clientes, pero sí reemplaza la excusa de entrar a ciegas en una decisión.

Prompt: análisis de competidor

Arma un análisis de cómo [competidor] maneja [trabajo por hacer]. Cubre: su posicionamiento declarado en sus propias palabras, el flujo tal como está documentado en su centro de ayuda, precios donde sean públicos, qué cambió en los últimos 12 meses con fechas, y los temas de queja visibles en reseñas públicas. Cita cada afirmación con una URL. Separa lo que la empresa afirma de lo que observan terceros.

Prompt: síntesis de entrevistas

Lee estas transcripciones de entrevistas. Devuelve: los trabajos que los usuarios intentan lograr, las soluciones alternativas que han construido, los momentos donde expresaron frustración con citas exactas, y cualquier lugar donde lo que dijo un usuario contradiga lo que describió hacer. No generalices más allá de las transcripciones. Si un patrón aparece en menos de tres entrevistas, etiquétalo como una observación aislada y no como un patrón.

Esa última restricción es la que más olvidan los PMs. A los modelos les entusiasma producir patrones limpios, y un patrón limpio de dos entrevistas es cómo un roadmap termina sirviendo a un cliente que no existe. Pide conteos junto a cada afirmación.

Narrativa ejecutiva y comunicaciones de lanzamiento

El mismo contenido tiene que existir en cuatro altitudes: un spec para ingeniería, una actualización para el equipo, un párrafo para la revisión de liderazgo y una nota de lanzamiento para clientes. Reescribir entre altitudes es el trabajo más mecánico del puesto y el más fácil de delegar.

Prompt: cambio de altitud

Reescribe esto para [audiencia]. Les importa [preocupaciones específicas]. Tienen [nivel] de contexto sobre esta área del producto. Mantén cada afirmación factual idéntica. Longitud: [restricción]. Empieza con la decisión o el resultado, no con el trasfondo. Borrador: [pega].

Prompt: el párrafo de liderazgo

Comprime esta actualización en 120 palabras para un ejecutivo que la leerá una sola vez. Estructura: qué cambió, qué significa para la métrica a la que nos comprometimos, qué necesitamos de ellos, y el único riesgo que merece su atención. Sin adjetivos que no estén medidos.

Prompt: el pre mortem

Asume que este lanzamiento fracasó dentro de seis meses. Escribe las tres explicaciones más plausibles, ordenadas por probabilidad, usando solo lo que está en el plan de abajo. Para cada una, indica la señal temprana que podríamos vigilar. Plan: [pega].

Mantén las cuatro altitudes en el mismo hilo de Whizi. La nota de lanzamiento hereda el contexto del spec y del análisis de feedback, así que dejas de reexplicar la funcionalidad cada vez que cambias de audiencia.

Dónde la IA engaña a los product managers en particular

Tres modos de fallo importan más en este puesto que en la mayoría de los demás.

Citas textuales inventadas. Si pides citas representativas sin anclar al modelo al texto fuente, a veces obtendrás una frase plausible que ningún cliente dijo. Indica siempre copia las citas exactamente, no parafrasees, y verifica manualmente tres de ellas contra los datos en bruto antes de que una cita llegue a una diapositiva.

Falsa confianza por muestras pequeñas. Un modelo categorizará ocho tickets de soporte con exactamente la misma seguridad con la que categoriza ochocientos. Pide conteos en cada tema, y trata cualquier cosa por debajo de un puñado de instancias como una observación y no como una señal.

Teatro de roadmap. Pedirle a un modelo que priorice tu backlog produce un ranking confiado derivado de nada más que las palabras de tus tickets. No tiene acceso a tu estrategia, tu capacidad, tu deuda técnica ni al trato que cierra el próximo trimestre. Úsalo para estructurar el trade off, nunca para tomar la decisión.