Concept 2 of 3

The product owner in organisational context

5 questions test this

The accountability described in the Scrum Guide is the same everywhere. The organisation around it is not, and a CSPO course is expected to cover at least three organisational designs and how each one changes the way the accountability gets carried out.

Three designs and what each one costs

In a product-aligned organisation, funding, staffing and the backlog all follow the product. The product owner's decision is close to unconstrained, and the hard part is choosing well rather than getting permission.

In a functional or matrix organisation, people report to functional managers and are lent to the product. The backlog decision is still the product owner's, but capacity is negotiated with people who have other priorities, so a large part of the job becomes making the cost of those negotiations visible.

In a project or contract-driven organisation, scope and date are agreed before the team starts. The product owner inherits an ordered list rather than creating one. The honest move is to keep ordering by value inside the agreed scope and to surface, early and in writing, what the fixed scope is displacing.

A fourth pattern worth naming is the internal platform, where users are colleagues and there is no revenue signal. Value has to be expressed in the terms the consuming teams care about, such as time saved or failures avoided.

One product owner, several teams

Where several scrum teams work on one product they share one product backlog, one Product Goal and one product owner. That scales badly by default, and two responses hold up.

The first is to delegate the work of product backlog management without delegating the decision. Developers draft items, subject matter experts supply detail, and the product owner still orders the list. The Scrum Guide permits this delegation explicitly.

The second is to reduce the number of decisions that need the product owner in the room. A clear Product Goal, an ordered backlog with visible reasoning, and direct access between developers and users all mean fewer questions have to route through one person. The failure mode is the opposite, a product owner who attends every event of every team and becomes the bottleneck they were trying to avoid.

Authority held while collaborating

Authority over the backlog and collaboration are not in tension, and the CSPO objectives ask you to explain why. The product owner holds the decision because order is a single sequence and only one item can be first. Collaboration is how the decision gets informed. Developers know what is cheap and what is expensive, stakeholders know what the market is asking for, and users know what actually gets in their way.

The practical version is that the product owner should be the easiest person in the organisation to argue with and the hardest to overrule. When a decision is overridden by seniority rather than by evidence, the accountability has moved in practice whatever the job title says.

Making progress transparent

The objectives also ask for at least one technique that gives stakeholders transparency on progress toward goals. A product backlog that is visible and ordered, a Product Goal stated in outcome terms, and an increment inspected at the sprint review together do more than a status report, because each one can be checked rather than believed.

Common misconceptions

A product owner inside a project management office has less authority over the backlog than one in a product-aligned organisation.

The accountability is identical. What differs is how many decisions are already constrained by the time they reach the product owner, and how much of the job is spent making those constraints visible rather than choosing freely.

Two scrum teams working on one product need two product owners.

One product has one product backlog, one Product Goal and one product owner. Splitting the product owner splits the ordering decision, which is the one thing that cannot be split without losing the trade-off.

A proxy product owner carries the accountability when the real product owner is unavailable.

A proxy can relay and clarify. The accountability does not transfer, and a standing proxy usually signals that the person with the decision rights is not the person in the room.

5 questions test this concept

A product owner joins a company where budgets are allocated per project, scope and dates are agreed with the sponsor before a team is formed, and the team is disbanded at the end. Which description of the accountability in this design is accurate?

  • AThe accountability is smaller here, because the ordering decision has already been made by the sponsor.
  • BScrum cannot be used in this design, so the role becomes a business analyst role.
  • CThe accountability is unchanged, and the practical work shifts toward ordering by value within the agreed scope and making visible what the fixed scope is displacing.
  • DThe product owner should refuse the fixed scope until the sponsor changes the funding model.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
How to Lead in Product Management, On holding a decision without formal authority over the people affected.
Book
Empowered, On what an organisation has to change for product decisions to sit with product teams.
Book
Team Topologies, On drawing team boundaries around products rather than around components.