| name | product-discovery |
| description | Use when the user wants to validate ideas before building, run product experiments, reduce risk on a new feature, or decide whether a problem is worth solving. Also use when the user mentions 'product discovery,' 'validate before building,' 'opportunity solution tree,' 'prototype testing,' 'hypothesis testing,' 'dual-track,' or 'de-risking a feature.' |
Product Discovery
Discovery is the work done before building to ensure the right problem is solved and the right solution is chosen. The cost of discovery is days. The cost of building the wrong thing is months.
The Four Discovery Risks
Every product bet carries four types of risk. Discovery must reduce each one before build begins.
| Risk | Question to answer |
|---|
| Value risk | Will customers find this valuable enough to use / pay for? |
| Usability risk | Can customers figure out how to use it? |
| Feasibility risk | Can we build this in a reasonable timeframe? |
| Viability risk | Does this work for the business? (legal, revenue, ops) |
Most teams only test value and feasibility. Usability and viability failures surface at launch.
Opportunity Solution Tree (Teresa Torres)
Structures the relationship between outcomes, opportunities, and solutions:
Desired Outcome (the product goal)
├── Opportunity 1 (customer problem/need)
│ ├── Solution A
│ └── Solution B
├── Opportunity 2
│ ├── Solution C
│ └── Solution D
└── Opportunity 3
Rules:
- Start with the outcome, not the solution
- Opportunities are customer problems — not features
- Each solution must be testable before building
- Never evaluate a solution without first naming the opportunity it addresses
Discovery Techniques by Risk Type
Value risk:
- Customer interviews ("would you use this" is not enough — test with a prototype)
- Concierge test (do the job manually for 5 customers before automating it)
- Fake door test (landing page with signup before building)
Usability risk:
- Prototype walkthroughs (no guidance — watch where they get stuck)
- Hallway testing (5 people, one afternoon, reveals most usability problems)
- First-click test (where do users click first? Does it match intent?)
Feasibility risk:
- Spike / technical prototype (not a UI — a proof of concept for the hard engineering problem)
- Engineering estimate with 2 approaches compared
Viability risk:
- Legal / compliance review before full build
- Finance modeling (unit economics at target scale)
- Ops review (support load, infrastructure cost)
The Experiment Hierarchy (Weakest to Strongest Evidence)
- Expert opinion / desk research
- Customer interview (what they say)
- Survey (what they say at scale)
- Prototype test (how they behave with a mock)
- Concierge test (how they behave with the real service)
- A/B test on live product (how they behave at scale)
For high-risk bets, run experiments at level 4+. For low-risk improvements, level 2-3 is enough.
Discovery Cadence
Weekly: 1-2 customer interviews or usability sessions
Sprint: Minimum 1 experiment that reduces the top risk on the next big bet
Quarterly: Review opportunity solution tree — are we working on the right opportunities?
Common Rationalizations
| Rationalization | Reality |
|---|
| "We don't have time for discovery" | You don't have time to rebuild a feature you didn't validate. Discovery is the time saver. |
| "We already know the solution" | You know a solution. Discovery finds the best one. |
| "Our customers are asking for this feature" | Customer requests are opportunities, not solutions. Test the job before committing to the feature. |
| "A prototype test isn't realistic enough" | Prototypes reveal usability problems. You don't need production fidelity to find them. |
Verification
