How Many Product Owners Does Your Product Need?

When a Product Owner works with several Scrum Teams, the workload can become difficult to manage, and managers or colleagues may offer to help. Such support can be valuable, but it raises a question about which responsibilities can be shared without blurring accountability.

The answer also depends on whether the teams work on one product or several.

One product, one Product Owner

The Scrum Guide describes a Scrum Team as having one Product Owner, but that does not mean the person serves only one team. When several Scrum Teams work on the same product, they share the same Product Owner, Product Backlog, and Product Goal.

The Product Goal gives the teams a common direction, while the Product Backlog makes the work being considered and its order visible. A product vision provides broader context for that direction, as illustrated by these product vision examples.

The Product Owner is accountable for maximizing product value and for effective Product Backlog management. Others can contribute their knowledge and take on work, but accountability remains with the Product Owner.

This becomes important when requests compete across teams. Different stakeholders may have legitimate needs, but their requests still need to be considered in relation to the product as a whole.

A booking decision

Consider an online appointment-booking product. One Scrum Team works on the booking interface and another on the service that manages available slots. Their current Product Goal is to make it easier for customers to complete a booking.

While the commercial team wants a promotional banner, customer support reports that people are selecting slots that are no longer available. A Developer traces the problem to delayed updates between the slot service and the booking screen.

After discussing the reports with support and exploring options with the Developers, the Product Owner orders the availability work ahead of the banner in the shared Product Backlog.

The banner will have to wait, but both teams now have a reason to coordinate around the same customer problem. Once a change is released, the Product Owner can review booking data and discuss with support whether reports have decreased. Depending on the evidence, the order of the Product Backlog may need to change again.

Now suppose a manager offers to help by taking responsibility for commercial requests. The manager could gather information from stakeholders and prepare options for the Product Owner to consider.

The difficulty arises if the manager independently commits the team to delivering the banner while the Product Owner is prioritizing the booking problem. Even with good intentions, their decisions could pull the teams in different directions because the underlying trade-off has not gone away.

The Product Owner needs support

A Product Owner does not have to attend every meeting or write every Product Backlog item. In the booking example, support can discuss customer reports directly with Developers, who can also investigate options without passing every message through the Product Owner.

Colleagues, including analysts and managers, can gather information and discuss options with stakeholders. Product Backlog management work can be delegated, while accountability for its effectiveness remains with the Product Owner.

When a Product Owner becomes overloaded, understanding which activities require their decisions and which can be handled by colleagues may help reduce the pressure. For example, colleagues could facilitate stakeholder conversations or work with Developers on Product Backlog items, allowing the Product Owner to concentrate on decisions that require their attention.

There is also an organizational dimension. A Product Owner may receive plenty of support and still struggle if stakeholders routinely overturn their ordering decisions. Additional help has limited value when the organization does not respect the accountability assigned to the role.

Where does the product end?

The situation changes when teams are working on distinct products.

Suppose the booking company also offers a scheduling service to hospitals. That service may serve different customers and pursue outcomes of its own. If its product decisions can be made independently of the booking product, it may warrant a separate Product Goal and Product Backlog. Having a different Product Owner could then make sense, even if the products share some technology.

Of course, distinct products do not automatically require different people as Product Owners. One person can be accountable for more than one product, provided they have the capacity and authority to serve each.

Product boundaries are not always obvious. Organizations often structure their work around departments or technical components. Those divisions may be useful for organizing people, but they do not necessarily reflect how value is delivered to customers.

Two offerings might share technology or customers while pursuing different outcomes. Conversely, several teams working on different components might contribute to the same product.

The relationship between the outcomes and the decisions needed to achieve them can help clarify the boundary. When decisions affect several teams contributing to a common outcome, a shared product boundary may make sense. When offerings can evolve independently, separate products may be more appropriate.

This also raises another possibility. If unrelated offerings have been grouped into one product, the Product Owner's workload may be a consequence of how that product has been defined. Additional support might ease the pressure without addressing its source.

When a decision gets stuck

A delayed or disputed product decision can reveal a great deal about how accountability works in an organization.

Two teams might be waiting for a priority decision because stakeholders disagree about which customer problem deserves attention. In other situations, the Product Owner may lack the information or authority needed to make a trade-off.

Understanding the outcome at stake and the teams affected can help explain why the decision became difficult.

If several teams contribute to the same product, the challenge may lie in how the Product Owner receives support and exercises accountability. If the work concerns separate products, their boundaries and accountabilities may deserve another look.

The number of teams alone tells us little about whether a Product Owner arrangement will work. The product boundary shapes which decisions belong together, while the Product Owner's authority and support affect how effectively those decisions can be made.

For Product Owners interested in exploring these accountabilities and the decisions involved, Professional Scrum Product Owner training is available from Agile Way.