Welcome to my new blog series. This time I’m tackling the challenging topic of [unfortunately] common anti-patterns that I have seen exhibited in Product Owners that spell doom. PO anti-patterns are a HUGE topic (on which I could probably write a book), so I’ll be taking it one category of anti-patterns at a time. The first category is “The Organization.”
Here are some of the most prevalent anti-patterns I have seen in my decade of working with Product Owners on Agile teams:
The Organization does not empower the Product Owner
Top-down support for authorized Product Owners is a must-have if companies want their products to be successful.
Problem
Having unempowered Product Owners is the top organizational anti-pattern that I have seen over and over again. Product Owners that aren’t genuinely empowered to make decisions are utterly hamstrung. When a Product Owner cannot control every aspect of their product, they may not feel ownership; this includes managing the budget and the Product Backlog. Without a sense of ownership, why should a Product Owner treat the role as anything more than just a “job”?
Solution
The Organization MUST treat the Product Owner role with respect. The Product Owner is the CEO of the product and is responsible for its success or failure; this is very difficult for most Organizations to do. It requires deep trust, and most companies aren’t willing to give someone other than an executive the reins. For Agile Product Owners to be successful, Organizations must LET GO of control. Easier said than done, I know, but it’s a necessary leap of faith to be successful using Agile.
The wrong person is selected to be the Product Owner
If there’s one thing that spells the success or doom of a product, it’s the Product Owner. Time and again, I have seen Product Owners that were entirely incapable of stepping up and owning the outcomes of their product; this is a sure recipe for failure.
Problem
How could an Organization possibly pick the wrong Product Owner? It seems inconceivable to me, and yet it happens every day. Politics are usually at play when a Product Owner is assigned. A Product Owner is a significant and visible role within a company. Landing a PO position could involve a pay bump and the prestige of a new title and responsibilities. However, this doesn’t mean that any random person is qualified to take on the Product Owner role. It’s a hard job and the most pivotal one on an Agile team.
Poor Product Owner selection happens for several reasons, including:
- Corporate politics
- Lack of qualified candidates
- No one is willing to volunteer for the role
- It’s not treated as a full-time job but rather as a secondary responsibility
- There isn’t anyone who is a subject matter expert on the product
- The Product Owner role is undervalued or misunderstood
- No one possesses all the necessary skills to be an influential and respected Product Owner
- Someone is an expert in a system but isn’t interested in truly “owning” it
- Becoming a PO is seen as a career progression for other roles (such as business analysts), but it requires additional skills that may require training
I’m sure there are plenty of other reasons that inappropriate people become Product Owners, but these are the ones that come to mind right away. If there are any you are aware of that I missed, please drop me a note in the comments below!
Solution
Organizations first need to understand the gravity and importance of the Product Owner position. Without a qualified [and even passionate] Product Owner, the company won’t realize its goals.
Companies need to be very selective about who they choose to be Product Owners. The skills and attributes of a good PO are challenging to find in a single individual. You may not find everything you want in a PO right away, but a strong candidate will rise to the challenge.
When selecting a PO, be sure that the Organization takes its time to do its due diligence to ensure the best candidate is selected, rather than the most expeditious or convenient one.
The Product Owner doesn’t have decision-making Authority
Okay, I acknowledge that this may sound redundant compared to the first section of this blog. Is the lack of authority to make decisions the same thing as not being empowered? Well, maybe – or maybe not…
Problem
A Product Owner wants to make decisions but can’t – or rather, isn’t allowed to. Some people are assigned as Product Owners in name only, and they have very little authority or ability to make decisions. In this case, the PO must usually run any decisions up the chain of command, leading to slower decision-making, and therefore reduced agility.
This problem can also arise when a group acts more like a Product Owner committee than having one leader who sets the vision and decides where to take the product. In this case, the group can steamroll over the Product Owner and override any decisions they disagree with.
Solution
One way to solve this problem is to educate others about the Product Owner role, its importance and reiterate that the buck stops with the Product Owner. If stakeholders want a decision to go in their favor, they can lobby the PO, but that’s no guarantee that they will get what they want.
As stated in the 2020 Scrum Guide:
“For Product Owners to succeed, the entire organization must respect their decisions.”
“The Product Owner is one person, not a committee.”
(Also, see my previous blog entitled “The Product Owner: There can be only One“)
Wrapping Up
I hope that you have enjoyed the first installment of this series on Product Owner Anti-patterns that doom a product to fail. Stay tuned to my blog (and subscribe on à on the side!) for more. If you have any other thoughts on how organizations hamper their Product Owners’ ability to succeed, let me know below!
The next topic in this series will cover the category of Industry and Market knowledge.
And if you missed the blog that spawned this series, check it out: “Anti-patterns that doom a Product Owner to fail.”