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
Una oficina de proyectos vale por las decisiones que hace posibles, no por los reportes que produce. Cuando la PMO se convierte en el área que persigue actualizaciones de estado, ya perdió: el equipo aprende a llenar el formato y la información real vuelve a viajar por los pasillos.
Leo estas cosas buscando dónde estaba el riesgo antes de convertirse en incidente. Casi siempre ya estaba escrito en algún registro que nadie revisaba, con un dueño asignado que nunca se enteró de que lo era. El riesgo identificado y no gestionado es peor que el no identificado: da la falsa sensación de que hay control.
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
- Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.
- Si el reporte de estado muestra proyectos en rojo: un portafolio todo en verde es un portafolio sin información.
- Qué riesgos están identificados, quién es dueño de cada uno y cuándo se revisaron por última vez.
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.
