3.3 The Product Owner

What the Product Owner Is Accountable For

The 2020 Scrum Guide states the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. That is the headline accountability, and the Guide notes that how this is done may vary widely across organizations, Scrum Teams, and individuals. There is no single prescribed technique — value maximization is the outcome the Product Owner is on the hook for.

The Product Owner is also accountable for effective Product Backlog management, which the Guide breaks into four concrete responsibilities:

• 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 Product Owner does not have to perform every one of these personally. The Guide explicitly allows the Product Owner to delegate this work — for example, having Developers help refine and break down items — but in every case the Product Owner remains accountable. This delegate-but-stay-accountable pattern recurs across all three Scrum accountabilities and is a favorite PSM I theme. A trap answer claims accountability "transfers" to whoever does the work; it never does.

A second precise point: the Product Owner orders the Product Backlog, but ordering is by value, not by a fixed priority scheme dictated by stakeholders. The Product Owner balances stakeholder input against the goal of maximizing product value.

One Person, Not a Committee

The Scrum Guide is unambiguous: the Product Owner is one person, not a committee. The needs of many stakeholders may be represented in the content of the Product Backlog, but those needs are channeled through this one accountable person. The Guide adds a memorable mechanism: those wanting to change the Product Backlog can do so by trying to convince the Product Owner. Influence flows toward the Product Owner; authority over the backlog does not flow away from them.

This single point of accountability is what keeps the product's direction coherent. Two classic PSM I trap answers contradict it directly: the "Product Owner committee" and "each stakeholder owns and prioritizes its own slice of the backlog." Both fragment ownership and are wrong.

Organizational Respect for Decisions

The Guide states that for Product Owners to succeed, the entire organization must respect their decisions. These decisions are made visible in two places: the content and ordering of the Product Backlog, and the inspectable Increment at the Sprint Review. Two hard rules follow that PSM I loves to test:

• No one is allowed to tell the Developers to work from a different set of requirements.
• The Developers are not allowed to act on what anyone else says (over the Product Owner's ordering).

So when a senior manager bypasses the Product Owner and instructs the Developers directly to build something, the Scrum-aligned answer is that this violates the Product Owner's accountability — the Developers should not act on it, and the organization is failing to respect the Product Owner's decisions.

Product Owner vs. Scrum Master vs. Developers

PSM I frequently presents a scenario and asks which accountability applies. Use this comparison table to keep them straight:

A simple decision rule for scenario questions: when the scenario describes deciding what to build and in what order, that points to the Product Owner. When it describes how the work gets done and the plan for the Sprint, that points to the Developers. When it describes improving how Scrum is used or the team's effectiveness, that points to the Scrum Master.

Why the Product Owner is not a 'proxy'

A common real-world anti-pattern — and PSM I trap — is treating the Product Owner as a proxy or messenger who simply relays whatever stakeholders or a "real" business owner decide, with no authority of their own. The Scrum Guide rejects this: the Product Owner is the single accountable decision-maker for value and backlog ordering. A pass-through proxy with no decision authority cannot fulfill the accountability, because the organization would not be respecting any Product Owner decisions — there would be none to respect.

The Product Owner and the Product Backlog Commitment

Each Scrum artifact carries a commitment that reinforces empiricism, and the Product Owner is closely tied to the Product Backlog's commitment: the Product Goal. The Product Goal describes a future state of the product and serves as the long-term objective for the Scrum Team. The Product Backlog emerges to define what will fulfill the Product Goal, and the team must fulfill (or abandon) one Product Goal before taking on the next. Developing and explicitly communicating that Product Goal is squarely the Product Owner's job.

This links several exam facts together:

• The Product Backlog is the single source of work for the Scrum Team; the Product Owner orders it to maximize value.
• Its commitment, the Product Goal, gives the ordering direction — items are ordered to advance toward that goal.
• Refinement (breaking items into smaller, clearer pieces and adding detail like description, order, and size) is an ongoing activity. The Product Owner is accountable for it but the Developers do the sizing — the people who will perform the work are responsible for the sizing.

Common Product Owner scenario rulings

That last row is a precise, frequently tested fact: only the Product Owner has the authority to cancel a Sprint, and the legitimate trigger is that the Sprint Goal has become obsolete. Sprint cancellation is rare and often traumatic, but the authority rests with the Product Owner alone — not the Scrum Master, not the Developers, not a stakeholder.