Continuous Discovery

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. Rate any discovery practice 0-10: a 10/10 means a weekly interview cadence, a living Opportunity Solution Tree, systematic assumption testing, and evidence-driven build decisions. Report the current score and the specific improvements needed to reach 10/10.

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:

Ethical boundary: Never cherry-pick opportunities to justify a predetermined solution — the tree must reflect 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 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:

Ethical boundary: Maps must reflect real customer experiences from interviews, not the team's projection of what 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 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:

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

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:

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

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:

• Relative comparison beats independent scoring
• Size opportunities by how many customers are affected, how often, how severely
• Weigh strategy alignment, team capability, and existing evidence
• Make a good-enough decision quickly, then learn fast — avoid analysis paralysis
• Revisit the ranking as new evidence arrives

Product applications:

Ethical boundary: Prioritization should surface real customer needs, not be gamed to justify features that serve business metrics at users' expense.

See: references/prioritization-methods.md

6. Building the Habit

Core concept: Continuous discovery only works as a sustainable weekly habit for the trio — automate recruitment, create lightweight rituals, and embed discovery into the existing workflow rather than treating it as extra work.

Why it works: Most teams do a research burst and stop; structural support (automated recruitment, standing slots, shared artifacts) makes the habit compound into deep customer intuition that transforms every decision.

Key insights:

• The whole trio participates — not just the PM
• Automate recruitment: in-app intercepts, advisory panels, scheduling tools that fill slots
• Block recurring calendar time — discovery that depends on "finding time" never happens
• Fill in the snapshot immediately after the interview, not days later
• Start with one interview per week; connect insights to the OST and from there into sprint planning

Product applications:

Ethical boundary: Respect participant time — keep interviews to 30 minutes, compensate fairly, and never disguise a sales pitch as discovery.

See: references/case-studies.md

Common Mistakes

Quick Diagnostic

Reference Files

• opportunity-trees.md: OST structure, how to build and maintain one, mapping opportunities to solutions
• interview-snapshots.md: Story-based interviewing, snapshot format, synthesis, automating recruitment
• assumption-mapping.md: Assumption types, mapping technique, designing tests, leap-of-faith assumptions
• experience-mapping.md: Current-state maps, identifying pain points, collaborative mapping exercises
• prioritization-methods.md: Opportunity scoring, compare-and-contrast, using data, avoiding analysis paralysis
• case-studies.md: Continuous discovery applied to B2B SaaS, consumer mobile, platform, and growth teams

Further Reading

Based on the continuous discovery framework developed by Teresa Torres:

• *"Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value"* by Teresa Torres

About the Author

Teresa Torres is an author, speaker, and coach who has helped hundreds of product teams — from startups to Capital One and Calendly — adopt continuous discovery. She created the Opportunity Solution Tree, writes the widely read Product Talk blog, and distilled her coaching practice into Continuous Discovery Habits.

Assumption Mapping

A detailed guide to identifying, categorizing, prioritizing, and testing the assumptions that underlie product decisions, so teams invest in building only what evidence supports.

Why Assumptions Matter

Every product decision rests on a stack of assumptions. When a team says "let's build feature X to solve opportunity Y," they are implicitly assuming:

• Customers actually have this need (desirability)
• Customers can figure out how to use it (usability)
• We can build it with acceptable effort (feasibility)
• The business can sustain it (viability)

Most teams never make these assumptions explicit. They build first and discover their assumptions were wrong after investing weeks or months. Assumption mapping inverts this: make assumptions explicit, identify the riskiest ones, and test them cheaply before committing resources.

Types of Assumptions

Desirability Assumptions

Question: Do customers want this? Will they choose to use it?

These are the most common and most dangerous assumptions because teams often believe their own enthusiasm is evidence of customer demand.

Viability Assumptions

Question: Does this work for our business? Can we sustain it?

Feasibility Assumptions

Question: Can we build this? Do we have the capability?

Usability Assumptions

Question: Can customers figure out how to use this? Will they succeed?

The Assumption Mapping Technique

Step 1: Generate Assumptions

For each solution the team is considering, brainstorm all the assumptions that must be true for it to succeed. Use the four categories as prompts:

Facilitator prompts:

• "For this solution to work, what must be true about what customers want?" (desirability)
• "For this to be viable, what must be true about our business model?" (viability)
• "For us to build this, what must be true about our technology and team?" (feasibility)
• "For customers to succeed with this, what must be true about the experience?" (usability)

Tips for generating assumptions:

• Write each assumption as a statement that could be true or false: "Users will share reports at least once per week"
• Be specific: "Users will pay" is too vague; "Users will pay $20/month for this feature" is testable
• Include implicit assumptions the team takes for granted -- these are often the most dangerous
• Aim for 10-20 assumptions per solution

Step 2: Map Assumptions on the 2x2

Plot each assumption on a two-axis grid:

                    HIGH IMPORTANCE
                    (fatal if wrong)
                          │
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
        │   TEST THESE    │   WATCH THESE   │
        │   FIRST         │   (probably OK)  │
        │                 │                 │
LOW ────┼─────────────────┼─────────────────┼──── HIGH
EVIDENCE│                 │                 │  EVIDENCE
        │   TEST THESE    │   SAFE TO       │
        │   SECOND        │   ASSUME        │
        │                 │                 │
        │                 │                 │
        └─────────────────┼─────────────────┘
                          │
                    LOW IMPORTANCE
                    (survivable if wrong)

Importance (vertical axis): How critical is this assumption? If it's wrong, does the whole solution fail (high), or is it a minor setback (low)?

Evidence (horizontal axis): How much do we already know? Do we have strong evidence from interviews, data, or tests (high), or is this pure speculation (low)?

Step 3: Identify Leap-of-Faith Assumptions

The assumptions in the top-left quadrant -- high importance, low evidence -- are your leap-of-faith assumptions. These are the ones that could kill your solution if wrong, and you have little or no evidence to support them.

Rule: Never build a solution without first testing its leap-of-faith assumptions.

Step 4: Prioritize Testing Order

Test in this order: 1. High importance, low evidence (leap-of-faith) -- test first, these are fatal unknowns 2. Low importance, low evidence -- test second if easy, or defer 3. High importance, high evidence -- monitor but don't spend testing effort 4. Low importance, high evidence -- safe to assume; revisit only if context changes

Designing Assumption Tests

Principles of Good Tests

Test Types by Assumption Category

Desirability Tests

Viability Tests

Feasibility Tests

Usability Tests

Setting Success Criteria

Before running any test, define what success and failure look like. This prevents post-hoc rationalization.

Formula for Success Criteria

"We'll consider this assumption validated if [measurable outcome] reaches [threshold] within [timeframe]."

Examples:

• "We'll consider 'users want PDF export' validated if at least 15% of active users click the painted-door button within one week."
• "We'll consider 'users can complete setup in under 5 minutes' validated if 80% of test participants finish the task without help."
• "We'll consider 'users will pay $20/month' validated if at least 5% of free users shown the upgrade page initiate checkout."

Choosing Thresholds

Assumption Testing in Practice

