The Way of the Lazy Product Owner
The Way of the Lazy Product Owner
Don't Make Yourself the Center of the Product Owner Universe
See that Corgi brimming with energy and excitement standing on the railroad tracks, blissfully unaware of the speeding train heading their way?
That Corgi was me many years back.
After facing hundreds of rejections, I finally started my first job as a Product Owner. I was confident I would do a great job and rise to the occasion.
Fast forward to six months later, I was in despair and talking to my manager: “Six months more like this, and I quit.” My manager was surprised by the statement.
What happened in between to turn me from ecstatically happy to utterly miserable?
Being a Product Owner for Five Teams Sucks
I started as a Product Owner for a single Scrum Team. Within a few months, I was promoted to Product Owner for five Scrum Teams. I quickly started to hate my job.
I spent most of my time in meetings. I always was a step behind, no matter how hard I worked. Every day felt like I was busy mopping the floor to get rid of water while the tap continued to run. Working my ass off to perpetuate a never-ending chain of cleaning up messes and firefighting was demotivating.
To make matters worse, some of these messes and firefighting were my creation because I did not have enough time. I had too many Scrum Teams under my belt for my experience level. The team maturity and the hypergrowth scale-up environment we were operating in didn’t help either.
Many years later, I’ve figured out how to work comfortably with around 3 Scrum Teams. I’m working in a completely different way than when I started.
Enter the way of the lazy Product Owner.
I want to share the five most important lessons I’ve learned to help you succeed with multiple Scrum Teams as a Product Owner.
#1. Build Empowered Scrum Teams That Drive the Delivery of Value
In the Scrum Guide, the following is written:
“The Product Owner is 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
However, the critical part of this section immediately follows afterward:
“The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. - Scrum Guide 2020”
Effective Product Backlog Management is necessary for the Scrum realm. It’s to keep the Sprint going in the right direction. However, nothing in Product Backlog Management ensures you’re working on the right thing or building a valuable product. That’s highly situational and dependent on your context, and Scrum doesn’t provide any answers for what you have to do.
However, the Scrum Guide also contains the following sentence:
“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”
This is a nice way of saying it’s all up to the Product Owner to discover what’s necessary to maximize value delivery. You’re on your own, and don’t expect answers from Scrum. This is the realm of Product Management that should supplement Scrum in the realm of discovery, delivery, and validation.
What does this mean for you as a Product Owner? You should spend most of your time and energy on the Product Management part of being a Product Owner. You should work in a way that the Scrum Team needs you as little as possible. This makes it possible to focus on the difficult Product Management part of figuring out how to deliver customer value that you can capture as business value.
#2. Move From Stakeholder Management to Stakeholder Inclusion
Depending on your environment and stakeholder management skills, your stakeholders can cost you a lot of time and even be plotting against you.
Here’s a matrix you can use to plot your current stakeholder situation:
When the Product Owner is terrible at saying no and poor at stakeholder management, you’ve got yourself a Ticking Time Bomb! It’s a matter of time before the situation explodes.
Imagine you have a Product Owner who is excellent at saying no but sucks at dealing with stakeholders. Your stakeholders will start undermining you, and you will have a Stakeholder Sabotage situation at hand.
If the Product Owner dislikes saying no but is excellent at pleasing stakeholders, you’ll have Stakeholder-driven Development. What’s quite surprising, these Product Owners often stay on for quite some time because everybody likes them until the ‘Rubble of Too Many Yeses’ becomes noticeable. And even then, they sometimes get away with it by being sufficiently likable and adept at politics.
If you have a Product Owner who is excellent at saying no and maintaining healthy, collaborative relationships, you’ll have Stakeholder Inclusion. Everybody is working together towards the same goals.
In essence, Product Ownership is the art of keeping everyone happy while you’re not giving them exactly what they want. The best way to do this is to include your stakeholders from the start to set the expectations on what we all want.
Here’s my journey in stakeholder management plotted on the matrix:
I started as a Ticking Time Bomb. I didn’t know what I was doing and wanted to please people. I was flooded with requests, not keeping promises, and disappointing many people.
I became annoyed with all the broken promises, so I swung the other way: I promised as little as possible. My default stance was to say no. Stakeholder Sabotage was imminent.
To mend relationships, I tried to give them what they wanted and listen more. Stakeholder-driven Development back-fired as we’d ultimately not be working on the most valuable things.
Instead of seeing stakeholders as adversaries, I began to work together and collaborate on the Product Vision, Strategy, and Roadmap. There was Stakeholder Inclusion, and if we had to make tough decisions, everyone understood why.
Delivering value with Scrum is a team effort that extends not only to the Scrum Teams but also to your stakeholders. By actively involving them in the Product Vision, Product Strategy, and Roadmap, you will no longer have to say no, as they will be in the same boat with you.
When there is buy-in and common understanding on the above, when they come up with an idea, they’ll first think: how does this fit with the Product Vision, Product Strategy, and Roadmap that we’ve agreed upon?
Get them to already say no to the idea in their mind, and you won’t even have to say no.
#3. Keep Your Product Backlog Short
I once arrived at a Product Backlog that looked like this sheep: like an absolute unit.
Every item on your Product Backlog is like a little monkey on your back that you have to feed bananas to keep alive. These little monkeys require constant attention and will distract you from what matters.
To make matters worse, Product Backlog Items become stale. The moment a Product Backlog Item is created, it is fresh with the latest insights and understanding. Then, as it lingers, by the time you pick it up, it may destroy value in your product because your whole situation has changed.
Don’t worry about missing out on good ideas. Great ideas will come back. You should worry about good ideas turning bad and returning with a vengeance to distract you from what truly matters.
#4. Collaborative Refinement
When I started as a Product Owner, I was proud to have experience as a Business Analyst. I would take an epic, split it up in Product Backlog Items and try to write perfect acceptance criteria.
When I presented a Product Backlog Item without receiving any questions from the Development Team, my heart made a little leap of joy.
Then, when the Development Team picked it up, it turned out they hadn’t been paying enough attention. Because it all looked great and seemed like I knew my stuff, people weren’t paying attention and tuned out.
Instead of throwing requirements over the fence, I now work together with the whole Scrum Team. I start with what we’re trying to achieve and why it matters. Then we have a conversation about splitting up and refining the work together. The acceptance criteria are ours, no longer just mine as a Product Owner.
When you write and refine collaboratively, what we’ve written down stops mattering. Everybody knows what we created together, and the acceptance criteria remind us of what we already know.
#5. Escape the Sprint Bubble
You should work together with your Scrum Teams, so they need you as little as possible to make decisions during the Sprint. We talk about Empowered Product Teams in the world of Product Management, but that’s the same as Self-Managing Scrum Teams. All the expertise necessary to deliver customer value and capture that business value should be part of the Scrum Team.
What does this mean in practice? Whenever you get a question from one of the Scrum Teams, ask yourself the following question: why are they not able to answer this question without needing me?
Is the Product Vision unclear?
Is the Product Strategy missing?
Is the roadmap not understood to the same level by everyone?
Do I have a better understanding of the customer than the Scrum team?
Whatever the reason, instead of answering their question, try to understand whether they are missing certain information or have all the information available to come up with the right answer.
Every question you receive from the Scrum Team potentially highlights missing information or understanding. Instead of simply answering the question, spend more time explaining the context and giving more information so the next time, they won’t have to ask you a question.
Empowering teams as a Product Owner means that they need you as little as possible to arrive at the right answer. It’s not that your expertise isn’t welcome, it’s that it ultimately slows things down, especially if you’re working with many Scrum Teams.
#6. Create a Safe Environment
Lots of Product Owners are bullies who pressure their teams to deliver more. Product Owners who do this spend most of their time in Sprint Planning and Refinement sessions. Why does this death by meetings happen to them?
Their Scrum Teams turn into scared and hungry caterpillars. Scared of being punished for things taking longer than expected, every detail is endlessly discussed to be sure we’re not missing something. You end up discussing the same Product Backlog Item endlessly in refinement.
Complex work means there will be surprises, and things will take longer than expected. What you didn’t know yet is discovered, and no matter how much you will prepare, this is bound to happen. Instead of punishing team members for something inevitable part of the work, work together with them to resolve obstacles.
When you throw your Scrum Team for the stakeholder sharks as a Product Owner, everything will cost more time, and everyone will be more unhappy. Work with them instead of against them. You’re sharing the same trenches with the whole Scrum Team.
The Way of the Lazy Product Owner Means Building Empowered Teams
I didn’t mention the elephant in the room: where do these unrealistic expectations of the Product Owner role come from?
Scrum expects one Product Owner per Product, regardless of the number of teams. Anybody who has ever been a Product Owner knows not having a limit is insanity. It’s that obvious for Product Owners, yet baffling enough it seems to be counter-intuitive for others in the Scrum community.
Usually, Product Owners have around 1 - 3 Scrum Teams they are working with. Anything higher is extremely unusual.
LeSS is more reasonable yet still appropriately crazy by setting the limit at eight teams. I have never met a Product Owner who was working with eight or more teams at any meet-up. The record stands at six at the moment, though this person was collaborating together with another person at the Product Owner, so it technically wasn’t even six teams.
The fact that the number of teams isn’t capped and that this number of teams is considered normal by the frameworks shows the disconnect between Scrum and the reality of Product Ownership.
This isn’t surprising, as the conversation in the Scrum community is dictated by Scrum Masters and Agile Coaches who usually have a limited perspective on Product Management and Product Ownership. Scroll on Medium, LinkedIn, or any platform where content is being written on Scrum. Product Owners and developers are severely under-represented.
That’s a shame, and that’s why the Scrum community acts in this Scrum bubble. There isn’t enough understanding of what it means to be a Product Owner. Most of it’s coming from a limited and theoretical Scrum Master perspective.
That being said, how we ended up here doesn’t matter. The Product Owner should be a servant leader who builds empowered teams that are capable of discovering better ways of delivering value.
Just like an orchestra doesn’t need a conductor to make music, Scrum Teams shouldn’t need the Product Owner to deliver value.
"The conductor of an orchestra doesn't make a sound. He depends, for his power, on his ability to make other people powerful.” - Benjamin Zander
The same applies to the Product Owner. The Product Owner doesn’t build any product. The Product Owner should be there to help bring out the best in all those Scrum Teams working in concert to deliver value to customers and the business.