The Product Owner is accountable for maximising the value of the product resulting from the Scrum Team's work. That is a single accountability held by a single person, and the Guide is deliberately unspecific about how it is discharged, because how value is maximised varies widely across organisations, teams and individuals.
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 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 is the one most often forgotten. Transparency is an activity the Product Owner owns, not a property the backlog acquires on its own once the first three are done.
One person, not a committee
Representing the needs of many stakeholders is part of the job, and the decision still sits with one person. 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 trade offs somebody's to make and somebody's to be wrong about. It also fixes the mechanism for changing the backlog, which is persuasion, so anyone wanting a change tries to convince the Product Owner rather than going around them to the Developers once a Sprint is under way.
Why the organisation has to respect the decisions
For the Product Owner to succeed, the entire organisation must respect their decisions. That is a condition on the organisation rather than advice to the Product Owner, and it is the part most often quietly dropped.
Where it 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 while leaving the accountability where it was, and Scrum cannot be run that way.
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, keeping the accountability
The Product Owner may delegate any of the work. Others may write items, run refinement, interview customers and analyse data. What cannot move is the accountability, so the answer to who decides is unchanged however much of the work somebody else did.
That is the line between the accountability and a proxy. A person who collects requirements, brings them to the team and refers every real decision back to a manager or a steering group 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 it is not the job, which 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 which items enter the Sprint Backlog and decide how the work gets done, 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 does not order the backlog.
When the Product Owner is not available
Absence happens and Scrum does not stop for it. Within the Sprint the Developers make the best decisions they can with what they know, keeping progress toward the Sprint Goal, and realign with the Product Owner once they are back. That is self-management doing the job it exists for, and the decisions taken in the meantime are provisional rather than final.
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, and outranking the Product Owner transfers no part of the accountability.
None of which makes prolonged absence acceptable. The remedy is availability rather than a procedure for coping without it, because a Product Owner the Developers cannot reach is an impediment, and impediments are the Scrum Master's business to remove.
Working with the Developers
The relationship runs in both directions, and the return leg is the part exams press on. Frequent collaboration lets the Developers build with the end user and the stakeholder in mind rather than working from a document, and it lets the Product Owner make informed decisions by weighing what an item would actually cost against what it is worth. Neither is available to 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 is enough to hand work over and not enough to shape it, and the ordering that results is set without any 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.
What none of it requires is deep technical knowledge of the stack. The Product Owner needs enough understanding to hold a real conversation about trade offs, 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 the first is a condition of the accountability.