Scrum Created the Product Owner and Spawned a Myriad of Conflicting Functions
There are many different types of Products Owners — Not all of them respect Scrum
There are many different types of Product Owners — Not all of them respect Scrum
The Product Owner is one of the three accountabilities of Scrum. According to the most recent Scrum Guide, this accountability entails the following:
“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.
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
There’s surprisingly little to unpack here. Only a few things make a Product Owner:
Accountability for maximizing the value of the product resulting from the work of the Scrum Team. This last part is crucial. It implies the Product Owner is NOT responsible for maximizing the value that is not from the Scrum Team.
Effective Product Backlog Management, which includes setting a Product Goal, creating, communicating, ordering Product Backlog Items.
Based on this minimal description of the accountability, the many shapes and forms of the Product Owner came to life. You will find Product Owners who are merely putting the wishes of others into words. Other Product Owners have total control over the direction of the product. If you wish to find a Product Owner for your product, it is not a good idea to hire someone only based upon the fact they claimed to have filled this accountability. It doesn’t say anything.
To bring clarity, I will discuss all variations and assess if these comply with the definition of the Scrum Guide. If not, I will address why this is an issue. I will also discuss the pros and cons of the variations.
Product Scribe
This Product Owner channels the wishes of others. She works with someone else’s product roadmap. This other person could be a Product Manager, a Project Manager, the CEO or anyone who owns the product vision and product planning. The Product Owner ensures the Scrum Team members understand what is needed for the product and in what order. This is the definition of a Proxy Product Owner or a scribe.
This type of Product Owner does not meet the Scrum criteria. You could argue she may be accountable for maximizing the value of the product resulting from the team. But if others determine the priority of items, this is not the case. On top of that, it is not the Product Owner but someone else who determines the Product Goal and order of the Product Backlog Items. You can’t make someone accountable for other people’s decisions.
This type of Product Owner is an anti-pattern. Someone else is the real Product Owner, delegating the work to a proxy. If this true Product Owner is close to the team, this is not ideal but also not a disaster. But if this person is far away, the Scrum Team is only cranking out functionality without proper ways to understand if they are on the right track and without options to adjust course.
Component/Feature owner with one team
This type of Product Owner serves one team. The team is working on a feature or component of the product. Multiple Product Owners together determine the course of their piece of the puzzle. They don’t control other aspects of the product.
As an example, Joe is a Product Owner. His team is responsible for a type of report of the payment product. His colleagues Anna and Jeena are responsible for different reports. Together, they are responsible for the reporting solutions of the payment product.
This type of Product Owner may be able to maximize the value of their piece of the puzzle and they may fully own the Product Backlog. They even align with the description of a Product Owner in the Scrum Guide. Their piece of the puzzle fits the Scrum Guide’s description of a product too:
“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
But it is crucial to look at what a product actually is. This quote from Roman Pichler answers it for me:
“I don’t go to Amazon to search or checkout. I want to buy the right product at the right price with minimum hassle.” — Roman Pichler
With this in mind, this type of Product Owner is Component Owner or Feature Owner. They don’t have the view and authority to cover the complete product. Maximizing the value of their piece of the puzzle doesn’t guarantee these are the best choices for the product as a whole.
This type of Product Owner also triggers another anti-pattern: generating work for the sake of giving something for the team to do.
Component/Feature owner with multiple teams
As a Product Owner, you work together with one or more teams. You determine the course of a software feature or component. You don’t control other aspects of the product.
This type of Product Owner has slightly more reach than the previous example as she is the only one responsible for a larger aspect of the product. But the same issues arise in the context of the complete product. This type of Product Owner is still a Component or Feature Owner only. With that, there’s a risk of silo-thinking and misalignment.
Still, this Product Owner does fit into the definition of the Scrum Guide. But it is not an ideal situation.
Core Product Owner
As a Product Owner, you work together with one or more teams. You determine the course of the core product. You don’t control other aspects of the product.
As an example, a Product Owner can be responsible for the Amazon webshop. You have every functionality in scope, from search to checkout. However, the delivery of the goods is not part of your responsibility. You could argue that delivery is part of the product that Amazon offers to its clients.
This type of Product Owner has considerably more reach than ones I discussed until now. She has the responsibility for the complete core product. She also has a good view of the opportunities and threats for the product.
Still, this Product Owner doesn’t have the full product experience in scope. It is only the core part of the product. There’s still a chance of misalignment and silo-thinking. But the risks are lower than in the previous examples.
This type of Product Owner fits the Scrum Guide description, although she doesn’t have the overall product experience as a responsibility.
Product Experience Owner
Someone in the organisation determines the company vision. Based on this vision, the Product Owner creates a product vision and Product Goal. The person has full ownership of the direction of the complete product experience.
For example, this Product Owner is responsible for the Amazon webshop and also looks at storage and delivery.
This type of Product Owner ticks all the boxes of what the Scrum Guide describes for this accountability. She doesn’t OWN the product vision but has full responsibility to make the decisions about this product based on that vision.
Product Vision Owner
This type of Product Owner owns the company vision, the Product Goal and is fully responsible for the complete product experience. Typically, this person operates at C-level.
This is the person who fits the name of the accountability. This is a true Product OWNER. This fact in itself doesn’t impact how this person can fulfil the Product Owner accountability. This Product Owner type in essence is similar to the previous type. It ticks all the boxes as described in the Scrum Guide.
Takeaways
I hope you got the following takeaways from this article:
The Product Owner is not a function. It is an accountability within the Scrum framework. It comes in many different shapes. The Product Owner could be the visionary in the company. But it could also be someone who weighs all wishes from stakeholders based upon other people’s visions to make the best choices for the product or product feature/component.
That said, there are also many implementations of this accountability that miss the mark. When the Product Owner doesn’t have the last say about Product Goal and ordering the Product Backlog, she is no more than a scribe. Someone else is the real Product Owner delegating responsibilities to the Product Owner in name only.
One set of vocal cords
I love how Alistair Cockburn — one of the creators of the Agile Manifesto and creator of Heart of Agile — put it:
“Make sure there’s only one set of vocal cords who answers questions and gives guidance to the team” — Alistair Cockburn
It brings forward why Scrum has this accountability. It is to avoid multiple people bringing conflicting messages to the team. It is to shield the team and help bring focus. As long as the Product Owner can achieve this, she does what she is supposed to do. In the end, it is not about owning the product, but about owning the responsibility to maximise the value of the product.
Original article Feb 2021