Why You Need Only One Product Owner

Scrum prescribes one person to 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 POs

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 POs 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 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 having a single PO because they consider the concept to be unrealistic. They feel having multiple POs 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 POs 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 handled by one person.
• There are too many meetings in Scrum for a single PO to attend.
• With multiple POs the PO-availability for teams can be provided at the required level.
• It is easier to have many POs as it avoids the fight over who should become the one real PO.
• We come from a situation where we thought we needed one PO per team. Now that they are working here, we cannot just send them away.
• (This is space to fill in some other silly argument you have heard in your organization.)

Downsides of Having Multiple Po's

Having Many POs Encourages Micromanagement of Teams

In a Product Owner-per-team situation, the PO becomes the person that spells out all the detailed specs (user stories). This setup leads to teams focusing on story readiness, negotiating the level of story detail instead of focusing on value creation. This is a well-known pattern known as the "contract negotiation game." Another effect is the growing absence of domain expertise in the teams. Domain knowledge is concentrated in the PO, which makes the team stick to executing tasks (opposed to solving customer problem), which re-enforces the need for more POs. The PO-per-team setup reduces opportunities for learning and self-organization. I normally suggest making the POs part of the development teams they work with. They will get the opportunity to become multi-skilled development team member with a focus on analysis.

Many POs Requires Coordination and Alignment

The POs decide in a PO team to agree who takes care of which items on the Product Backlog. The customer features are sliced and each PO gets their own sub-scope of the customer value in a Product Backlog. The work is sliced on arbitrary and artificial grounds, creating a coordination need to deliver an integrated product by the end of the sprint. Also, prioritization is decentralized and will lead to local optimization per backlog. This inevitably introduces asynchronous dependencies between teams, as some teams are "full" and cannot do certain work other teams depend upon. Teams don't have a whole product view and lose track of what is customer value. If the coordination need is high between POs, then the Product Backlog has probably not been sliced to optimize for minimal dependencies and the teams are not structured to serve that goal. Having only one PO managing a single Product Backlog for multiple teams creates the transparency required for proper empiricism.

Many POs Bring Unclear Responsibility and Ownership

One PO means that one person is accountable for the ROI on the product under development. With multiple Product Owners, accountability, responsibility, and ownership are obscure. Management has a tough job getting a grip on product development as there is no "single neck to wring." Multiple POs stimulates part-time jobs by adding the PO work to someone's existing workload. This introduces a conflict of interest. With multiple people working part-time on one product the situation does not get any better. Volunteers come to the rescue, thinking "If nobody takes care of this, then I will," and change backlog item priority, add items, or even create their own backlog, creating more complexity. In such cases, I suggest restoring transparency by extending the Definition of Done gradually to include the work described in the additional backlogs or simply merge them into one single Product Backlog.

What If It Fails?

If your PO cannot handle the work involved managing the product:

• Being a PO is a difficult job and not everybody can do it. Hire someone else, or maybe you can fix it by sending the PO to a proper training.
• Reduce the number of features (user stories) in the backlog, as they are probably too detailed.
• Aggregate specs to a low number (3 to 5 stories per team per sprint) to experiment with. 
• Stimulate "prioritization over clarification." Reduce the level of detail at which the PO is dealing with features by explicitly bringing the clarification responsibility in the team. The PO can help by connecting the team to a stakeholder or customer.
• Limit the planning horizon to no more than 2 to 3 sprints of work ahead, as preparing more work is likely to result in waste. If you are able to predictably specify your work more than 3 sprints ahead you maybe should not be doing Scrum as your product is not complex enough.
• Prevent the Product Backlog from spawning by extending the DoD, continuously reducing technical debt with merciless refactoring and strict bug policies.

Conclusion

The PO role is better not scaled by multiplying POs as this has many downsides. I encourage having a single Product Backlog and a single PO being responsible for return-on-investment when developing one product. Having a single Product Owner creates transparency and enables proper empiricism. The concept of a single Product Owner in a scaled environment (multiple teams working on a single product) is challenging if you stick to the idea that the PO has to manage every detail. When scaling, try shifting the PO focus from clarification to prioritization. This will encourage the teams to better understand what needs to be created for the product. This approach is completely in line with backlog management described in the Scrum Guide:

"The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." (Scrum Guide)