Continuous Discovery Habits by Teresa Torres — Cliff Notes Summary

👁 0 views📖 2,589 words⏱ 12 min read5/31/2026

Direct Answer

Continuous Discovery Habits by Teresa Torres (Product Talk, 2021) is the modern operating manual for how product teams should learn from customers — not as a quarterly research project, but as a weekly cadence. Torres, founder of Product Talk and a 15-year discovery coach to product orgs at Spotify, Atlassian, and across the Silicon Valley Product Group (SVPG) orbit, argues that the best product teams interview 3-5 customers every week, maintain a living Opportunity-Solution Tree, and test assumptions BEFORE building — not after.

Her signature artifact, the Opportunity-Solution Tree, hangs a clear Desired Outcome at the top, branches down into Opportunities (customer needs), then Solutions (experiments), then Assumptions that must be tested first. The book has become the canonical bridge between Rob Fitzpatrick's The Mom Test (2013, [[bs0126]]) and Marty Cagan's Inspired (2008, [[bs0190]]) — and it now sits in the modern PM canon alongside MEDDPICC, JTBD, and the SVPG product-trio model that every PLG company uses.

1. Part One — Why Continuous Discovery (Chapters 1-2)

1.1 Chapter 1 — The Case for Continuous Discovery

Torres opens with the central indictment: most product teams treat discovery as a rare, expensive event — a six-week generative research sprint, an annual customer-satisfaction survey, an offsite workshop with five strategic accounts. The teams that ship the best products treat discovery as a weekly habit.

Torres defines continuous discovery formally: at a minimum, weekly touchpoints with customers, by the team building the product, where they conduct small research activities in pursuit of a desired outcome.

The verbatim Torres-ism that bookends the chapter: "Continuous discovery is a HABIT, not a project." Habits compound; projects decay. A team that does 3 interviews a week does 150 customer touchpoints per year — more than most organizations do in five years of "real research."

1.2 Chapter 2 — The Product Trio

The cadence requires a specific team shape: a product trio of one product manager, one designer, and one engineer who own the outcome together. The trio is the unit of discovery — not the PM alone, not a research function on the side. When the engineer hears the customer say "I copy-paste this into a spreadsheet every Friday," she is ten times more likely to build something useful than when she reads it in a Notion doc weeks later.

Torres cites the Spotify squad and Atlassian triad structures as prior art and pulls the model into a sharper prescription: the trio meets weekly to review the tree, divide interview duties, and decide what to test next.

2. Part Two — Focusing the Outcome (Chapters 3-4)

2.1 Chapter 3 — From Output to Outcome

The first discipline shift Torres demands is measuring outcomes, not outputs. Outputs are features shipped; outcomes are customer-behavior changes that produce business value. A team chartered with "ship the new dashboard" will ship the dashboard whether or not anyone uses it.

A team chartered with "increase the percentage of weekly active users who view a report at least once a week from 22% to 35%" has to figure out what to build to move that number.

Torres draws hard lines between business outcomes (revenue, retention), product outcomes (engagement, conversion), and traction metrics (clicks, sessions). Discovery teams should be chartered with product outcomes — they sit at the right altitude.

2.2 Chapter 4 — Mapping the Opportunity Space

Once the outcome is fixed, the team starts collecting opportunities — verbatim customer needs, pain points, and desires that, if addressed, would move the outcome. Opportunities are written from the customer's perspective, not the company's. "Engineers waste an hour every Monday reconciling deploy logs" is an opportunity.

"Build a deploy-log dashboard" is a solution. Conflating the two is the most common discovery mistake.

3. Part Three — The Opportunity-Solution Tree (Chapters 5-7)

3.1 Chapter 5 — Building the Tree

This is the book's signature chapter and the artifact Torres is best known for. The Opportunity-Solution Tree has four layers, top to bottom:

Desired Outcome (root) — the single product outcome the trio is accountable for.
Opportunities (mid-branches) — customer needs surfaced from interviews, sized and prioritized.
Solutions (leaf nodes) — specific features, experiments, or interventions to address an opportunity.
Assumptions (under each solution) — what must be true for the solution to work; tested before building.

