Scrum Guide says, “The Product Owner is one person, not a committee.” However, many times, teams often seem to want multiple People acting out as a product owner for same Product. This usually happens when product starts getting bigger and more complex. In this article we will discuss why the Scrum Guide says Product Owner is One Person and NOT a Committe.
Why Some Scrum Teams May Want Multiple Product Owners within a Single Product
While it sounds counter intuitive, some Scrum Teams plan for multiple product Owners within a Single Product. I have seen some Scrum Teams quote reasons like below to have more than one Product Owner. Some Teams go even further and want multiple Product Owners even within same Scrum Team!
- Complex Business Domain – Business domain is complex and one person may not have end to end knowledge. Sometimes One person may not be even capable of explaining all the functionality to the Developers.
- Multiple Time-zones – Sometimes Scrum Team is distributed and pans over multiple time-zones. It then becomes difficult for a single person to be available to all scrum team members. A variant of this is where we have stakeholders in one time zone and rest of Scrum Team Members especially Developers in another time zone
- Too much work – Sometimes product owners do not have the bandwidth to do all the work needed to keep the Product Backlog healthy
Disadvantages faced when you have Multiple Product Owners
- Diluted Ownership – Multiple Product Owners usually will end up with diluted ownership. When there is a Single Product Owner, there is only one person accountable for the Value. When we have multiple Product Owners, it may lead to a “blame game” culture within the different Product Owners
- Delayed Decisions – When there are multiple Product Owners for a Product, coordination and alignment work will increase. This will lead to delay in decisions.
- Conflicting Directions for the Scrum Team – With many decision makers, the Developers may get conflicting directions.
- Increase in Rework – Conflicting directions may end up increasing rework.
- Encourage “Part time Product Owners” – I have seen that when the Scrum Team believes that they can have multiple Product Owners, It leads to stakeholders taking on “Product Owner Job for a specific part of the Product. This means being a Product Owner is an “additional responsibility” for the said person. In such cases often there are issues with the availability of the said Product Owner for the Scrum Team needs.
Scrum does not list out these reasons. However, Scrum equivocally does state that Product Owner is One Person and NOT a Committe.
Is it OK to have Multiple Product Owners For Multiple Teams Working on Single Product?
The situation is little different when the product starts growing and becomes big enough to need multiple scrum teams. In such a case, all the reasons stated above by scrum teams to have multiple product owners for a single team have increased multi fold. However, scrum does not still recommend having multiple product owners for a single product. When there are multiple scrum teams working on the same product, they should share a product backlog. This means they should share a product owner. To read more about how to scale up the Product Owner role for a large Product please read this article.
Product Owner is One Person and NOT a Committe – Suggestions To Make it Work,
While we agree that multiple Product Owners are not recommended, the problems stated above indeed are true. Here are some suggestions that may help to deal with these issues
- Build Product Knowledge within Developers – It helps if Developers have basic knowledge of Product and the Business Domain in which the Product operates. Then the Developers can help to help in adding details to some product backlog items. With the enhanced knowledge, Product Owner will need to spend less time in clarification to the Developers.
- Encourage Direct Communication between Developers and Stakeholders – In many cases, I see that Product Owner becomes an intermediatory between the Developers and the Stakeholders. Product Owner remains accountable for Product Backlog and when in doubt Developers should follow the recommendation by Product Owner to decide next piece of work then can do. However as long as Developers and Stakeholders keep Product Owner in loop, a direct communication between them will reduce a lot of unnecessary duplication of effort.
- Keep the Product Backlog manageable. Many times Product Owners find it difficult to say “no” to work. Rather than saying no they add those items to Product Backlog and keep on ordering them towards bottom of the Product Backlog. This may seem like a non-controversial way to manage stakeholders. However, it does add to overheads of constant discussions and ordering activity.