Can we have more than one Product Owner?
One of the questions about Scrum I’m often asked is, “Can we have more than one Product Owner per product?” In fact, one of the few Scrum rules about the Product Owner role is,
“The Product Owner is one person, not a committee.” (The Scrum Guide)
Instead of responding to the question by simply reciting this rule, I like to use a metaphor to create an understanding of why Scrum requires the Product Owner to be a single person, and why you should require this too:
Imagine that your Scrum Team is the crew of a rowing boat. There are people doing the hard work of rowing, there’s a person who among other things helps these people create and maintain rhythm and then there’s the person holding the rudder.
The boat is your Scrum Team. The people doing the rowing are your Development Team, the person facilitating rhythm is your Scrum Master, and the person holding the rudder is your Product Owner. The rudder determining the direction of your boat towards a goal is the Product Backlog. The content and ordering of the Product Backlog make visible the decisions of the Product Owner.
With that metaphor established, I like to ask, “What do you think would happen, if more than one person held the rudder?”
People usually get the metaphor quickly, although they often like to explain why things are different in their organization. When this happens, I ask them to stay with the metaphor for a moment which leads to answers like, “The people holding the rudder may not agree / may require time to agree / may have to compromise on where to steer the boat.”
I then ask, “What does this mean for the crew and their boat?” which gets the person thinking about the potential implications. After their first answers, I often ask, “And what else?” to get more nuanced answers. Among these are:
- “The boat might progress slower than it could as the crew have to wait for or clarify direction.”
- “The people doing the rowing might not know where they are rowing to or why.”
- “The crew might try to reach many goals at the same time and might end up not reaching any.”
- “The people waiting for the boat to arrive might become dissatisfied as the boat takes too long to arrive / doesn’t arrive / doesn’t deliver what was expected.
- The crew might not create value as they do not reach a goal / reach a goal too late.
- “The crew might become frustrated, and their morale and discipline might drop.”
- “The organization that sent out the boat originally to reach the goal might stop the initiative”
There are many more versions of these answers and all come down to the same conclusion: Scrum Teams will likely be less efficient in what they do and less effective in what they achieve. Their stakeholder’s expectations will likely not be met. Goals might not be met. The benefits of Scrum, to optimize value, will likely not be seen.
Many times, people tell me that they can’t do Scrum with just a single Product Owner as their product has to meet the goals of many different stakeholders or the scope is just too big for a single Product Owner to understand and manage.
I then ask them if the potential implications they just came up with by themselves go away if they do “Scrum, but with more Product Owners” or if they do something entirely different. That’s when we understand that this isn’t a problem caused by Scrum but made transparent by Scrum.
The conversation then focuses on the fact that you can’t expect the benefits of Scrum without the effort to create favorable conditions. One of these conditions is to be clear and transparent about who’s accountable for maximizing value. This is best achieved through a single accountable person who can make decisions quickly without having to wait for a committee to meet and decide. A single accountable person, so that it’s clear to everyone who they can ask for direction. A single accountable person whose decisions are respected by the entire organization until the Scrum Team can prove the value of that decision. The clarity and speed that come from having a single Product Owner per product greatly increase your chances of success.
So, what can you take away from this post?
If you are a Scrum Master, you are responsible for the implementation of Scrum. If you see this, it’s your job to make this situation and the (potential) implications transparent.
If you are a Product Owner, a Development Team or a manager working with a Scrum Team struggling with this, you shouldn’t hold back. Whatever your role, you can use this metaphor to start a conversation that might lead to improvements and optimized value.
In one of my next blogs, I’ll use a similar metaphor to show the implications of having developers work on more than one team at a time.