continuous-discovery

What this skill does

# Continuous Discovery Habits Framework

Framework for building a sustainable, weekly practice of customer discovery that keeps product teams making progress toward desired outcomes. Rather than treating discovery as a phase that happens before development, this framework embeds customer learning into the ongoing rhythm of product work so that 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 goal is at least one customer touchpoint per week, every week, by the product trio (product manager, designer, engineer).

## Scoring

**Goal: 10/10.** When reviewing or creating a product discovery practice, rate it 0-10 based on adherence to the principles below. A 10/10 means the team has a weekly interview cadence, maintains a living Opportunity Solution Tree, systematically tests assumptions, and uses evidence to decide what to build. Lower scores indicate gaps in cadence, structure, or rigor. Always provide the current score and specific improvements needed to reach 10/10.

## Framework

### 1. Opportunity Solution Trees

**Core concept:** An Opportunity Solution Tree (OST) is a visual map that connects a desired outcome at the top to customer opportunities in the middle and potential solutions at the bottom. It makes implicit product thinking explicit and shared.

**Why it works:** Most teams jump from a business outcome straight to solutions, skipping the customer need entirely. The OST forces teams to first understand the opportunity space -- the unmet needs, pain points, and desires customers have -- before generating solutions. This prevents building features nobody wants.

**Key insights:**
- The tree has four layers: Outcome > Opportunities > Solutions > Experiments
- Opportunities are customer needs, pain points, or desires -- framed from the customer's perspective
- A single outcome typically has many opportunities; a single opportunity can have many solutions
- The tree is a living artifact -- updated weekly as the team learns
- Breaking large opportunities into smaller sub-opportunities makes them actionable
- Teams should pursue multiple opportunities simultaneously, not bet everything on one

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Quarterly planning | Define the outcome, then map the opportunity space before committing to features | "Increase trial-to-paid conversion" as outcome, then discover why users don't convert |
| Feature prioritization | Compare solutions across different opportunities to find highest-leverage bets | Three solutions for "users can't find relevant content" vs. two for "onboarding is confusing" |
| Stakeholder alignment | Use the tree as a shared visual to align on strategy and tradeoffs | Walk leadership through the tree to show why you chose opportunity X over Y |

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

See: [references/opportunity-trees.md](references/opportunity-trees.md)

### 2. Experience Mapping

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

**Why it works:** Teams often assume they understand the customer's current experience, but mapping it collaboratively from interview data reveals gaps, workarounds, and emotions that are invisible from the inside. The map generates opportunities you would never brainstorm from a conference room.

**Key insights:**
- Map the current state, not a future ideal -- you need to understand reality first
- Include actions, thoughts, and feelings at each step
- Build maps collaboratively with the full product trio
- Use interview data as the source, not assumptions
- Journey maps (your product's touchpoints) differ from experience maps (the customer's full experience regardless of your product)
- Pain points and moments of high emotion on the map become opportunities on the OST

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| New problem space | Map the end-to-end experience before designing anything | Map how a small business owner handles invoicing today, from creating to chasing payment |
| Churn analysis | Map the experience of users who churned to find failure points | Discover that users abandon onboarding at step 4 because they need data they don't have handy |
| Cross-functional alignment | Build the map together so engineering, design, and product share one view | Three-hour collaborative session produces a shared reference artifact |

**Ethical boundary:** Experience maps must reflect real customer experiences from interviews, not the team's projection of what they imagine customers feel.

See: [references/experience-mapping.md](references/experience-mapping.md)

### 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 that the whole team can quickly absorb and reference.

**Why it works:** Traditional interview methods ask customers what they want -- but customers are poor predictors of their own future behavior. Story-based interviewing grounds insights in real past events, revealing what customers actually did and felt. The snapshot format makes synthesis fast and creates a growing library of customer evidence.

**Key insights:**
- Ask about specific past behavior, not hypothetical futures: "Tell me about the last time you..." not "Would you use a feature that...?"
- Each snapshot captures: the story, key quotes, opportunities identified, and a photo or identifier
- The product trio should interview together so insights aren't lost in translation
- Automate recruitment so interviews happen weekly without heroic effort
- Synthesize across snapshots to find patterns -- single interviews reveal stories, patterns reveal opportunities
- Aim for at least one interview per week; many teams do two or three

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Weekly cadence | Schedule three 30-minute interviews every Thursday | Recruit from existing users via in-app prompt; rotate who leads the conversation |
| Opportunity discovery | Extract customer needs from interview stories and add to the OST | User describes workaround for exporting data -- becomes an opportunity node |
| Team alignment | Share snapshots in a visible location so everyone absorbs the same evidence | Physical wall or digital board where snapshots accumulate and patterns emerge |

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

See: [references/interview-snapshots.md](references/interview-snapshots.md)

### 4. Assumption Testing

**Core concept:** Before building a solution, identify the underlying assumptions that must be true for it to succeed, map them by type and risk, then design small, fast tests to validate or invalidate the riskiest ones first.

**Why it works:** Every solution is built on a stack of assumptions about desirability, viability, feasibility, and usability. Most teams test none of them before building, or they test the easy ones instead of the risky ones. Systematic assumption mapping and testing prevents investing 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