The proxy Product Owner problem

The pattern is easy to recognise once you have seen it. The Developers ask the Product Owner whether an edge case should be handled one way or another. The answer is "I will check with the business". Three days later the answer arrives, and meanwhile someone built it one way and is now redoing it. Nobody is lazy. The person in the Product Owner role simply is not the person who decides.

What the Guide expects

The Guide's description is short and exacting. The Product Owner is accountable for maximising the value of the product and for effective Product Backlog management, including the Product Goal, the items and their order. They may delegate the work but remain accountable. For Product Owners to succeed, the entire organisation must respect their decisions, and those decisions are visible in the content and ordering of the backlog and through the inspectable Increment at the Sprint Review. The Product Owner is one person, not a committee, and those wanting to change the backlog do so by trying to convince them.

Each phrase is a condition for the role to work. "Accountable" needs decision rights. "One person" excludes a rotating panel. "Respect their decisions" excludes routine overruling from above. A proxy fails one or more of these.

The SBOK® Guide agrees on the shape. It calls the Product Owner the Voice of the Customer, responsible for maximising business value, defining acceptance criteria and keeping the business justification, and notes that of the three core roles no role has authority over the others. In large projects it adds a Chief Product Owner so that one person still makes the day-to-day business decisions across several teams. In every case, a person decides.

How to spot one

Some signs are visible within a Sprint.

• Questions to the Product Owner are answered with "I will ask" more than with an answer.
• The backlog is reordered after meetings the Product Owner did not attend.
• Acceptance of a story at the Sprint Review is followed by "let me check with my manager".
• Stakeholders go around the Product Owner directly to the Developers, because they have learned that is where decisions are made.
• The Product Owner cannot say no. See how a Product Owner says no.

A simple measurement helps. For two Sprints, note how long each Developer question to the Product Owner takes to get a decision. If most are resolved within hours, there is a Product Owner. If many take days, there is a messenger.

What it costs

The costs are concrete.

Waiting. A Developer who cannot get an answer either blocks or guesses. A guess that is wrong is rework. The Sprint Goal suffers either way.

Slow learning. The Sprint Review should change the backlog, but if the Product Owner cannot act on what stakeholders say, the feedback loop is open at the exact point where it should close.

Hidden ordering. When the real decision is made elsewhere, the backlog's order reflects a negotiation the team never sees. Transparency, one of the three pillars of the framework, is quietly lost. See transparency in Scrum.

Disengagement. Developers who learn that the Product Owner's word does not stick stop investing in conversations with them.

Why it happens

Rarely out of bad faith. Common causes include a senior owner who has no time and appoints a junior delegate; a culture in which important decisions are made by a committee; a fear of making a visible mistake; and an organisation that has adopted the roles and left the decision rights where they were. Sometimes it is the result of a good idea applied badly: a proxy introduced to protect the business owner's time ends up cutting the team off from them.

The Guide allows delegation, and that is where the confusion often starts. A real Product Owner can delegate the work of writing items or clarifying details. A proxy has delegated the decision and not just the work. The question to ask is who can say "yes, that is how it will be" and not be overruled the next day.

A worked example

This is an illustrative case. A team builds a loan-application product for a regional lender. The named Product Owner is a business analyst who reports to the head of lending, and every priority decision is taken at a weekly committee of five managers.

In a three-week period, the team asks sixteen questions. Nine are answered the same day by the analyst, who knows the product. Seven go to the committee, and wait on average four days. Two of those seven change direction after the team has already started.

The Scrum Master brings this to the Retrospective with a simple chart. The committee agrees to a change: the head of lending becomes the Product Owner, delegating the day-to-day detail to the analyst within a written scope. Decisions inside the Product Goal and the budget for this quarter are the Product Owner's alone. The committee keeps a quarterly review of the Product Goal itself. In the following period, nearly all questions are answered the same day, and the backlog's order is something the Sprint Review can discuss openly.

Four ways to fix it

1. Move the decision to the person. Put the real decision maker in the role, or give the current one a written scope of authority that others agree to respect. GOV.UK's guidance on agile governance says teams should know they have the authority to make decisions, what the boundaries are, and who is accountable for helping when a decision falls outside them. The same logic applies to the Product Owner.
2. Shrink the loop. If a committee must be involved, set a fast route for small decisions and a slower one for strategic ones.
3. Make the order visible. Whoever has influence puts it into the Product Backlog openly, so that it is argued with the Product Owner and not around them.
4. Bring the decision maker to the Review. The Guide expects the Sprint Review to be a working session. Decision makers who see the Increment and talk to the Product Owner there trust the role more.

The Scrum Master's part is to make the pattern visible and to raise it with the organisation, as the Guide says they should work to remove barriers between stakeholders and Scrum Teams.

How to practise it

Time your own team's questions for a fortnight. The data will say more than any workshop. In the simulator you hold the Product Owner's decisions and see how a slow or hedged answer lands on the team.