Many Product Owners, One Product

Many companies decide to give many people different pieces of the product owner role. Organizations often do this because that’s what they did in the past when they used waterfall practices. They believe there isn’t a single person in the organization who knows all the domains necessary to develop a product, nor anyone who has all the skills to work with development teams, stakeholders, and customers. (Those may also be separate duties in reporting structures.) So the product owner role gets split across multiple people to ensure each gets a say in how the product is built.

The product owner committee comes to the table with competing interests: technical, departmental, customer, political, organizational, etc. Eventually this leads to debates about what to build next. Each product owner has his or her own interests in mind and it’s often difficult to get anyone to admit that an idea other than their own is most important. These stalemates get escalated up the org chart until someone with a big enough title gets tired of all the noise and makes a snap decision. These games take precious time which often leads to waste, turmoil, and creating products that no one wants.

You may also experience multiple product owners “owning” their particular team or area of a product within the bounds of a single product. The segregated product owners become isolated doing what they want, and as a result, there’s no holistic view of what the product should be. This will result in an incohesive product for your users and likely a disjointed architecture laden with technical debt.

With one and only one product owner, the development teams know what work is truly important for the product and what they should be focused on. There is a holistic view, both within the Scrum team and to stakeholders, of where the product is now and where it’s heading in the future because there is one person guiding it. The sole product owner gathers stakeholder and customer feedback and incorporates potential changes into the product backlog. And decision making isn’t stalled by competing interests.

Does having multiple product owners on a single product sound familiar? We’ve been through this many times and know the pain that it can cause. It’s important for you to work with your organizations to show how vital it is that a product owner must be a single person who listens to stakeholders and customers and then makes decisions centered around the overall value of the product.

If you’re dealing with a product owner committee (or the prospect of one), do everything you can to change that. Share the story at the beginning of this chapter with management to help them understand the problems such a committee will cause. More than once, we’ve seen platforms crash because of competing interests or disparate functionality and the downstream problems that ensued. It takes the Scrum value of courage to approach this issue with management and the multiple product owners. But trust us: this is a cause worth fighting for.

Something we find to be useful in this situation is to trace the money. Find out who owns the budget and has final say on all decisions—that person is the real product owner. Have a conversation with them highlighting the difficulties caused by having multiple product owners, and explain why having a single product owner is a better approach. By tracing the money, you’ll find the right person to have this conversation with.