# Product Discovery

> 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.

- Skill: `amey-thakur/product-discovery` (Agent Skill)
- Install (CLI): `npx skillmds@latest add amey-thakur/product-discovery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/amey-thakur/product-discovery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Amey-Thakur (https://skillmd.com/u/amey-thakur)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/amey-thakur/product-discovery

---


# 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).