In a nutshell, Tim breaks down the complete Product Discovery into 6 phases:
Create clarity, shared understanding, and commitment in the discovery team about the scope of the current discovery iteration, including the context, the business intent behind it, the team objective, and the boundaries.
Achieve a deep understanding of the problems and pains of actual users, ideally firsthand directly by observing users during a job-to-be-done.
Start thinking about potential solutions to the problem(s) identified; attempt to think big initially.
Create a prototype that can afterward be tested.
Note that while in most cases we think of a prototype as a kind of click dummy to show to users, a feasibility prototype can also be used to understand a new technology, test a new integration, validate an idea of a new technology architecture, etc.
Involve the learnings from testing and create a final, polished concept ready to be handed over to Product Delivery.
Just like the process that we explained in part 3 of this playbook, this framework also distinguishes between the problem space and solution space:
Contrary to what the initial hexagon suggests, Product Discovery is rarely a linear process. Rather, sometimes it is ok to cut corners. In other situations, it may be required to take a step back and start fresh because the team might got stuck:
