Product Manager de IA: 3 pasos para convertirse en un Product Builder
Étienne Fénétrier es consultor sénior en el departamento de Producto. Tras un año en Converteo, ha dirigido proyectos de concepción, diseño y desarrollo de productos SaaS y de datos para usuarios profesionales.
Ideas clave:
- El Product Manager (PM) de IA ya no gestiona tareas: arbitra una cartera de apuestas estratégicas entre el valor operativo inmediato y la ventaja competitiva a largo plazo.
- La POC (Prueba de Concepto) ya no es una demostración técnica, es un experimento científico para reducir el riesgo de la inversión, no de la tecnología.
- La industrialización exige una nueva mentalidad: la del Product Builder, un arquitecto del valor que define la visión y lidera la ejecución.
La IA está transformando profundamente el rol del Product Manager. Gestionar un roadmap y redactar especificaciones —los pilares del PM tradicional— ya no es suficiente ante tecnologías probabilísticas, opacas y en constante evolución. El verdadero desafío es cerrar la brecha entre un prototipo impresionante y un producto robusto, adoptado y rentable.
La cifra es demoledora: casi el 95% de los proyectos de IA generativa nunca llegan a producción. Se quedan atrapados en el “purgatorio de las POC”, no por falta de capacidad técnica, sino porque se siguen gestionando como proyectos clásicos. Para triunfar, el PM debe evolucionar: aprender a construir. Aquí tienes los tres pasos para convertirte en el arquitecto del valor en la IA.
Paso 1 — El Product Manager de IA piensa como un inversor, no como un jefe de proyecto
La paradoja de la IA es que construir un prototipo es hoy algo trivial, pero crear un producto viable es exponencialmente difícil. Es la “ilusión del progreso”, y es la primera trampa.
El rol del Product Manager de IA ya no es planificar una secuencia de tareas. Es gestionar una cartera de apuestas estratégicas en un contexto de alta incertidumbre. Esto es precisamente lo que distingue al Product Builder del PM clásico: donde uno ejecuta un plan, el otro construye una tesis de inversión.
¿Valor operativo o ventaja competitiva sostenible?
Cada proyecto de ia debe ser evaluado según la naturaleza del valor que crea:
- Valor operativo: optimizar lo existente: hacerlo mejor, más rápido, más barato. Retorno de la inversión rápido, pero sin ventaja competitiva sostenible.
- Valor de capital: crear un activo que nadie más posee: un modelo propietario, un conjunto de datos único, una capacidad agéntica inédita. El impacto es a más largo plazo, pero construye el foso (moat) que protege a la empresa.
Una herramienta como el lienzo go / no-go para IA no sirve para priorizar tareas: sirve para enmarcar una conversación estratégica. Obliga a evaluar cada iniciativa según su viabilidad y su valor real, y a abandonar sin remordimientos los proyectos “pozo sin fondo”.
Paso 2 — Hacer de la prueba de concepto un instrumento de medida, no una demostración
Antes, la prueba de concepto era una demostración técnica destinada a tranquilizar a la dirección. Hoy, su papel se ha invertido.
La POC ya no es una herramienta de persuasión. Es una experiencia científica cuya misión es reducir la incertidumbre del negocio recopilando datos reales. Frente a un sistema probabilístico, es imposible predecir la reacción de los usuarios a priori.
Lo que el Product Manager de IA debe medir con su POC
El objetivo ya no es demostrar la viabilidad técnica (compatibilidad de las API, rendimiento de un modelo). Las verdaderas preguntas son:
- ¿Entienden los usuarios las respuestas del agente?
- ¿Confían en él aunque las respuestas no sean deterministas?
- ¿Cómo afecta realmente a su flujo de trabajo (workflow)?
Al transformar una idea abstracta en un artefacto palpable, la POC aporta lo que ninguna presentación teórica puede ofrecer: una primera prueba de valor de negocio. Aquí es donde el product builder cobra todo su sentido: no valida una tecnología, valida una hipótesis de valor. Ya no se trata de “reducir el riesgo técnico”, sino de reducir el riesgo de la inversión.
Paso 3 — El rol del Product Manager de IA en la industrialización
El paso a escala marca un cambio de postura importante. El product builder que tenía las manos en los prompts y las herramientas sin código debe tomar altura para convertirse en el guardián de la visión.
Su rol ya no es construir ladrillo por ladrillo, es asegurarse de que el edificio final corresponda al plano, que sea robusto y escalable. Esta es la etapa más crítica: aquí es donde la deuda técnica acumulada durante el prototipado puede hundir el proyecto.
El dosier de traspaso: un contrato de confianza
Este traspaso de responsabilidad debe formalizarse en un entregable central: el Plan de Transferencia o Handover. Este documento transforma el empirismo del prototipo en estándares de ingeniería, respondiendo a:
Un dosier de traspaso eficaz responde a cinco preguntas fundamentales:
- El porqué — La brújula del proyecto: valor esperado y caso de negocio.
- El comportamiento — El “contrato del prompt”: tono, reglas de interacción, personalidad del agente.
- El saber — El modelo de datos: pertinencia, calidad y gobernanza de las fuentes.
- La estructura — La arquitectura del agente: modularidad y escalabilidad.
- La validación — El conjunto de datos de oro (golden dataset): el conjunto de datos de referencia para medir el rendimiento de forma objetiva.
Sin este trabajo de arquitecto, el prototipo sigue siendo un artilugio brillante pero frágil.
Al dominar estos tres pasos —pensar como un inversor, experimentar con rigor, industrializar con método— el Product Manager de IA ya no se limita a gestionar un proyecto. Se convierte en lo que llamamos un Product Builder: el verdadero catalizador de la transformación de IA de su empresa.
