A Product Owner is an important accountability when it comes to creating Valuable products. However, a Scrum Team may not always have a Valuable Product Owner. What I mean is, if the person performing the accountability of Product Owner is not well versed or executes their responsibilities poorly then it leads to a lot of challenges and eventually can lead to failure of the Product.
Here are a few anti-patterns that I have experienced and observed with Product Owners. Hope, this will give you some ideas to identify and break the anti-patterns to make the Product Owners effective.
The Product Owner Proxy or Proxy Product Owner:
In my past article about practices leading to anti-patterns I mentioned the Proxy Product Owner being a widely used practice, especially in scenarios where you have distributed teams or onshore-offshore models. Since it is a widely used practice, it is also a widely spread anti-pattern. A proxy Product Owner typically becomes a bottleneck to the Scrum Team's ability to create value as they do not have any decision making authority nor do they have direct access to stakeholders and customers.
A proxy Product Owner often leads to issues like misaligned priorities, reduced team engagement and delayed decision making.
The inaccessible Product Owner:
The next anti-pattern on my commonly found list is the inaccessible Product Owner. This Product Owner is never available to the teams for any clarifications. Often this person is so engrossed with the end user that they forget all the other aspects of product delivery including quality and timely feedback.
This leads to developers deciding on their own what to deliver and how to deliver. This means teams are often building features with a lot of assumptions thus creating low value, low impact features. This also means that the Product Owner has become a bottleneck and is hindering the progress of the team.
The Feature Factory Product Owner:
This Product Owner has one and one purpose only. Get as many features out as possible in the next release. It does not matter whether the features add any value to the user or not. The Product Backlog of this Product Owner is a never ending wishlist of their desires. They also lack clarity on the vision of the product or at times it is lost under the pile of features to be built.
Sumeet my friend cum guru and I share an experience of a Product, where the Product Owner got a video conferencing feature built in a ticketing system even though the team was already using slack, zoom and MSTeams for their daily communication.
The Product Owner with a Changing Scope of Work
Now, let me be clear. There is no issue with changing scope of work. In a complex environment, as we learn more about the product or needs of the customer, the scope will eventually change and evolve.
For a Scrum Team to deliver some value they should be left alone at least for the Sprint so that they can create something. This Product Owner, however, has a different definition of agility. They bring in changes every other day impacting the plan and goals of the scrum team.
This leads to a disengaged team, reduction in overall quality, lack of predictability and clarity on what will be delivered, plus at times increased stress and burnout of team members.
All Stakeholders are important Product Owner
This Product Owner struggles in managing the expectations of the Stakeholders. The Product Owner often becomes the “Yes Man”. Every requirement of the stakeholders becomes a must have.
Such Product Owners miss out on identifying the right stakeholders and do not have any engagement plan to deal with them. Also, such Product Owners often lack courage to say no to the stakeholders leading to an overloaded Product Backlog and unrealistic expectations.
Over a period of time, such an attitude leads to loss of credibility, loss of predictability and missed opportunities.
Overly Technical Product Owner
Again, there is nothing wrong with a Product Owner being technical.
The problem starts when the Product Owner starts getting involved in product development and starts ordering the Scrum Team on how to implement a piece of software. This Product Owner can be seen as an epitome of micromanagement. The Product Owner keeps telling the team what features to implement and how to implement those features.
This level of micromanagement impacts collective ownership of the team. Since, the team members are not making any decisions they refuse to take ownership of the results.
Also, if the Product Owner keeps getting involved in technical implementations then the Product Owner digresses from their most important accountability and that is to maximize the value of the product.
My Product My Way Product Owner
This Product Owner operates as a dictator, often sidelining the team in most of the discussions. They often consider themselves higher in the hierarchy and make decisions unilaterally without the input of the rest of the team.
Such Product Owners lead to a demoralized team and lack of ownership in the team. This also impacts the self management of the Scrum Team. As the Product Owner keeps making all the decisions and team members simply comply with those decisions, the focus on creativity, innovation and problem solving is also impacted.
Conclusion
If looked properly we can easily identify a lot of Product Owner anti-patterns around us. But identifying the anti-patterns is the least important concern. What is more important is to find ways to enable Product Owners to break free of these antipatterns.
It requires formal training, learning, constant mentoring and coaching to make Product Owners adept at what they do. Empowering the Product Owners so that they can make decisions instead of only following decisions is essential too.
Also, by recognizing and addressing these anti-patterns, organizations can empower their Product Owners to effectively guide their teams and deliver valuable products that meet the needs of their customers.