Product Discovery
Product discovery is the process of learning which problems are worth solving and which solutions are worth building, using research and quick experiments before a team commits to full development.
Discovery lowers the risk of building something nobody needs. Teams study the people they want to serve, define the problem, generate possible solutions, and test the most promising ones with prototypes before writing production code. A widely used framing, from product author Marty Cagan, sorts product risk into four questions: whether people will value it, whether they can use it, whether it can be built, and whether it works for the business.
Discovery is different from delivery, which is the work of building, releasing, and supporting the product. Many teams do both continuously rather than treating discovery as a phase that ends. A common misconception is that discovery means collecting a long list of requirements. It is closer to testing assumptions. People can enjoy a concept and still not do what the product needs them to do, so good discovery tests behavior, not only opinions.
How it works
Frame the problem. Agree on the goal, the users, and the riskiest assumptions.
Research. Learn from users through interviews, observation, and data.
Explore solutions. Generate options and choose which ideas to test.
Prototype and test. Put quick versions in front of users and watch what they do.
Decide. Build, change direction, or stop, based on the evidence.
