I have been an IT consultant for many years, and I have worked with many, many Product Owners at various different companies in all sorts of industries. Through painful experience, I know what NOT to look for in a Product Owner. Let me help you avoid the pain that I have experienced by sharing 7 things to avoid (also known as anti-patterns) in a Product Owner. You should avoid Product Owners who are:
1. Not Empowered to make Decisions
If a PO is not empowered or has to go up the chain five levels to get approvals on decisions, your Product Owner won’t be effective. I have seen this time and time again. This totally defeats the purpose of being agile. Every delayed decision is a waste, and if there is no agreement, it slows things down even more.
I believe that the root cause of this issue is a lack of education, usually at the top of the organization. Most command-and-control traditional organizations want to know everything in advance and are in on every decision. In today’s world, this just won’t work. Executives must be educated to understand what agility is and empower their Product Owners to make decisions that they will respect.
2. Working a “day job”
Many so-called Product Owners enter the role as a side gig to their day job. If the PO is busy all the time with the responsibilities of their “day job”, then he or she will not be available to the team. A Product Owner must be available to the Scrum Team to answer questions and plan out the future iterations. Without access to the PO, a team will quickly become blocked and their efficiency and velocity will plummet.
3. Totally Missing in Action
I know this one is kind of hard to believe, but trust me, I have seen it. I once worked at a very large retail organization on the mobile application development team. Our “Product Owner” (a Marketing executive) was totally missing in action; he was not engaged with the team and had little to no interest in what we were doing. So, without leadership or a Product Vision driving our work, we sort of meandered meaninglessly about, deciding what work to tackle on our own.
Take it from me, leaving the team to its own devices without a Product Owner is no good. If you find yourself in this unfortunate situation, find a new Product Owner. The Scrum Team will do their best to try to continue driving out the value in lieu of a PO, but they don’t have the right knowledge or skill to successfully do that on their own for long. We eventually found a different executive who cared about our work and engaged with us to redirect and refocus our efforts.
4. Unable to Negotiate and/or make Trade-offs
A Product Owner must be able to negotiate. Remember that everything in a Product Backlog should meet the INVEST criteria (coined by Bill Wake). This stands for:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
All items in the Product Backlog are negotiable, and are not a promise that something will be delivered. A PO who can’t negotiate will not be able to prioritize and order the Product Backlog. Negotiating often includes dealing with conflict, and a lot of people don’t like conflict. Being able to deal with conflict is an important Product Owner skill.
Another important skill of a Product Owner is the ability to make trade-offs. This means giving something up to get something else. This is a tricky and difficult skill to learn, but it is very important for successful Product Ownership.
5. Lacking Domain and/or Market Knowledge
If the PO is not an expert in their business or market, how can he or she understand what is valuable in the product? Product Owners often come from inside their organization and they may or may not have deep knowledge about the business. Without a strong understanding of the company and its strategic goals, a Product Owner may be totally ineffective.
Market knowledge is also important to Product Ownership. The PO should not only understand their business, but also the surrounding marketplace, industry, and competition. The Product Owner needs to keep their eye on the “big picture” so they can build a successful product.
6. A Committee instead of One Person
Having more than one Product Owner for a product drives me crazy. It just doesn’t work. I have experimented with having two Product Owners (not by choice) before. The two people swore up and down that they had all the same knowledge and could both make decisions, but when it came down to it, this just wasn’t true. It involved lots of conflicting decisions and re-work; this could have been avoided with a single person as Product Owner.
Another thing to avoid is having a PO committee rather than a single, authorized Product Owner. A PO can (and should) represent a stakeholder group or committee, but that shouldn’t substitute having that dedicated role.
7. Untrained in Agile Practices
Last, but not least, Product Owners need to have training in being a Product Owner. You can’t just pluck someone from the business or IT and dub that person a Product Owner without it. This role is the most important one on a Scrum Team, and without a strong person in this position, the product will likely fail.
Organizations need to recognize the importance of Product Ownership and invest in it. Yes, there is usually a cost to this, but it is well worth the investment and it will quickly return dividends.
Conclusion
I have experienced these Product Owner failure patterns many times. I hope that this blog will help you to overcome the perils of going down the wrong path with Product Owners in your organization. If you have any other thoughts on areas where Product Owners often stumble, please share with me!