Weekly Rhythm

When Tests Are Inconclusive

Not every test produces a clear signal. When results are ambiguous:

1. Check the test design: Was the sample large enough? Was the test specific enough? 2. Refine and retest: Adjust the test to be more targeted 3. Lower the stakes: If you can't get a clear signal, is there a way to build a smaller version that lets you learn in production? 4. Time-box the uncertainty: "If we can't validate this in two more weeks of testing, we'll move to a different solution"

Documenting Test Results

For each assumption test, record:

• Assumption tested: The specific statement
• Test type: What you did
• Success criteria: What you defined upfront
• Results: What actually happened
• Decision: Validated, invalidated, or inconclusive
• Next step: What changes based on this result

This creates an audit trail of evidence that supports decision-making and helps new team members understand why choices were made.

Leap-of-Faith Assumptions: Deep Dive

Leap-of-faith assumptions are the untested beliefs that, if wrong, make the entire solution pointless. They deserve special attention.

How to Identify Them

Ask the team: "If we could only test one thing before building, what would tell us the most about whether this will work?"

Common leap-of-faith patterns:

• "They have this problem" -- the need hasn't been validated through interviews
• "They'll change their behavior" -- the solution requires users to adopt a new habit
• "They'll pay for this" -- no evidence of willingness to pay
• "This will work technically" -- novel technology that hasn't been proven at this scale

The Cost of Skipping

The asymmetry is clear: the cost of testing is always small compared to the cost of building on a false assumption.

Case Studies: Continuous Discovery in Practice

Four realistic scenarios showing how product teams apply continuous discovery habits across different contexts. Each case study follows a team from establishing the practice through making evidence-based decisions.

Table of Contents

1. Case Study 1: B2B SaaS -- Project Management Tool 2. Case Study 2: Consumer Mobile -- Fitness App 3. Case Study 3: Platform Team -- Internal Developer Platform 4. Case Study 4: Growth Team -- E-Commerce Marketplace 5. Patterns Across Case Studies

---

Case Study 1: B2B SaaS -- Project Management Tool

Context

Company: Mid-stage B2B SaaS company (200 employees) building a project management tool for marketing teams. 15,000 paying customers, $20M ARR.

Team: Product trio -- Priya (PM), Jake (designer), and Lena (engineer). They've been a team for 4 months.

Assigned outcome: Increase 90-day retention for new accounts from 62% to 75%.

Establishing the Practice

Week 1-2: Setting up the cadence

Priya's first step was automating interview recruitment. The team added an in-app banner for users in their first 30 days: "Help us make [Product] better for your team. Chat for 25 minutes and get a $25 gift card." This fed into a Calendly link with two weekly slots -- Tuesday at 2pm and Thursday at 10am.

The team created a shared Miro board for their Opportunity Solution Tree, with the outcome ("Increase 90-day retention from 62% to 75%") at the top and empty space below for opportunities.

Week 3-4: First interviews and experience mapping

In the first two weeks, the trio conducted 4 interviews with users who were 2-3 weeks into their accounts. They asked each user: "Tell me about the last time you tried to set up a project in [Product]. Start from the very beginning."

The stories revealed a consistent pattern: users understood how to create projects, but they struggled to get their team members to adopt the tool. One user said: "I spent an hour setting it up perfectly, then sent the link to my team, and nobody logged in. I felt like an idiot."

The team built an experience map of "Getting your team onto a new project tool" and identified five distinct steps, with the biggest pain point at "getting team members to log in and start using it."

The Opportunity Solution Tree Takes Shape

After 6 interviews, the team's OST looked like this:

Outcome: Increase 90-day retention from 62% to 75%
│
├── "Account creator can't get team members to adopt the tool"
│   ├── "Team members don't understand why they should switch"
│   ├── "First login experience is confusing for invited members"
│   └── "No accountability -- nobody knows if team is using it"
│
├── "Users can't figure out which features are relevant to their workflow"
│   └── "Marketing teams have different workflows than the default templates"
│
└── "Users lose momentum after initial setup"
    ├── "No reason to come back daily"
    └── "Progress isn't visible to the person who advocated for the tool"

Assumption Testing

The team decided to focus on "Account creator can't get team members to adopt the tool" because 5 of 6 interviews mentioned this struggle. They brainstormed three solutions:

1. Onboarding buddy system: Pair the account creator with a CS rep for the first 2 weeks 2. Team adoption dashboard: Show the creator which team members have logged in, completed tasks, etc. 3. Magic invite link: Pre-populate the invited member's view with their first assigned task so they immediately see why they need to log in

For the "magic invite link" solution, the riskiest assumption was: "Team members will engage if they see an assigned task rather than an empty dashboard." They designed a painted-door test: existing invite emails were A/B tested. Version A was the current generic invite. Version B said "You have a task waiting for you in [Product]" (the task was the standard onboarding tutorial, reframed).

Result: Version B had 34% higher click-through and 22% higher day-1 activation. The assumption was validated.

Outcome

Over 8 weeks, the team shipped an improved invite flow based on validated assumptions. After one quarter of continuous discovery, 90-day retention moved from 62% to 71%. Not yet at the 75% target, but the team had clear evidence pointing to the next opportunities to pursue.

---

Case Study 2: Consumer Mobile -- Fitness App

Context

Company: Early-stage startup (20 employees) with a mobile fitness app targeting busy professionals who want to exercise but struggle to maintain a routine. 50,000 MAU, freemium model.

Team: Product trio -- Marcus (PM), Ava (designer), and Chen (engineer). This is their first time practicing continuous discovery.

Assigned outcome: Increase 7-day retention (users active on day 1 and day 7) from 25% to 40%.

Getting Started with Limited Resources

Marcus had no budget for a research platform, so they started scrappy. Ava added a single screen after the user's third workout: "We're building this app for people like you. Got 20 minutes for a quick call? We'll give you a free month of premium." This generated 3-4 willing participants per week.

The trio blocked Thursday at 3pm as their standing interview slot. They created a simple Google Doc template for their interview snapshots.

Key Discovery: The Motivation Gap

The first 5 interviews revealed something the team hadn't expected. Users weren't leaving because the workouts were bad -- they left because they couldn't figure out which workout to do on any given day.

One user described it: "I open the app on Monday feeling motivated. I see 200 workouts. I spend 5 minutes scrolling, can't decide, and close the app. By Wednesday my motivation is gone."

Another user: "The app has great content, but it feels like a library, not a coach. I don't need more options -- I need someone to tell me 'do this today.'"

The team mapped the experience of "deciding what workout to do today" and found that the decision point was where most users dropped off. The experience map showed:

1. Open app with intention to work out 2. Browse workout library (feeling: overwhelmed) 3. Try to filter or search (feeling: frustrated -- too many options) 4. Either pick something random or give up (feeling: defeated or unsatisfied) 5. If they picked something, do the workout (feeling: good during, but uncertain if it was the "right" choice)

Opportunity Solution Tree

