Successful Product Owners Are Players, Coaches, and Leaders.
Not knowing how to behave in different situations leads Product Owners to painful failures.
Not knowing how to behave in different situations leads Product Owners to painful failures.

Product Owners carry a massive burden on their backs. The value maximizer responsibility is daunting. Even though many companies work with Scrum, they still misunderstand what value means. Yet, Product Owners are ultimately responsible for maximizing the value.
For years, I’ve been wearing the Product Owner hat. Many times my misconceptions held me back from thriving. But something helped me significantly overcome the challenges I faced: knowing how to behave in each situation.
Allow me to share with you the different roles Product Owners should have on their repertoire.
The Player
Many Companies perceive the Product Owners as a position above the Development Team. This is a mistake. The Product Owner is a peer to all other Scrum members.
Until Product Owners behave as team members, success is hardly achievable.
To be a part of the Scrum Team is more than sharing the same workspace. The Product Owner should belong to the team. Every team member should trust each other. But trust is not a given; it’s something that evolves within time. For me, Product Owners should:
Be available: the Scrum Team knows the Product Owner will always find time for them. The Product Owner spends time with the team to strengthen the relationship.
Be honest: the communication is clear. Whenever something is wrong, the Product Owner will talk openly with the team. The conversation is never political; it’s open and honest. The Product Owner is humble to admit her mistakes and share the learnings with the team.
Help: if the team is stuck with something, the Product Owner will do whatever it takes to help the team overcome the challenge. Even if it means doing something out of the comfort zone. Sometimes, Product Owners may test the application or perform user interviews. The Product Owner should care about the team and show a willingness to help.
First-person language: it’s only we. The Product Owner is proud of being part of the team. During meetings, the conversation is always using we instead of you or them. The Product Owner feels she belongs to the team.
“Great teams do not hold back with one another. They are unafraid to air their dirty laundry. They admit their mistakes, their weaknesses, and their concerns without fear of reprisal.”
― Patrick Lencioni
But don’t misunderstand what being part of the Scrum Team means. I’ve come across some dangerous misunderstandings. Product Owners should not:
Estimate the work of the Development Team. Only Developers can estimate their work.
Define how to implement a solution. This responsibility lies on the Developers’ shoulders.
Spend their whole time with the Development Team while ignoring the end-users and businesses

The Leader
It annoys me when people perceive Product Owners as the Product Backlog manager. As Product Owners, we are not:
Requirement keepers.
Scope defenders.
Feature maximizers.
Stakeholders’ puppets.
Manager of the developers.
To succeed as a Product Owner, you need to break the misconceptions of this role. It’s challenging to do it. But if you are bold, you can become the leader your team needs. A value-driven mindset will help you change the status quo.
“At the end of the day, your job is to minimize output, and maximize outcome and impact.”
― Jeff Patton
If Product Owners don’t act as leaders, Scrum Teams will fail to maximize the real value for the end-users and businesses. Product Owners have many clear opportunities to behave as a leader:
Product Vision: every product should have a compelling vision, which team members can connect with. Without a vision to pursue, teams run in circles, and everything is arguably a priority. Product Owners are responsible for the Product Vision.
Sprint Goal: each Sprint should have a goal to achieve. The goal should be challenging and engaging. The Development Team feels like they are on a mission. The inability to craft a Sprint Goal leads Scrum Teams to the feature-factory anti-pattern.
Communication: leaders don’t give orders; they share a purpose. Product Owners should always start with the why behind everything. By doing that, the Development Team can connect easily with the problem and find meaningful solutions. If the Product Owner doesn’t know the why behind the wish, she needs to clarify until it’s clear.
Outcome focus: it’s not about delivering features to the end-users. It’s all about changing the end-users’ lives for the better. That’s why features are a means to an end, never the end itself. Successful Product Owners focus on the outcome they want to achieve. Then, together with the Development Team, they find how to achieve the desired outcome.
“This is what it means to serve: improving another’s life and, in turn, improving the world.”
― Daniel H. Pink
The Coach
In my opinion, a great Product Owner enables the Development Team to achieve more than they imagined being possible. A bad Product Owner holds the Development Team back by being the bottleneck for them.
I used to think Product Owners should make the work of the Development Team easier. Therefore, I prepared highly detailed Product Backlog Items. Also, I made almost all the decisions because I didn’t want to overwhelm the Development Team. Well, I was wrong. My behavior limited the Development Team from becoming a better team, and I became the bottleneck of everything.
Nowadays, I believe Product Owners should be catalysts. We should search for opportunities to accelerate the decisions. We should give the space the Development Team needs to evolve.
Daily decisions: the Development Team has to make small decisions constantly. If the Product Owner insists on being part of everything, inefficiency is on the way. That’s why Product Owners should encourage developers to be autonomous. Developers can consult the Product Owner if they want, but they should progress without it.
Sprint changes: if the Sprint Goal is to deliver all features at the end of the Sprint, you’re locked into prison. However, if the goal is well set and the Development Team found an alternative to achieve it, they should do so without consulting the Product Owner.
Inspect & Adapt: living the pillars of Scrum help evolving as a team. The Product Owner encourages the team autonomous. Then, the Scrum Team is constantly inspecting and adapting to become a better team.
“Control leads to compliance; autonomy leads to engagement.”
― Daniel H. Pink
Achieving the Product Owner’s Mission
To reach your mission as a Product Owner, you need to learn how to transform the Scrum Team into a high-performing team. Once you can observe the following, you can be sure you are on the right track:
The Scrum Team feels you belong to them, instead of perceiving you as an outsider.
You move out of your comfort zone to help your team instead of fearing the unknown.
You set goals to achieve instead of features to deliver.
You encourage developers to make decisions instead of being the bottleneck.
Do you want to write for Serious Scrum or seriously discuss Scrum?