Why you need only ONE Product Owner

Scrum prescribes one person in the role of Product Owner (PO). Not multiple people, not a committee, just one person:

“The Product Owner is the sole person responsible for managing the Product Backlog.” (Scrum guide)

And when multiple teams work on a single product, the Scrum Guide says:

“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” (Scrum guide)

I encounter many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak “to make Scrum work in your context”.

The apparent need for multiple PO’s

When companies need to scale up their development effort, they tend to copy complete Scrum teams, including the Product Owner. They soon find out that the PO role does not scale that well by multiplication. As they lose transparency over responsibilities, they try differentiating the PO role in various types of PO’s such as Feature Owners, Epic Owners, Component Owners and more. They are looking in the right direction to solve their problem but choose the path of complexity instead of simplification: When working with multiple teams on one product, you only need exactly one Product Owner. A product is a real product that satisfies a customer need and people want to pay money for it.

In many cases I see that there is not a problem in handing over the authority and accountability for the whole product to one single person. However, people resist to having a single PO because they consider the concept to be unrealistic. They feel having multiple PO’s and multiple product backlogs is a necessity for various reasons:
- The scrum guide says we need one PO per team, which means we must have multiple PO’s as we have multiple teams. (This is a myth; One Product Backlog means we need one Product Owner).
- The domain knowledge for a complex product like ours is too vast for one person to grasp.
- The workload to produce all user stories is too big and cannot be…