What Makes Product Owner Weak
After years of experience with various Product Owners and later on, becoming one, I've learned how big an impact this role has. Thanks to eager and knowledgeable Product Owners, we might be able to deliver the products that take us in front of the competition, win big contracts, earn more money, and gain more satisfied users. Thanks to poor Product Owners, we might miss the momentum, end up behind the competition, go in a circle, struggle as an organization, and lose team members, customers, and so money.
No one is wise by birth and nor are Product Owners. We all learn as we go. I am using this opportunity to list a few things I think a great Product Owner never should do (I check a few, so I am not there myself YET!).
The Scrum Guide says: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team". As simple as it sounds, identifying the value is highly challenging. But once we avoid the points above and master the messages after, we'll be fine as so our product. If you have other thoughts, I'd be happy to hear them in the comments, or you can reach out directly through the Contact form here.
1. No hands-on experience with own product
If I'd be a Product Owner of the mobile app, shouldn't I have it downloaded and be curious to play with the new functionality ASAP? How can I have discussions with customers to collect their valuable feedback if I don't even know where to click to feel their needs fully? How can I even share the expectations with the team effectively if I don't have the app opened and navigate through it as we refine it? Sure, we can have screenshots, notes, and presentations ready, fed by someone else. To me, this would be unacceptable since without hands-on experience I don't think anyone can truly feel the problem. And unfortunately, this is quite common. Especially when he/she sees him/herself as a project manager who only manages the backlog and oversees the increments delivered.2. Solutionize before fully acknowledging the problem
On the other side, when Product Owner knows his/her product pretty well, the common tendency is to jump to the solution when just hearing an idea. I spent some time with the acceptance criteria, and the team came up with the other solution when they heard the whole story behind it. So instead of me doing something I am not the most qualified for, I could rather focus on understanding the problem better and weighing the value of solving it.3. Underestimate quality
My experience with a Product Owner causing poor quality is when there has been a deadline. Thinking that there won't be any deadlines now and then in an agile world is naive. It's still business. We still promise things to earn more money. But we can avoid rushing things when a deadline is around the corner. The better way to maintain value and quality would be to maximize focus while working closely on a daily basis. Since we have a deadline, we should have a plan. If we feel we're behind, we can ask ourselves: is there something we can exclude/postpone? Anything that works for you. Just don't rush it. Rather having two out of four promised features stable, than four are full of noticeable issues. Then when do you plan to catch up and fix everything? There is another set of features waiting in the backlog.4. Let someone else disrespect your desitions
There are many other roles than Scrum Guide defines. We have many managers. The test managers, release managers, product managers, project managers, r&d managers ... . They all are our stakeholders, and we need to collect their feedback. So if the test manager feels there is an increased number of in-life issues, you need to consider helping to fix some, even if it's not something you introduced. If the product manager asks the team to implement something "small", you need to step in and understand the need first. I consider the Product Owner being the sole product decision-maker as a sign of a healthy working environment. The less decision-making power the Product Owner has, the more issues the organization structure faces. Also, the team sometimes chooses something from the bottom of the backlog. Not that they want to disrespect you. Just because it seems interesting. There, I see two options: let it slide or let them do it soon while highlighting there is something else first. Letting it slide is never a good option. It happened once, it'll happen again, and you'll end up with too "self-organized" team when the value is driven by technical excellence only. Not a bad thing. But make sure you are the one making a knowledgeable decision.5. Lack of interest in the market
Just imagine you have your own company. It's your baby. You hire experienced Product Owners. But they seem not to be interested in the market. They are not doing any market research. They are just fed by the feedback. You know the market well, but as a founder, you don't have enough capacity to understand the trends. And if you don't know the trends, you're worried that your company will be behind the competition soon. You'd expect the Product Owners to own it. Right? RIGHT?!6. Passively waiting for a feedback
Two out of four Agile manifesto values state: "Individuals and interactions over processes and tools" & "Customer collaboration over contract negotiation". It's been defined like this since 2001. As much as marked has changed, I don't think these values have. Product Owner needs to create space for people to share their feedback to keep maximizing the value delivered. Sprint Reviews and Quarterly plans might not be enough. Can you imagine you're a customer support team member or sales, and someone writes you a message asking you to genuinely share your issues? I am sure you'd appreciate the interest, and there will be plenty. So why not ask and learn about the product from a different angle? Internal, yet the closest one to the customer!7. Be a naysayer
Sometimes, comfort takes place over value. Someone asks you to address the problem, and your response would be: "It's too big an effort, we have other well-defined things in a backlog, we have uncertainty if there will be some revenue in it, we won't do it". It happens once or twice, and the person won't reach out again. Why lose a valuable source of feedback and ideas just because it's discomfort for me to consider building that?8. Accept the silos
Multiple communication layers between Product Owner and customer increase with the company's size. Scaling doesn't necessarily mean that Product Owner needs to accept that they are disconnected from the customer and that the only information they have is from the Product Manager. I'd recommend finding a way to get closer and closer to the users. The closer you'll be, the better feedback you'll get, and the better product will become. We should be proactive and creative in ways to get there too.9. Delegate too much
The delegation isn't a bad thing. If there is something that can be done better or more effectively by someone else, ask for it. But make sure that while someone else is doing you a favor, you'll focus on something else. It's thin ice, and if the other person feels that they have been used or you're useless, you're done with trust.10. Unknowledgable prioritization
Typically, disconnection from customers and the financial aspects of the company can lead to poor prioritization. The Product Owner needs to know the details about how the product has been / will be sold, along with aimed quantity. And make this a part of the hypothesis built for every feature. This can help better prioritize the value, and based on money and/or quantity, we'd have the metrics to measure the value delivered. I want to highlight here that the Product Owner needs help from management. Without such support, whatever Product Owner would do, is just a blind shot.The Scrum Guide says: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team". As simple as it sounds, identifying the value is highly challenging. But once we avoid the points above and master the messages after, we'll be fine as so our product. If you have other thoughts, I'd be happy to hear them in the comments, or you can reach out directly through the Contact form here.