TL; DR: Product Discovery Anti-Patterns
Scrum has proven to be an effective product delivery framework for all sorts of products. However, Scrum is equally well suited to build the wrong product efficiently as its Achilles heel has always been the product discovery part. What product discovery part, you may think now. And this is precisely the point: The Product Owner miraculously identifies what is the best way to proceed as a Scrum Team by managing the Product Backlog. How that is supposed to happen is nowhere described in the Scrum Guide. Consequently, when everyone is for themselves, product discovery anti-patterns emerge.
From sunk costs, HIPPO-ism, my-budget-my-features to self-fulfilling prophecies?— learn more about the numerous product discovery anti-patterns that can manifest themselves when you try to fill Scrum’s product discovery void.
Scrum’s Achilles Heel: Product Discovery
In the attempt to fill Scrum’s product discovery void, product delivery organizations regularly turn to other agile frameworks like lean UX, jobs-to-be-done, lean startup, design thinking, design sprint—just to name a few. The wave of agile transition projects, particularly in large, established organizations over recent years, has provided those frameworks with a tremendous tailwind. Meanwhile, some ideas have gained buzzword status in the process, causing the occasional collateral damage along the way. (Think of “MVP.”)
Generally, it is safe to assume that product discovery anti-patterns result from a broader set of issues by comparison to the anti-patterns of a particular framework such as Scrum.
The main contributing variables to various product discovery anti-patterns are:
Additionally, particularly larger organizations struggle with the necessary transition at the core of the process of becoming an agile, learning organization: The move from allocating budgets to projects staffed with temporary teams group of FTEs to building and funding lasting, empowered product teams.
I do believe that a separation between product discovery on the one side (product management), and product delivery (Scrum teams) on the other side is no longer a viable approach. To prevail in today’s game of an accelerated innovation-based competition—software is eating the world—, every organization needs to acquire a holistic understanding of an agile product creation process:
A vision leads to a strategy that (probably) results in a portfolio of products (and services). Each of those products has a product roadmap that needs to be reflected in the product’s backlog, which ultimately provides the Sprint Backlog. This core agile product creation process is agnostic to the product delivery framework, be it Scrum, XP, or any other framework.
The organization needs to inspect and adapt every layer of this hierarchy continuously within appropriate time intervals. Apparently, there is a difference in the inspect & adapt cadence when product strategy and Sprint Backlog are compared to each other. (Example: The Secret Tesla Motors Master Plan (just between you and me) from August 2nd, 2006.)
Keeping this holistic product creation process in mind, you can often observe some of the following product discovery anti-patterns in practice.
Product Discovery Anti-Patterns: The Fallacy of Knowing Better
Product Discovery Anti-Patterns: Silos at Work
Product Discovery Anti-Patterns: Cargo-Cult Discovery
Product Discovery Anti-Patterns: Ideas, Hypotheses, and Feedback
Product Discovery Anti-Patterns: Egos at Work
A holistic product discovery & delivery process is at the heart of any learning organization employing Scrum. Filling the product discovery void of Scrum or any other product delivery framework of your choice becomes, therefore, is a necessity. And there are plenty of agile frameworks and practices to choose from for that purpose. Watching out for the product discovery anti-patterns listed above will save your organization significant resources in doing so.
What product discovery anti-patterns am I missing? Please share your experience with us in the comments.