Comunidad
28/10/2026 | Canal De Producto
El término "AI Product Owner" ha pasado de la nada a aparecer en cientos de ofertas de empleo en apenas un año, y con él ha vuelto una pregunta que reaparece con cada ola tecnológica: ¿viene la IA a sustituir al product owner o a transformarlo? La conversación del sector oscila entre dos extremos poco útiles: el pánico de quien teme quedar obsoleto y el entusiasmo de quien promete que la IA hará el trabajo por nosotros. Ninguno describe bien lo que está pasando.
Cuando preguntamos "¿la IA sustituye al product owner?", asumimos que el rol equivale a la suma de sus tareas visibles: escribir historias, mantener el backlog, redactar criterios de aceptación, resumir feedback. Si la IA puede hacer todo eso, la conclusión parece obvia. Pero esa ecuación confunde el rol con su parte más automatizable.
Un product owner no existe para producir artefactos. Existe para asegurar que el equipo construye lo correcto: para representar el valor, decidir qué merece hacerse y qué no, y sostener esas decisiones ante stakeholders con intereses enfrentados. Los artefactos son el rastro visible de ese trabajo, no el trabajo en sí. Automatizar la producción del rastro no automatiza el juicio que lo genera.
Aquí conviene una distinción que Marty Cagan lleva años defendiendo y que retomó con fuerza en Transformed (2024): hay una diferencia enorme entre un PO que actúa como administrador de backlog y un PO que ejerce dirección de producto real. La IA amenaza directamente al primero. Al segundo lo transforma. Y esa distinción, que ya era importante antes, se ha convertido en la línea que separa a quien la tecnología deja atrás de quien la aprovecha.
Seamos concretos, porque el debate abstracto no ayuda a nadie. ¿Qué partes del trabajo de un PO está asumiendo hoy la IA de forma efectiva?
La redacción de historias de usuario deja de ser un ejercicio de página en blanco: a partir de la descripción de una funcionalidad, un modelo puede proponer un desglose en historias y borradores de criterios de aceptación. La síntesis de feedback disperso que antes consumía días, se resuelve en minutos con una agrupación temática razonable. En el refinamiento, la IA sugiere dependencias, rangos de estimación basados en histórico y casos límite que a menudo se nos escapan. Y el roadmapping se vuelve más dinámico: recalcular prioridades ante un cambio de contexto ya no exige rehacer hojas de cálculo a mano.
Según Scaled Agile, aplicar estas técnicas puede reducir de forma sustancial el tiempo de redacción de historias y liberar al PO de buena parte de la "deuda administrativa" que hoy le come la agenda. Las cifras concretas que manejan las consultoras conviene tomarlas con cautela, pero la dirección es difícil de discutir: una porción grande del trabajo operativo del PO es automatizable, y se está automatizando.
Nada de esto es menor. Si la IA absorbe el trabajo de bajo valor, el PO recupera tiempo para lo que siempre debió ser el centro de su rol y que la urgencia operativa devoraba. La pregunta interesante no es si la IA hace estas tareas, sino qué hacemos con el tiempo que libera.
Hay una idea que resume bien el límite, y viene del propio análisis del trabajo con agentes: detectar una señal no es lo mismo que decidir qué significa. Un modelo puede identificar que una funcionalidad se pide mucho; no puede decidir si construirla es una buena idea para este producto, este momento y esta estrategia. Puede recomendar una priorización con un método como RICE; el trade-off lo sigue asumiendo una persona que responde por ello.
Esto conecta con algo que en Scrum Manager está en la base de la práctica sólida, lo que la guía Agile Bedrock recoge como fundamentos de agilidad de equipo: la agilidad no consiste en producir incrementos, sino en descubrir y entregar valor con criterio. La IA cambia las herramientas con las que hacemos ese trabajo; no cambia su naturaleza ni la responsabilidad de decidir.
Melissa Perri lo advertía antes de que existieran estos modelos, en Escaping the Build Trap (2018): las organizaciones caen en la trampa de medir su éxito por la cantidad de funcionalidades entregadas en lugar de por el valor generado. La IA, usada sin criterio, es un acelerador de esa trampa. Nunca ha sido tan fácil producir historias, prototipos y funcionalidades; y por eso nunca ha sido tan barato construir cosas que no había que construir. El cuello de botella se desplaza: ya no es la capacidad de producir, sino la calidad del juicio sobre qué merece producirse.
Si la IA absorbe la ejecución, ¿en qué se convierte el PO? La metáfora que se está imponiendo en el sector es la del orquestador: alguien que ya no toca todos los instrumentos, sino que dirige un conjunto de capacidades hacia un resultado coherente.
Orquestar con criterio exige competencias que hasta hace poco no formaban parte del perfil. El Institute of AI Product Management, tras analizar más de doscientas ofertas de este perfil emergente en 2026, identifica tres que se repiten y que antes no aparecían juntas en ningún rol. La primera es la especificación del comportamiento de un sistema de IA: escribir con precisión qué debe hacer y qué no, en un lenguaje que tanto ingeniería como negocio puedan verificar. La segunda es el diseño de la evaluación: definir cómo sabremos si el sistema se comporta bien, con qué datos y con qué umbrales. La tercera es el diseño de la supervisión humana: decidir dónde tiene que intervenir una persona y cómo, sin convertir ese control en un cuello de botella.
Hay aquí un cambio conceptual profundo. Los criterios de aceptación de una funcionalidad tradicional son deterministas: el botón se pone azul al pulsarlo, la API devuelve un 200. Los de una funcionalidad con IA son probabilísticos: el modelo debe acertar en un porcentaje de casos, no debe inventar datos, no debe ejecutar cierta acción sin aprobación humana. Escribir buenos criterios de aceptación probabilísticos es una habilidad nueva y es, en el fondo, dirección de producto: decidir qué nivel de error es tolerable es una decisión de valor y de riesgo, no una cuestión técnica.
Conviene ser críticos con la propia narrativa de la orquestación, porque tiene una versión perezosa y peligrosa: la del PO que se limita a pulsar el botón, aceptar lo que el modelo propone y pasar al siguiente ticket. Ese PO no ha ascendido a orquestador; ha delegado su juicio en una herramienta que no responde por las consecuencias.
El problema, como observa Bartosz Jaworski al analizar el impacto de la IA en producto, es que la IA no reemplaza el rigor: amplifica los huecos que ya existen en él. Un equipo con fundamentos débiles que adopta IA no se vuelve más sólido; produce sus errores más rápido y con mejor apariencia. La fluidez de un texto generado nos invita a bajar la guardia justo cuando deberíamos subirla, porque la plausibilidad de la salida no garantiza su acierto.
Por eso la orquestación con criterio descansa sobre los fundamentos, no los sustituye. Solo un PO que entiende de verdad a sus usuarios, que sabe distinguir valor de actividad y que reconoce un mal criterio de aceptación cuando lo ve puede dirigir a la IA en lugar de ser dirigido por ella. Los fundamentos son precisamente lo que permite que la velocidad de la IA sea una ventaja y no un multiplicador del caos.
Toca honestidad, sin adornos. Algunos POs sí están en riesgo real: aquellos cuyo trabajo se reducía a administrar el backlog, a traducir peticiones en tickets sin ejercer criterio. Esa función se automatiza, y pretender lo contrario no ayuda a nadie.
Pero el panorama es más matizado que un simple "la IA elimina POs". Está surgiendo un perfil nuevo que no es un mero cambio de nombre, sino un rol con acento propio: definir el comportamiento de sistemas de IA, diseñar su evaluación, decidir dónde vive la supervisión humana. Según el análisis de ofertas del Institute of AI Product Management, se concentra sobre todo en organizaciones que despliegan IA en sus operaciones internas, más que en startups nativas de IA. Y sigue habiendo, más necesaria que nunca, la dirección de producto de siempre: entender el problema correcto, representar el valor, sostener las decisiones difíciles. Lo que se está evaporando no es el rol, sino la versión del rol vaciada de juicio.
La conclusión, para cada profesional, es personal e incómoda: la pregunta no es "¿me sustituirá la IA?", sino "¿qué parte de mi trabajo era juicio y qué parte era tarea?". Quien vivía de la tarea tiene motivos para preocuparse. Quien ejerce criterio tiene, por primera vez, una herramienta que le devuelve el tiempo para ejercerlo mejor.
"Era de la orquestación" es una etiqueta atractiva y, como toda etiqueta, corre el riesgo de convertirse en eslogan vacío. Pero apunta a algo real: el centro de gravedad del rol de producto se está desplazando de la ejecución al criterio. La IA cambia el cómo, pero no toca el porqué: por qué construimos algo, para quién y a costa de qué.
Quizá la mejor forma de prepararse no sea acumular herramientas, sino reforzar los fundamentos que hacen que un juicio sea bueno. Porque un orquestador sin oído no dirige una orquesta: solo agita la batuta más rápido. Y en un momento en que producir es trivial, el criterio de producto (el oído) es lo único que no se puede automatizar.
¿Dónde te sitúas tú? ¿Sientes que la IA te está liberando para hacer mejor dirección de producto, o que te empuja hacia un papel de validador de lo que propone la máquina?
Si quieres entrenar y acreditar tu criterio en este terreno, la skill IA aplicada al trabajo ágil de Skill Arena está pensadas justo para esta transición.
Este tema no tiene comentarios.