The Product Owner role is like the Scrum definition. Simple to understand, difficult to master. The Scrum Guide clarifies what the Product Owner’s mission is, but assumes the execution may vary widely according to the organization’s situation. So, you’re on your own when it comes to implementation.
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
So how can someone be a successful Product Owner? Product Management skills are the answer because Product Managers understand how to build excellent products and what value means. Without this knowledge, it will be challenging to thrive as a Product Owner.
Scrum’s Product Management expert is called the Product Owner. An excellent Product Owner is a strong Product Manager. You can’t be a good Product Owner without understanding Product Management. Without following Product Management practices, Scrum can’t meet its promise of delivering products of the highest possible value.
The complexity does not stop with Product Management skills. In Scrum, the figure of a Project Manager is nonexistent, who has to handle it? The Product Owner also gains this responsibility.
My favorite picture of a Product Owner is the four quadrants, which Bob Galen described as follows.
So let’s go now to the anti-patterns. What are the most common mutations I have ever seen?
- Waiter: receives orders and sends them to the team directly. The waiter behavior results in low-business value and many pointless features.
- Manager: micromanage the team and behave as the manager of the development team.
- Architect: defines all the solutions alone. The development team does not have a voice on how to solve problems.
- Protector: protect the backlog and lock to ensure no one can handle it, only the Product Owner can touch this kid.
“Can I take your order, sir/madam?”. That’s how useless features start.
The Product Owner acts literally as a waiter. In this scenario, the Product Owner does not own the prioritization. Instead, he or she only receives the orders or wishes from the stakeholders, write down the product backlog items, and gives it to the team without questioning the need.
This scenario is widespread because some companies think that implementing Scrum is only a set of roles, events, and artifacts. However, they forget the mindset. Therefore, a lot of problems emerge. But why? If the stakeholders remain with the mentality of the traditional approach, that just doesn’t fit with the Scrum Team.
The challenge is implementing Scrum correctly and understanding that Scrum is more than a framework. It is a mindset of collaboration and maximizing the value for business and the users. The Product Owner, in this case, should challenge the requests and become the visionary of the product, where he or she sees the big picture and understand what makes sense and what doesn’t!
Be careful with this mutation, if you fall into this you may notice:
- Delivering tasks instead of maximizing the value.
- Focus doesn’t exist.
- Everything is a priority.
- Unhappy stakeholders, because no real value is delivered.
- The team doesn’t know what they are fighting for.
Scrum.org classifies this misunderstanding role of Product Owner as The Clerk.
It’s 09.15 a.m. the Daily Scrum Starts.
Product Owner: The search improvement task is lying on the To-Do lane for three days already. Björn, can you do that? I want to test it by tomorrow. Ah! Also, I need you, Harold, with something else, I will tell you later.
I experienced Daily Scrums like that. The vital understanding is, the Product Owner is not a manager; the Product Owner is a servant-leader.
Product Owners behave as responsible for the team once the manager mutation happened. Such behavior is a massive mistake because the Product Owner is part of the team instead. Scrum has no hierarchy. Therefore, the Product Owner, Scrum Master, and Development Team are all peers.
How can you identify this dangerous behavior?
- The Product Owner starts doing command and control, monitoring the daily progress of the team, and pressuring them during the sprint.
- One-on-one between Product Owner and Developers.
- Stakeholders see the Product Owner as the responsible for the team.
- Individual performance matters.
- The Development Team cannot move without the Product Owner’s approval.
The manager behavior is a critical problem because trust evaporates while collaboration diminishes. Until the Product Owner understands the Development Team is self-organized, the team will reach no more than ordinary results. This behavior is also another misunderstanding approach for the Product Owner role known as The Manager.
In summary, the Product Owner is part of the team and not on the top of them.
“We need a high-performing API. Let’s do it with Go!” That’s how the fight begins.
Once the Product Owner crosses the dangerous line of How, the Development Team won’t receive this with open arms. The Product Owner is responsible for Why and What, while the Development Team is responsible for How. It’s a thin line, which the Scrum Team should respect to have a sustainable and productive workplace.
Product Owners should focus on the problem we want to solve or the opportunity we want to take and discuss around that. On the other hand, the team takes care of the implementation. The team defines the solution for the What presented by the Product Owner.
How can you identify that?
- The Product Owner comes to the backlog refinement session with the User Stories totally prepared, where the solution is clear, and the team has no room to explore options.
- The development team is frustrated because they are not thinking; they are only executing.
- No discussion over epics or about the problem itself.
Be careful with this behavior because it can demoralize the team and bring no results. Bear in mind; Scrum is a collaborative framework meaning that the team is bigger than the sum of its individual.
“Talent wins games, but teamwork and intelligence win championships.” — Michael Jordan
You can avoid this problem by bringing the problems to the team and explore the alternatives together. The Product Owner should present the challenge and trusts the team will find the best solution for it.
Excellent Product Owners are humble, great team players, and know-how to foster collaboration. A high-performing team transforms the impossible into possible.
Stakeholder: Hey Product Owner, I wanted to write one request on the Product Backlog, but I don’t have access. Could you help me with that? Please.
Product Owner: Actually, I’m the only one who inserts new items into the Product Backlog. What do you need? I can understand with you, then eventually insert it into the Product Backlog.
That’s how a Product Owner diminishes collaboration and becomes overloaded.
Many Product Owners manage the Product Backlog alone. Therefore, anyone else to insert new items into the Product Backlog. Is that right? For sure, not! The Product Owner is accountable for the Product Backlog, which doesn’t mean we are the only one who can insert new items, being accountable for the Product Backlog means that we:
- Should understand each item inside the backlog.
- Should be able to order in a way to maximize the business value.
- Should refine with the items until they get ready to be developed.
We should encourage the stakeholders to insert new items into the Product Backlog. Then, the Product Owner should understand each item and define how relevant they are for the business. Thus, determine if and when they could go into a Sprint.
Product Owner managing the Product Backlog alone is a myth, which Christiaan Verwijs nailed this topic down!
Being a Product Owner is a challenge every day. We must embrace continuous learning mindset, and we cannot be in the comfort zone. Every day we need to get a better understanding of how we can maximize the value for the business sustainably, meaning that the principles of Scrum are respected and enacted!
To thrive as a Product Owner, a person should:
- Have an excellent Product Management competencies.
- Focus on maximizing the business value, while saying no to what doesn’t contribute to it.
- Be part of the Scrum Team instead of behaving as a Manager.
- Respect the boundaries between the Product Owner and the Development team.
- Invite the stakeholders to collaborate to build a meaningful product.