Product Discovery skill for Claude Code

Discovery is done well when the team can say which customer problem it is solving, what evidence says the problem is real and worth solving, which assumptions behind the chosen solution were tested, and what result would have killed the idea. The goal is to learn cheaply before building, not to produce research for its own sake.

Ground rules

• Start from a measurable outcome (an OKR or metric), not a feature idea.
• Opportunities are customer needs, pains, or desires in the customer’s words, never solutions. “No way to see overdue tasks across projects” is an opportunity; “a dashboard” is a solution.
• Compare at least three solutions per target opportunity. One idea is a decision already made.
• Test assumptions, not whole ideas. The smallest test that could change your mind wins.
• Write the pass/fail threshold before the test runs. Thresholds set afterwards are rationalizations.
• Talk to customers every week while discovery is active: 3–5 interviews a week beats a big study every quarter.

Workflow

- [ ] 1. Name the outcome and its current baseline
- [ ] 2. Gather what is already known (tickets, analytics, past research, sales notes)
- [ ] 3. Interview customers about past behavior; capture stories
- [ ] 4. Build the opportunity solution tree; pick one target opportunity
- [ ] 5. Generate 3+ solutions; map their assumptions
- [ ] 6. Test the riskiest assumptions with the cheapest adequate test
- [ ] 7. Decide: build, iterate, pivot to another opportunity, or stop

Opportunity solution tree

Outcome: Week-1 activation 22% → 35%
├── Opp A: "I don't know what to set up first" (9 of 14 interviews)
│   ├── Sol A1: Setup checklist
│   ├── Sol A2: Templates by team type
│   └── Sol A3: Guided import from Trello/Asana
├── Opp B: "My team won't join until there's something in it" (6 of 14)
│   ├── Sol B1: Invite after first project with preview
│   └── Sol B2: Sample project pre-filled with their data
└── Opp C: "Notifications are noisy so people mute it" (3 of 14)

Pick the target opportunity by: size (how many customers, how often), link to the outcome, and whether the team can plausibly win. Break vague opportunities into children until one is specific enough to generate solutions for.

Jobs to be done

Frame each opportunity as a job: When <situation>, I want to <motivation>, so I can <expected outcome>.

When a new client project kicks off, I want everyone to see the plan in one place, so I can stop answering “what’s next?” in Slack.

Capture the forces for each job: push of the current situation, pull of the new solution, anxiety about switching, habit of the present way. If anxiety plus habit outweigh push plus pull, a better product still loses; design for switching cost, not just features.

Customer interviews

Rules:

• Ask about specific past behavior: “Tell me about the last time you…”. Never “Would you use…?” or “How much would you pay?” (hypothetical answers are unreliable).
• One interviewer, one note-taker. 30–45 minutes. Record with consent.
• Recruit people who had the problem recently (last 30–90 days), including people who churned or chose a competitor.
• 5–8 interviews per segment usually surface the main themes; stop when new interviews add no new opportunities.

Interview guide skeleton:

1. Context (5 min): role, team, tools they use for <area>
2. Story (20 min): "Tell me about the last time you <did the job>."
   - What triggered it? What did you do first? Then what?
   - What was hardest? What did you try that didn't work?
   - Who else was involved? What did it cost (time, money, risk)?
3. Current workaround (5 min): show me how you do it today
4. Wrap (5 min): anything we didn't ask? Who else should we talk to?

Leading vs. neutral:

Leading	Neutral
“Would a dashboard help you track overdue tasks?”	“How do you find out a task is overdue today?”
“Isn’t onboarding confusing?”	“Walk me through your first day with the product.”
“How often do you export reports?” (assumes they do)	“What happens after the monthly review meeting?”

Synthesize each interview the same day into an interview snapshot: quote, story, opportunities heard, insights (see user-research-synthesis for cross-interview work).

Assumption mapping

For the chosen solution, list assumptions in five categories:

Category	Question	Example
Desirability	Do they want it?	Leads will open a weekly digest
Viability	Does it work for the business?	Digest doesn’t raise email unsubscribes
Feasibility	Can we build it?	Risk scoring works on existing data
Usability	Can they use it?	Leads understand the risk score without help
Ethical / legal	Should we?	Showing individual workload is acceptable to teams

Plot each on importance (would the idea fail if wrong?) vs. evidence (what do we know?). Test the important, low-evidence quadrant first.

Choosing a test

Assumption type	Test	Cost	Signal
Problem exists and is frequent	Data pull, ticket search, interview stories	Hours	Counts, frequency
Demand for a solution	Fake door / painted door button with “coming soon”	1–3 days	Click-through vs. baseline
Willingness to pay	Pricing page test, pre-order, LOI from customers	Days	Conversion, signed commitments
Value of the outcome	Concierge or Wizard-of-Oz (manual behind the scenes)	1–2 weeks	Repeat use, retention of test group
Usability	Clickable prototype, 5 users, task-based	2–4 days	Task success rate, time on task
Feasibility	Technical spike (see technical-spike)	1–5 days	Works on real data or not

Write each test as a card before running:

Assumption: Team leads want a weekly risk digest.
Test: Fake-door "Weekly risk digest" toggle in settings for 2 weeks, 50% of leads.
Metric: % of exposed leads who click the toggle.
Pass: ≥ 8% click (baseline for new settings toggles is ~2%). Fail: < 4%. Between: iterate copy, rerun once.
Sample: ~1,200 exposed leads → enough to tell 8% from 4%.
Decision if pass: build v1 digest. If fail: drop, revisit Opp A.

For quantitative pass/fail on live traffic, size the sample and analyze it properly (see experiment-analysis).

Decide

Evidence	Decision
Riskiest assumptions passed	Build the smallest version that delivers the outcome; write the PRD (see prd-writing)
Mixed, with a clear reason	Iterate the solution and retest once
Failed on desirability	Try another solution for the same opportunity
Opportunity itself weak	Move to the next opportunity on the tree
Two rounds without signal	Stop and report what was learned

Gotchas

• Validation theater: interviewing to confirm a decided feature. If no result could change the plan, skip the research and say so.
• Asking customers for solutions. They describe problems well and design poorly.
• Compliments as data. “That sounds great” predicts nothing; commitments (time, money, data, introductions) do.
• Over-indexing on the loudest customer. Count how many interviews mention an opportunity before acting on it.
• Fake doors without follow-up. Show a clear “not available yet” message and optionally collect interest; never charge or mislead.
• Discovery as a phase. Discovery continues alongside delivery; keep the tree updated.

Verification

• The outcome and its baseline are written at the top.
• Every opportunity is phrased as a need, with interview or data counts.
• At least three solutions were considered for the target opportunity.
• Every test card had a pass/fail threshold dated before the test started.
• The decision follows from the results table, and the evidence is linked.

Output contract

# Discovery: <outcome> — <dates>
Outcome: <metric baseline → target>   Interviews: <n, segments>   Tests run: <n>

## Opportunity solution tree
## Target opportunity and why (size, evidence)
## Solutions considered
## Assumption map (top risks)
## Tests
| Assumption | Test | Pass/fail set before | Result | Decision |
## Decision and next step
## Evidence appendix (snapshots, data pulls)