continuous-discovery

Files (7)

• SKILL.md
• assumption-mapping.md · references/
• case-studies.md · references/
• experience-mapping.md · references/
• interview-snapshots.md · references/
• opportunity-trees.md · references/
• prioritization-methods.md · references/

SKILL.md (first lines)

# Continuous Discovery Habits Framework

Framework for building a sustainable weekly practice of customer discovery that keeps product teams progressing toward desired outcomes. Discovery is not a phase before development — it is embedded in the ongoing rhythm of product work so every decision is informed by fresh evidence.

## Core Principle

**Good product discovery requires a continuous cadence, not a one-time event.** Teams that talk to customers every week, map opportunities visually, and test assumptions before building consistently outperform teams that rely on intuition, stakeholder opinions, or quarterly research cycles. The benchmark: at least one customer touchpoint per week, every week, by the product trio (product manager, designer, engineer).

## Scoring

**Goal: 10/10.** Score a discovery practice by the seven Quick Diagnostic rows below — start at 3, add 1 point per row answered "yes" (max 10). Bands: **9-10** = weekly cadence, a living Opportunity Solution Tree, systematic assumption testing, and every shipped feature traceable to a customer opportunity; **5-6** = some discovery happening but ad hoc, PM-only, or disconnected from delivery; **≤3** = intuition- and stakeholder-driven with no regular customer contact. Report the current score, the failing rows, and the specific fix for each.

## Framework

### 1. Opportunity Solution Trees

**Core concept:** An Opportunity Solution Tree (OST) visually connects a desired outcome (top) to customer opportunities (middle) to potential solutions and experiments (bottom), making implicit product thinking explicit and shared.

**Why it works:** Most teams jump from business outcome straight to solutions, skipping the customer need entirely; the OST forces understanding of the opportunity space first, preventing features nobody wants.

**Key insights:**
- Four layers: Outcome > Opportunities > Solutions > Experiments
- Opportunities are customer needs, pain points, and desires — framed from the customer's perspective
- The tree is a living artifact, updated weekly as the team learns
- Break large opportunities into smaller sub-opportunities to make them actionable
- Pursue multiple opportunities simultaneously — don't bet everything on one

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Quarterly planning | Map the opportunity space before committing to features | "Increase trial-to-paid conversion" → discover why users don't convert |
| Feature prioritization | Compare solutions across opportunities for the highest-leverage bet | Three solutions for "can't find content" vs. two for "confusing onboarding" |
| Stakeholder alignment | Use the tree as the shared strategy visual | Walk leadership through why you chose opportunity X over Y |

**Ethical boundary:** Never cherry-pick opportunities to justify a predetermined solution — the tree must reflect needs discovered through research.

See [references/opportunity-trees.md](references/opportunity-trees.md) when building or auditing a tree — adds the 4-layer diagram, good-vs-poor outcome tables, solution-generation techniques, a weekly update rhythm, healthy/dying-tree signals, two worked examples, and four anti-patterns.

### 2. Experience Mapping

**Core concept:** Current-state experience maps capture how customers accomplish a goal today, step by step, revealing pain points that become opportunities on the tree.

**Why it works:** Teams assume they understand the customer's current experience; mapping it from interview data exposes gaps, workarounds, and emotions invisible from inside the building.

**Key insights:**
- Map the current state, not a future ideal — understand reality first
- Include actions, thoughts, and feelings at each step
- Build collaboratively with the full trio, sourced from interview data, not assumptions
- Experience maps cover the customer's full experience; journey maps cover only your product's touchpoints
- Pain points and high-emotion moments become OST opportunities

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| New problem space | Map end-to-end before designing | How a small business owner handles invoicing, from creation to chasing payment |
| Churn analysis | Map churned users' experience to find failure points | Users abandon onboarding at step 4 — they lack data they need on hand |
| Cross-functional alignment | Build the map together | A three-hour collaborative session produces one shared reference artifact |

See [references/experience-mapping.md](references/experience-mapping.md) when mapping a new problem space or churn flow — adds the current-state map template, the experience-vs-journey-map distinction, and the collaborative mapping exercise.

### 3. Interview Snapshots

**Core concept:** Story-based interviews capture specific past experiences (not opinions or predictions), and each interview is synthesized into a one-page snapshot the whole team can absorb and reference.

**Why it works:** Customers are poor predictors of their own future behavior; grounding insights in real past events reveals what they actually did and felt, and snapshots turn each interview into a growing library of evidence.

**Key insights:**
- Ask about specific past behavior: "Tell me about the last time you..." not "Would you use...?"
- Each snapshot captures the story, key quotes, opportunities identified, and an identifier
- The trio interviews together so insights aren't lost in translation
- Automate recruitment so interviews happen weekly without heroic effort
- Patterns across snapshots reveal opportunities; single interviews only reveal stories

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Weekly cadence | Standing 30-minute interview slots | Recruit via in-app prompt; rotate who leads |
| Opportunity discovery | Extract needs from stories onto the OST | A data-export workaround becomes an opportunity node |
| Team alignment | Share snapshots visibly | A board where snapshots accumulate and patterns emerge |

**Ethical boundary:** Never lead participants toward conclusions — ask open-ended questions about past behavior and let the story reveal what matters.

See [references/interview-snapshots.md](references/interview-snapshots.md) when running interviews or setting up recruitment — adds story-based interview structure, the one-page snapshot format, synthesis across snapshots, and how to automate weekly recruitment.

### 4. Assumption Testing

**Core concept:** Before building, identify the assumptions a solution depends on, map them by importance and evidence, then run small fast tests on the riskiest ones first.

**Why it works:** Every solution sits on a stack of desirability, viability, feasibility, and usability assumptions; most teams test none — or only the easy ones — and invest months in solutions built on false premises.

**Key insights:**
- Four assumption types: desirability (do they want it?), viability (can we sustain it?), feasibility (can we build it?), usability (can they use it?)
- Map on a 2x2: importance vs. evidence; high-importance, low-evidence = leap-of-faith assumptions to test first
- Design the smallest test that generates evidence: one-question surveys, painted-door tests, prototypes, data mining
- Set success criteria before running the test: "validated if..."
- One assumption test should take days, not weeks

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Before building | Test the riskiest assumption of the top candidates | "Users will share reports with their manager" → painted-door button before building sharing |
| Comparing solutions | Test each candidate's riskiest assumption to eliminate weak options fast | A's riskiest assumption fails, B's passes → pursue B |
| De-risking a roadmap | Find untested assumptions hiding in committed features | Q3 feature assumes users want real-time notifications — no evidence yet |

**Ethical boundary:** Never deceive participants — painted-door tests should say the feature is coming soon, not fake functionality without disclosure.

See [references/assumption-mapping.md](references/assumption-mapping.md) when designing a test for a risky assumption — adds the four assumption types in depth, the importance-vs-evidence 2x2, the test-design menu, and how to set success criteria for leap-of-faith assumptions.

### 5. Prioritizing Opportunities

**Core concept:** Compare opportunities against each other — not in isolation — using opportunity size, market, company, and customer factors to find the highest-leverage bets.

**Why it works:** Teams default to the loudest stakeholder, recency bias, or gut feel; structured head-to-head comparison forces explicit tradeoff discussions and surfaces disagreements before implementation.

**Key insights:**

From DevRik99/forge-mcp, MIT.

More from DevRik99/forge-mcp