Five Ways Bad Product Owners Screw Up Scrum Teams

When Product Owners miss the mark, the entire organization suffers from pointless results.

Many things can ruin Scrum teams, but one aspect stands out for me most: A Bad Product Owner will obliterate the success chances of any team. 

I’m not exaggerating because I’m a product person by heart. I’m talking from painful experiences and recognition of my f*ck ups. 

Look at the other Scrum accountabilities. An amateur Scrum Master will drastically reduce the Scrum adoption, but the team still has success chances. The same would go for inexperienced developers. They will slow the team down but not impede them from growing. 

A bad Product Owner will destroy any chance of standing out.

Wearing the Product Owner’s hat is tough. You can’t ignore the complexities of living up to a solid Product Owner’s responsibilities, yet it’s easy to take some wrong steps and put you and success in opposite directions. Let me share with you five common mistakes bad Product Owners make. 

1. Obey Your Master

When I first wore a Product Owner’s hat, someone told me, “You’re responsible for the what, while the team is responsible for the how.” I only wished I hadn’t listened to that or had the guts to challenge it. Instead, I blindly focused on that poor definition of my responsibilities.

Back then, I was a tech person. I thought I could define solutions on my own and hand them over to the team, and they would take care of the implementation. That’s how I worked in the beginning. As a result, I got the following attitude:

• We only do what’s written in our backlog items
• If something goes wrong, it’s the Product Owner’s fault
• Product Owner versus the rest of the team
• No decision-making without the Product Owner’s consent
• Nobody ever talked about problems because we cared only about solutions

Don’t do like I did. 

A Product Owner isn’t solely responsible for the what. A better way is to start with why and then, together with the team, identify which solutions are suitable for the problem you want to solve. 

It’s way more important the team understands the problem they are solving than the solution they want to implement.

2. Making Promises on Behalf of the Team

Product Owners receive gazillions of requests from trillions of stakeholders. Everyone wants something done in your next Sprint. This situation may be stressful for many, but it’s just part of a Product Owner’s daily life. So you better get used to it.

Avoiding stakeholders isn’t an option. They would bypass you and either go directly to developers or drop an email to your boss. Also, flooding your Product Backlog with everyone’s wishes is a flawed approach.

A common mistake is when Product Owners make promises to stakeholders on behalf of the Scrum team. I’ve done that, and it smells bad.

Sometimes, a stakeholder would bring a relevant idea connected to our goals. I would carefully listen and make promises on when to deliver what. The problem is that I didn’t involve anyone from the team and would only communicate the agreement. Needless to say, they were mad at me for such a pointless approach.

My key takeaway: Don’t ever make promises without aligning with the team. 

3. Delivery Is All That Matters

The Product Owner is responsible for tactics, and the Product Manager is responsible for strategy. This flawed understanding will diminish your role as a Product Owner, create confusion, and contribute to a lack of responsibility.

SAFe — the undercover waterfall agent — is one of the sources of this anti-pattern. Don’t confuse the SAFe Product Owner with the Scrum Product Owner. This is a trap. 

When I say Product Owner, I mean end-to-end responsibility. That entails strategy and tactics. Discovery and delivery. You won’t create value when all your energy goes to execution.

“Good companies manage Engineering. Great companies manage Product.” – Thomas Schranz, Founder and CEO of Blossom

I fell into the delivery trap many times. Here are some traits of this trap:

• Extensive focus on writing Product Backlog items
• Feature obsession: The more, the better
• Teams velocity is the ultimate success metric
• No or little time invested in discovery activities
• The job is done once a feature goes live

More features doesn’t mean more value. 

No discovery = pointless delivery.

4. The Big Boss

Scrum has no hierarchy. All Scrum members are on the same level. Yet some Product Owners behave like bosses. Have you ever observed one of the following points?

• Product Owner sign-off is part of Definitions of Done
• Developers do not decide without the Product Owners’ blessing
• Product Owners alone decide what goes to the Sprint and what doesn’t
• Developers must beg for Product Owners’ permission to address critical tech debts
• Product Owners bridge the communication between business and developers

Does any of this ring a bell for you? If it does, the Product Owner needs guidance to step back and understand the role better. 

Product Owners aren’t bosses. 

They are part of the Scrum team as everyone else. 

Behaving as a boss is detrimental to the team. Once Product Owners fall into this trap, Scrum Masters have to act immediately to help the Product Owner behave as a leader, not a boss.

Great Product Owners lead by context. They ensure Scrum teams understand the problem space and which outcome they aim to reach. Trying to play the boss will consume precious time that could be used doing more important activities such as exchanging with real end-users and learning from them.

5. I Know It All

The title Product Owner is exaggerated, in my opinion. It’s utopian to believe a single person can own the whole product. It’s more likely they will work with several Product Owners, and each owns different parts of the product, hopefully, end-to-end. But that’s not the main challenge. The main one is to understand what your real end-users need and how to help them in a way that creates value for them and the business.

Ask your Product Owner how often they talk to real end-users. I get surprised when people call themselves Product Owners without ever talking to end-users.

“At the heart of every product person, there’s a desire to make someone’s life easier or simpler. If we listen to the customer and give them what they need, they’ll reciprocate with love and loyalty to your brand.” – Francis Brown, Product Development Manager at Alaska Airlines

Many Product Owners I know have never talked to a real end-user, yet they either believe in knowing best what end-users need or rely on stakeholders’ opinions. Neither one nor the other will lead you to create value.

I’m shocked by the number of Product Owners leading teams as if they know it all. The result of this attitude is a pointless product that end-users couldn’t care less about.

Without talking to real end-users, you cannot understand what makes sense for them. Get out of your daily business and speak to real people.

Final Thoughts

It’s exhausting to be a Product Owner. You’ve got too many challenges ahead of you, and it’s easy to fall into endless traps on your way. To succeed as a Product Owner, you need to get comfortable with being wrong and changing how you work. 

Be open to new perspectives and brave to change your style. That’s mandatory if you want to excel in your role.

You cannot get everything right all the time. That’s fine. But you can learn from everything you do and strive to become a better version of yourself.

‍