TL; DR: Three Wide-Spread Product Owner Failures
There are plenty of Product Owner failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone.
Explore with me three widespread examples of how Product Owners fail their team in three short video clips, totaling 6 minutes and 9 seconds.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 31,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Join more than 165 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.
The Scrum Guide on the Product Owner
Let’s refresh our memories regarding the job of the Product Owner:
“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. […] For Product Owners to succeed, the entire organization must respect their decisions. […] The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”
Source: The Scrum Guide on the Product Owner.
Three Wide-Spread Product Owner Failures
Let me “walk” you through often observed Product Owner anti-patterns, from oversized Product Backlogs to prioritization by proxy to the omniscient Product Owner:
Oversized Product Backlogs
The Product Backlog of your team comprises hundreds of entries, from user stories to ideas to hypotheses and experiments to documentation fragments—you name it. Dumping everything into the Product Backlog—probably in the name of transparency—poses a massive challenge for various reasons:
- Garbage in, garbage out: Increasing the quantity of input does not increase the outcome of the Scrum Team’s work. In other words: Being“ busy” ≠ providing value to customers & the organization.
- The Product Backlog is the Scrum Team’s best chance to identify every Sprint the best way ahead to make your customers’ lives easier. Hence you need signals, not noise. Too many entries may make teammates less inclined to engage in the Product Backlog refinement actively.
Tip: Apply the Goldilocks principle—“just right”—and find your balance as a team. Then, dump the rest. You want an actionable Product Backlog that comprises eight to maybe twelve weeks of work. Be warned, though: Typical objections to deleting unnecessary Product Backlog items range from “we cannot delete them—it is our documentation as required by governance” to “we invested so much work in creating them.” (The former is a form of loss aversion, the latter a manifestation of the sunk cost syndrome.)
Prioritization by Proxy — Product Owner Failures
Product Owners do not represent a committee—see above—and are hence solely accountable for the maximization of value created on behalf of the customers. Nevertheless, in many organizations, stakeholders see Product Owners primarily as a tactical role, turning requirement documents into Jira tasks.
There are many reasons for that attitude, from being in the early phase of a transformation—thus being less skilled in Scrum—to a general lack of trust in the capabilities of the Scrum Team. No matter the reason, Product Owners in this situation should team up with their Scrum Masters and try to fill the role in an intended way. Otherwise, you may face grave consequences:
- You are likely to end up in a feature factory.
- Probably, you will be shipping the org chart instead of creating real value for the customer. (Conway’s law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”)
- If you practice metered funding for the Scrum Team, on top of that, it is like introducing Waterfall 2.0 through the backdoor.
I Know What to Build—Follow Me!
In this PO anti-pattern, Product Owners know best where to go the create value for the customers. They provide the “why, what, and how” and do not doubt that they are best suited to make investment decisions. They expect the rest of the Scrum Team to fall in line and follow their lead.
The problem is that this attitude renders success-critical checks & balances useless. The Developers are supposed to challenge the Product Owner: “PO, is this really the best use of our time?” As a Scrum Team, we want our Product Owners to fall in love with our customers’ problems, not their solutions.
The Conclusion: Three Wide-Spread Product Owner Failures
Admittedly, the Product Owner role is the most challenging Scrum accountability, and the higher the expectations are, the easier it is to fail them. Nevertheless, the concept of continuous improvement also applies to the Product Owner role. The examples of Product Owner anti-patterns above may be a starting point. As a Product Owner, just reach out to your teammates and ask for support. After all, Scrum is a team sport.
What Product Owner failures have you observed? Please share them with us in the comments.
✋ Do Not Miss Out and Learn about Product Owner Anti-Patterns: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Product Owner Failures — Related Posts
Product Owner Anti-Patterns — 31 Ways to Improve as a PO
28 Product Backlog and Refinement Anti-Patterns
Three Wide-Spread Scrum Master Failures in 5:31 Minutes—Making Your Scrum Work
27 Sprint Anti-Patterns Holding Back Scrum Teams
A Sprint Review without Stakeholders — Making Your Scrum Work #3
