Chapter 1. The what and why of continuous discovery
Product managers bring the business context - they help teams ensure that the products they are building are viable for the business. They ensure that the business that supports the product will survive over time, allowing the team to further satisfy customers’ needs.
To distinguish teams who occasionally do modern discovery activities from teams who do continuous discovery, we’ll adopt the following definition of continuous discovery:
At at minimum, weekly touchpoints with customers
By the team building the product
Where they conduct small research activities
In pursuit of a desired outcome
Chapter 2. A common framework for continous discovery
Finding the best path to your desired outcome is what researchers call an “ill-structured problem” Ill-structured problems are defined by having many solutions.
Much of the work when tacking an ill-structured problem is framing the problem itself. How we frame a problem has a big impact on how we might solve it.
In this book, I’ll refer to customer needs, pain points, and desires collectively as “opportunities” Why don’t we call them “problems to solve”? In the product world, we don’t just solve customer problems. The word “problem” implies something needs fixing. However, we have many examples of products or services that don’t fix problems.
How we frame an ill-structured problem impacts how we might solve it. … good problem-solvers try out many framings, exploring how each impacts the solution space.
Shifting from a project mindset to a continuous mindset is hard. We tend to take our six-month-long waterfall project, carve it up into a series of two-week sprints, and call it “Agile.” But this isn’t Agile. Nor is it continuous. A continuous mindset requires that we deliver value every sprint. We create customer value by addressing unmet needs, resolving pain points, and satisfying desires.
In Descisive, the Heath brothers outline many tactics for overcoming the four villains of decision-making … Instead of framing our decisions as “whether or not” decisions, this book will teach you to develop a “compare and contrast” mindset. Instead of asking, “Should we solve this customer need?” we’ll ask, “Which of these customer needs is most important for us to address right now?”
Some have come to believe that product managers own defining the problem and that designers and software engineers own defining the solution. This sounds nice in theory, but it quickly falls apart in practice.
Best designers evolve the problem space and the solution space togehter.