product-discovery

name	product-discovery
description	Reduce product uncertainty before major commitment by framing the problem, identifying risky assumptions, gathering user and market evidence, testing solution hypotheses, and deciding what to build or learn next.

Product Discovery

Use when the team is unsure whether a problem matters, which users have it, what outcome is valuable, whether a proposed solution is desirable, or which assumption should be tested before implementation.

Procedure

1. Frame the problem without anchoring on the requested feature. State who appears affected, what they are trying to accomplish, the current pain or opportunity, and the evidence already available.
2. List the assumptions that must be true for the initiative to succeed. Separate desirability, usability, viability/business, feasibility, adoption/change, and measurement assumptions as relevant.
3. Rank assumptions by risk: how consequential it would be if false and how uncertain the team currently is. Discovery should attack the riskiest unknowns first rather than collecting broad background information indefinitely.
4. Choose the cheapest credible evidence for the assumption. This may be existing analytics/support data, user research, market research, prototype/usability testing, a concierge/manual test, technical spike, pricing test, or another bounded experiment. Route each evidence-gathering task to the specialist who owns the method.
5. Define what result would change the decision before gathering evidence. Avoid experiments whose success criteria are invented after the results are known.
6. Preserve raw evidence and distinguish observation from interpretation. A handful of enthusiastic comments, survey responses, usage events, or competitor features should not be generalized beyond what the sample and method support.
7. Update the problem/opportunity and assumptions from the evidence. Kill, narrow, reframe, or expand the idea when evidence justifies it rather than treating discovery as a ritual before the predetermined build.
8. When solution exploration is appropriate, compare multiple approaches around the user outcome and constraints. Keep implementation architecture with design/engineering owners.
9. Conclude with a decision: proceed to requirements/design, run another specific discovery step, change target/problem, defer, or stop. Record the evidence and remaining uncertainty behind that decision.

Decision rules

• Discovery exists to change decisions, not to generate decks.
• Start with the highest-risk assumption, not the easiest research activity.
• Product Manager coordinates discovery but does not replace User Researcher, Market Researcher, Product Designer, Technical Lead, or other specialists who own the methods.
• A prototype can test comprehension or workflow without proving demand; a signup can show interest without proving sustained use. Match evidence to the claim.
• Stopping a weak idea after cheap discovery is a successful outcome.

Quality gate

Discovery is complete for the current decision when the risky assumptions are explicit, appropriate specialists gathered evidence capable of testing them, decision thresholds were defined in advance where practical, conclusions do not exceed the evidence, and the next product commitment or learning step follows clearly from what was learned.