Strong Product Owners Don’t Complain! They Change the Game!

Don’t ask for permission. Ask for forgiveness.

Do organizations respect the Product Owner's decision?

Are Product Owners empowered to make decisions at all?

Are Product Owners rule followers or game-changers?

From my experience, Product Owners in practice differ dramatically from the Scrum Guide. But, strong Product Owners don’t use the misconceptions as excuses to stop them. Instead, they are bold to challenge the status quo and change the game!

Strong Product Owners never ask for permission! They have the guts to challenge the status?quo.

Over my journey, I’ve encountered enduring misconceptions about the Product Owner role. Let me share with you some ideas on how to overcome them.

Prioritization NOT Done by the Product?Owner

One of the most dreadful anti-patterns is: that the Product Owner doesn’t own the prioritization. I’ve experienced this scenario in two ways:

• Direction defined by someone else: the Product Owner receives features to implement. At best, the Product Owner can shape the scope of the feature, but not beyond that. This scenario is demotivating because the Product Owner is the requirements keeper, not the value maximizer.
• A committee defines prioritization: the Product Owner might be part of the discussions, but the decision will come from the committee. In this case, the Product Owner is more like a facilitator. Unfortunately, this scenario tends to lead to a people-pleaser Product Owner.

If you comply with the status quo, you won’t achieve your mission as a Product Owner, which is the value maximizer for end-users and businesses. Suppose you are experiencing one of these misunderstandings. You have to be a rebel to change it. The following attitudes could help you to change the game:

• Product Vision: if you are locked in a vicious circle where the goal is to deliver features, it’s time to craft an appealing Product Vision. Don't be afraid of challenging people who own the priority and insist on having a vision to pursue. Without a vision, teams will inevitably fall into the feature factory trap.
• Start with the end in mind: what is the outcome you want to achieve? Understand what is the most important thing for the moment. For example, suppose you need to increase customer satisfaction because the business constantly loses customers. You can discuss openly with the stakeholders what could bring the required impact. Then, anything that doesn’t collaborate with the ultimate goal should be discarded.
• Don’t accept solutions to implement: as a Product Owner, you should lead teams to solve the users’ real problems. If someone brings a solution to implement, you should transform it into a goal to achieve. Yet, you have to evaluate if it is worth doing so.

To succeed as a Product Owner, you must challenge everything that will lead to a poor outcome. Regardless of your responsibilities, you are ultimately responsible for the product's success. Don’t let the misconceptions hold you back from thriving.

Nobody Cares About the End-users

Stakeholders always have many wishes to fulfill. They might insist that everything is urgent and important. Unfortunately, many of their wants might not be related to the end-users real needs. If you do your best to fulfill the stakeholders’ wishes, the end-users may not be as satisfied as expected.

“We must learn what customers really want, not what they say they want or what we think they should want.”― Eric Ries, The Lean?Startup

As Product Owners, our success relies heavily on differentiating assumptions from needs. We may think we know what our end-users need, but if we don’t validate or falsify our assumptions, we will inevitably waste time building something nobody needs. Yet, many teams insist on building solutions based on unchecked assumptions.

But what does hold Product Owners from validating the assumptions?

• Execution mode: Product Owners may receive well-defined requirements. Stakeholders believe they know exactly what is needed. Therefore, the Product Owner jumps into the execution mode and organizes the work with the Scrum Team.
• No UX expertise: the Scrum Team has no UX expertise. That’s why the focus might be on delivering features instead of solving the end-users problems.
• Lack of Product Management skills: if the Product Owner ignores Product Management, the outcome is not promising.

As Product Owners, we cannot accept problems as blockers. We need to be problem-solver.

• If assumptions are not validated, we must find ways to validate them.
• If the Scrum Team has no UX expertise, we need to learn how to understand our end-users issues.
• If we receive precise requirements to implement, we must clarify each requirement's needs.
• If decisions are made without understanding the end-users, we have to go and talk to the end-users to validate the decisions.

It’s Time to Break the Rules and Become a Real Product?Owner

If you decided to become a Product Owner, congratulations, your days will never be boring. Endless challenges, misunderstandings, and conflicts await you. However, how you deal with them will define how successful you can be.

Don’t ask for permission, ask for forgiveness.

Companies don’t share a common understanding of the Product Owner role. Wherever you work, you may bump into misconceptions about being a Product Owner. But it’s your ultimate responsibility to maximize the product's value for the end-users and businesses. Don’t be afraid of conflicts.

To rock as a Product Owner, you should not comply with the rules. You should change the game until you can lead teams to build meaningful products!