This post is part of the Scrum Whys blog series.
“A product owner can be a member of only one Scrum team”
“A product owner must compose every user story”
“A product owner creates all of the requirements for a development team”
“A product owner is the only person that should talk to our customers”
“There are no business analysts in Scrum, so we made them the product owners for our teams”
These are all things I’ve heard from people responsible for implementing Scrum during their organizations’ agile adoptions, and each of these beliefs limits the success and agility you can expect from Scrum. As I explained in Scrum Doesn’t Give You the Kitchen Sink, you’ll see more benefits from Scrum when you apply it as a framework while understanding why the framework requires certain elements and rules.
Scrum requires one owner for a product, and that person maximizes the value of their product by determining what product enhancements are done and when. How they do that will vary greatly depending on a number of factors, like where the product is in its lifecycle and whether it’s an internal or external product. A product in a startup will need a very different ownership strategy than a 35-year-old product in a company that’s been acquired by four different organizations over the years and is now part of a 50,000 person enterprise.
Why Scrum requires one product owner
Scrum is a framework that is intended to be used in complex environments where frequent feedback and decision making are required, and it is optimized for rapid innovation. Having more than one person making decisions about the direction of a product can lead to slower decision making, and it tends to break down communication.
“Better one bad general than two good ones”
– Napoleon Bonaparte
Having one person in charge of the path forward is obviously not unique to Scrum – it can be seen in organizational structures across the world and throughout history. This pattern of leadership, called unity of command in some circles, has been a pattern in military operations for thousands of years, and its breakdown has led to some of the greatest military defeats in history (Want to learn more? Check out The 33 Strategies of War).
Unity of command is applied when a situation requires cohesive vision, quick decision making, and having a single source of truth for the path forward. It also enables efficient communication as information can flow up and down a command structure with minimal distortion. These things enable agility – the ability to respond gracefully and rapidly to changing conditions.
When Scrum is applied with more than one owner for a product…
…it is often done without a clean separation of duties, so the product owners almost always depend on each other in some way. Because they often interface with slightly different stakeholders, they are serving different people and hearing different information. When neither has “tie-breaking powers”, they often get stuck in a stand-still when their priorities conflict. Decisions take longer, and responsiveness suffers as a result.
Stakeholders can also get confused about who they should talk to about the product. Without a single point of contact, they hear conflicting things from the different product owners and are unsure of what is actually going on.
Each product owner optimizes the value of the work their team is doing, but because no one owns the bigger picture, the product owners can cause constraints for other teams. When priorities don’t align, product owners can cause roadblocks for other teams that are doing the work that is truly the most valuable for an organization.
These things are by no means the only downsides to having more than one owner for a product – they’re just the most common from my experience. There’s a solution though – have one product owner for each product. If that seems like a lot of work for one person, then chances are that your product owners are spending too much time in the weeds.
Scrum doesn’t require a product owner to do everything
Everyday product owners have a key decision to make.
- Am I going to ensure the most valuable things are being worked on by my teams? Or…
- Am I going to clarify the work that I’ve already decided will be worked on by my teams?
Most product owners I’ve worked prioritize #2 over #1, and it’s usually not their fault. Those responsibilities have been placed on them by their organization, or they aren’t really accountable for #1 so they let someone take care of it. The problem is, for many products, having one person perform 100% of these responsibilities is not sustainable. After all, product management can involve a lot of work, and many products require multiple people to manage them effectively.
Scrum allows others to work with a product owner to manage a product. The product owner can then focus primarily on prioritization of work rather than clarification, although the product owner still remains accountable for the value that is produced.
Scaling product ownership
There are many patterns for sharing the responsibilities of product ownership. Here are some of the most common:
- One product owner who does all of the prioritization and most of the clarification, working with tech-heavy development teams to do the remaining clarification.
- One product owner who does all of the prioritization plus business analyst skills on the development teams so they are equipped to do most of the clarification.
- One product owner who does macro prioritization plus area product owners who prioritize work in their areas. The area product owners use a mixture of the first two patterns.
- One product owner who does all of the prioritization plus a team of product managers who support the product owner in market research and clarification.
Most scaling frameworks incorporate these patterns in some way. LeSS Huge has area product owners and suggests they shouldn’t be members of more than 10 Scrum teams. Scrum.org’s Nexus framework suggests not exceeding 9 Scrum teams for a Nexus, and a single Nexus is owned by one product owner. You can scale Nexus with Nexus+, and that will likely require a similar product owner scaling structure as LeSS Huge. SAFe suggests that each Scrum team should have an internal-focused product owner and that those product owners should report to external facing product managers, although that approach goes against what we’ve already discussed in this blog and has already been well critiqued by others.
Choosing your product ownership strategy
Having one person be responsible for a product increases the agility of decision making and enables a cohesive path forward, but that does not mean one person has to do all the work of creating the path forward for a product, defining each item on a product backlog, interfacing with stakeholders, and prioritizing work. For many products, the responsibilities required to successfully manage a product are too much for one person, which is why product owners in Scrum are often supported by their development teams and other people with product management and business analysis skills. In those situations, the product owner is focused more on determining priorities rather than clarifying and detailing product backlog items.
Choosing your product ownership strategy is a matter of determining the speed of decision making, clarity of communication, and cohesiveness of vision required for your environment.