Outcome: Increase 7-day retention from 25% to 40%
│
├── "I can't decide which workout to do today" ← FOCUS
│   ├── "I don't know what's appropriate for my fitness level"
│   ├── "I don't have a plan -- every day feels like starting over"
│   └── "There are too many options and I'm overwhelmed"
│
├── "I lose motivation when I don't see progress"
│   └── "I can't tell if I'm getting stronger or fitter"
│
└── "Life gets in the way and I fall off the routine"
    └── "Once I miss a day, I feel guilty and avoid the app"

Testing Assumptions

The team focused on "I don't have a plan -- every day feels like starting over" because it appeared in 4 of 5 interviews and was connected to the strongest emotional language.

Solution idea: A simple daily plan that tells users exactly which workout to do today based on their stated goals, available time, and equipment.

Riskiest assumption: "Users will follow a prescribed daily plan instead of browsing on their own."

Test: They created a Wizard of Oz test. For 20 users who opted in, Ava manually selected a daily workout based on their profile and sent a push notification each morning: "Today's workout: [name] (25 min, upper body). Tap to start." Marcus tracked how many tapped the notification and completed the workout.

Result: 14 of 20 users (70%) completed the recommended workout on day 1. By day 7, 11 of 20 (55%) were still following the daily plan. Compared to the 25% baseline retention, this was a dramatic improvement.

Outcome

The team built a lightweight recommendation engine based on what they learned from the Wizard of Oz test. Day-7 retention climbed to 38% within 6 weeks. The continuous interview cadence continued to reveal refinements -- users wanted to swap workouts without losing their plan, and they wanted a "rest day" option that didn't feel like failure.

---

Case Study 3: Platform Team -- Internal Developer Platform

Context

Company: Large enterprise (5,000 employees) with an internal platform team that builds tools for the company's 300 software engineers.

Team: Product trio -- Sam (PM), Robin (designer), and Alex (engineer). Their "customers" are internal developers.

Assigned outcome: Reduce average deployment time from 45 minutes to under 15 minutes.

Adapting Discovery for Internal Customers

Sam's advantage was direct access to customers -- they sat in the same Slack channels. The challenge was that internal developers had strong opinions about solutions ("just give us better CI/CD pipelines") but rarely articulated the underlying needs.

The team set up a weekly "Deploy Stories" interview. Every Thursday, they invited one developer to walk through their most recent deployment step by step. The framing was crucial: "We're not asking what tools you want -- we want to understand your actual experience of deploying code last week."

Surprising Findings

The team assumed the slow deployment was a CI/CD pipeline problem. The experience map told a different story:

1. Write code and get it reviewed (15 min, well-understood) 2. Merge to main (2 min, no pain) 3. Wait for CI to run (8 min -- the part the team expected to be the bottleneck) 4. Manually check 3 dashboards to verify the deploy is healthy (12 min -- unexpected) 5. Write a deploy summary in Slack for the on-call engineer (5 min -- unknown to the platform team) 6. Wait for the on-call engineer to acknowledge (variable: 3-20 min -- the actual bottleneck)

Steps 4, 5, and 6 accounted for more time than CI (step 3) and were entirely manual. The platform team had been investing in CI speed while the real time sinks were elsewhere.

The OST Reframed

Outcome: Reduce deployment time from 45 min to under 15 min
│
├── "I have to manually check multiple dashboards to verify deploy health"
│   ├── "I don't trust that the deploy is healthy without checking myself"
│   └── "Each dashboard shows different metrics and I'm not sure what to look for"
│
├── "I have to write a manual deploy summary and wait for acknowledgment"
│   ├── "The summary format isn't standardized so I spend time figuring out what to include"
│   └── "The on-call person doesn't always see my message quickly"
│
└── "CI takes 8 minutes and I context-switch during the wait"
    └── "By the time CI finishes, I've started something else and don't come back for 10+ min"

Evidence-Driven Solutions

Instead of optimizing CI (which would have saved 2-3 minutes at best), the team focused on the deploy verification and handoff steps. They tested a simple assumption: "Developers will trust an automated health check if it shows the same metrics they currently check manually."

They built a prototype that aggregated the three dashboards into a single deploy health summary posted automatically in Slack. Seven developers tested it for one week. Six of seven said they no longer needed to check the dashboards separately. The seventh wanted one additional metric included.

Outcome

By automating health verification and deploy summaries, the team reduced average deployment time from 45 minutes to 18 minutes -- without touching the CI pipeline at all. Continuous interviews continued to reveal further optimizations, and the team estimated they could reach the 15-minute target within another quarter.

---

Case Study 4: Growth Team -- E-Commerce Marketplace

Context

Company: Series B e-commerce marketplace connecting independent artisans with buyers. 200,000 registered buyers, 8,000 sellers.

Team: Product trio -- Dana (PM), Leo (designer), and Nia (engineer). They sit on the growth team focused on buyer-side metrics.

Assigned outcome: Increase first-purchase conversion from 12% to 20% (percentage of registered users who make a purchase within 30 days).

Two-Sided Discovery

The team's challenge was that their outcome depended on both sides of the marketplace. They needed to understand why buyers registered but didn't purchase. They split their interview cadence:

• Tuesdays: Interview a registered buyer who hadn't purchased yet (recruited via email: "We noticed you signed up but haven't found anything yet -- can we learn why?")
• Thursdays: Interview a buyer who did make their first purchase within 30 days (recruited via post-purchase email)

This contrast was powerful. By interviewing both converters and non-converters, the team could identify what was different about their experiences.

The Discovery

Non-converter interviews revealed three dominant patterns:

Pattern 1 (mentioned in 7 of 10 non-converter interviews): "I browsed for a while but couldn't tell if the products were actually good quality. The photos looked nice but I wasn't sure about sizing, materials, or durability."

Pattern 2 (mentioned in 5 of 10): "I found something I liked but the shipping cost surprised me at checkout. I thought 'I'll come back later' and never did."

Pattern 3 (mentioned in 4 of 10): "I signed up because someone shared a link to a specific product, but when I looked at the rest of the site, nothing else caught my eye."

Converter interviews showed a contrasting pattern: buyers who purchased often mentioned reading reviews, seeing detailed product descriptions, or having a friend recommend a specific seller.

Opportunity Solution Tree

Outcome: Increase first-purchase conversion from 12% to 20%
│
├── "I can't assess product quality from the listing" ← PRIMARY FOCUS
│   ├── "Photos don't show scale, materials, or details"
│   ├── "I don't trust reviews -- are they real?"
│   └── "I can't find information about the seller's craftsmanship"
│
├── "Shipping costs surprise me and kill my motivation to buy"
│   ├── "I don't see shipping costs until checkout"
│   └── "Shipping feels too expensive relative to the product"
│
└── "After seeing the product I came for, I don't discover anything else"
    └── "The 'recommended for you' section isn't relevant to my interests"

Assumption Testing

For the primary focus opportunity, the team generated three solutions:

1. Enhanced listing requirements: Require sellers to include size reference photos and material close-ups 2. Verified review badges: Show which reviews come from verified purchases 3. Seller story cards: Short profiles showing the artisan's workshop and process

