Image It's Monday morning. Over the weekend, an AI system read every support ticket from the last quarter, every sales-call transcript and every competitor's release notes.
Image It's Monday morning. Over the weekend, an AI system read every support ticket from the last quarter, every sales-call transcript and every competitor's release notes.
The memo is good. Better, honestly, than what most of us would have produced in the same week. Then a stakeholder forwards it with one question: "What does the Product Owner add here?"
In my Professional Scrum Product Owner – AI Essentials classes, I hear some version of that question more and more. Usually it is framed as "Will AI replace Product Owners?" I think that framing misses the point. Today's AI is no longer just a tool that saves the Product Owner a few hours. For much of the work that fills a Product Owner's week, it is a candidate for the job.
So the more useful question for our community is this: if artificial general intelligence, or something close to it, can do most Product Owner tasks, what does Scrum say the Product Owner is still for?
The Scrum Guide was never about the tasksRead the Product Owner section of the Scrum Guide again with AI in mind. It describes one accountability: maximizing the value of the product resulting from the work of the Scrum Team.
It then lists Product Backlog management: developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering them, and keeping the Product Backlog transparent. And it adds a sentence that matters more now than when it was written: the Product Owner may do this work or delegate it to others, but regardless, the Product Owner remains accountable.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 18/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
En gestión de proyectos casi todo lo que se discute como problema técnico es en realidad un problema de expectativas mal negociadas al principio. Alcance, plazo y costo se pactaron en un momento en que nadie tenía la información suficiente, y después nadie quiso reabrir la conversación.
Mi filtro es la calidad del reporte de estado. Si todos los proyectos están en verde, el sistema de información no sirve: en cualquier portafolio real hay iniciativas en problemas, y una organización sana las muestra a tiempo en vez de descubrirlas en el comité de cierre.
Lo que suele salir mal
Donde suele romperse es en el traspaso a operación. El proyecto se declara terminado cuando se entrega, no cuando el área que lo recibe puede sostenerlo. Tres meses después el equipo se disolvió, nadie documentó nada y la operación convive con algo que no entiende y no puede modificar.
Qué mirar
- El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.
- Cómo se estimó y qué tan cerca estuvieron las estimaciones anteriores de la misma organización.
- Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.
Cómo leo esta entrada
Si esto llegara a mi mesa, lo primero que pediría no es el avance porcentual: es la lista de decisiones pendientes con nombre y fecha. El porcentaje se puede maquillar; una decisión trabada hace tres semanas con un responsable identificado no se puede discutir, y explica el atraso mucho mejor.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
