In any consulting engagement, I always communicate the importance of the Product Owner. Without a caring, competent person in this role, most products will fail to come to fruition, earn and retain market share, and evolve.
Here are the top 10 primary ways that I have seen Product Ownership go epically wrong (pun intended):
No Product Owner
Problem
This one is so obvious it almost goes without saying, but sadly, I have seen this happen. I don’t call this the “key accountability” in Scrum for nothing – the Product Owner role is the most crucial and critical to success with product development. Without one, there’s little hope that the product will gain traction.
Solution
Ideally, there is one Product Owner with all the skills and attributes needed to be the CEO of the product and drive it forward. Not only is there a single P.O., but this person is fully empowered to drive value, make decisions, and own the product.
Product Owner Missing in Action
Problem
If you have an assigned Product Owner, but they’re just too busy because they have a day job, other responsibilities, or their role is only part-time, you’re almost as bad off as having no Product Owner at all. While their intentions may be good, A P.O. that isn’t available to the team can cause all manner of problems, including slowing things down (inhibiting agility), the team making incorrect decisions, building features the customers don’t want, and lots of rework.
Solution
The solution for a Product Owner who’s missing in action is to either free up their time from other responsibilities to focus exclusively on the product or pair them up with a skilled person with strong Business Analysis skills. While the “proxy” is not ideal, it’s an alternative that can work when there is a tight partnership between these two people who want the product to succeed.
Multiple Product Owners for One Product
Problem
If you have a sole product, but there is more than one assigned Product Owner, you have a big problem on your hands. Multiple P.O.s can lead to various issues, such as contradictory requirements, decisions, or both; this results in confusion, frustration, and rework. Even if the relationship between the multiple Product Owners is good, it’s still a recipe for disaster, in my experience.
Solution
There should be one, and only one, Product Owner. As the saying goes, there has to be one “neck to wring.” One person is ultimately responsible for a product’s success (or failure). When two people are in charge independently, the chance of misalignment is 100%. So, conduct a careful analysis and decide who the best fit is for the role, and give that person the official title and responsibilities of Product Owner.
Product Owner by Committee
Problem
Slightly different from having multiple Product Owners for a product is having a committee of people acting in the Product Owner role. Imagine a diverse group of stakeholders sitting in a room trying to hash out whose priorities are most important – this rarely goes well. Usually, the most influential people in the room dominate, or the business units that make the most money squawk the loudest and get their way. Smaller, less powerful, or less wealthy groups get relegated to the bottom of the Product Backlog, and they don’t get their needs met.
Solution
Each product should have one (and only one) Product Owner. One Product Owner may oversee multiple products (although this is still not ideal). But a committee trying to make decisions for a specific product just doesn’t work. The assigned Product Owner can still meet with and hear the arguments from the stakeholders, but the Product Owner has ultimate decision-making capability.
Product Owner with no Business Knowledge
Problem
I might get some pushback on this, but as a consultant, I generally don’t recommend hiring someone from outside an organization to be a new Product Owner. External resources may not have the market or industry knowledge needed, the relationships, or customer and stakeholder connections to be successful in the role. And while I generally advocate for people to be more generalists than specialists on a Scrum Team, the Product Owner is the primary exception.
Solution
The person in the Product Owner role must know about their internal organization, competition, market, industry, region, and customers. The P.O. must also be able to make high-impact decisions. You can usually find the best candidates for this role inside your company. Look primarily at the business side of the equation – people who are already subject matter experts can learn Product Ownership skills.
Technical Product Owners
Problem
I’m not saying that Product Owners can’t come from a technical background or the I.T. part of an organization, but this is not typically my first choice. Some perils come with technical people as Product Owners, including thinking more about solutions and figuring out the how versus focusing on the business needs and value (i.e., who, what, and why).
Solution
I suggest avoiding having a technical person as your Product Owner whenever possible. However, if in the final analysis, someone with this skillset is still the best choice, you can minimize problems by ensuring the P.O. is trained by a qualified trainer with real-life experience as a practitioner. On top of that, I highly recommend hiring an external Agile Coach to support the team and the Product Owner to ensure the person doesn’t create or fall into bad habits.
Product Owners who aren’t Engaged
Problem
If you have an officially anointed Product Owner, but they care little about this part of their job, or it wasn’t their choice to take it on, you will have problems – period. A person without genuine interest in the product just won’t cut it. They will play hooky from every Scrum event, defer or delegate responsibilities, and won’t respond timely to questions (if ever). It’s another surefire way to kill your product.
Solution
In this situation, you’d be best off replacing the existing Product Owner with someone who genuinely cares. If the person doesn’t necessarily have all the skills or knowledge on day 1, that’s okay. People can learn many skills as they start doing. The key is ensuring they’re truly engaged and want to make the product a success.
Product Owners not representing the Voice of the Customer
Problem
If you think you know what your customers want and need but never actually talk to them or seek their feedback, chances are you’re wrong. Many Product Owners may be subject matter experts, system admins, or previous product users, but that still doesn’t mean they can read minds. No one can pull out their Magic 8-ball and make good decisions, but that’s what you do if you try to develop a product without customer involvement.
Solution
The solution to this problem is another obvious: talk to your customers! While it may not be easy to round up a group of willing participants willing to sacrifice their time and energy to let you know what they think about your product, you won’t know what they need. Most people don’t have a clue until you put something in front of them that they can touch, play with, and feel. Once they do, the sparks start going off, and the information you gather from them will drive your product forward. The Product Owner must engage directly with customers to gain this knowledge.
Product Owners with no Training
Problem
I’m not saying that Product Owners will flop if they don’t have formal training, but their chances of success dramatically increase by providing them with the training they need. Without training, the Product Owner won’t understand their role, responsibilities, or power. I have seen brand new people in the position struggle and become disheartened, unable to act confidently because they don’t know what they’re doing.
Solution
Provide your new Product Owners with training as soon as possible. If your Product Owner is struggling, don’t wait another day to get help. There are many training resources available, both self-study and in-person. As a consultant, I think having an Agile Coach and Trainer is the best option, but there are less expensive ways to go. However you do it, ensure your Product Owner has not only the knowledge but also the skills, confidence, and understanding of their role.
An Umempowered Product Owner
Problem
Last on the list, but not least (maybe the most important, actually), is the Product Owner assigned to the role, but in name only. The person doesn’t have the authority or empowerment to take ownership and make decisions without having to go up the chain for approvals. If your Product Owner can’t choose what to build or when to release, they’re not piloting the ship, which is what they should do.
Solution
Powerless Product Owners are unsuccessful ones who are set up to fail from the beginning. To resolve this issue, you must usually escalate within the organization. Everyone, from the CEO to the Help Desk, should respect a Product Owner’s decisions. Executive training is often necessary, so they can understand the role and give it its due power and respect.
Final Thoughts
These are the top 10 problems I have seen with Product Owners; this is the most crucial accountability on a Scrum Team, so you don’t want to get it wrong. It may require investment and education, but with the proper training, knowledge, empowerment, and support, the Product Owner can and will be successful.
I always end by asking you what you have seen or experienced. Have you seen any (or all) of these problems? If so, please share it with me in the comments below! I would love to hear from you!