The riskiest assumption for seller story cards was: "Seeing the artisan's story will increase buyer confidence in product quality." They tested this with a simple experiment: for 500 product views, they added a one-line artisan bio with a workshop photo at the top of the listing. For another 500 views (control), the listing was unchanged.

Result: Listings with artisan context had 18% higher add-to-cart rates and 11% higher checkout completion. Buyers spent an average of 8 seconds longer on the listing -- suggesting they were reading the context and it influenced their decision.

For the shipping cost opportunity, they tested upfront shipping display. The assumption: "Showing shipping costs on the product listing page (instead of at checkout) will reduce cart abandonment without significantly reducing add-to-cart rates." They ran an A/B test on 2,000 product views.

Result: Showing shipping costs upfront reduced add-to-cart by 5% but increased checkout completion by 23%. Net effect: more completed purchases. The transparency removed the unpleasant surprise.

Outcome

Over 10 weeks, the team shipped artisan context cards, verified review badges, and upfront shipping display. First-purchase conversion moved from 12% to 17.5%. The continuous interview cadence revealed that the next biggest opportunity was in the post-first-purchase experience -- buyers who had a good first experience but didn't come back for a second purchase.

---

Patterns Across Case Studies

1. The Real Problem Is Rarely Where You Expect It

• The B2B team thought retention was a feature problem; it was a team adoption problem
• The fitness team thought content quality was the issue; it was decision fatigue
• The platform team thought CI speed was the bottleneck; it was manual verification
• The growth team thought conversion was about product appeal; it was about trust signals

Lesson: Continuous discovery's greatest value is correcting the team's initial assumptions about where the problem lies.

2. Interviews Reveal What Data Cannot

Analytics showed the platform team that deployments took 45 minutes. Only interviews revealed that 25 of those minutes were spent on manual steps invisible to the deployment pipeline.

Lesson: Quantitative data tells you what is happening. Qualitative interviews tell you why.

3. Small Tests Prevent Big Mistakes

Every team ran cheap tests before committing to building. The fitness team's Wizard of Oz test cost zero engineering effort. The marketplace team's artisan story card test was a simple content addition.

Lesson: The cheapest test that generates evidence is always the right first step.

4. The Cadence Compounds

In each case study, the team's understanding deepened over weeks. Early interviews revealed surface-level problems. Later interviews, informed by earlier learning, probed deeper and uncovered root causes.

Lesson: Individual interviews are informative. A sustained cadence of interviews is transformative.

5. The Trio Makes Better Decisions Together

When PM, designer, and engineer all hear the same customer stories, alignment happens naturally. There's no need for lengthy requirements documents or persuasion -- everyone saw the user struggle with the same pain point.

Lesson: Shared evidence creates shared conviction. The product trio interviewing together is not a luxury; it's a prerequisite for good decisions.

Experience Mapping

A guide to creating current-state experience maps that reveal customer pain points, emotions, and unmet needs -- turning interview data into actionable opportunities for the Opportunity Solution Tree.

What Is an Experience Map?

An experience map is a visual representation of how a customer accomplishes a specific goal today, capturing each step they take, what they think and feel at each step, and where they struggle. Unlike a journey map (which tracks interactions with your product), an experience map captures the customer's full experience regardless of which tools, products, or workarounds they use.

Experience Map vs. Journey Map

Rule of thumb: In continuous discovery, start with experience maps. They reveal the full landscape of opportunities. Use journey maps later to optimize specific product flows.

Anatomy of an Experience Map

The Five Rows

A well-structured experience map has five horizontal rows that run across each step of the experience:

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│  Step 1  │  Step 2  │  Step 3  │  Step 4  │  Step 5  │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│  DOING   │  DOING   │  DOING   │  DOING   │  DOING   │
│ (actions)│ (actions)│ (actions)│ (actions)│ (actions)│
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ THINKING │ THINKING │ THINKING │ THINKING │ THINKING │
│(questions│(questions│(questions│(questions│(questions│
│ & goals) │ & goals) │ & goals) │ & goals) │ & goals) │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ FEELING  │ FEELING  │ FEELING  │ FEELING  │ FEELING  │
│(emotions)│(emotions)│(emotions)│(emotions)│(emotions)│
├──────────┼──────────┼──────────┼──────────┼──────────┤
│  PAIN    │  PAIN    │  PAIN    │  PAIN    │  PAIN    │
│ POINTS   │ POINTS   │ POINTS   │ POINTS   │ POINTS   │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│  OPPS    │  OPPS    │  OPPS    │  OPPS    │  OPPS    │
│(needs)   │(needs)   │(needs)   │(needs)   │(needs)   │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Row 1 -- Doing (Actions): What the customer physically does at this step. Be specific: "Opens three browser tabs to compare prices" not "Researches options."

Row 2 -- Thinking (Questions & Goals): What the customer is trying to figure out or decide. "Am I getting a good deal?" "Is this the right size?" "What do other people recommend?"

Row 3 -- Feeling (Emotions): The emotional state at this step. Use specific emotion words: frustrated, anxious, confident, overwhelmed, relieved, excited, bored.

Row 4 -- Pain Points: Where the experience breaks down. Long waits, confusing interfaces, missing information, forced workarounds, dead ends.

Row 5 -- Opportunities: Customer needs that emerge from the pain points and emotions. These feed directly into the OST.

How to Build an Experience Map

Step 1: Choose the Experience to Map

Select a specific goal that your target customers are trying to accomplish. The scope should be:

• Broad enough to capture the full experience (not just the part involving your product)
• Narrow enough to be mappable in a single session (not "manage their entire business")

Step 2: Gather the Data

Experience maps must be built from real customer data, not team assumptions. Sources include:

Minimum data: At least 5 interview snapshots describing the same general experience before attempting to map it. Fewer than 5 and the map will reflect individual stories, not patterns.

Step 3: Map the Steps

Lay out the major steps of the experience from beginning to end. Start rough and refine.

Process: 1. Review interview snapshots and list every distinct step mentioned 2. Arrange steps in chronological order 3. Merge similar steps described by different participants 4. Add steps that participants implied but didn't explicitly state 5. Validate the sequence: does this flow make sense?

Example -- "Hiring a contractor for home renovation": 1. Realize renovation is needed 2. Research what's involved and set a budget 3. Ask friends and search online for contractors 4. Contact 3-5 contractors for estimates 5. Compare estimates and check references 6. Select a contractor and negotiate terms 7. Manage the project during renovation 8. Inspect and approve the finished work 9. Handle issues or follow-up repairs

Step 4: Fill In the Rows

For each step, use interview data to populate the Doing, Thinking, Feeling, and Pain Point rows.

Example -- Step 4: "Contact 3-5 contractors for estimates":

• Doing: Calling phone numbers, leaving voicemails, sending emails, filling out contact forms on websites
• Thinking: "How many should I contact?" "What should I ask?" "How do I compare their responses?"
• Feeling: Anxious about making the right choice, frustrated when calls go to voicemail, overwhelmed by different formats of estimates
• Pain Points: Many contractors don't call back; estimates come in different formats making comparison difficult; no standard way to evaluate quality

Step 5: Identify Opportunities