The verbatim Torres-ism: "The Opportunity-Solution Tree is the artifact that aligns the trio." The PM, designer, and engineer can stare at the same tree on a Tuesday morning and instantly agree on what they know, what they don't, and what they are testing this week.

3.2 Chapter 6 — Prioritizing Opportunities

Not all opportunities are equal. Torres prescribes opportunity sizing by three axes: how many customers experience the opportunity, how frequently they experience it, and how severe the pain is. A daily papercut hitting 80% of users beats a once-a-quarter blocker hitting 5%.

The trio actively prunes the tree — small opportunities get cut so the team can go deep on the ones that move the outcome.

3.3 Chapter 7 — Generating Solutions

For the top 1-3 opportunities, the trio brainstorms 10-20 solutions each — deliberately divergent before convergent. Torres borrows from IDEO and Stanford d.school design-thinking practice here: bad ideas surface good ones; the first solution is almost never the best one.

4. Part Four — Story-Based Interviewing (Chapters 8-9)

4.1 Chapter 8 — The Weekly Interview Cadence

Torres prescribes 3-5 customer interviews per week as the non-negotiable floor. The interviews are short (20-30 min), recorded, and synthesized into opportunities the same day. The trio rotates who runs the interview — the engineer interviews one week, the designer the next — so nobody loses customer context.

She names the automated recruiting pipeline as the unblock: a tiny in-product widget that lets satisfied users opt in to "talk to the team," booking directly onto the trio's calendar. Once the pipeline runs, the weekly cadence stops being heroic.

4.2 Chapter 9 — Story-Based Interviewing

Torres's interview technique is the story-based interview, lifted from Indi Young's generative research and Rob Fitzpatrick's The Mom Test ([[bs0126]]). The rule: ask about the past, not the hypothetical. Instead of "Would you use a feature that does X?" — which gets you a polite lie — ask "Tell me about the last time you tried to do X." The customer reconstructs an actual event with real friction, real workarounds, and real emotional weight.

That is where opportunities live.

Torres gives the exact opening phrase every PM should memorize: "Tell me about the last time you..." The follow-up probes are "What happened next?" and "Why was that frustrating?" — neutral, non-leading, and infinitely repeatable.

5. Part Five — Testing Assumptions (Chapters 10-11)

5.1 Chapter 10 — Assumption Mapping

For every promising solution, the trio runs assumption mapping: list 5-10 assumptions that must be true for the solution to work, then plot them on a 2x2 — risk (high/low) vs. evidence (strong/weak). The top-right quadrant — high risk, weak evidence — is where the team tests first.

Torres breaks assumptions into five families: desirability (will customers want it?), viability (will it make business sense?), feasibility (can we build it?), usability (can they use it?), and ethical (should we build it?).

The verbatim Torres-ism: "Test assumptions BEFORE building — not after." Most product failures are failures of skipped assumption tests, not bad engineering.

5.2 Chapter 11 — Designing Smallest-Possible Experiments

For each high-risk assumption, the trio designs the smallest possible experiment that could disprove it — a one-question survey, a Figma click-through, a fake door, a concierge MVP, an unmoderated Maze test. Torres cites the Wizard of Oz test (human behind the curtain pretending to be the product) and landing-page MVPs as canonical small experiments.

The goal is not a perfect test; it is a fast cheap disproof before engineering time is spent.

6. Part Six — The Weekly Operating Cadence (Chapters 12-13)

6.1 Chapter 12 — The Weekly Trio Review

Torres prescribes a recurring weekly trio review — typically 60 minutes — where the PM, designer, and engineer walk the tree together: did last week's interviews surface new opportunities, did the assumption tests confirm or kill any solutions, what are we testing this week. The tree gets updated live during the meeting.

No slide deck, no status report — just the trio and the tree.

6.2 Chapter 13 — Continuous Improvement of the Habit

