Español

La IA en el flujo de trabajo del gerente de producto: dónde ayuda y dónde falla

Cada herramienta de PM ahora tiene un interruptor de "IA". Notion AI redacta su PRD. Linear resume su sprint. Productboard extrae temas del feedback. Jira escribe los criterios de aceptación. El interruptor está en todas partes, y la mayoría de lo que sale de él es mediocre. Especificaciones mediocres que los ingenieros dejan de leer para la tercera semana. Resúmenes de investigación mediocres que aplanan la única cita extraña que en realidad era el insight. Priorizaciones mediocres que clasifican con confianza funcionalidades que nadie pidió.

El PM que copia y pega el borrador de PRD de Notion AI en Jira es el PM cuyo equipo de ingeniería deja de leer los PRD en silencio. He visto que esto sucede en tres equipos en el último año. El patrón es idéntico: el PM se vuelve más rápido, el equipo de ingeniería se vuelve más silencioso, y seis semanas después alguien lanza lo equivocado porque la especificación fue escrita por un modelo que nunca ha conocido a un cliente.

Así que este es el encuadre honesto. La IA es una herramienta de palanca para la parte aburrida de su flujo de trabajo. No sustituye las dos cosas por las que realmente le pagan: el criterio y la verdad del cliente. El resto de este artículo es la visión de un PM en activo sobre dónde la IA se gana su lugar, dónde definitivamente no, los patrones de flujo de trabajo que resisten bajo presión, y un plan de 30 días para desarrollar el músculo.

Dónde ayuda la IA (úsela a diario)

La parte aburrida es real. Es el 60% del trabajo del PM que consiste en síntesis mecánica, redacción, escaneo y verificación de patrones. La IA es excelente en esto cuando la mantiene con la correa corta.

Síntesis de transcripciones de entrevistas. Este es el punto de mayor ROI por donde empezar. Tome una transcripción de Gong o Grain, pegue el texto completo en Claude (no un resumen, el texto completo) y pida citas textuales agrupadas por un tema específico. La estructura de prompt que funciona: "Extrae citas textuales sobre objeciones de precio de esta transcripción. Agrupa por persona si hay varios participantes. No parafrasees. Si un participante matiza algo, incluye el matiz." Esa última frase importa, porque los modelos tienden por defecto a hacer resúmenes confiados y usted pierde la textura.

Borradores de especificaciones. Un primer borrador de historias de usuario, casos límite y criterios de aceptación, a partir de un brief estructurado que usted mismo escribió. El brief es el trabajo. El borrador es solo escribir a máquina. Si le proporciona su planteamiento del problema, sus suposiciones sobre el modelo de datos y sus tres casos límite conocidos, le devolverá un andamiaje utilizable. Aun así reescribirá la mitad. Está bien. Se ahorró la mitad que no reescribió.

Escaneos competitivos. Vuelque ocho changelogs de competidores en un modelo y pida un diff frente a su roadmap. Pregunte cuál de sus lanzamientos alcanza a un segmento de clientes al que usted también atiende. Este es trabajo pesado que solía comerse medio viernes. Ahora se come 20 minutos y usted dedica el resto del tiempo a decidir qué hacer al respecto, que es el verdadero trabajo.

Texto de variantes para fake door. ¿Generar seis titulares de landing page para un A/B test? Bien. ¿Generar la estrategia detrás de cuál fake door ejecutar? No tan bien. El modelo es bueno en la superficie, malo en la elección. Úselo para la superficie.

Verificación de cordura del análisis de cohortes. Pegue una tabla de resultados de SQL y pregunte "¿qué falta aquí, qué objetaría un científico de datos escéptico?". No está pidiendo análisis. Está pidiendo un segundo par de ojos para ver si su cohorte está contaminada, su ventana temporal es rara, o su filtro está excluyendo a la población que importa. Detecta cosas tontas. Eso vale la pena.

Dónde falla la IA (haga esto usted mismo, siempre)

Esta es la parte que la mayoría de los artículos de "IA para PMs" se saltan, porque no vende herramientas. Pero esta es la parte que determina si conserva su empleo en dos años.

Encuadre del problema. La única frase que dice "qué estamos resolviendo en realidad y para quién" es su trabajo. Siempre. Un modelo producirá un encuadre que suena fluido y que se parece a todos los demás encuadres que ha leído. El suyo tiene que ser específico para sus clientes, sus datos, su momento en el mercado. Si su encuadre se lee como si pudiera aplicarse a cualquier empresa de su categoría, ha tercerizado la frase más importante de la especificación.

