What is NOT the role of a Product Owner?
Since the Agile Manifesto, many companies started working with many agile frameworks, mostly Scrum and Kanban. However until now it is…
Since the Agile Manifesto, many companies started working with many agile frameworks, mostly Scrum and Kanban. However, until now, it is clear that so many companies don’t understand who the Product Owner is. Why do I say that? I’ve been working as a PO over the last eight years, and every company had a different understanding of the role of a Product Owner.
I’d like to discuss with you not who the Product Owner is, but instead some anti-patterns that I have seen over my journey. But before we jump into that, let’s take a look at some definitions of this role.
Bob Galen has one way of seeing the Product Owner that is my favorite; he defines as the four quadrants:
The Scrum guide says:
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 let’s go now to the anti-patterns. What are the most common misunderstanding I have ever seen?
Order taker: receives orders and send it to the team directly. Generally, there is a long-term goal;
Responsible for the team: micromanage the team and behave as the manager of the team;
The technical architect: defines all the solutions alone, the development team does not have a voice on how to solve problems;
The only one who manages the backlog: the backlog is protected and locked under seven keys, only the PO can touch this kid.
There is a post in Scrum.org about the types of Product Owner. The content is similar to what I am sharing here, take a look from here.
Order taker
Let’s start with the most critical, in my opinion. In this scenario, the PO does not own the prioritization. Instead, he or she only receives the orders or wishes from the stakeholders, write 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, ceremonies, and artifacts; that’s it. 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 here is implementing Scrum correctly and understanding that Agile is more than a framework. It is a mindset of collaboration and maximizing the value of the business. Therefore, everyone must be aligned. The Product Owner, in this case, must 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 he must say no!
Be careful with this trap, if you fall into this you may notice:
The team works on delivering tasks instead of maximizing the value;
There is no focus;
Everything tends to be a priority;
The stakeholders are unhappy, because everyone wants everything;
The team doesn’t know what they are fighting for.
Scrum.org classifies this misunderstanding role of Product Owner as The Clerk.
Responsible for the team
The 2nd most common problem is, the PO may behave as responsible for the team. That is a huge mistake, because the PO is part of the team instead. There is no hierarchy on Scrum. Therefore, PO, Scrum Master, and Development Team are all peers.
How can you identify this dangerous behavior?
The PO starts doing command and control, monitoring the progress of the team and pressuring the team during the sprint;
There is one on one meetings with all the team members;
Stakeholders see the PO as the responsible for the team;
The PO is interested in individual performance;
The PO needs to approve the team’s decisions.
The manager behavior is a critical problem because the PO must trust the team and collaborate to reach the Sprint goal. However, the PO doesn’t manage the team. Instead, the PO leads the team to a product direction, which is different.
In summary, the PO is part of the team and not on the top of the team.
This behavior is also another misunderstanding approach for the PO role known as The Manager.
The technical architect
The 3rd problem is also a severe one; this happens when the PO doesn’t understand the boundaries. What do I mean by that? There is a clear division between PO’s responsibilities and the team’s responsibilities.
The PO must present to the team the What, 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 How. The team defines the solution for the What presented by the PO.
How can you identify that?
The PO comes to the refinement meetings with the User Stories totally prepared, where the solution is already defined, and the team has no room to discuss it;
The development team is frustrated because they are not thinking, they are only executing;
There is no discussion over epics or about the problem itself.
Be careful about this behavior because it can demoralize the team and brings no result. Bear in mind; Scrum is a collaborative framework meaning that the team is bigger than the sum of its individual.
You can avoid that by directly bringing the problem to the team and discussing openly, the PO presents and challenges and trusts the team will find the best solution for it, believe me, they will.
Don’t try to be the hero. Don’t try to behave as you know everything, be collaborative, and maximize the results with the team!
The only one who manages the backlog
The last point is about the backlog management. Many POs believe that they are the only ones who can manage the backlog. Therefore, they don’t let anyone insert new items there, is that right? For sure, NOT! The PO is accountable for the backlog, that doesn’t mean that we are the only one who can insert new items, being accountable for the backlog means that we:
Must understand each item inside the backlog;
Must be able to order in a way that maximizes the value for the business;
Must refine with the items until they get ready to be developed.
We should encourage the stakeholders to write new items into the backlog as well as the development team. Then, our role is to understand each of these items and define how relevant they are for the business. Thus, determine if and when they could go into a Sprint.
PO owning the backlog is a myth, one article I would recommend is the one written by Christiaan Verwijs, he nailed this topic down!
Being a Product Owner is a challenge every day. We must be in constant learning, and we cannot be in the comfort zone. Every day we need to get a better understanding of how we maximize the value for the business sustainably, meaning that the principles of Scrum are respected!