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.
Why it matters
A project management office is worth the decisions it makes possible, not the reports it produces. Once the PMO becomes the function chasing status updates, it has already lost: the team learns to fill in the template and the real information goes back to travelling through the corridors.
I read these things looking for where the risk sat before it became an incident. It was almost always already written in some register nobody reviewed, with an assigned owner who never found out they were one. A risk identified and not managed is worse than one never identified: it creates the false sense that there is control.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
- Whether the status report shows any red projects: an all-green portfolio is a portfolio without information.
- Which risks are identified, who owns each one, and when they were last reviewed.
How I read this entry
If this landed on my desk, the first thing I would ask for is not percentage complete: it is the list of pending decisions with a name and a date. A percentage can be dressed up; a decision stuck for three weeks with an identified owner cannot be argued with, and it explains the delay far better.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