Review each pain point and emotion peak on the map and translate them into opportunity statements for the OST.

Translation examples:

Collaborative Mapping Exercises

The Workshop Format (2-3 Hours)

Experience maps are most valuable when built collaboratively by the product trio. The exercise creates shared understanding that no document can replicate.

Participants: Product manager, designer, engineer(s), and optionally: data analyst, customer success representative

Materials: Large wall or digital whiteboard, sticky notes (physical or virtual), markers, printed interview snapshots

Agenda:

Facilitation Tips

• Start with divergence: Let each person work independently before coming together, to avoid groupthink
• Use quotes: Place verbatim customer quotes on the map to keep it grounded
• Mark confidence levels: Use dots or colors to indicate which steps are well-supported by evidence (green) vs. assumed (red)
• Capture disagreements: When team members see the experience differently, that's valuable -- it reveals where you need more data
• Time-box ruthlessly: It's better to have a rough complete map than a detailed partial one

Remote Collaboration

For distributed teams, use digital whiteboarding tools (Miro, FigJam, Mural) with these adaptations:

• Pre-populate the template before the session
• Use breakout rooms for the individual review phase
• Assign a facilitator to manage the digital board and prevent chaos
• Record the session for team members who can't attend

Using Maps to Generate Opportunities

The Opportunity Extraction Process

After the map is built, systematically scan it for opportunities:

1. Emotion peaks: Where do feelings become strongly negative (frustrated, anxious, overwhelmed) or surprisingly positive (relieved, delighted)? Negative peaks are unmet needs; positive peaks are moments to protect or amplify.

2. Workarounds: Where are customers cobbling together multiple tools, doing manual work, or inventing their own solutions? Workarounds signal high-value unmet needs -- the customer is already motivated enough to create their own solution.

3. Drop-off points: Where do customers abandon the experience or give up? These are the highest-friction moments and represent either simplification opportunities or entirely new approaches.

4. Handoff points: Where does the customer move from one tool, person, or context to another? Handoffs create information loss, confusion, and frustration.

5. Wait times: Where does the customer have to wait -- for information, for another person, for a process to complete? Waiting creates anxiety and abandonment.

Opportunity Quality Check

For each opportunity extracted from the map, verify:

Maintaining Maps Over Time

Experience maps are living documents that should evolve as the team conducts more interviews and the product changes.

Update Triggers

When to Create a New Map vs. Update an Existing One

• Update when the goal is the same but details have changed
• Create new when you're exploring a different goal or a significantly different customer segment
• Archive old maps rather than deleting them -- they provide historical context

Example: Complete Experience Map

Experience: "Small business owner creating and sending an invoice"

Step 1 -- Complete the work

• Doing: Finishing the project, tracking hours, gathering receipts
• Thinking: "Did I track everything? Am I forgetting any billable items?"
• Feeling: Relieved work is done, anxious about accuracy
• Pain: No single place where all billable items live; have to check email, time tracker, and notes

Step 2 -- Create the invoice

• Doing: Opening invoicing tool, entering line items, adding client details
• Thinking: "What's the right format? Do I need a PO number? What's the tax rate?"
• Feeling: Tedious, worried about looking professional
• Pain: Re-entering information that exists elsewhere; unsure about tax rules

Step 3 -- Review and send

• Doing: Proofreading, saving as PDF, attaching to email, writing a message
• Thinking: "Does this look professional? Will they pay on time?"
• Feeling: Anxious about the payment timeline, insecure about professionalism
• Pain: Manual process of export-attach-email; no tracking of whether client received it

Step 4 -- Wait for payment

• Doing: Checking bank account, checking email for confirmation
• Thinking: "Did they get it? Should I follow up? When is it rude to ask?"
• Feeling: Anxious, uncertain, sometimes resentful
• Pain: No visibility into whether invoice was viewed; unclear payment timeline

Step 5 -- Follow up on late payment

• Doing: Writing a follow-up email, calling the client, feeling awkward
• Thinking: "How do I ask without damaging the relationship?"
• Feeling: Frustrated, uncomfortable, dreading the conversation
• Pain: No standard follow-up process; feels personal rather than professional

Opportunities extracted: 1. "Business owners need all billable items in one place so nothing falls through the cracks" 2. "Business owners need to create professional invoices without re-entering data they've already recorded" 3. "Business owners need visibility into whether a client has seen an invoice" 4. "Business owners need a way to follow up on late payments that feels professional, not personal" 5. "Business owners need clarity on tax rules relevant to their specific invoices"

Interview Snapshots

A practical guide to conducting story-based customer interviews, capturing insights in a standardized snapshot format, and building a sustainable weekly interview cadence.

Story-Based Interviewing

Why Stories, Not Opinions

Traditional customer interviews ask people what they want, how they'd rate features, or whether they'd use a hypothetical product. These approaches fail because:

Story-based interviewing asks customers to describe specific past experiences in rich detail. Real stories reveal what people actually did, felt, and struggled with -- not what they think they might do.

The Core Technique

The anchor question: "Tell me about the last time you [did the relevant activity]."

This single prompt unlocks a narrative. From there, follow up with:

• Sequence questions: "What happened next?" "And then what did you do?"
• Clarification questions: "What do you mean by 'frustrating'?" "Can you walk me through that step by step?"
• Emotion questions: "How did that make you feel?" "What were you thinking at that point?"
• Context questions: "Where were you when this happened?" "Who else was involved?"
• Contrast questions: "Was that different from the time before?" "Have you ever done it differently?"

Interview Structure (30 Minutes)

Minutes 1-3: Warm-up

• Thank the participant
• Explain the purpose: "We're trying to understand how you [activity] so we can make the experience better"
• Reassure: "There are no right or wrong answers -- we just want to learn from your real experience"
• Ask permission to record

Minutes 3-8: Context setting

• "How often do you [activity]?"
• "How long have you been doing it this way?"
• "Who else is involved when you [activity]?"

Minutes 8-25: Story elicitation

• "Tell me about the last time you [activity]. Start from the very beginning."
• Follow the story wherever it goes, using follow-up questions
• Probe pain points: "You mentioned that was annoying -- can you tell me more about that?"
• Probe workarounds: "You said you used a spreadsheet for that part -- walk me through why"
• Get specifics: "You said 'a while' -- was that minutes? Hours? Days?"

Minutes 25-30: Wrap-up

• "Is there anything else about this experience that we haven't covered?"
• "What's the single most frustrating part of [activity]?"
• Thank the participant and explain next steps

Common Interview Mistakes

The Interview Snapshot Format

After each interview, the product trio fills out a one-page snapshot. The goal is a concise, scannable artifact that anyone on the team can read in two minutes.

Snapshot Template

