Validate problems before building solutions using evidence standards and opportunity mapping. Use when deciding what to build next or challenging a solution that arrived before its problem.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add Amey-Thakur/AI-SKILLS --skill product-discovery --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Product Discovery?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-product-discovery)More formats (shields.io, HTML) on the badges page.
---
name: product-discovery
description: Validate problems before building solutions using evidence standards and opportunity mapping. Use when deciding what to build next or challenging a solution that arrived before its problem.
---
# Product discovery
Discovery de-risks building. The question is never "is this idea
good" but "what evidence shows this problem is real, frequent, and
painful enough that someone changes behavior to solve it".
## Method
1. **Start from the problem space, held open.** Write the target
outcome (business and user), then map opportunities beneath it
(an opportunity solution tree: outcome, opportunities,
candidate solutions, experiments). Solutions arriving first
get parked as candidates under whichever opportunity they
claim to serve; if none fits, that is the finding.
2. **Grade evidence by what it cost the user.** Weakest to
strongest: opinions in a meeting, survey answers, interview
stories about the past (see customer-interviews), observed
current behavior and workarounds, and paid/effortful
commitment (signed up, prepaid, switched tools). Fund
decisions on the top half; a deck of survey percentages is
not discovery.
3. **Hunt the workaround.** Users solving the problem today with
spreadsheets, interns, or duct tape prove frequency and pain
at once: the workaround is the demand signal *and* the
competing product. No workaround usually means no felt
problem, whatever the interviews politely said.
4. **Size before you commit.** How many users hit this, how
often, at what cost each time (see estimation-techniques for
honest Fermi work); a real problem afflicting few people
rarely is a segment decision, not a roadmap item. Check the
result against the outcome it claims to move (see
product-metrics).
5. **Run the cheapest killing experiment.** For the riskiest
assumption, choose the test that could disprove it fastest:
landing-page demand tests, concierge/manual service, fake
door (ethically: tell users after; see mvp-scoping),
prototype walkthroughs. Write the pass/fail bar before
running (see hypothesis-driven-work); experiments without
kill criteria are theater.
6. **Close the loop visibly.** Each discovery cycle ends in a
decision (pursue, park, kill) recorded with its evidence
(see decision-journals, architecture-decision-records'
sibling for product); killed ideas with reasons prevent
their monthly resurrection.
## Boundaries
- Discovery is continuous, not a phase gate; a quarter of pure
research with no shipped learning is its own failure mode
(see mvp-scoping's ship-to-learn).
- Some bets are vision-driven and evidence-light by nature;
label them as such deliberately rather than laundering them
through fake validation.
- B2B discovery must separate buyer, user, and blocker
personas; one enthusiastic champion is not a validated
market (see customer-interviews' recruiting).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!