9 Potential Pitfalls for Product Managers as Product Owners
Product Owners are Product Managers
Many organizations have Product Managers and Product Owners. The Product Managers typically address the strategic part of the product while the Product Owners are responsible for the tactical part: to create and sustain the product.
This is an anti-pattern. It is undermining the actual importance of the Product Owner accountability in Scrum:
“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. […] For Product Owners to succeed, the entire organization must respect their decisions.” - Scrum Guide 2020
In Scrum, the Product Owner OWNS the product.
The Product Owner is an accountability. But many people have misinterpreted Scrum. So, instead of acknowledging that anyone could be a Product Owner (a Product Manager, a customer, perhaps even the CEO), the world created the Product Owner job position. And with that, many organizations had Product Managers and Product Owners. I agree with
(and many other thought leaders) that this is an undesirable situation.Their arguments have persuaded organizations to solve the situation by merging the two and having Product Managers working as the Scrum Product Owners. But this often isn’t that easy. Here are 9 vital practices a Product Manager needs to embrace to be a Scrum Product Owner. They are pitfalls if not addressed.
1. Understanding empiricism
Scrum exists to create value in a complex world. Empiricism, learning from what happened to understand better what to do next, is at the core of Scrum. Instead of thinking that you can exactly plan out the work on a product for the coming year, the Product Manager needs to understand that it is all about taking small steps towards the goals.
Too often, I see Product Managers who determine the value of work upfront, never actively checking afterwards if their estimates are correct. This is at odds with Scrum and very dangerous to do in a product environment that is unpredictably changing all the time.
2. Being part of the Scrum Team
The Product Owner is part of the Scrum Team. With the premise that the product environment is complex, people with all kinds of skills need to work together to create value. Every day they may learn new things that impact their work, which requires them to pivot. The Product Owner needs to be aware and actively engaged.
When Product Owners position themselves outside of the Scrum Team, they will not be in a position to respond to change. They will have the teams work on topics that they could have known would not bring the desired value. Needlessly burning time, effort and money.
3. No hierarchies
Scrum Teams know no hierarchies. This is to enable empiricism. Everyone's input should be equally valuable. When learning is crucial, people should not be held back because the opinion of someone higher in rank is more important.
Often Product Managers are positioned higher in the organization, After all, they are the ones working on a strategic level and the Scrum Team on a tactical level. This anti-pattern is poison for the learning culture. It only works when the world is predictable and Scrum is not required.
4. Working with goals
In a complex product environment, you don’t know what work will bring you the highest value. But what you do know, is the desired outcome. You may want to attract a new segment of users. You may want to change the world with your new product. You may want to have zero defects. What you don’t know, is the exact road to these goals.
This is why Scrum works with Product Goals to have a long-term target for the Scrum Team. On top of that, the team works with Sprint Goals. You may not be able to exactly plan what needs to be done to reach your objective. So instead of describing the exact path, teams formulate the desired destination.
Product Managers often don’t consider outcome-oriented goals. Instead, they work with roadmaps filled with several stages of the product. The worst I encountered was a two-year plan to launch a Minimum Viable Product (MVP). Spoiler: this is not what MVPs are for.
5. Managing the Product Backlog
One of the main accountabilities for a Product Owner is to manage a Product Backlog. This typically is a list of topics, ordered by potential value. This is the way for Product Owners to communicate how they believe they will reach the Product Goal.
Product Managers often find this task daunting, expecting to be buried in the nitty-gritty details. This is probably the main reason to have a separate Product Owner, who is no more than a backlog owner then.
But a Product Owner should not fall into the trap of being a Product Backlog writer. That is not their role. They are accountable for maximizing the value. Often, it is better to refrain from detailing the items too much, as stated in this article by Maarten Dalmijn.
By focusing on what matters, value discovery, Product Owners may find a better balance in what they do and have more opportunities to embrace the strategic part of their work.
6. Developers determine the solution to the goals
I already established that when the work is complex, it is about working towards the goals, allowing for new learnings to impact the exact road to travel. Like taking an alternative route towards your destination when your original route is blocked by a traffic jam.
Developers need that freedom to decide what to do. They might find that the original plan towards their Sprint Goal doesn’t work, so they need to find something else. Constantly keeping an eye on the goal.
Product Managers should not fall into the trap of asking for a specific solution. They should ask for the next step towards the goal. It doesn’t only allow the Developers to find the best way. It also helps the Product Manager as a Product Owner to focus on value maximization.
7. The crucial Sprint Review
The Sprint Review is crucial. It is the moment when the Scrum Team and their stakeholders sit together to discuss the developments of the product. They will inspect the team’s next increment of the product. They will discuss if the product is well-received. They will discuss progress towards the Product Goal.
This all culminates in a decision on what to do next. Based upon this, the Product Owner can update the Product Backlog and prepare the next Sprint Planning.
I often engaged with Product Managers who didn’t understand the merits of the Sprint Review and their part in it. They were either passive during the event or even completely absent.
But knowing that everything in Scrum is about tackling complexity with empiricism, the Product Manager simply can’t skip this event. Rather, they should aim to maximize the effectiveness of the opportunity to collaborate with the team and the stakeholders.
8. The Sprint Retrospective to become more effective
The Product Owner is part of the Scrum Team. Every Sprint they work together to find ways to improve. They may want to spotlight their collaboration, ways to measure success, organizational issues that hold them back and many other things.
A Product Manager should not think they should not be part of the discussion. They may be able to play an important role in maximizing the focus on value.
9. Working with multiple teams
Product Owners own a product. They may work with one team, but perhaps they have multiple teams working on different parts of the product. Any Product Owner that doesn’t span the entire product is merely a component owner or feature owner.
Product Managers are well-positioned to play their role for multiple teams. By taking into account several lessons from this article, they should be able to handle this efficiently.
One thing to note is that when teams work on the same product, they all are in one Sprint Review to tie everything together and have the complete picture with the stakeholders.
End note
It is easy to state that a Product Manager and Product Owner are the same and having multiple positions is an anti-pattern. But in many organizations, there’s a clear distinction between the roles. The Product Manager is working on a strategic level. The Product Owner works to create the value.
The reason for this split often is a firm misunderstanding of Scrum. The Product Owner often acts like a team feature/component/backlog owner, putting a lot of effort into clearly describing the items. But actually, the Product Owner should be the one accountable for maximizing the value of the product. I’d argue this is what the Product Manager should do. Hence, it makes sense to have one person doing this job.
That doesn’t mean that any Product Manager can act like a Product Owner without any preparation. There are many pitfalls. They all boil down to:
A Product Owner should know why Scrum exists.
A Product Owner should know their role, the team’s role and the role of the stakeholders in Scrum.
Bonus: Connecting people - team members to stakeholders, regardless whether internal, customers or users.