How do you diagnose and fix a Product Owner who holds the title but no ordering authority?

## What the accountability is supposed to buy Scrum names **one** Product Owner so that a single question — what should this team do next, and what should it not do — has a single, fast, unambiguous answer. That is the whole reason for concentrating it in a person rather than a committee: a team that can get an ordering decision inside a conversation does not accumulate half-started work waiting for one. A **proxy Product Owner** holds the seat without the decision. They gather requirements, write items, attend the events, and every question that actually matters goes somewhere else and comes back later, if it comes back at all. The title is real; the authority is not. ## The tells Diagnose by decision latency and by where decisions get reversed, never by job title or seniority: - Questions raised in refinement are answered days later, in writing, or not at all. - The order of the Product Backlog changes after a Sprint has started, decided by someone who was not in the room. - The person in the seat answers 'I will have to check' to questions squarely inside their stated scope. - Developers start items on a guess because waiting is worse, then rework them when the answer lands. - Stakeholders bypass the seat entirely and bring requests straight to the Developers. ## What it costs Take the billing team at a community-energy supplier: six Developers, three of them on an on-call rotation that eats roughly half their week, and a Product Backlog of 47 items. Thirteen of those 47 carry an open question only the funding sponsor can settle, and the sponsor answers in about nine working days. The cost is not that people type more slowly. It is that started work cannot finish. The team pulls an item, hits the question, starts a second item rather than sit idle, hits another question, and arrives at the Sprint Review carrying four unfinished items and nothing to show. When the answers finally come, two of the four were built against the wrong assumption and are reworked. The Sprint Goal was never honest, because nobody in the room could commit to what the Sprint was for. | | Product Owner with authority | Proxy in the seat | | --- | --- | --- | | Ordering decision | Made in the room | Escalated, then relayed | | Typical answer latency | Minutes to a day | Days to weeks | | Where reversals happen | Nowhere; the decision holds | Outside the team, after the fact | | Effect on the Developers | Items finish | Items start and wait | | The Sprint Goal | Something the team can commit to | A list of hopes | ## The two honest fixes There are only two, and the difference between a senior answer and a junior one is refusing to pretend there is a third. 1. **Move the authority to the person.** The sponsor delegates ordering and value judgement explicitly: a written scope, a spending or risk threshold above which escalation is required, and a commitment to be reachable inside the team's events. Delegation that is not written down is not delegation; it is a habit that evaporates the first time it is tested. 2. **Move the person to the authority.** If the sponsor will not delegate, then the sponsor is the Product Owner and belongs in the seat with the time commitment it requires. This is often unwelcome, and it is frequently the honest answer. The fake third option is another hop — an extra analyst, a delivery lead, a weekly clarification meeting. Every one of them preserves the latency and adds to it. ## Raising it without blaming the person The individual in a proxy seat is usually doing their best inside an arrangement they did not design, so bring evidence rather than an opinion: - Count the items that cannot be started or finished for want of a decision. - Measure the wait between a question being raised and answered. - Count the items reworked because the answer arrived after the work did. Put those three numbers in front of the sponsor with a choice attached: delegate the decision, be present for it, or accept the wait as the team's stated capacity limit so the forecast can say so out loud. In parallel, change the team's own habit — stop pulling items whose decisive question is unanswered. That turns an invisible cost into a visible queue, which is the only reliable way to get an organisation to act on it. One caution: do not let the Developers quietly take the ordering over. It relieves the pain and hides the cause, and it orders the product by technical convenience rather than by value. If it has to happen at all, make it explicit, time-boxed and visible to the sponsor.