Continuous Discovery Habits

Continuous Discovery Habits

A structured, repeatable approach to product discovery that helps teams make better product decisions through weekly customer touchpoints, opportunity mapping, and rapid assumption testing. Based on Teresa Torres' "Continuous Discovery Habits."

Core Principle

Good product teams don't debate opinions — they test assumptions. The goal of discovery is not to validate ideas, but to discover opportunities and find the best path to a desired outcome. Discovery is not a phase; it is a continuous, weekly habit embedded into how teams work.

The foundation: most product teams skip discovery entirely, jumping from a business outcome directly to a solution. The Opportunity Solution Tree (OST) provides the missing structure — it forces teams to explore the problem space before committing to solutions, and to compare multiple solutions against clear criteria before building anything.

Scoring

Goal: 10/10. When reviewing product discovery work, rate it 0-10:

The Opportunity Solution Tree (OST)

The core visual framework connecting business outcomes to solutions through opportunities:

        Desired Outcome
        (metric to move)
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
Opportunity Opportunity Opportunity
 (unmet need) (pain point) (desire)
    │         │
  ┌─┴─┐    ┌─┴─┐
  ▼   ▼    ▼   ▼
Sol. Sol.  Sol. Sol.
  │         │
  ▼         ▼
Assumption Assumption
  Tests      Tests

Rules for a good OST:

• One desired outcome at the top — the metric the team is trying to move
• Opportunities are customer needs, pain points, or desires — never solutions
• Solutions address specific opportunities — each solution maps to at least one opportunity
• Assumption tests validate the riskiest assumptions before building
• The tree is a living document, updated weekly

Premortem Check

Before committing to a solution branch on the OST, run a premortem: imagine the solution has shipped and failed completely. Ask "What went wrong?" and have every member of the product trio independently write down failure causes. Cluster the answers — recurring themes reveal the assumptions that are most likely to be fatal.

How to run it:

When to use it: After generating solution candidates (step 4 below) but before selecting which to test first. A 20-minute premortem is the cheapest way to surface the assumption most likely to kill the solution — before any engineering time is spent.

The Seven Habits

1. Setting the Desired Outcome

Core concept: A product trio (PM, designer, engineer) needs a single, clear outcome to optimize for. This outcome should be a measurable business or product metric that the team can directly influence.

Why it works: Without a clear outcome, teams optimize for output (ship features) instead of impact. A well-chosen outcome gives the team autonomy to find the best path while staying aligned with business goals.

Key insights:

• Outcomes should be lagging indicators of customer value (retention, activation, task success rate), not business vanity metrics (revenue alone)
• Teams need the authority to choose their own path to the outcome
• "Increase revenue" is too broad; "Increase 30-day retention for new users from 40% to 55%" is actionable
• Product outcomes (what customers do) lead to business outcomes (what the company gets)

Product applications:

Ethical boundary: Never manipulate outcomes to justify pre-decided solutions. The outcome must come before the solution, not be reverse-engineered to support it.

See: references/desired-outcomes.md

2. Discovering Opportunities

Core concept: Opportunities are unmet customer needs, pain points, and desires discovered through continuous customer interviews. They live in the middle layer of the OST, between the outcome and solutions.

Why it works: Most teams jump from outcome to solution. The opportunity layer forces teams to understand the problem space first. Multiple opportunities exist for any outcome; choosing the right one to address is a strategic decision.

Key insights:

• Opportunities come from customer stories, not from asking "what do you want?"
• Use story-based interviews: "Tell me about the last time you [did the thing]"
• Extract opportunities from stories — pain points, workarounds, unmet needs
• Organize opportunities in a hierarchy (parent opportunities break into sub-opportunities)
• Prioritize by frequency, intensity, and alignment with the desired outcome

The Interview Snapshot:

Product applications:

Copy patterns:

• Frame features around the opportunity they solve: "Never lose your place — pick up exactly where you left off"
• Use customer language from interviews, not internal jargon

Ethical boundary: Never cherry-pick interview quotes to support a preferred solution. Report all opportunities honestly, even if they challenge existing plans.

See: references/opportunity-discovery.md

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

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:

Copy patterns:

• "Our current-state map shows customers spend [X] on [step] before reaching [step]. Friction concentrates at [step]."
• "The emotional curve on our map comes from direct interview quotes — we are not guessing how customers feel."
• "The opportunities we are pursuing this quarter all lift from points of high friction on the experience map."

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

4. Generating and Evaluating Solutions

Core concept: For each target opportunity, generate multiple solutions (at least 3) and compare them. Never go with the first idea. Use compare-and-contrast thinking to find creative combinations.

Why it works: The first idea is rarely the best. By forcing multiple options, teams escape anchoring bias and find solutions that are simpler, cheaper, or more effective than the obvious choice.

Key insights:

• Generate at least 3 solutions per opportunity
• Mix solution types: product changes, process changes, service changes, content changes
• Use "How Might We" (HMW) framing to generate ideas: "How might we help users pick up where they left off?"
• Evaluate solutions against effort, impact, and assumption risk
• Combine elements from different solutions — the best solution is often a hybrid

Product applications:

Copy patterns:

• "We explored [N] approaches before choosing the one that best addresses [opportunity]"
• "Instead of building the obvious solution, we tested [alternatives] and found [insight]"
• "This solution combines the best of [approach A] and [approach B]"