The final chapter zooms out: the trio should also reflect on the discovery practice itself. Are the interviews actually surfacing new insights or recycling the same complaints? Are assumption tests killing solutions early enough to save build time?

Are stakeholders aligned around the tree, or are they still asking for status updates in a different format? Torres treats the discovery habit as itself a product to be iterated on — a meta-discipline most PM books skip.

flowchart TD A[Desired Outcome - Product Metric] --> B[Opportunity 1] A --> C[Opportunity 2] A --> D[Opportunity 3] B --> E[Solution 1A] B --> F[Solution 1B] C --> G[Solution 2A] D --> H[Solution 3A] E --> I[Assumption Test - Desirability] F --> J[Assumption Test - Feasibility] G --> K[Assumption Test - Viability] H --> L[Assumption Test - Usability] I --> M{Survived?} J --> M K --> M L --> M M -->|Yes| N[Build + Ship] M -->|No| O[Kill Solution, Generate New One] O --> E

7. Frameworks at a Glance

The named frameworks that travel directly from Torres into modern PLG and PM operating systems:

The Opportunity-Solution Tree — the four-layer artifact (Outcome → Opportunities → Solutions → Assumptions) now used at Spotify, Atlassian, Pendo, Amplitude, and dozens of PLG companies as the default discovery artifact.
The Product Trio — PM + designer + engineer as the unit of discovery, codified into team-shape playbooks at Shopify and Stripe.
Story-Based Interviewing — the "Tell me about the last time you..." opener, descended from Rob Fitzpatrick's The Mom Test and Indi Young's generative research.
Assumption Mapping — the 2x2 of risk vs. Evidence, descended from David Bland's Testing Business Ideas and Strategyzer's assumption-mapping canvas.
Smallest Possible Experiment — Wizard-of-Oz, fake door, concierge MVP, Figma click-through, landing-page test — the canonical lightweight tests every modern PM uses before writing engineering tickets.
Weekly Trio Review — the 60-min recurring meeting where the tree is walked, updated, and pruned by the people building the product.

flowchart LR A[3-5 Weekly Customer Interviews] --> B[Story-Based Opportunities] B --> C[Update Opportunity-Solution Tree] C --> D[Trio Prioritizes Top Opportunity] D --> E[Brainstorm 10-20 Solutions] E --> F[Assumption Map - Risk vs Evidence] F --> G[Smallest Possible Experiment] G --> H{Assumption Survived?} H -->|Yes| I[Build + Ship to Outcome] H -->|No| J[Kill Solution, Update Tree] J --> A I --> A

8. What Holds Up, What Has Aged

What still holds (2025-2027):

The weekly interview cadence has become the operating default at PLG companies — Linear, Vercel, Figma, Notion, and Loom all run versions of Torres's trio-plus-tree model.
The Opportunity-Solution Tree is now embedded in Pendo, Productboard, and Dovetail as a native artifact type.
Story-based interviewing has migrated out of PM into customer success, sales discovery, and founder customer-development practice — the "Tell me about the last time you..." opener is now table stakes.
Assumption-test-before-build is the foundation of every modern PLG growth model and JTBD-driven roadmap.

What has aged or evolved:

AI tools (Claude, Notion AI, Dovetail's AI synthesis, Grain) now accelerate interview synthesis — what took the trio an hour after every interview now takes 5 minutes, dropping the cost of the weekly cadence and lifting the realistic ceiling to 5-8 interviews per week.
Remote-first interviewing via Zoom, Google Meet, and Riverside is now standard — Torres's 2021 book assumed a mix of in-person and remote, but the world went fully remote and stayed there.
The trio model has expanded into a quartet at some companies — adding a data scientist or growth marketer to the PM-designer-engineer core, especially in PLG orgs where in-product instrumentation is the primary discovery channel.
The book underweights community-driven discovery (Discord servers, Slack communities, public roadmap voting) — a channel that did not exist at scale in 2021 but now produces high-signal opportunities at companies like Linear and Raycast.

FAQ

Why should sellers care about a PM discovery book? Because the same trio cadence applies to sales teams building toward a quota or pipeline outcome — 3-5 weekly prospect conversations, a tree mapping pipeline opportunities to ICP segments to outreach experiments, and assumption tests on which messaging actually books meetings.

The Opportunity-Solution Tree generalizes to any team accountable for an outcome.

How does this book relate to the Mom Test? Rob Fitzpatrick's The Mom Test ([[bs0126]], 2013) is the tactical bible for the interview itself — how to avoid leading questions and false validation. Torres builds on it with the surrounding operating system: who interviews, how often, and how the insights become an artifact the team acts on.

Read Fitzpatrick first, then Torres.

Where does Torres sit relative to Cagan and Inspired? Marty Cagan's Inspired ([[bs0190]], 2008) defines the product manager role and the SVPG empowered-team model. Torres operationalizes the discovery half of Cagan's model — Inspired says empowered teams discover continuously, and Torres says here is exactly how. They are companion volumes.

What if my org will not give me 3 hours a week for interviews? Torres's reply: start with one interview a week for a month, share what you learned with leadership, and let the insights make the case. Most teams that try one weekly interview cannot go back — the signal-to-noise ratio of a single real customer conversation outperforms a dozen internal stakeholder meetings.

Is the book worth reading or just the summary? Worth reading — the case studies (anonymized Spotify, Atlassian, and SVPG client stories) and the exact interview scripts make the practice concrete. The summary gives you the model; the book gives you the muscle memory.

Does the framework apply outside software product teams? Yes. Marketing teams use the tree to ladder campaigns to revenue outcomes, sales orgs use it to map quota to ICP segments to outreach experiments, and customer success teams use it to ladder NRR targets to expansion plays.

The artifact is outcome-agnostic — any team chartered with a measurable outcome benefits from the same discipline.

Bottom Line

Read Continuous Discovery Habits if you build product, sell to product teams, or own any outcome that depends on understanding what customers actually do. The Monday-morning takeaway: book three customer interviews this week, draw an Opportunity-Solution Tree on a whiteboard, and list five assumptions under your top solution that you could test before writing a line of code. Torres's framework is the operating system the modern PM canon converged on — and the discipline it teaches (outcome over output, evidence over opinion, weekly cadence over rare research) applies as cleanly to sales, marketing, and customer success as it does to product.

Sources

Torres, Teresa — Continuous Discovery Habits (Product Talk, 2021)
Torres, Teresa — Product Talk blog and continuous-discovery course materials (producttalk.org)
Fitzpatrick, Rob — The Mom Test (Founder Centric, 2013) — story-based interviewing foundation
Cagan, Marty — Inspired (SVPG / Wiley, 2008, 2017 2nd ed.) — empowered product team model
Cagan, Marty and Jones, Chris — Empowered (SVPG / Wiley, 2020) — companion to Torres on team enablement
Young, Indi — Practical Empathy (Rosenfeld Media, 2015) — generative interview technique
Bland, David and Osterwalder, Alex — Testing Business Ideas (Strategyzer / Wiley, 2019) — assumption-mapping canvas
Christensen, Clayton — Competing Against Luck (HarperBusiness, 2016) — Jobs-to-be-Done framing
Silicon Valley Product Group — SVPG articles and Empowered Product Team research (svpg.com)
Productboard, Pendo, Dovetail — Opportunity-Solution Tree implementation references (2024-2026 product docs)
Reforge — Continuous Product Discovery program materials (Torres collaboration, 2022-2025)

Keep reading

Download:

### Direct Answer

**Continuous Discovery Habits** by **Teresa Torres** (Product Talk, 2021) is the modern operating manual for how product teams should learn from customers — not as a quarterly research project, but as a **weekly cadence**. Torres, founder of **Product Talk** and a 15-year discovery coach to product orgs at **Spotify**, **Atlassian**, and across the **Silicon Valley Product Group (SVPG)** orbit, argues that the best product teams interview **3-5 customers every week**, maintain a living **Opportunity-Solution Tree**, and **test assumptions BEFORE building** — not after. Her signature artifact, the **Opportunity-Solution Tree**, hangs a clear **Desired Outcome** at the top, branches down into **Opportunities** (customer needs), then **Solutions** (experiments), then **Assumptions** that must be tested first. The book has become the canonical bridge between **Rob Fitzpatrick's The Mom Test** (2013, [[bs0126]]) and **Marty Cagan's Inspired** (2008, [[bs0190]]) — and it now sits in the **modern PM canon** alongside MEDDPICC, JTBD, and the SVPG product-trio model that every PLG company uses.

## 1. Part One — Why Continuous Discovery (Chapters 1-2)

### 1.1 Chapter 1 — The Case for Continuous Discovery

Torres opens with the central indictment: most product teams treat discovery as a **rare, expensive event** — a six-week generative research sprint, an annual customer-satisfaction survey, an offsite workshop with five strategic accounts. The teams that ship the best products treat discovery as a **weekly habit**. Torres defines continuous discovery formally: at a minimum, weekly touchpoints with customers, by the team building the product, where they conduct small research activities in pursuit of a desired outcome.

The verbatim Torres-ism that bookends the chapter: **"Continuous discovery is a HABIT, not a project."** Habits compound; projects decay. A team that does 3 interviews a week does **150 customer touchpoints per year** — more than most organizations do in five years of "real research."

### 1.2 Chapter 2 — The Product Trio

The cadence requires a specific team shape: a **product trio** of one product manager, one designer, and one engineer who **own the outcome together**. The trio is the unit of discovery — not the PM alone, not a research function on the side. When the engineer hears the customer say "I copy-paste this into a spreadsheet every Friday," she is **ten times more likely** to build something useful than when she reads it in a Notion doc weeks later.

Torres cites the **Spotify squad** and **Atlassian triad** structures as prior art and pulls the model into a sharper prescription: the trio meets weekly to review the tree, divide interview duties, and decide what to test next.

## 2. Part Two — Focusing the Outcome (Chapters 3-4)

### 2.1 Chapter 3 — From Output to Outcome

The first discipline shift Torres demands is **measuring outcomes, not outputs**. Outputs are features shipped; outcomes are customer-behavior changes that produce business value. A team chartered with "ship the new dashboard" will ship the dashboard whether or not anyone uses it. A team chartered with **"increase the percentage of weekly active users who view a report at least once a week from 22% to 35%"** has to figure out what to build to move that number.

Torres draws hard lines between **business outcomes** (revenue, retention), **product outcomes** (engagement, conversion), and **traction metrics** (clicks, sessions). Discovery teams should be chartered with **product outcomes** — they sit at the right altitude.

### 2.2 Chapter 4 — Mapping the Opportunity Space

Once the outcome is fixed, the team starts collecting **opportunities** — verbatim customer needs, pain points, and desires that, if addressed, would move the outcome. Opportunities are written from the **customer's perspective**, not the company's. **"Engineers waste an hour every Monday reconciling deploy logs"** is an opportunity. **"Build a deploy-log dashboard"** is a solution. Conflating the two is the most common discovery mistake.

## 3. Part Three — The Opportunity-Solution Tree (Chapters 5-7)

### 3.1 Chapter 5 — Building the Tree

This is the book's signature chapter and the artifact Torres is best known for. The **Opportunity-Solution Tree** has four layers, top to bottom:

1. **Desired Outcome** (root) — the single product outcome the trio is accountable for.
2. **Opportunities** (mid-branches) — customer needs surfaced from interviews, sized and prioritized.
3. **Solutions** (leaf nodes) — specific features, experiments, or interventions to address an opportunity.
4. **Assumptions** (under each solution) — what must be true for the solution to work; tested **before** building.

The verbatim Torres-ism: **"The Opportunity-Solution Tree is the artifact that aligns the trio."** The PM, designer, and engineer can stare at the same tree on a Tuesday morning and instantly agree on what they know, what they don't, and what they are testing this week.

### 3.2 Chapter 6 — Prioritizing Opportunities

Not all opportunities are equal. Torres prescribes **opportunity sizing** by three axes: **how many customers** experience the opportunity, **how frequently** they experience it, and **how severe** the pain is. A daily papercut hitting 80% of users beats a once-a-quarter blocker hitting 5%. The trio actively **prunes** the tree — small opportunities get cut so the team can go deep on the ones that move the outcome.

### 3.3 Chapter 7 — Generating Solutions

For the top 1-3 opportunities, the trio brainstorms **10-20 solutions** each — deliberately divergent before convergent. Torres borrows from **IDEO** and **Stanford d.school** design-thinking practice here: bad ideas surface good ones; the first solution is almost never the best one.

## 4. Part Four — Story-Based Interviewing (Chapters 8-9)

### 4.1 Chapter 8 — The Weekly Interview Cadence

Torres prescribes **3-5 customer interviews per week** as the non-negotiable floor. The interviews are short (20-30 min), recorded, and synthesized into opportunities the same day. The trio rotates who runs the interview — the engineer interviews one week, the designer the next — so nobody loses customer context.

She names the **automated recruiting pipeline** as the unblock: a tiny in-product widget that lets satisfied users opt in to "talk to the team," booking directly onto the trio's calendar. Once the pipeline runs, the weekly cadence stops being heroic.

### 4.2 Chapter 9 — Story-Based Interviewing

Torres's interview technique is the **story-based interview**, lifted from **Indi Young's** generative research and **Rob Fitzpatrick's The Mom Test** ([[bs0126]]). The rule: **ask about the past, not the hypothetical**. Instead of "Would you use a feature that does X?" — which gets you a polite lie — ask "Tell me about the last time you tried to do X." The customer reconstructs an actual event with real friction, real workarounds, and real emotional weight. That is where opportunities live.

Torres gives the exact opening phrase every PM should memorize: **"Tell me about the last time you..."** The follow-up probes are "What happened next?" and "Why was that frustrating?" — neutral, non-leading, and infinitely repeatable.

## 5. Part Five — Testing Assumptions (Chapters 10-11)

### 5.1 Chapter 10 — Assumption Mapping

For every promising solution, the trio runs **assumption mapping**: list **5-10 assumptions** that must be true for the solution to work, then plot them on a 2x2 — **risk** (high/low) vs. **evidence** (strong/weak). The top-right quadrant — high risk, weak evidence — is where the team **tests first**. Torres breaks assumptions into five families: **desirability** (will customers want it?), **viability** (will it make business sense?), **feasibility** (can we build it?), **usability** (can they use it?), and **ethical** (should we build it?).

The verbatim Torres-ism: **"Test assumptions BEFORE building — not after."** Most product failures are failures of skipped assumption tests, not bad engineering.

### 5.2 Chapter 11 — Designing Smallest-Possible Experiments

For each high-risk assumption, the trio designs the **smallest possible experiment** that could disprove it — a one-question survey, a Figma click-through, a fake door, a concierge MVP, an unmoderated **Maze** test. Torres cites the **Wizard of Oz** test (human behind the curtain pretending to be the product) and **landing-page MVPs** as canonical small experiments. The goal is not a perfect test; it is a **fast cheap disproof** before engineering time is spent.

## 6. Part Six — The Weekly Operating Cadence (Chapters 12-13)

### 6.1 Chapter 12 — The Weekly Trio Review

Torres prescribes a recurring **weekly trio review** — typically 60 minutes — where the PM, designer, and engineer walk the tree together: did last week's interviews surface new opportunities, did the assumption tests confirm or kill any solutions, what are we testing this week. The tree gets updated live during the meeting. No slide deck, no status report — just the trio and the tree.

### 6.2 Chapter 13 — Continuous Improvement of the Habit

The final chapter zooms out: the trio should also reflect on the **discovery practice itself**. Are the interviews actually surfacing new insights or recycling the same complaints? Are assumption tests killing solutions early enough to save build time? Are stakeholders aligned around the tree, or are they still asking for status updates in a different format? Torres treats the discovery habit as itself a product to be iterated on — a meta-discipline most PM books skip.

```mermaid
flowchart TD
    A[Desired Outcome - Product Metric] --> B[Opportunity 1]
    A --> C[Opportunity 2]
    A --> D[Opportunity 3]
    B --> E[Solution 1A]
    B --> F[Solution 1B]
    C --> G[Solution 2A]
    D --> H[Solution 3A]
    E --> I[Assumption Test - Desirability]
    F --> J[Assumption Test - Feasibility]
    G --> K[Assumption Test - Viability]
    H --> L[Assumption Test - Usability]
    I --> M{Survived?}
    J --> M
    K --> M
    L --> M
    M -->|Yes| N[Build + Ship]
    M -->|No| O[Kill Solution, Generate New One]
    O --> E
```

## 7. Frameworks at a Glance

The named frameworks that travel directly from Torres into modern PLG and PM operating systems:

- **The Opportunity-Solution Tree** — the four-layer artifact (Outcome → Opportunities → Solutions → Assumptions) now used at Spotify, Atlassian, Pendo, Amplitude, and dozens of PLG companies as the default discovery artifact.
- **The Product Trio** — PM + designer + engineer as the unit of discovery, codified into team-shape playbooks at Shopify and Stripe.
- **Story-Based Interviewing** — the "Tell me about the last time you..." opener, descended from **Rob Fitzpatrick's The Mom Test** and **Indi Young's** generative research.
- **Assumption Mapping** — the 2x2 of risk vs. Evidence, descended from **David Bland's Testing Business Ideas** and **Strategyzer's** assumption-mapping canvas.
- **Smallest Possible Experiment** — Wizard-of-Oz, fake door, concierge MVP, Figma click-through, landing-page test — the canonical lightweight tests every modern PM uses before writing engineering tickets.
- **Weekly Trio Review** — the 60-min recurring meeting where the tree is walked, updated, and pruned by the people building the product.

```mermaid
flowchart LR
    A[3-5 Weekly Customer Interviews] --> B[Story-Based Opportunities]
    B --> C[Update Opportunity-Solution Tree]
    C --> D[Trio Prioritizes Top Opportunity]
    D --> E[Brainstorm 10-20 Solutions]
    E --> F[Assumption Map - Risk vs Evidence]
    F --> G[Smallest Possible Experiment]
    G --> H{Assumption Survived?}
    H -->|Yes| I[Build + Ship to Outcome]
    H -->|No| J[Kill Solution, Update Tree]
    J --> A
    I --> A
```

## 8. What Holds Up, What Has Aged

**What still holds (2025-2027):**
- The **weekly interview cadence** has become the operating default at PLG companies — **Linear**, **Vercel**, **Figma**, **Notion**, and **Loom** all run versions of Torres's trio-plus-tree model.
- The **Opportunity-Solution Tree** is now embedded in **Pendo**, **Productboard**, and **Dovetail** as a native artifact type.
- **Story-based interviewing** has migrated out of PM into **customer success**, **sales discovery**, and **founder customer-development** practice — the "Tell me about the last time you..." opener is now table stakes.
- **Assumption-test-before-build** is the foundation of every modern **PLG growth model** and **JTBD-driven roadmap**.

**What has aged or evolved:**
- AI tools (**Claude**, **Notion AI**, **Dovetail's AI synthesis**, **Grain**) now **accelerate interview synthesis** — what took the trio an hour after every interview now takes 5 minutes, dropping the cost of the weekly cadence and lifting the realistic ceiling to **5-8 interviews per week**.
- **Remote-first interviewing** via **Zoom**, **Google Meet**, and **Riverside** is now standard — Torres's 2021 book assumed a mix of in-person and remote, but the world went fully remote and stayed there.
- The trio model has expanded into a **quartet** at some companies — adding a **data scientist** or **growth marketer** to the PM-designer-engineer core, especially in PLG orgs where in-product instrumentation is the primary discovery channel.
- The book underweights **community-driven discovery** (Discord servers, Slack communities, public roadmap voting) — a channel that did not exist at scale in 2021 but now produces high-signal opportunities at companies like **Linear** and **Raycast**.

## FAQ

**Why should sellers care about a PM discovery book?** Because the same trio cadence applies to sales teams building toward a quota or pipeline outcome — 3-5 weekly prospect conversations, a tree mapping pipeline opportunities to ICP segments to outreach experiments, and assumption tests on which messaging actually books meetings. The Opportunity-Solution Tree generalizes to any team accountable for an outcome.

**How does this book relate to the Mom Test?** Rob Fitzpatrick's The Mom Test ([[bs0126]], 2013) is the tactical bible for the interview itself — how to avoid leading questions and false validation. Torres builds on it with the surrounding operating system: who interviews, how often, and how the insights become an artifact the team acts on. Read Fitzpatrick first, then Torres.

**Where does Torres sit relative to Cagan and Inspired?** Marty Cagan's Inspired ([[bs0190]], 2008) defines the product manager role and the SVPG empowered-team model. Torres operationalizes the discovery half of Cagan's model — Inspired says empowered teams discover continuously, and Torres says here is exactly how. They are companion volumes.

**What if my org will not give me 3 hours a week for interviews?** Torres's reply: start with one interview a week for a month, share what you learned with leadership, and let the insights make the case. Most teams that try one weekly interview cannot go back — the signal-to-noise ratio of a single real customer conversation outperforms a dozen internal stakeholder meetings.

**Is the book worth reading or just the summary?** Worth reading — the case studies (anonymized Spotify, Atlassian, and SVPG client stories) and the exact interview scripts make the practice concrete. The summary gives you the model; the book gives you the muscle memory.

**Does the framework apply outside software product teams?** Yes. Marketing teams use the tree to ladder campaigns to revenue outcomes, sales orgs use it to map quota to ICP segments to outreach experiments, and customer success teams use it to ladder NRR targets to expansion plays. The artifact is outcome-agnostic — any team chartered with a measurable outcome benefits from the same discipline.

## Bottom Line

Read **Continuous Discovery Habits** if you build product, sell to product teams, or own any outcome that depends on understanding what customers actually do. The Monday-morning takeaway: **book three customer interviews this week, draw an Opportunity-Solution Tree on a whiteboard, and list five assumptions under your top solution that you could test before writing a line of code.** Torres's framework is the operating system the modern PM canon converged on — and the discipline it teaches (outcome over output, evidence over opinion, weekly cadence over rare research) applies as cleanly to sales, marketing, and customer success as it does to product.

## Sources

- Torres, Teresa — Continuous Discovery Habits (Product Talk, 2021)
- Torres, Teresa — Product Talk blog and continuous-discovery course materials (producttalk.org)
- Fitzpatrick, Rob — The Mom Test (Founder Centric, 2013) — story-based interviewing foundation
- Cagan, Marty — Inspired (SVPG / Wiley, 2008, 2017 2nd ed.) — empowered product team model
- Cagan, Marty and Jones, Chris — Empowered (SVPG / Wiley, 2020) — companion to Torres on team enablement
- Young, Indi — Practical Empathy (Rosenfeld Media, 2015) — generative interview technique
- Bland, David and Osterwalder, Alex — Testing Business Ideas (Strategyzer / Wiley, 2019) — assumption-mapping canvas
- Christensen, Clayton — Competing Against Luck (HarperBusiness, 2016) — Jobs-to-be-Done framing
- Silicon Valley Product Group — SVPG articles and Empowered Product Team research (svpg.com)
- Productboard, Pendo, Dovetail — Opportunity-Solution Tree implementation references (2024-2026 product docs)
- Reforge — Continuous Product Discovery program materials (Torres collaboration, 2022-2025)

Was this helpful?

⌬ Apply this in PULSE

Pillar · Founder-Led Sales GovernanceThe governance stack that scales Gross Profit CalculatorModel margin per deal, per rep, per territory

Related in the library