Pesos de priorización. Los números de RICE e ICE que salen de un LLM son pura intuición. El número de alcance viene de una conversación real con marketing sobre qué segmento van a apuntar el próximo trimestre. El número de esfuerzo viene de una conversación de 10 minutos con su líder técnico. El número de confianza viene de cuántos clientes ha hablado realmente sobre esto. Ninguno de esos números existe en los datos de entrenamiento de un modelo para su roadmap específico. Si deja que la IA genere las puntuaciones, ha automatizado la parte menos valiosa de la priorización (la matemática) y se ha saltado la más valiosa (las conversaciones de compensación que produjeron los datos de entrada).

Verdad del cliente. Nunca deje que la IA resuma 12 entrevistas en 3 temas sin que usted lea las transcripciones en bruto. Los modelos comprimen hacia la mediana. El verdadero insight es casi siempre el valor atípico: el único cliente que dijo algo que nadie más dijo, de una manera que replanteó su suposición. La compresión mata los valores atípicos. Lea las transcripciones. Use la IA para extraer citas, no para extraer conclusiones.

Decisiones de criterio sobre recortes de alcance. Un modelo puede enumerar todas las opciones para recortar alcance antes de una fecha límite. No puede sostener la sala cuando ingeniería está cansada, diseño está a la defensiva, y el GM quiere el compromiso original. Eso no es un problema de prompt. Es un problema de "tiene que estar realmente ahí".

Patrones de flujo de trabajo que sí funcionan

Unos pocos patrones que ejecuto semanalmente. Ninguno es ingenioso. La gracia es que son aburridos y repetibles.

Gong/Grain más Claude para síntesis de entrevistas. El patrón exacto: grabe la llamada (Gong si es una llamada de discovery vinculada a ventas, Grain si es investigación pura). Tome la transcripción completa. Péguela en una conversación nueva de Claude. Use un prompt de extracción ajustado, no un prompt de resumen. Verifique leyendo la transcripción original para las dos o tres mejores citas que el modelo haya sacado a la luz. Si el modelo parafraseó algo material, descarte el resultado y vuelva a hacer el prompt con un lenguaje más estricto. El paso de verificación es el trabajo. Sáltelo y citará a un cliente diciendo algo que no dijo, lo cual es un movimiento que arruina la carrera en una presentación a las partes interesadas.

Un prompt que se gana su lugar, textual:

Estás extrayendo citas de la transcripción de una entrevista con un cliente. Voy a pegar la transcripción a continuación. Tu tarea: extrae cada cita directa donde el participante mencione precio, presupuesto o adquisición. No parafrasees. No resumas. Conserva exactamente los matices, las muletillas y las contradicciones del participante. Devuélvelo como una lista con viñetas con la marca de tiempo si está disponible. Si no hay citas relevantes, di "no se encontraron citas" y no inventes.

La línea de "no inventes" importa. Sin ella, los modelos alucinan citas que suenan plausibles.

Cursor como acelerador de especificaciones. Útil solo cuando su equipo de ingeniería también lo usa. Cursor (o cualquier herramienta de codificación con IA en pareja que el equipo haya adoptado) significa que los ingenieros leen su especificación mientras redactan código en el mismo editor. Si ellos lo usan y usted no, su especificación se desvía de cómo se escribe el código en realidad. Si ninguno de los dos lo usa, está bien, escriba las especificaciones a la vieja usanza. La trampa es el PM que lo usa en solitario y asume que el equipo de ingeniería experimenta la especificación igual que usted. Pregunte. Iguálese a su flujo de trabajo.

La trampa del "PRD escrito por IA". Los ingenieros detectan un PRD falso al instante. Las señales: casos límite genéricos ("manejar fallos de red con elegancia"), criterios de aceptación que suenan bien pero pasan por alto el modelo de datos real ("el usuario puede guardar sus preferencias"), y una ausencia sospechosa de los detalles desordenados que vienen de usar el producto de verdad. La prueba del olfato: si no puede defender cada línea de la especificación en el standup, bórrela antes del standup.

Una lista de verificación de la prueba del olfato para un PRD que vale la pena ejecutar antes de entregar el documento:

  • ¿Puedo nombrar al cliente que pidió esto y citarlo?
  • ¿Puedo dibujar el modelo de datos en una pizarra sin notas?
  • ¿Mis casos límite hacen referencia a nuestros estados de error reales, no a unos genéricos?
  • ¿Enumeré al menos una cosa que explícitamente no vamos a construir, y por qué?
  • ¿Mi líder técnico leería esta especificación y aprendería algo que aún no sabía?

Si alguna respuesta es no, la especificación es demasiado endeble. La IA no le ayudó. Le ayudó a lanzar un borrador que no puede defender.

