top of page

          

Scrum

          

29 September 2023

 · 

3

 minute read

Product Owner vs Scrum Master: Two Accountabilities That Should Never Be Combined

The Product Owner and Scrum Master are the two most frequently confused roles in Scrum. They interact closely, they both care about team effectiveness, and they are fundamentally different in what they are accountable for. Here is the distinction that matters.

HS

Heidi Reidel Sørensen

Better Change Coach

In a Scrum Team, the Product Owner and Scrum Master work closely together — but they are accountable for different things, they face in different directions, and they require different orientations to do their jobs well. Understanding the distinction is not just definitional tidiness; combining the two accountabilities in a single person consistently produces worse outcomes than keeping them separate.

The Product Owner: accountable for value

The Product Owner is accountable for maximising the value of the product resulting from the Scrum Team's work. This is a business accountability, not a process one. The Product Owner owns the Product Backlog — its content, its ordering, and its communication — and is responsible for ensuring that the team is always working on the most valuable things.

Day to day, this means developing a clear Product Goal and communicating it to the team. It means maintaining an ordered, well-prepared backlog. It means making trade-off decisions when capacity is limited. It means engaging meaningfully with stakeholders, translating their needs into backlog items, and providing the team with enough context to make good technical decisions.

The Product Owner faces outward: toward the customer, the stakeholders, and the business. Their primary question is: what is the most valuable thing we should build next?

The Scrum Master: accountable for process quality

The Scrum Master is accountable for the effectiveness of the Scrum Team and the quality of the Scrum process. This is a process and coaching accountability, not a delivery one. The Scrum Master helps the team understand and apply Scrum — not by policing compliance, but by developing genuine understanding of why Scrum works the way it does and how to improve its application.

Day to day, this means coaching the team on self-management, facilitating events effectively, removing impediments that are outside the team's control, and helping stakeholders understand what Scrum requires. It also means supporting the Product Owner — helping them develop effective backlog management techniques and facilitating stakeholder collaboration.

The Scrum Master faces inward: toward the team's process, capability, and health. Their primary question is: how can we work more effectively?

Where the two roles interact

Both accountabilities care about team performance, which creates the perception that they overlap. They don't. The Product Owner cares about what the team delivers and whether it creates value. The Scrum Master cares about how the team works and whether the process supports good delivery. These are genuinely different orientations.

In practice, a well-functioning relationship between the two produces a productive tension: the Product Owner pushes for value delivery and the Scrum Master ensures the team is healthy and capable enough to sustain it over time. When the two accountabilities are combined in a single person, this tension collapses — and usually the process quality suffers, because the delivery pressure consistently wins.

Why they must be separate people

Combining the Product Owner and Scrum Master in one person is explicitly discouraged in the Scrum Guide, and the reasoning is sound. The Product Owner needs to make product decisions that are sometimes unpopular with the team. The Scrum Master needs to be a trusted, neutral advocate for the team. A single person cannot genuinely occupy both positions simultaneously.

There is also a practical problem: both roles are substantial, full-time accountabilities in any functioning Scrum Team. A person combining both tends either to neglect one or to create a bottleneck where too many decisions are waiting on one person. Neither outcome serves the team.

If your organisation is struggling to resource both roles, the right response is to understand what is preventing it — whether that is a misunderstanding of what each role requires, a structural constraint, or a resourcing priority decision — rather than to combine the accountabilities and accept the resulting compromises.

More articles ON

Scrum

The Scrum Process Explained

Can the Product Owner also be the Scrum Master?

What is a Product Vision?

courses in this topic

⬤  INTERESTED IN TRAINING?

View our

Scrum

courses

FLIN (free), FL2D, and FL3D — certified by the Flight Levels Academy.

bottom of page