The Product Owner is accountable for maximising the value of the product resulting from the Scrum Team's work. One person holds that accountability, and the Guide is deliberately unspecific about how it is discharged, because the way value gets maximised varies widely across organisations, Scrum Teams and the people in them.
Product Backlog management
The Product Owner is also accountable for effective Product Backlog management. The Guide breaks that into four activities.
- Developing and explicitly communicating the Product Goal.
- Creating and clearly communicating Product Backlog items.
- Ordering Product Backlog items.
- Ensuring the Product Backlog is transparent, visible and understood.
The order of those four repays reading. A Product Goal comes first, because ordering is meaningless without something to order towards, and the ordering itself is the most consequential act in the accountability.
The fourth activity is the one most often forgotten. Transparency is something the Product Owner keeps doing, so a backlog does not become visible and understood on its own once the first three activities are complete.
The Product Owner is one person
The Product Owner is one person, not a committee. Representing the needs of many stakeholders is part of the job, but the decision sits with one person all the same. The rule exists because value under uncertainty is a judgement rather than a calculation, and judgements made by committee drift towards whatever offends nobody. A group can produce an order that every department can live with and that no customer particularly wants.
Naming one person makes the tradeoffs somebody's to make and somebody's to be wrong about. It also fixes the mechanism for changing the backlog, which is persuasion, so those wanting to change the Product Backlog can do so by trying to convince the Product Owner. Approaching the Developers directly once a Sprint is under way changes nothing, because the Developers cannot reorder the backlog either.
Why the organisation has to respect the decisions
Persuasion only works if the Product Owner's answer is final, and the Guide states that condition directly. For the Product Owner to succeed, the entire organisation must respect their decisions. That sentence sets a condition on the organisation, so it is not advice to the Product Owner, and it is the part most often quietly dropped.
If that respect fails, the symptom is that decisions get reopened somewhere else. Work appears in a Sprint having never passed through the Product Backlog, an executive reorders the top of that backlog after the fact, or the team is asked to justify why a senior stakeholder's item is not next. Each of those moves the decision away from the person accountable for it and leaves the accountability exactly where it was, which is a combination Scrum cannot run on.
Respect is not deference. The Sprint Review exists so that stakeholders can argue with the direction on the evidence of a working Increment, and the Product Backlog exists so that the direction can be seen and questioned before then.
Delegating the work while keeping the accountability
The Product Owner may delegate any of the work. Others may write items, run refinement, interview customers and analyse data. The accountability is the one thing that cannot move, so the answer to who decides stays the same however much of the work somebody else did.
The same line separates the accountability from a proxy. When a person collects requirements, brings them to the team and refers every real decision back to a manager or a steering group, that person is doing the work of the accountability without holding it. The team then has somebody to ask and nobody who can answer.
The same distinction separates the accountability from a business analyst post. Writing clear items is part of the job, and the job itself is deciding what the product should become and being answerable for the result.
What belongs to the Product Owner alone
Two decisions sit with the Product Owner and nowhere else. The ordering of the Product Backlog is theirs, and while anyone may advise, the order that stands is the one they set. Only the Product Owner may cancel a Sprint, which may happen when the Sprint Goal becomes obsolete.
The boundaries running the other way are just as firm. The Developers select the items that enter the Sprint Backlog and decide how they will do the work, so the Product Owner may not assign work to them or set how much they take on. The Scrum Master helps the Product Owner find techniques for effective Product Goal definition and Product Backlog management, and the ordering stays with the Product Owner.
When the Product Owner is away
A Product Owner is sometimes away, and Scrum has no procedure that stops the Sprint for it. Within the Sprint the Developers make the best decisions they can with what they know, keep progress moving toward the Sprint Goal and realign with the Product Owner on their return. That is self-management doing the job it exists for, and every decision taken in the meantime stays provisional until the Product Owner confirms it.
The alternatives fail in instructive ways. Stopping and waiting spends a whole Sprint on nothing and treats the Product Owner as a gate the work has to pass through, which the accountability was never meant to be. Having management appoint a substitute breaks the single accountability and hands the Developers a second source of direction, so the team acquires two people to satisfy and one of them is going to be overruled. Escalating to the Product Owner's manager puts the ordering decision with somebody who does not hold it, since outranking the Product Owner transfers no part of the accountability.
A Scrum Master stepping into the gap fails for the same reason. The service owed to the Product Owner is help with techniques for Product Goal definition and Product Backlog management, so taking the ordering decision converts that help into the accountability itself. The team is then served by one person holding two of its three accountabilities.
None of this makes prolonged absence acceptable. The remedy is availability, because a Product Owner the Developers cannot reach is an impediment, and causing the removal of an impediment is the Scrum Master's service to the team.
Working with the Developers
The relationship runs in both directions, and the direction from the Developers back to the Product Owner is the one the assessment presses on. Frequent collaboration lets the Developers build with the end user and the stakeholder in mind, which no document gives them. It also lets the Product Owner make informed decisions, by weighing what an item would actually cost against what it is worth. Neither benefit reaches somebody who arrives with the decision already made.
Meeting the Developers only at Sprint Planning and Sprint Review is too little. Two conversations a Sprint are enough to hand work over, and shaping the work needs more than that, so the ordering that results carries no sense of effort, which is half of the value question. Keeping business and technology deliberately apart, so that requirements travel one way and estimates travel back, is the failure this arrangement exists to prevent.
None of that requires deep technical knowledge of the stack. The Product Owner needs enough understanding to hold a real conversation about tradeoffs, and grasping the implications of a choice is a different thing from being able to implement it. Being reachable and being technical are separate claims, and only reachability is a condition of the accountability.