Discover more from Maarten’s Newsletter
Resolving the one Product Owner per product conundrum
Does a blanket rule of one Product Owner per product fit with the situational character of Product Ownership?
Let’s start by asking some simple questions for a company using Scrum to build a single product with ten teams:
Who is accountable for the Scrum implementation?
Who is accountable for software quality?
Who is accountable for software architecture?
The correct answer to all these questions would be: there isn’t a single person accountable.
Let me provide the textbook Scrum Guide answers:
Scrum Masters are accountable for establishing Scrum as defined in the Scrum Guide (unless a single Scrum Master suffices for the number of teams).
The Developers are accountable for the quality and software architecture.
To prevent possible confusion: accountable and responsible aren’t synonyms.
To give a simple example: imagine I need to give an important presentation to the CEO and delegate the responsibility of making the presentation to someone on my team. The person on my team isn’t able to deliver and as a result, I show up empty-handed to my meeting with the CEO and look bad.
Do you think the CEO cares why I didn’t have a presentation ready? He holds me accountable, even though someone else didn’t pull through on their responsibility.
When someone is accountable, they are ultimately answerable for something. When someone is responsible, they carry responsibility for something happening. When you’re responsible for something happening, it doesn’t automatically mean you’re ultimately answerable (accountable) and vice versa.
Now that we have refreshed our memory on the difference between accountability and responsibility, how does this apply to Scrum?
In Scrum, a single Scrum Master is appointed as accountable at the team level. Once you go beyond the team level with multiple Scrum Masters working together on the same product, then all Scrum Masters together become accountable for the Scrum implementation at the organizational level.
Many accountabilities in Scrum belong to groups of people, which makes sense considering Scrum centers around self-managing teams. Everything concerning delivery is a team effort without a single person being accountable.
But even in the world of Scrum, there are exceptions to team accountability. The moment we slap on the word ‘Value’ and begin discussing value delivery, Scrum does a 180-degree turn in terms of accountability. Let’s show this by asking ourselves the following question: who is accountable for maximizing the value of the product?
When we talk about maximizing the value of the product, then it mysteriously no longer becomes a team effort. Scrum requires a single set of vocal cords no matter how many teams work on the same product: the Product Owner.
Scrum is all about self-managing, empowered teams, yet it always requires a single ‘Value Babysitter’ for the whole product. The same isn’t required for anything else. There is no ‘Scrum Owner’, ‘Architecture Owner’, or ‘Quality Owner’.
What’s interesting is that people can simultaneously hold the belief that a single Product Owner for ten teams is an effective solution, but then if you ask if a single Scrum Master can handle ten teams, those same people will claim that you’re crazy.
Is Scrum’s requirement to have a single Product Owner per product outdated? Is it at odds with the self-managing nature of Scrum Teams? Is it strange considering all other accountabilities in Scrum except the Product Owner can be shared by multiple people?
The answer to all these questions, in my opinion, is yes. Let’s start by digging into the accountability of the Product Owner.
How far-reaching is the accountability of the Product Owner?
Things get even more complicated when you reflect on the fact that Scrum is a framework that helps with the delivery of value. Delivery of value doesn’t exist in a vacuum. Nearly everything the Scrum Team does affects the delivery of value, e.g., their decisions on quality and architecture also affect the value of the product.
When you keep these considerations in the back of your head, then it’s safe to say that the Product Owner should have far-reaching tentacles in everything the Scrum Team is doing. Product Ownership isn’t a passive role where you can sit back and let the Scrum Teams work their magic.
It doesn’t matter if you work with 1, 10, 100, or 1000 teams. If all of these teams work on a single product, then all that responsibility rests on the shoulders of a single Product Owner.
Does a picture of Atlas carrying the world on his shoulders come to mind yet?
Why does Scrum go for the Atlas solution of requiring a single Product Owner per product to maximize the delivery of value?
The single Product Owner per product is a solution to a particular problem: the desire to have a single interface and value decision-maker for all Scrum Teams working on the same product.
The aim of appointing a single person as accountable is to prevent communication issues and long debates around what we should best be doing, resulting in noise and inaction in the Scrum Teams. It forces demanding stakeholders to all go through the same person. Plus, it allows global optimization of the product’s value versus limiting yourself to local optimization at the team level.
However, as Scrum grows in popularity worldwide, the original vision for the Product Owner role is beginning to show its age. Companies rarely have a single Product Owner per product in practice.
Why is the reality of the Product Owner role different than the theory?
Does the one Product Owner per product approach scale?
Now let me ask a different question: do you think one Product Owner per Product approach scales beyond a handful of teams?
It absolutely does not.
From personal experience, I have handled a maximum of 5 teams at once, and that’s when I told my manager: “If I need to do this for another six months, I quit”. I was constantly running, stressed, and never completely on top of things. It felt like everything was continuously burning and I always arrived too late.
When I talk to other Product Owners, their limit is usually around 2–4 teams, though I have heard of anomalies who claim they can handle 10 teams. But you have to wonder if they really can keep all these balls successfully in the air.
I’ve also never worked at a single company with 5 teams or more, where only one Product Owner was in play. I talk to many companies all over the world and none of them tout having a single Product Owner per product there either (unless they have a few teams). I only hear about these illustrious Product Owner superheroes on LinkedIn through comments.
Sure, you can chalk this all off as anecdotal evidence, but let’s take a look at different scaling frameworks and how they scale the Product Owner role:
LeSS Huge: A single Product Owner works together with Product Area Owners.
SAFe: Product Owner and Product Manager work together.
Nexus: approximately 3 — 9 teams and 81 people for each Nexus with a single Product Owner belonging to a single Nexus.
Scrum@Scale: Chief Product Owner works together with Product Owners.
All of them provide solutions for the one Product Owner per product conundrum (the SAFe solution sucks though).
I believe the one Product Owner per product solution, depending on the context, can be a fantasy that doesn’t work. Why and when doesn’t it work? And what should we be doing instead?
To answer these questions, let’s put the Product Owner role aside for now, and let’s think about how Scrum Teams should work together to maximize the delivery of value.
Delivering value is a team effort that requires Product Management expertise in the teams
Let’s start by turning to our trusty old friend the Scrum Guide. I will quote the relevant passages and break them down into simpler terms.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals — Scrum Guide 2020
We already covered this before. The Product Owner is accountable for the teams delivering as much value as possible in the product. The next part dives deeper into what this exactly entails:
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood. — Scrum Guide 2020
What’s interesting here is that the Product Backlog is defined as follows:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. — Scrum Guide 2020
What’s important to keep in mind, the Product Backlog is what the team will be working on. The Product Backlog doesn’t magically get conjured out of thin air. How do you arrive at an ordered Product Backlog?
No answers here in the Scrum Guide.
Building a Product Increment is a slow way of getting feedback. There are many steps you should perform before you start building. Scrum doesn’t prescribe these because it’s a framework for delivery, it doesn’t tell you what you do before you deliver something or afterward when you need to validate what you delivered.
I want to stress, I’m not claiming you can’t do discovery or validation during a Sprint. I just don’t believe all discovery and validation can and has to happen in the same Sprint where you produce the Product Increment.
Ideally, you should try to bring discovery, delivery, and validation as close as possible to each other, but it’s rare that all three are possible in the same Sprint. Especially considering the proof of the pudding often lies in lagging indicators that change over a longer time period than a single Sprint.
And then here is where it gets interesting:
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. — Scrum Guide 2020
Great news! Everything the Product Owner does may be delegated, but then the Scrum Guide starts making things murky again:
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner. — Scrum Guide 2020
Wait let me make sure got it right: The Product Backlog management can be delegated, but the Product Owner must be a single person AND when you want to change the Product Backlog, you have to convince a single Product Owner?
Does running every change to the Product Backlog through a single Product Owner sound effective to you? It’s a bottleneck by design, which means it isn’t a robust or scalable solution.
Could we do better than having a bottleneck by default? Should you really have to convince a single Product Owner whenever you want to change something to the Product Backlog?
Empowered and self-managing teams shouldn’t be limited to delivery
To be fair, the Scrum Guide also has the following passage that acknowledges the importance of self-managing teams that focus on the delivery of value:
"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint" - Scrum Guide 2020
However, this is limited to the context of the Sprint and the creation of the Product Increment. It is important to be aware that the Product Increment represents the whole Product (including all Sprints before and the current Sprint).
Though I can’t be sure, my hunch is there is a clear separation of concerns between the Product Owner ‘maximizing value’ accountability across all Sprints and the Scrum Team accountability to deliver a valuable increment during a single Sprint.
The Product Owner is accountable for the global optimization of the value of the product.
The Scrum Team is accountable for local optimization of Product Value — delivering a valuable increment during the Sprint.
I want to stress, since all responsibilities of the Product Owner may be delegated to the Scrum Team, then it’s possible that the Scrum Team is ultimately responsible for maximizing the value of the product. However, they still will never be accountable.
If we agree the Product Owner is defined by its accountability and must be a single person, and that we can distribute the responsibilities as we see fit. The next question then becomes, how can you scale the Product Owner role?
Let’s walk through three different solutions to the problem.
Solution 1: Your Product is too big and should be split into smaller Products
The Scrum Guide defines a product as follows:
“A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” — Scrum Guide 2020
This definition is so generic you could get away with splitting your Product into different areas and claiming each of them is a ‘Product’. Voila, a new product! All you need is a clear boundary, and all the stakeholders, users and customers can remain the same.
I don’t think splitting a product into artificial sub-products is a good way of solving the problem and I don’t believe it aligns with the intent behind Scrum Guide’s product definition, but I can’t be sure.
Splitting a product into artificial sub-products to make scaling possible means you’ll still run in the global optimization of the product vs. local optimization of the sub-products problem.
If people are only accountable for parts of the product, then nobody is responsible for the overall product, and as a result, maximizing value over the whole product becomes difficult. As a consequence, I don’t think this solution makes sense unless there is someone who is accountable for the overall Product. Who is accountable for all Product Owners across all products in this scenario?
Even in the case where a single product really can be split up into multiple products that interact closely together, then you still run in the same global vs. local value optimization problem. Except it will be on the portfolio level instead of the single product level.
In such a scenario, there will be no one accountable for the overall value of how the different products interact with each other, leading to the same issues the single Product Owner per product is supposed to help resolve. These issues just happen at a higher level: the portfolio (multi-product) level instead of the single product level.
Solution 2: Multiple Product Owners on the same Product
I don’t believe that being a Product Owner is something you can easily delegate to others. It’s a demanding role. I still struggle with aspects even though I have been performing the role for many years.
The multiple Product Owners on the same Product is extremely common. Technically speaking, none of them are Product Owners as they lack the final accountability. However, they are all performing the responsibilities of the role. The single person who is accountable will ultimately be the real Product Owner, at least according to the Scrum Guide.
The real Product Owner is usually the person with the most accountability in the Product Team for the product(Chief Product Officer, VP of Product) or sometimes even the CEO. It depends on who is considered ultimately accountable for how the whole product is performing in the organization.
From Scrum Guide’s perspective, accountability determines the title of Product Owner. It doesn’t matter who performs the responsibility. However, in the real world, people give the Product Owner title to people who perform the responsibilities that belong to the role.
Solution 3: No Product Owner but Product Management expertise part of teams
All the Product Management expertise necessary to deliver value is part of the Scrum Team, without any Product Owner to call the shots.
I think this scenario happening will be rare. It’s difficult to find a single person who is awesome at all facets of Product Ownership. Product Management is a broad field with a lot of depth. When a whole team takes on parts of the role, you can play to everyone’s strengths and cover more ground than if there is a single person trying to have expertise in all the facets of Product Management.
Mike Cohn has written about this before in ‘Has the Scrum Product Owner Role Run Its Course?’.
To sum it up: a single Product Owner per product only works for small products
The Scrum Guide defines the Product Owner role as an accountability meant for only a single person per Product. Whoever actually performs the responsibilities doesn’t matter from the perspective of Scrum, as long as they are part of the Scrum Team.
However, the big problem is that in the real world everybody who does the responsibilities STILL labels themselves a Product Owner. And I believe that’s a reasonable stance. When you do all the work and cover the responsibilities, why can’t you claim you are a Product Owner?
In theory, the Product Owner role is defined by your accountability, in practice, it often is defined by your responsibilities.
Let’s also think about this logically: it’s way more important that you have one or more Product Owners that perform the responsibilities rather than a single person who is accountable.
If you only have a Product Owner who is accountable but nobody who takes on the responsibilities of the Product Owner, then you will struggle to deliver value. If you have multiple Product Owners who are responsible, but nobody who is accountable, then you can still deliver value. You might make some suboptimal decisions due to being unable to reach an agreement together.
Product Management expertise being part of the Scrum Teams is essential, no matter what solution you go for. A choice for Scrum means you are doing complex work and the aim should be to have feedback loops that are as short as possible.
Whether you achieve that by having multiple Product Owners, Product Managers part of the Scrum Teams or by simply having teams who can cover all the essential Product Management expertise together doesn’t really matter. The result is the same: the Product Management expertise is part of the Scrum Teams and they have all skills necessary to make short feedback loops towards the delivery of value possible.
I believe even the Scrum Guide is unclear about the difference between calling someone with the accountability the Product Owner or someone with the responsibility:
Those wanting to change the Product Backlog can do so by trying to convince the Product Owner. — Scrum Guide 2020
This sentence doesn’t make sense unless they are talking about those who perform the responsibility of the Product Owner. I can’t imagine they mean that every change in the Product Backlog has to run through a single person regardless of how many teams are working on that Product. Otherwise, this conflicts with the delegation of the Product Owner responsibilities statement also present in the Scrum Guide.
When you have a big Product, there are often multiple Product Owners who do all the same work as a Product Owner for a small Product, but they are not allowed to call themselves a Product Owner according to Scrum because they lack the final accountability.
Such a Product Owner could easily join a company that is smaller and then suddenly you would be allowed to call yourself a Product Owner, while the only thing that has changed is your accountability.
When few Scrum Teams are working on the same product, the accountability and responsibilities of the Product Owner role usually overlap and belong to a single person we call the Product Owner.
As the number of Scrum Teams working on a product grows, the responsibility of the Product Owner shrinks until ultimately only the accountability of the role remains. We still call this person the Product Owner, even though others are handling their responsibilities now.
The flip-flop that happens based on the number of Scrum Teams working on the same product is highly confusing. The distinction between accountability and responsibility is already difficult to understand, let alone that depending on the context, sometimes responsibility and accountability belong together in the Product Owner role, and sometimes they do not.
I believe the Scrum Guide should be amended to make the distinction clearer. Here’s what I would propose to change in the Scrum Guide, let’s label it pragmatic Product Ownership for now:
Allow a single product to have multiple Product Owners. However, allow only a single Product Owner to be designated as accountable. Make it clear this person is meant to resolve disagreements and make sure we go for a global optimum in the delivery of value with our product and not a local optimum.
In the real world, large products already have multiple Product Owners working on them. We can try to deny this and wave our Scrum Guide in front of them, but I believe that won’t change. With this solution, you assign one of them as accountable and the problem is solved. Ideally, you let them self-organize to figure that out but your org chart may not permit that.
Scaling the Product Owner role is a big problem for companies. The Product Owner's responsibilities can’t be easily pawned off to teams who lack the expertise or knowledge to carry the burden of the role.
Without considering the situational nature of the Product Owner role, the rift between the theory of Scrum and the real-world application will grow. People don’t get the Product Owner role accountability/responsibility mess, as created by the unclear presentation in the Scrum Guide.
We can either blame the people or try to make it clearer.
Transparency, inspection, and adaptation? Or is that only something that applies to Scrum Teams and not Scrum itself?