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:

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

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:

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

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:

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

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 t