┌─────────────────────────────────────────────────────┐
│ INTERVIEW SNAPSHOT                                  │
│                                                     │
│ Date: [date]          Participant: [name/alias]     │
│ Interviewer(s): [names]                             │
│ Role/Segment: [description]                         │
│                                                     │
│ ── THE STORY ──────────────────────────────────────│
│ [2-3 sentence summary of the specific experience    │
│  the participant described]                         │
│                                                     │
│ ── KEY QUOTES ─────────────────────────────────────│
│ • "[verbatim quote 1]"                              │
│ • "[verbatim quote 2]"                              │
│ • "[verbatim quote 3]"                              │
│                                                     │
│ ── OPPORTUNITIES IDENTIFIED ───────────────────────│
│ • [Opportunity 1 -- framed as customer need]        │
│ • [Opportunity 2 -- framed as customer need]        │
│                                                     │
│ ── SURPRISES / NEW INSIGHTS ───────────────────────│
│ • [Something unexpected that challenges our         │
│   assumptions]                                      │
│                                                     │
│ ── FOLLOW-UP ──────────────────────────────────────│
│ • [Questions to explore in future interviews]       │
│ • [Data to look up]                                 │
│                                                     │
└─────────────────────────────────────────────────────┘

Filling Out the Snapshot

Timing: Complete the snapshot immediately after the interview, while the conversation is fresh. This should take 10-15 minutes for the trio together.

The Story section: Write 2-3 sentences that capture the specific experience the participant described. Not a summary of everything they said -- the core narrative arc. Example: "Maria described her weekly process of preparing client reports. She spends 2 hours every Monday manually pulling data from three different tools into a spreadsheet, then another hour formatting it. She sends the report by email and rarely hears back, so she doesn't know if clients actually read it."

Key Quotes: Write down 2-4 verbatim quotes that were particularly revealing. These are gold for communicating customer voice to stakeholders. Example: "I just copy and paste from three different dashboards. It's ridiculous, but I don't know a better way."

Opportunities Identified: Translate pain points and unmet needs into opportunity statements. These should be framed from the customer's perspective and be solution-agnostic. Example: "Users need a way to aggregate data from multiple sources without manual copy-paste."

Surprises: Capture anything that challenged the team's assumptions or was genuinely new. This section forces the team to acknowledge what they didn't know.

Synthesizing Across Interviews

Individual interviews tell stories. Patterns across interviews reveal opportunities. Synthesis is how you move from anecdotes to evidence.

The Synthesis Process

Weekly (after each interview): 1. Complete the interview snapshot 2. Add new opportunities to the Opportunity Solution Tree 3. Note if the opportunity reinforces a pattern seen in prior interviews

Bi-weekly (every 2 weeks): 1. Lay out all recent snapshots side by side 2. Look for recurring themes across participants 3. Cluster similar opportunities together 4. Identify which opportunities have the most supporting evidence 5. Update the OST with refined opportunity framing

Monthly: 1. Review the full snapshot library 2. Assess coverage: are we hearing from diverse segments? 3. Identify gaps: what questions remain unanswered? 4. Adjust recruitment strategy based on gaps

Identifying Patterns

Avoiding Synthesis Pitfalls

• Recency bias: The most recent interview feels most important. Counter by reviewing all recent snapshots together.
• Confirmation bias: You notice patterns that confirm what you already believe. Counter by specifically looking for disconfirming evidence.
• Loudest voice: One particularly articulate participant's story dominates thinking. Counter by counting -- how many participants mentioned this?
• Premature closure: You stop interviewing once you hear a pattern. Counter by continuing interviews even when you think you've found the answer.

Extracting Opportunities from Stories

The Translation Process

Stories contain raw data. Opportunities are insights extracted from that data. The translation requires separating what customers did and felt from what the team might do about it.

Step 1: Identify the pain point or unmet need in the story

• Customer action: "I export data to a spreadsheet, then reformat it manually"
• Pain point: Manual data transformation is time-consuming and error-prone

Step 2: Frame it from the customer's perspective

• Bad: "We need to add a data export feature" (solution-framed)
• Good: "Users need their data in a usable format without manual transformation" (need-framed)

Step 3: Validate the scope

• Is this too broad? ("Users need data") -- break it down
• Is this too narrow? ("Users need CSV export with custom columns") -- zoom out
• Just right: specific enough to be actionable, broad enough to allow multiple solutions

Automating Recruitment

The biggest reason teams stop doing weekly interviews is that recruitment is painful. Automation makes the habit sustainable.

Recruitment Channels

The Ideal Recruitment System

