La IA: oportunidad y riesgo para el Product Owner
La inteligencia artificial está cambiando el trabajo del Product Owner de formas que aún estamos aprendiendo a gestionar. Y como ocurre con cualquier herramienta potente, viene con oportunidades reales y riesgos que conviene no ignorar.
La oportunidad es clara. El PO es un rol que vive entre la información y la decisión: sintetiza feedback, prioriza, comunica, negocia y define. Todas esas actividades tienen algo en común: requieren estructurar el pensamiento antes de actuar. Y ahí es exactamente donde la IA puede añadir valor, ayudando a organizar lo que se sabe, anticipar lo que falta y formular mejores preguntas.
El riesgo también es real. Un PO que delega en la IA la definición de criterios de aceptación sin revisarlos, o que usa un resumen automático de entrevistas sin volver a las notas originales, está tomando decisiones de producto sobre una base que no ha verificado. La IA no conoce al usuario, no ha estado en la reunión y no entiende el contexto político de la organización. Eso lo sabe el PO.
Hay además un riesgo más sutil. Con la IA generando funcionalidades, historias de usuario y roadmaps en segundos, algunos equipos pueden caer en la trampa de construir más y descubrir menos. Más velocidad de entrega no es lo mismo que más valor entregado. El Product Owner que entiende esta diferencia tiene una ventaja enorme sobre el que no.
Lo que define el valor no es la herramienta, sino el criterio con el que se usa. Los cinco casos que siguen muestran cómo se ve eso en la práctica.
Prompt 1 — Refinamiento y escritura de PBIs
El contexto
Marta acaba de asumir el rol de Product Owner en un equipo de desarrollo de software para el sector salud. El backlog que hereda tiene 60 ítems: algunos son épicas sin descomponer, otros son tareas técnicas sin contexto de negocio y varios son frases sueltas que nadie recuerda de dónde vienen. El Sprint Planning es en tres días. Marta necesita rescatar al menos los diez ítems más prioritarios y dejarlos en condiciones de ser trabajados por el equipo.
El prompt
Actúa como un Product Owner experto en escritura de historias de usuario y criterios de aceptación. Te voy a pasar un ítem del backlog tal como está redactado ahora, junto con el contexto de negocio que conozco sobre él. Necesito que me ayudes a transformarlo en una historia de usuario bien estructurada.
Ítem original: "Mejorar el proceso de alta de pacientes" Contexto: los médicos se quejan de que el formulario de alta tarda demasiado y tiene campos redundantes. El objetivo es reducir el tiempo de alta para que puedan atender a más pacientes por turno.
Por favor: (1) redacta la historia de usuario en formato "Como… quiero… para…", (2) propón entre tres y cinco criterios de aceptación concretos y verificables, (3) identifica qué información me falta para completarla correctamente, (4) sugiere si este ítem debería descomponerse en historias más pequeñas y por qué, y (5) recomienda qué técnica de análisis del flujo (como un User Journey, un Service Blueprint u otra que consideres útil) me ayudaría a entender mejor el contexto antes de refinarlo, y genera un esquema mínimo de esa técnica aplicado a este caso.
Qué pasó
La IA reformuló el ítem como una historia centrada en el médico, propuso criterios de aceptación medibles e identificó dos preguntas clave que Marta no se había hecho. Además, recomendó un User Journey del proceso de alta con cinco pasos —solicitud, validación clínica, cumplimentación del formulario, aprobación y registro— señalando en cuáles había más fricción según el contexto descrito.
Marta usó ese esquema para una conversación de diez minutos con un médico antes del Planning. Llegó con una historia mucho más precisa y el equipo no tuvo que interrumpir el Sprint para pedir aclaraciones.
Prompt 2 — Toma de decisiones de priorización
El contexto
Carlos es PO en una empresa de software B2B con tres stakeholders que tiran en direcciones distintas. El Director Comercial necesita una funcionalidad de exportación de informes para cerrar un contrato importante. El CTO quiere dedicar el próximo Sprint a refactorizar el módulo de autenticación antes de que cause problemas en producción. El CEO ha pedido acelerar la hoja de ruta para llegar antes a un mercado nuevo. Carlos tiene capacidad para una sola línea de trabajo y necesita defender su decisión con argumentos que vayan más allá de "es mi criterio".
El prompt
Actúa como un consultor experto en priorización de producto en entornos B2B. Tengo tres peticiones en competencia para el próximo Sprint y necesito ayuda para estructurar mi decisión y comunicarla con criterios objetivos.
Las tres opciones son: (1) funcionalidad de exportación de informes, solicitada por el Director Comercial para cerrar un contrato; (2) refactorización del módulo de autenticación, solicitada por el CTO por riesgo técnico; (3) adelantar funcionalidades del roadmap para entrar en un mercado nuevo, solicitado por el CEO.
Ayúdame a: (1) definir qué criterios debería usar para comparar estas opciones de forma objetiva (impacto, urgencia, riesgo, coste de no hacerlo…), (2) aplicar esos criterios a cada opción con la información que tengo, (3) identificar qué información me falta para decidir con más seguridad, y (4) preparar el argumento para comunicar la decisión a los tres stakeholders sin que ninguno sienta que ha "perdido".
Qué pasó
La IA propuso un marco de cuatro criterios: impacto en ingresos a corto plazo, coste del riesgo si no se actúa, reversibilidad de la decisión y alineación con la estrategia trimestral. Aplicados a los tres casos, el resultado apuntaba a la refactorización como prioridad, pero con una condición: comprometer la exportación de informes para el Sprint siguiente con una fecha concreta.
Carlos usó ese argumento en la reunión. El Director Comercial aceptó cuando entendió que el riesgo técnico podía afectar al cliente que quería cerrar. Fue la primera vez que una conversación de priorización terminó sin tensión.
Prompt 3 — Comunicación con stakeholders
El contexto
Elena es PO en una empresa de retail digital. Hace tres Sprints, el equipo se comprometió a entregar un rediseño del proceso de checkout antes del inicio de la campaña de verano. A mitad del trimestre, negocio cambió de prioridades y ese trabajo quedó aparcado. Ahora la campaña está a dos semanas y el Director de Marketing acaba de preguntar cuándo estará listo el checkout. Elena tiene que dar una respuesta que sea honesta, que no genere una crisis de confianza y que no señale a nadie como responsable del cambio.
El prompt
Actúa como un experto en comunicación de producto con stakeholders no técnicos. Necesito preparar una conversación difícil con el Director de Marketing de mi empresa.
La situación: hace tres meses se acordó entregar un rediseño del checkout antes de la campaña de verano. A mitad del trimestre, la dirección decidió redirigir al equipo hacia otra prioridad. Ese cambio fue una decisión de negocio, no un fallo del equipo. Ahora el Director de Marketing espera el checkout y no está al tanto del cambio de prioridades.
Ayúdame a: (1) estructurar cómo explicar la situación con honestidad sin generar alarma ni señalar responsables, (2) anticipar las reacciones más probables y cómo responderlas, (3) proponer qué alternativa o compensación puedo ofrecer para minimizar el impacto en la campaña, y (4) definir cómo cerrar la conversación con un compromiso claro hacia adelante.
Qué pasó
La IA le ayudó a Elena a reformular el mensaje: en lugar de "no lo hemos podido hacer", el encuadre pasó a ser "el equipo ejecutó la prioridad que se decidió en el comité, y ahora necesitamos decidir juntos cómo gestionar el impacto". Le propuso además una alternativa concreta: una versión parcial del checkout con las mejoras de mayor impacto en conversión, entregable en diez días.
El Director de Marketing no estaba contento, pero la conversación fue profesional y terminó con un plan. Elena salió con un acuerdo, no con una queja abierta.
Prompt 4 — Construir un mapa de métricas desde cero
El contexto
Javier es PO de una aplicación de gestión de gastos para equipos. Su empresa acaba de definir un OKR para el trimestre: "aumentar la retención de clientes en un 15%". Javier tiene una lista de funcionalidades planificadas, pero no tiene ninguna métrica definida para saber si lo que está construyendo contribuye al objetivo. No hay dashboards, no hay datos históricos de uso y el equipo nunca ha medido nada de forma sistemática. Javier necesita un punto de partida.
El prompt
Actúa como un experto en métricas de producto y diseño de sistemas de medición. Tengo un OKR trimestral y una lista de funcionalidades planificadas, pero no tengo ninguna métrica definida. Necesito construir un mapa de métricas sencillo que me permita saber si lo que estoy construyendo está generando el impacto esperado.
OKR: aumentar la retención de clientes en un 15% este trimestre. Funcionalidades planificadas: (1) recordatorios automáticos de gastos pendientes, (2) resumen semanal por email del estado del equipo, (3) integración con Slack para aprobar gastos sin entrar en la app.
Siguiendo un modelo de tres niveles, ayúdame a definir: (1) métricas de producto: qué puedo medir directamente en la aplicación para saber si cada funcionalidad se usa como esperaba, (2) resultado para el usuario: qué cambio de comportamiento o experiencia debería producirse si la funcionalidad funciona bien, y (3) resultado para la empresa: cómo se conecta ese comportamiento del usuario con el OKR de retención.
Propón entre dos y tres métricas por nivel, explica la lógica de conexión entre niveles y señala cuáles son las más críticas para empezar a medir.
Qué pasó
La IA construyó un mapa coherente. Para los recordatorios automáticos, por ejemplo, propuso medir la tasa de apertura y acción sobre el recordatorio (métrica de producto), la reducción de gastos enviados fuera de plazo (resultado para el usuario) y la reducción de fricciones en el proceso de cierre mensual como señal de retención (resultado para la empresa).
Javier no tenía todos los datos para medirlo desde el primer día, pero el mapa le dio claridad sobre qué instrumentar primero y, sobre todo, una forma de hablar con su equipo sobre el valor de lo que estaban construyendo más allá de si la funcionalidad "estaba lista" o no.
Prompt 5 — Convertir insights en hipótesis
El contexto
Sara acaba de terminar una ronda de cinco entrevistas con usuarios de su producto, una plataforma de formación online para empresas. Tiene quince páginas de notas, algunas frases textuales de los usuarios, varias contradicciones entre lo que unos y otros han dicho y una sensación general de que "hay algo importante ahí" pero no sabe cómo articularlo. El backlog refinement es mañana y necesita llegar con algo concreto.
El prompt
Actúa como un investigador de producto experto en síntesis de entrevistas de usuario. Te voy a pasar fragmentos de notas de cinco entrevistas. Necesito que me ayudes a convertirlos en hipótesis concretas y priorizables que pueda llevar al backlog.
Fragmentos de las entrevistas: — "Nunca sé si mis empleados están haciendo los cursos o no hasta que llega el informe mensual, y para entonces ya es tarde." — "Lo uso porque me lo piden, pero no entiendo para qué sirve la mitad de las opciones." — "El problema no es el contenido, es que no puedo asignar cursos por equipos, solo por personas." — "A veces entro y no sé por dónde empezar." — "Me gustaría que me avisara cuando alguien lleva más de dos semanas sin entrar."
Por favor: (1) identifica los patrones o necesidades recurrentes que aparecen en estos fragmentos, (2) formula entre tres y cinco hipótesis en formato "Creemos que [usuario] necesita [capacidad] para poder [resultado esperado]", (3) ordénalas por potencial impacto percibido, y (4) señala qué habría que validar antes de llevar cada hipótesis al backlog.
Qué pasó
La IA identificó dos patrones principales: falta de visibilidad sobre el progreso del equipo en tiempo real y complejidad percibida de la interfaz para usuarios administradores. Formuló cuatro hipótesis, siendo la más prioritaria: "Creemos que los responsables de formación necesitan alertas proactivas sobre inactividad para poder intervenir antes de que un empleado abandone un curso."
Sara llevó esa hipótesis al refinement con una propuesta concreta: una funcionalidad de alertas configurables antes de invertir en rediseñar la interfaz. El equipo la debatió en veinte minutos y la añadió al backlog con criterios de aceptación claros. Sin la síntesis, Sara habría llegado con quince páginas de notas y ninguna conclusión.
Lo que estos cinco casos tienen en común
La IA no tomó ninguna decisión de producto. No sabe qué usuario importa más, qué stakeholder tiene más poder ni qué funcionalidad va a generar más valor. Eso lo sabe el Product Owner.
Lo que hizo fue ayudar a transformar información en estructura: notas en hipótesis, opciones en criterios, situaciones difíciles en argumentos. En todos los casos, el valor real ocurrió después, en la conversación con el equipo, con el stakeholder o en la decisión de backlog.
Tres aprendizajes que vale la pena retener.
1️⃣ El contexto que das es el límite del resultado que obtienes. Un prompt con el OKR, las funcionalidades y el punto de partida real produce un mapa de métricas útil. El mismo prompt sin contexto produce una lista genérica de KPIs que podría aplicar a cualquier producto del mundo.
2️⃣ La IA es mejor preparando que decidiendo. En todos los casos sirvió para llegar mejor preparado a una conversación o una decisión. No para sustituirla. El Product Owner que confunde las dos cosas acabará tomando decisiones sobre bases que no ha verificado.
3️⃣ Usar IA con criterio es ya parte del rol. No como obligación ni como tendencia, sino como competencia. Saber cuándo un prompt ahorra dos horas de trabajo y cuándo es mejor hablar directamente con un usuario es, en sí mismo, un juicio de producto.
Este post forma parte de una serie sobre el rol de los equipos ágiles en la era de la IA. Si te ha resultado útil, puede interesarte también [5 prompts que potenciarán tu trabajo como Scrum Master] y los cursos [PSM-AIE] y [PSPO-AIE] disponibles en itnove.com.