Ethical boundary: Never pre-select a solution and reverse-engineer the comparison to justify it. Compare-and-contrast must be genuine — if the process always picks the first idea, it's theater.

See: references/solution-generation.md

5. Prioritizing Opportunities

Core concept: Use structured methods to compare opportunities against each other rather than evaluating them in isolation. Assess opportunity size, market factors, company factors, and customer factors to find the highest-leverage bets.

Why it works: Teams default to prioritizing by loudest stakeholder voice, recency bias (whatever the last customer said), or gut feel. Structured comparison forces explicit tradeoff discussions and surfaces disagreements that would otherwise go unspoken until implementation is underway.

Key insights:

• Compare opportunities head-to-head rather than scoring them independently — relative comparison produces better decisions
• Consider opportunity sizing: how many customers are affected, how often, how severely
• Assess alignment with company strategy and team capabilities
• Factor in what you already know — opportunities with more supporting evidence are less risky to pursue
• Avoid analysis paralysis: the goal is to make a good-enough decision quickly, then learn fast
• Revisit prioritization as you learn — new evidence may shift the ranking

Product applications:

Copy patterns:

• "We compared opportunities head-to-head. Here is why we chose [opportunity] over [alternative]."
• "Our top opportunity scores high on frequency, severity, and outcome alignment — and is mentioned in [N of M] interviews."
• "We deprioritized [opportunity] not because it is unimportant, but because [reason]. Documented for revisit when [trigger]."

Ethical boundary: Prioritization frameworks should surface real customer needs, not be gamed to justify features that serve business metrics at the expense of user value.

See: references/prioritization-methods.md

6. Assumption Mapping and Testing

Core concept: Every solution is built on assumptions. Before building, identify the riskiest assumptions and test them with the smallest possible experiment. Map assumptions across four categories: desirability, viability, feasibility, and usability.

Why it works: Building is the most expensive way to test an idea. Most solutions fail because of one or two wrong assumptions. Finding those early saves weeks or months of wasted work.

Assumption categories:

The Assumption Testing Ladder:

Key insights:

• Test the riskiest assumption first — the one that, if wrong, kills the whole idea
• Use the smallest experiment that will give you confidence
• "Will customers use it?" is almost always riskier than "Can we build it?"
• Set success criteria before running the test — don't rationalize results after
• Use the premortem output (see OST section) to identify which assumptions to map first

Product applications:

Copy patterns:

• "Before building, we tested our riskiest assumption: [assumption]. Here's what we found."
• "We set a success threshold of [X] before running the experiment — the result was [Y]"
• "This experiment disproved our assumption that [belief], saving us [time/money] in wasted development"

Ethical boundary: Design experiments to learn, not to confirm. If you're only running tests that validate your idea, you're doing it wrong.

See: references/assumption-testing.md

7. Building the Habit

Core concept: Continuous discovery only works if it becomes a sustainable weekly habit for the product trio. This requires automating recruitment, creating lightweight rituals, and embedding discovery into the existing workflow rather than treating it as extra work.

Why it works: Most teams do a burst of research at the start of a project and then stop. Continuous discovery requires structural support: automated participant recruitment, standing interview slots, shared synthesis artifacts, and team norms that make discovery non-negotiable. The habit compounds — teams that maintain it for months develop deep customer intuition that transforms every decision.

Key insights:

• The product trio (PM, designer, engineer) should participate together — not just the PM
• Automate recruitment: in-app intercepts, customer advisory panels, or scheduling tools that fill slots automatically
• Block recurring calendar time — discovery that depends on "finding time" will never happen
• Keep synthesis lightweight: fill in the snapshot immediately after the interview, not days later
• Start small: one interview per week is enough to build the habit; scale from there
• Connect discovery to delivery: insights should flow into the OST and from there into sprint planning

Product applications:

Copy patterns:

• "Discovery is on our calendar weekly, not when we 'have time.' The cadence is [day/time] every week."
• "The full trio (PM, designer, engineer) participates in every interview. Filtering insights through one person costs us context."
• "Our interview-to-insight cycle takes [N] days. We are working to compress it to [target]."

Ethical boundary: Respect participant time. Keep interviews to 30 minutes, compensate fairly, and never use discovery interviews as a disguised sales pitch.

Common Mistakes

Quick Diagnostic

Reference Files

• Desired Outcomes Guide — How to set product outcomes vs. business outcomes, outcome anti-patterns, and examples of well-written outcomes across different product stages
• Opportunity Discovery — Story-based interview techniques, opportunity extraction, interview snapshot templates, and opportunity hierarchy construction
• Experience Mapping — Current-state experience maps, identifying pain points, collaborative mapping exercises
• Solution Generation — How Might We techniques, compare-and-contrast evaluation, solution combination strategies, and avoiding first-idea bias
• Prioritization Methods — Opportunity scoring, compare-and-contrast, using data, avoiding analysis paralysis
• Assumption Testing — Assumption mapping across desirability/viability/feasibility/usability, experiment design templates, the testing ladder in detail, and success criteria frameworks

Further Reading

• Continuous Discovery Habits by Teresa Torres
• Opportunity Solution Tree template (producttalk.org)

About the Author

Teresa Torres is a product discovery coach who has worked with hundreds of product teams at companies like Netflix, Microsoft, and Spotify. She created the Opportunity Solution Tree framework and advocates for weekly customer touchpoints as a core product team habit.