Product Owners are great when their team doesn’t need them
Product Owners must escape the Sprint bubble
Often when I watch other Product Owners and notice they spend most of their time with their Scrum Teams, I begin to wonder: “What the hell are they doing?”
Well, what they are doing is obvious upon closer examination.
Like proper disciples of Scrum, they polish the Product Backlog, whip up Sprint Goals, and meticulously prepare refinement sessions.
To outsiders, it looks like everything is going perfectly. The Product Owners are totally immersed in the Sprint bubble like Scrum is the only thing that matters.
When I observe this behavior with Product Owners, I begin to worry. I don’t see them talking to customers. They aren’t attending sales meetings or crunching numbers. All they are doing is pushing the Scrum cart forward, one Product Backlog Item at a time. They don’t have time to do anything else, as their teams always need them, like The Very Hungry Caterpillar.
They don’t have time to analyze data, understand their customers, or attend sales calls. Acceptance criteria must be clarified. Scope changes need to be discussed. Backlog Items need to be accepted.
Scrum can result in a toxic Sprint bubble that incapacitates the Product Owner role. As a result, Scrum teams are limited to becoming a highly efficient Feature Factory. Features are delivered, but nobody knows if they provide value to our customers and the business.
Why are Product Owners often distracted and sucked into the Sprint bubble?
The Product Owner availability misconception
The Scrum.org Open assessment questions can create the false impression that a Product Owner must be available to their team at all times. Just look at the way it is phrased in the Scrum.org Open assessment:
“What must the Scrum Team do when the Product Owner is unavailable?” — Scrum.org Open Assessment
Oh dear, the Product Owner is unavailable. What should the Developers do, now they are left to their own devices? Hit the panic button?
The way the question is phrased seems to suggest that the availability of the Product Owner is crucial. The correct answer stresses the importance of the Product Owner being available, which I think is an incomplete way of looking at it. Especially since the Product Owner is nowadays phrased as an accountability, instead of a role in the newest version of the Scrum Guide.
Expressing the Product Owner role as an accountability opens the door to working without a designated Product Owner, as already proposed by Mike Cohn before the new Scrum Guide was released.
“I think an intriguing and appealing future is presented by the idea that the product owner role could go away. Current product owner responsibilities would become shared across the entire team, much as testing responsibilities are shared today.
I do not believe there is anything inherent in the product owner role that prevents it being shared.” — Mike Cohn, Is It Time to Do Away with Scrum’s Product Owner Role
I believe the whole point of the Product Owner’s accountability is to make his or her availability unnecessary during the Sprint. Scrum is designed in a way that Scrum Teams shouldn’t need you most of the time.
Unconvinced? Let me walk you through a day in the life of a great Product Owner.
A great Product Owner ensures that everyone knows where we’re heading with our product and why
Imagine we have a great Product Owner in our Scrum Team. What does this mean?
Everybody on the team can answer the following questions:
- What is our Product Vision?
- What is our Product Strategy?
- What is our product?
- Who is our customer/are our customers?
- What does value mean for our customers and the business?
- What are our product goals? How will these product goals help achieve the goals of our customers and the business?
- How we increase confidence that what we’re working on will be valuable?
- How do we validate that what we've delivered actually is valuable?
With the right answers to all these questions at the top of our minds, what’s still missing to deliver value?
The Product Owner needs to break down the Product Goals into Sprint Goals together with the teams. Armed with a shared understanding of why our product matters to customers together with clear Sprint Goals, the Product Backlog Items can be created with minimal support from our Product Owner.
During the Sprint, our Developers should rarely need the Product Owner because when they need to make a decision, they should already have sufficient context to make the right decision.
And when they lack knowledge or context, they can ask the Product Owner who provides the missing information or understanding to arrive at the right conclusion. Until the Product Owner is available, they make decisions to the best of their knowledge or ability.
This is what it’s like to work as a self-managing team. Nobody holds your hand, even though you’re in it together. You have to walk an unknown path, fall, fail and pick yourself up again so you can learn from it.
Self-managing teams free the Product Owner up so they can do their real job
When the Product Owner gets trapped in the Sprint bubble, keeping the Scrum train chugging along becomes the only thing that matters. Product Owners should not be too involved with the team during the Sprint. This is the only way you can reap the benefits of self-managing teams.
It’s not that Product Owners don’t care about what happens during the Sprint, but if they focus too much on the Sprint, then they can’t do their actual job, which is figuring out the following:
- A compelling Product Vision that all Scrum Teams working on understand and support
- An effective Product Strategy that describes the biggest challenges our product faces, and how we believe to best overcome them.
- A deep understanding of the problems of our customers and how we can best solve them.
- A pretty good idea of how we can leverage our customer understanding to capture business value.
- A Roadmap that has been crafted to meet our customer goals and business goals optimally.
- There are one or more Product Goals formulated. Product Goals are valuable goals for our product that don’t necessarily fit in a Sprint and need to be broken down into one or more Sprint Goals.
For the Developers, the magic of delivering a valuable product happens inside the Sprint bubble by delivering a Product Increment that realizes the Sprint Goal and meets the Definition of Done.
For the Product Owner, the magic of delivering a valuable product happens outside the Sprint bubble. That’s where Product Owners can make the biggest difference for the team by ensuring we are building the right thing while including our stakeholders.
Product Owners: stop pushing the Scrum cart and escape the Sprint bubble
When you spend most of your time with your Scrum Teams as a Product Owner, you should be wondering what the hell you are doing. You shouldn’t have an active role during the Sprint. It’s what you do outside of the Sprint that counts.
Scrum is like a shopping cart with fresh ingredients. It’s a great start when you’re trying to prepare a magnificent meal, but it isn’t enough. It’s about what you add and how you combine and prepare those ingredients that determine whether you can serve a tasty and delightful dish to your guests. That’s where Product Management practices come into play, which the Product Owner should supply and apply.
Escaping the Sprint bubble is the only way a Product Owner can do their real job: figuring out what problems we should solve for our customers and using this to capture value for the business. If you work with multiple teams as a Product Owner, it’s the only way you are able to survive and make it work.
Product Owners, you should direct most of your attention to everything that happens outside the Sprint, as that’s the only place where you can make a difference. Self-managing Scrum Teams don’t need a babysitter, so please don’t act like one. If you don’t know how to achieve this, please ask your Scrum Master to help you.
When a Product Owner does their job well, everyone understands our Product Vision, Product Strategy, and upcoming Product Goals we are trying to achieve, together with why it is important to our customers and the business.
In some cases, it’s not even about providing answers but teaching your team to arrive at the right conclusion without needing you as a Product Owner. Every question you receive highlights missing information or understanding. You should spend enough time explaining what they don’t know or understand, so the next time they will be able to answer the question without needing you.
It’s not your job to keep the Scrum train chugging along. It’s your responsibility to make sure the train is heading in the right direction without the Scrum Team needing your constant attention.
Do you want to write for Serious Scrum or seriously discuss Scrum?
