Appointing one person accountable for AI is a sound first step. In an organisation moving to a product operating model, or already running one, the same role puts a dependency and a handoff between product teams and the decisions the model gives them.Most organisations adopted AI before anyone was accountable.
Appointing one person accountable for AI is a sound first step. In an organisation moving to a product operating model, or already running one, the same role puts a dependency and a handoff between product teams and the decisions the model gives them.Most organisations adopted AI before anyone was accountable.
As a first step, the role works. Executives know whom to ask about AI, and one person collects lessons from separate pilots instead of losing them when each pilot ends. The difficulty starts when the first step becomes the permanent design. Once an organisation commits to a product operating model, in which persistent product teams are accountable for outcomes (Cagan et al., 2024), an AI Product Owner holds the decisions the model assigns to each product's Product Owner, and every team that adopts AI adds to that one person's queue.
Capable organisations create the role for a structural reason. When a new technology is adopted, the familiar response is to set up a function for it and appoint someone to run that function, because a project-funded organisation has no persistent product that could own the technology. The AI Product Owner is that response with a Scrum title. Manufacturers took the same path with quality: inspection departments checked work after it was done, until Deming (1986) argued that quality had to be built into the production process rather than inspected afterwards.
AI is rarely a productThe Scrum Guide makes the Product Owner accountable for maximising the value of the product that results from the Scrum Team's work. The Product Owner is also accountable for effective Product Backlog management: developing the Product Goal, creating and ordering Product Backlog items, and keeping the Product Backlog transparent (Schwaber & Sutherland, 2020). The Scrum Guide describes a product as a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers. Its Product Owner is "one person, not a committee", and succeeds only when the whole organisation respects their decisions.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 02/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
Projects rarely fail on the day they are declared failed. They fail months earlier, in a meeting where somebody saw the problem coming and calculated it was not in their interest to say so. Everything else — the slipping schedule, the stretching budget — is the visible consequence of that silence.
My filter is the quality of the status report. If every project is green, the reporting system is not working: in any real portfolio some initiatives are in trouble, and a healthy organisation surfaces them in time rather than discovering them at the closure committee.
What usually goes wrong
The classic mistake is treating risk management as a deliverable of the planning phase. The matrix gets built, approved, filed. Nobody opens it again until closure, when it serves to document that the risk was foreseen — which is exactly the opposite of managing it.
What to watch
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
- How it was estimated and how close the same organisation's previous estimates turned out to be.
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
How I read this entry
I would use it to review how the organisation estimates. If historical estimates were systematically out by half and nobody adjusted the method, no project will land well: you are planning with a ruler that measures short and blaming the team for not reaching the mark.
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.