1. Trigger: An in-app message appears to users who match your target criteria (e.g., users in their first week, users who haven't used feature X, users who recently churned) 2. Opt-in: The message says: "Help us make [product] better for you. Chat for 20-30 minutes and receive [incentive]." 3. Scheduling: Clicking the message opens a scheduling tool with the team's available slots 4. Reminder: Automatic email reminder 24 hours and 1 hour before the session 5. Follow-up: Automatic thank-you email with incentive delivery after the session

Incentive Guidelines

The Weekly Interview Cadence

Minimum Viable Cadence

• One interview per week with the full product trio present
• 10-15 minutes of snapshot synthesis immediately after the interview
• 30 minutes of bi-weekly synthesis reviewing patterns across recent snapshots

Scaling the Cadence

As the team builds the habit, scale to 2-3 interviews per week:

What If You Can't Get Interviews?

Snapshot Library Management

Organization

Organize snapshots so the team can reference them easily:

• Chronological: Newest on top for scanning recent learning
• Tagged by opportunity: Each snapshot tagged with the opportunities it supports
• Tagged by segment: Each snapshot tagged with participant characteristics
• Searchable: Use a tool that allows keyword search across all snapshots

Using the Library

• Before designing a solution: Pull up all snapshots related to the target opportunity
• During stakeholder discussions: Reference specific snapshots and quotes to ground conversations in evidence
• When onboarding new team members: Have them read the last 10-15 snapshots to build customer empathy quickly
• During prioritization: Count how many snapshots support each opportunity to assess evidence strength

Opportunity Solution Trees

A comprehensive guide to building, maintaining, and using Opportunity Solution Trees (OSTs) as the central artifact of continuous product discovery.

What Is an Opportunity Solution Tree?

An Opportunity Solution Tree is a visual diagram that maps the path from a desired business outcome to the customer opportunities that could drive that outcome, the solutions that could address those opportunities, and the experiments that could test those solutions.

The Four Layers

           [Desired Outcome]
                 |
    ┌────────────┼────────────┐
    |            |            |
[Opportunity] [Opportunity] [Opportunity]
    |            |        |         |
  [Sub-opp]  [Solution] [Solution] [Sub-opp]
    |            |        |         |
[Solution]   [Experiment] [Experiment] [Solution]
    |                                    |
[Experiment]                         [Experiment]

Layer 1 -- Desired Outcome: A measurable business or product metric the team is responsible for. Examples: increase trial-to-paid conversion from 8% to 15%, reduce time-to-value below 3 minutes, increase weekly active usage by 20%.

Layer 2 -- Opportunities: Customer needs, pain points, and desires discovered through interviews and research. These are always framed from the customer's perspective. Example: "I can't tell if the product is worth paying for during the trial."

Layer 3 -- Solutions: Specific product changes, features, or interventions that could address an opportunity. Multiple solutions can map to one opportunity. Example: "Add a guided tour that highlights premium features during trial."

Layer 4 -- Experiments: Small, fast tests that validate whether a solution will work before the team commits to building it fully. Example: "Show a 30-second video walkthrough to 50% of trial users and measure upgrade rate."

How to Build an Opportunity Solution Tree

Step 1: Define the Outcome

Work with leadership to identify a clear, measurable outcome for the team. Good outcomes are:

• Measurable: Has a number attached (conversion rate, retention, revenue)
• Controllable: The team can influence it through product changes
• Time-bound: Has a target date or review cadence
• Customer-connected: Improving this metric also improves the customer's life

Step 2: Populate the Opportunity Space

Use interview data, support tickets, analytics, and experience maps to identify customer opportunities. For each opportunity, ask:

• Is this framed from the customer's perspective?
• Is this a need, pain point, or desire -- not a solution?
• Did this come from research, not just team brainstorming?

Common mistakes when writing opportunities:

Step 3: Break Down Large Opportunities

Large, abstract opportunities should be broken into smaller, more specific sub-opportunities. This makes them actionable and testable.

Example decomposition:

"Users struggle with onboarding"
    ├── "Users don't understand what the product does before signing up"
    ├── "Users can't figure out how to complete their first task"
    ├── "Users don't know which features are relevant to their role"
    └── "Users lose motivation before experiencing the core value"

Each sub-opportunity can have its own solutions and experiments. The team can choose to focus on one sub-opportunity at a time.

Step 4: Generate Solutions

For each prioritized opportunity, brainstorm multiple solutions. The goal is to have at least three distinct approaches so the team can compare rather than falling in love with the first idea.

Solution generation techniques:

• How Might We: Reframe the opportunity as "How might we help users [opportunity]?" and brainstorm freely
• Analogy mapping: How do other industries or products solve a similar need?
• Extreme constraints: What would we do if we had only one day? One hour? No code changes?
• Customer co-creation: Show the opportunity to customers and ask how they'd solve it

Step 5: Design Experiments

For each promising solution, identify the riskiest assumption and design a small test. See assumption-mapping.md for detailed assumption testing methodology.

Comparing Solutions on the Tree

When multiple solutions map to the same opportunity, use these criteria to compare:

Important: Don't reduce this to a formula. Use the criteria to have an explicit conversation about tradeoffs. The goal is shared understanding, not a magic score.

Keeping the Tree Alive

The OST is not a document you create once and file away. It is a living artifact that evolves weekly.

Weekly Update Rhythm

Signs Your Tree Is Healthy

• New opportunities are being added every week from fresh interviews
• The team can explain why they chose their current focus opportunity
• Solutions have been tested with assumption tests before being built
• Stakeholders can look at the tree and understand the team's strategy
• The tree has changed meaningfully in the last month

Signs Your Tree Is Dying

• No new opportunities have been added in two or more weeks
• The tree was created once and lives in a forgotten document
• Solutions were added without connecting to a customer opportunity
• The team can't explain the relationship between their current work and the tree
• Opportunities are all written from the business perspective, not the customer's

Visual Tree Examples

Example 1: SaaS Trial Conversion

Outcome: Increase trial-to-paid conversion from 8% to 15%
│
├── Opportunity: "I don't understand the value before trial ends"
│   ├── Sub: "I don't know which features to try first"
│   │   ├── Solution: Personalized onboarding checklist
│   │   └── Solution: Role-based guided tour
│   └── Sub: "I can't tell how this is better than my spreadsheet"
│       ├── Solution: Side-by-side comparison calculator
│       └── Solution: Import existing spreadsheet data
│
├── Opportunity: "The pricing feels too high for what I've seen"
│   ├── Solution: Usage-based tier that starts cheaper
│   └── Solution: Highlight features user hasn't discovered
│
└── Opportunity: "I forget about the trial and it expires"
    ├── Solution: Smart reminder emails based on usage
    └── Solution: Extend trial for active users automatically

Example 2: Consumer App Retention

Outcome: Increase Day-30 retention from 20% to 35%
│
├── Opportunity: "I run out of content that matches my interests"
│   ├── Solution: Improved recommendation algorithm
│   └── Solution: User-curated collections
│
├── Opportunity: "I don't have a reason to come back daily"
│   ├── Sub: "There's nothing new since yesterday"
│   │   └── Solution: Daily digest of new relevant content
│   └── Sub: "I don't have a routine around using the app"
│       └── Solution: Morning briefing notification
│
└── Opportunity: "I feel overwhelmed by too many choices"
    ├── Solution: Simplified home screen with 3 picks
    └── Solution: "Start here" single recommendation

Common Anti-Patterns

The Solution Tree

The tree has outcomes at the top and solutions at the bottom -- but no opportunity layer. This means the team is guessing at what customers need.

Fix: Go back to interviews. Every solution on the tree must trace to a customer opportunity discovered through research.

The Wish List Tree

The opportunity layer is populated with feature requests from customers or stakeholders: "users want dark mode," "users want an API." These are solutions masquerading as opportunities.

Fix: Ask "why?" for each item. "Users want an API" becomes "Users need to connect our product to their existing workflow tools."

The Stale Tree

The tree was created at the start of the quarter and hasn't been updated since. It no longer reflects what the team has learned.

Fix: Schedule a 30-minute weekly session to update the tree with insights from that week's interviews.

The Disconnected Tree

The tree exists but the team's actual sprint work doesn't connect to it. Features are being built that don't appear anywhere on the tree.

Fix: Every sprint item should trace back to a solution on the tree. If it can't, either the tree is incomplete or the work isn't strategically aligned.

Tools and Formats

The OST can be maintained in:

• Physical whiteboard: Best for co-located teams; highly visible and easy to modify
• Digital whiteboarding tools: Miro, FigJam, or Mural for remote teams
• Dedicated tools: ProductBoard, Vistaly, or Notion databases with relational views
• Simple documents: Even a nested bullet list in a shared doc works for small teams

The format matters less than the discipline of updating it weekly.

Prioritization Methods

A guide to structured methods for comparing and ranking opportunities on the Opportunity Solution Tree, so product teams focus on the highest-leverage bets backed by evidence.

Why Structured Prioritization Matters

Without a structured approach, teams default to prioritizing by:

• HiPPO (Highest Paid Person's Opinion) -- the loudest voice wins
• Recency bias -- whatever the last customer said becomes the top priority
• Squeaky wheel -- the most vocal internal stakeholder gets their feature built
• Gut feeling -- the PM "just knows" what's important

Each of these leads to suboptimal outcomes because they skip the explicit tradeoff discussion that good prioritization requires. Structured methods don't eliminate judgment -- they channel it through a framework that surfaces disagreements early and ensures the team is aligned on why they're pursuing one opportunity over another.

Compare and Contrast Prioritization

Teresa Torres recommends comparing opportunities head-to-head rather than scoring them independently. Independent scoring creates the illusion of objectivity while masking the real tradeoffs. Comparison forces the team to make explicit choices.

How It Works

1. Take your top opportunities from the OST (ideally 5-7, no more than 10) 2. Compare each pair of opportunities across several dimensions 3. Through successive comparisons, a ranking emerges 4. The top-ranked opportunities become the team's focus

Comparison Dimensions

Running a Comparison Session

Time: 60-90 minutes Participants: Product trio (PM, designer, engineer) Preparation: Each participant reviews the top opportunities and supporting evidence beforehand

Process:

1. Round 1 -- Pair comparison (20 min):

• Compare opportunity A vs. opportunity B on each dimension
• For each dimension, which opportunity is stronger?
• Record the "winner" of each pair

2. Round 2 -- Discussion (30 min):

• Where did the trio disagree? Discuss those dimensions
• Surface the underlying assumptions behind disagreements
• Look for dimensions where the answer is genuinely unknown -- these signal a need for more evidence

3. Round 3 -- Stack rank (20 min):

• Based on the pair comparisons and discussion, create a rough rank order
• The team doesn't need a perfect ranking -- they need to identify the top 2-3 opportunities to focus on

4. Decide (10 min):

• Commit to a primary opportunity and a secondary opportunity
• Identify any "must-know" questions before committing further (these become interview questions for the next week)

Example Comparison

Opportunity A: "Users can't find relevant content in search results"

• Size: Affects 70% of active users (based on analytics showing search usage)
• Frequency: Daily for most users
• Severity: Moderate -- users work around it but it takes extra time
• Evidence: 8 interview snapshots mention search frustration

Opportunity B: "New users can't figure out how to complete their first project"

• Size: Affects 100% of new users (by definition)
• Frequency: Once per user, during onboarding
• Severity: High -- many users abandon before completing first project
• Evidence: 5 interview snapshots, plus analytics showing 60% drop-off at project creation

Discussion: A affects more total interactions (daily * 70% of users), but B affects a critical moment (first-use experience). If users never complete their first project, they never become the daily users who'd benefit from search improvements. The team decides B is higher priority because it gates everything else.

Opportunity Scoring

For teams that need a lightweight quantitative approach, opportunity scoring provides a structured framework. This works well when you need to communicate priorities to stakeholders who expect numeric justification.

Scoring Criteria

Score = (Reach + Impact + Confidence + Effort) / 4

Confidence Scoring Guide

Confidence deserves special attention because it reflects the strength of your evidence:

When Scoring Falls Short

Scoring methods have real limitations:

• False precision: A score of 3.7 vs. 3.5 is meaningless noise, not a real difference
• Dimension conflation: Averaging across dimensions hides tradeoffs (a high-reach, low-impact opportunity looks the same as a low-reach, high-impact one)
• Gaming: Teams unconsciously inflate scores for opportunities they already prefer
• Missing context: Numbers don't capture the strategic narrative

Recommendation: Use scoring as a starting point for discussion, not as a final decision. If the scores are close, switch to compare-and-contrast to resolve the tie.

Impact vs. Effort

The classic 2x2 prioritization framework. Simple and intuitive, but should be used carefully.

The Matrix

              HIGH IMPACT
                  │
     ┌────────────┼────────────┐
     │            │            │
     │  DO FIRST  │  BIG BETS  │
     │ (quick     │ (worth the │
     │  wins)     │  investment)│
     │            │            │
LOW ─┼────────────┼────────────┼── HIGH
EFFORT│            │            │  EFFORT
     │  FILL-INS  │  AVOID     │
     │ (do if     │ (high cost,│
     │  capacity  │  low return│
     │  allows)   │            │
     └────────────┼────────────┘
                  │
              LOW IMPACT

Using It Well

Impact estimation: Base impact on customer evidence, not team opinion. An opportunity mentioned in 10 interviews with strong emotional language has higher estimated impact than one mentioned once.

Effort estimation: Get a rough engineering estimate -- not a detailed plan, but a t-shirt size (days, weeks, months). Include design, engineering, and validation effort.

Common mistake: Teams consistently underestimate effort and overestimate impact. Build in a skepticism factor: if you think it's "medium effort," it's probably "high effort."

When to Use Impact vs. Effort

Using Data to Prioritize

Quantitative data strengthens prioritization by grounding estimates in reality rather than intuition.

Data Sources for Prioritization

Combining Qualitative and Quantitative

Neither data type alone is sufficient. Use them together:

Rule: Let qualitative data tell you what the opportunity is. Let quantitative data tell you how big it is.

Avoiding Analysis Paralysis

The most common failure mode in prioritization is not choosing poorly -- it's not choosing at all. Teams get stuck in endless analysis, waiting for more data, debating criteria, and deferring decisions.

Signs of Analysis Paralysis

• The team has been "prioritizing" for more than two sessions without a decision
• Every opportunity has roughly equal scores and the team can't break the tie
• The team keeps asking for "one more interview" or "one more data point" before deciding
• No opportunities have been committed to for more than two weeks

How to Break Free

1. Time-box the decision: "We will commit to our top opportunity by end of day Friday. Period."

2. Lower the stakes: Remind the team that this is not an irreversible decision. You can switch opportunities as new evidence emerges. The cost of delay is higher than the cost of a suboptimal choice.

3. Use the "regret minimization" test: "If we spend the next 6 weeks on this opportunity and it doesn't pan out, would we regret it? Or would we say 'we learned something valuable'?"

4. Default to evidence: When opinions are split, ask: "Which opportunity has the most supporting evidence from interviews?" Default to the better-evidenced choice.

5. Start with assumption testing: If you truly can't decide between two opportunities, don't build either one yet. Instead, test the riskiest assumption for each and let the test results break the tie.

When to Pivot Between Opportunities

Committing to an opportunity doesn't mean ignoring new evidence. Here's when to revisit:

Pivot vs. Persevere Framework

Before pivoting, ask: 1. Have we actually tested assumptions, or did we jump to building? If you didn't test, go back and test. 2. Did we give the solution enough time to show results? Some solutions need weeks of adoption before impact appears. 3. Is the evidence pointing consistently in one direction? One failed test isn't enough; a pattern of failures is. 4. What would we learn by spending one more week here? If the answer is "nothing new," it's time to pivot.

Prioritization Cadence

Weekly

• Review test results and how they affect current opportunity ranking
• Quick check: is the team still working on the highest-priority opportunity?

Monthly

• Full prioritization review with updated evidence
• Add new opportunities discovered through recent interviews
• Remove or de-prioritize opportunities that have been addressed or invalidated

Quarterly

• Strategic review of the outcome itself -- is this still the right outcome?
• Major re-prioritization aligned with company goals
• Stakeholder alignment on opportunity ranking

Communicating Priorities to Stakeholders

What Stakeholders Need to See

Handling Stakeholder Requests

When a stakeholder requests a feature that doesn't align with current priorities:

1. Acknowledge the request: "Thank you -- this is worth considering" 2. Map it to the OST: "Let me see which opportunity this serves" 3. Show the tradeoff: "Pursuing this would mean deprioritizing [current focus], which is supported by [evidence]. Here's what we'd give up." 4. Offer alternatives: "If the underlying need is [X], here's how we're addressing it through [current opportunity]"

This approach respects the stakeholder's input while keeping the team focused on evidence-based priorities.