La lente del marco ACE (opcional)

Si lee suficientes presentaciones de estrategia, se topará con el marco ACE: Ingest, Analyze, Predict, Generate, Execute. Los PMs se sitúan más cerca de Analyze y Generate (síntesis y redacción). Ahí es exactamente donde vive la palanca de este artículo. Ingest (la fontanería de datos, ETL, pipelines de embeddings) suele pertenecer a la ingeniería de datos. Execute (la automatización del flujo de trabajo que corre sin un humano en el bucle) suele pertenecer a operaciones o a plataforma.

No necesita memorizar esto. Pero vale la pena conocer el vocabulario, porque en el momento en que las funcionalidades de IA aterricen en su roadmap, sus líderes de ingeniería y su equipo de datos usarán estas palabras. Se ahorrará una reunión si ya sabe qué capacidad está comprando frente a la que está construyendo.

Su plan de 30 días para desarrollar el músculo

Cuatro semanas. Un flujo de trabajo a la vez. Sin dispersión de herramientas. La gracia es construir un pequeño conjunto de movimientos repetibles en los que confíe bajo la presión de las fechas límite.

Semana 1: elija un flujo de trabajo y ejecútelo dos veces. La síntesis de transcripciones es el punto de mayor ROI por donde empezar. Elija una entrevista con cliente de esta semana. Sintetícela primero de forma manual. Lea la transcripción, anote las tres cosas que le sorprendieron, enumere las citas textuales que las respaldan. Luego pase la misma transcripción por Claude con un prompt de extracción. Compare. Aprenderá dos cosas: dónde añade velocidad el modelo, y qué descarta en silencio. Ambas importan.

Semana 2: escriba su propia biblioteca de prompts. De cuatro a seis prompts, con control de versiones en un documento compartido. Uno para extracción de transcripciones. Uno para andamiaje de especificaciones a partir de un brief. Uno para escaneo competitivo. Uno para verificación de cordura de SQL. Quizás uno para variantes de texto de fake door. Eso es todo. Si tiene más de seis prompts, está coleccionando herramientas en lugar de usarlas. Cada prompt debe tener un formato de entrada claro, un formato de salida claro, y una nota de una línea sobre qué verificar antes de confiar en el resultado.

Semana 3: muéstreselo a un compañero de equipo. Entregue sus prompts a otro PM o a su líder técnico. Pídales que usen uno en una tarea real. Si no pueden replicar su resultado sin que usted esté encima, el prompt es demasiado frágil. Los prompts frágiles son un único punto de fallo. El día que esté enfermo, su flujo de trabajo se detiene. Ajuste el prompt hasta que sea transferible.

Semana 4: auditoría. Dos columnas. Columna izquierda: lo que la IA le ahorró este mes (horas, decisiones aceleradas, borradores que no tuvo que escribir). Columna derecha: lo que le costó en confianza con ingeniería, con los clientes, con su propio criterio. Sea honesto. Si un prompt produjo una especificación que ingeniería objetó, anótelo. Si una síntesis pasó por alto un valor atípico que detectó después, anótelo. Recorte lo que no se ganó su lugar. Conserve lo que sí. Ahora tiene un flujo de trabajo, no una corazonada.

Probé una versión de esto en un ciclo de discovery el trimestre pasado. La semana 1 estaba receloso. Para la semana 3 había recortado mi tiempo de síntesis de entrevistas aproximadamente a la mitad, pero me sorprendí a punto de lanzar un resumen de temas que no había verificado contra las transcripciones en bruto. En la auditoría de la semana 4, el prompt de síntesis se quedó. El prompt de "resumir 12 entrevistas en temas" se eliminó. Ese es el músculo.

El argumento de cierre silencioso

Los PMs que ganarán en los próximos dos años no son los que usan más IA. No son los que tienen el stack de herramientas más largo ni la biblioteca de prompts con más estrellas en Notion. Son los que saben exactamente dónde la IA deja de funcionar y protegen esas partes del trabajo. El encuadre del problema. Los pesos de priorización. La verdad del cliente. Las decisiones de criterio bajo la presión de las fechas límite.

Todo lo demás es terreno libre. Use las herramientas. Ahorre el tiempo. Pero invierta el tiempo que ahorre en las partes del trabajo que un modelo no puede hacer: sentarse con un cliente hasta que entienda de verdad lo que está diciendo, pelear por el recorte de alcance correcto en la sala, escribir la única frase en la parte superior de la especificación que hace coherentes las próximas 12 semanas del equipo.

Ese es el trabajo. La IA es una palanca, no un sustituto.

Más información