www.producttalk.org
2026/6/21 · 20:26
Continuous Discovery Habits — Teresa Torres's argument that talking to customers isn't a phase, it's a practice
Teresa Torres's 2021 Continuous Discovery Habits makes the case that product discovery fails when treated as a phase rather than a habitual practice. The article unpacks the book's four core frameworks (weekly customer interviews, the Opportunity Solution Tree, assumption mapping, and outcome-based thinking), presents four real-world cases, surveys Torres's 2026 AI stance and current practitioner critiques, and closes with five PM experiments actionable this week.
Continuous Discovery Habits — Teresa Torres's argument that talking to customers isn't a phase, it's a practice
Teresa Torres spent years watching product teams do discovery the same wrong way: kick off a sprint, schedule a round of user interviews for the first week, synthesize findings into a deck, and then not talk to a customer again until the next sprint cycle. The research informed a roadmap decision. The roadmap got built. The roadmap was mostly wrong. Repeat.
Her response was a book published in 2021 by Product Talk Press. Continuous Discovery Habits doesn't argue that customer research matters — that argument was already made. It argues that discovery conducted as a phase, even a well-executed phase, is structurally incapable of keeping product teams calibrated to what customers actually need. The only solution is to make it continuous — weekly, habitual, woven into the team's regular working rhythm rather than scheduled as a project.
Five years after publication, the idea has become industry consensus. By 2026, 71% of B2B SaaS product managers report conducting at least one customer conversation per week, compared to 22% in 2022. 1 The Perspective AI report (which surveyed 89 product organizations) credits AI interview tooling for breaking the time barrier that made weekly touchpoints aspirational rather than operational — compressing PM time per week from ~10 hours of scheduling, conducting, and synthesizing down to ~90 minutes with AI interview agents. 1 Torres's framework didn't change. The infrastructure around it did.
What hasn't changed is the harder problem: teams fluent in the CDH vocabulary that can't tell you what they learned from their last ten customer conversations. 2 The book is worth reading carefully not because the framework is complicated, but because its implementation requires behavioral change that vocabulary alone won't produce.
The thesis: discovery isn't something you do, it's something you become
Torres distinguishes between two kinds of product work: discovery (figuring out which problems and solutions are worth pursuing) and delivery (building and shipping what you've decided to build). Most teams treat these as sequential phases. Torres's argument is that they're parallel tracks — that a well-functioning product team is always doing both simultaneously, every week, not swapping between them in blocks.
The shift from "discovery as phase" to "discovery as habit" sounds small. Its implications are not. When discovery is a phase, customer contact is event-driven — something you do to answer a specific question, then stop. When it's a habit, you accumulate a rolling understanding of the customer's world: their goals, their struggles, the gaps between what they need and what existing solutions provide. Patterns that only become visible over dozens of conversations can surface. Surprises can arrive before they become expensive.
Torres's standard is demanding: the product team — which she defines as the Product Trio (a product manager, a designer, and an engineer) — should be talking to customers at least weekly, together, so that all three roles share the same ground truth and carry it directly into decisions about what to build and how to build it. The trio structure is deliberate. It prevents the common failure mode where discovery is done by one function and "handed off" to others, who didn't witness what customers actually said.
The named frameworks
Weekly customer interviews
The foundational habit, from which everything else derives. Torres recommends one customer interview per week per product trio — with "interview" meaning a conversation about the customer's existing experience, not a presentation of your ideas or a prototype test. (Those are useful too, but separate.) The format she advocates is exploratory: ask about what customers do, what frustrates them, what workarounds they've built. Ask about the past. Don't ask what they would want; ask what they've actually done.
This is calibrated to a minimum viable habit. One interview per week per trio sounds modest. For most teams, it requires a continuous recruiting pipeline and a shared calendar commitment that has to be protected from the demands of delivery cycles.
The 2026 landscape data shows what changed when AI interview tooling entered this workflow: the median number of weekly customer conversations per PM rose from 0.7 in 2022 to 4 in 2026, with the ratio shifting to one synchronous interview plus roughly three asynchronous AI-conducted conversations. 1 Teams running discovery at this cadence deploy features with 90-day retention rates 34% higher than teams on quarterly discovery cycles (67% vs. 50%), and kill approximately three bad features per quarter before they ship — a number that teams on ad-hoc discovery round to zero. 1
The Opportunity Solution Tree (OST)
The book's most-cited tool. The OST is a visual artifact that organizes a product trio's discovery work around a hierarchy: the desired outcome at the top (a business or product metric the team owns), then a branching structure of opportunities (customer needs, pain points, or desires that, if addressed, would move the outcome), and beneath each opportunity, solutions (product ideas), and below each solution, assumption tests (experiments to validate before building).
The critical function of the tree is that it forces teams to separate opportunity space from solution space — to spend time understanding what customers need before generating ideas for what to build. Most teams invert this, starting with solutions (feature requests, competitor moves, stakeholder asks) and working backward. The OST makes the inversion visible and correctable.
Torres's operational rules for the tree:
- One outcome per tree. The team commits to moving one metric; multiple outcomes on one tree diffuse focus.
- Opportunities should use the customer's language. Not "improve onboarding" (a product-centric framing) but "I can't figure out what to do after I sign up" (what a customer actually said). The test: could a customer have said this exact thing in an interview?
- Prioritize opportunities before jumping to solutions. The tree's branching structure is a prioritization tool. Not every opportunity deserves solution generation; the ones closer to the desired outcome and supported by more interview evidence take priority.
- Assumption tests beat full builds. For any given solution, identify the riskiest assumption — the one that, if wrong, invalidates the whole idea — and find the cheapest possible way to test it before writing production code.
The tree is not built once. It evolves. Grailed's product trio evolved their OST through eight versions over nine months, starting from a single node labeled "increase relevance" and expanding into a layered map of user behaviors, motivations, and friction points. 3 The most important correction happened early: the team had assumed users wanted to control what the feed showed them. Interviews revealed what users actually wanted was for the algorithm to figure it out — "show me more stuff I like and less stuff I don't." The OST surfaced this mismatch before the team built the wrong controls. 3
Assumption mapping and testing
Torres gives considerable attention to the mechanics of testing ideas without building them. Her framework: before committing to a solution, the team should enumerate its underlying assumptions — what must be true about customer behavior, technical feasibility, and business viability for this solution to work — and then identify which assumption is riskiest.
She categorizes assumptions by two dimensions: how much confidence the team has, and how important the assumption is to the solution's success. The ones that are both high-importance and low-confidence are the ones to test first.
Testing methods Torres covers include fake door tests (advertising a feature before building it to measure click-through), concierge tests (manually delivering the outcome the solution would automate), and prototype tests (clicking through a static or low-fidelity version of the idea). The shared principle: learn the most important thing first, spend the minimum necessary to learn it.
Outcome-based thinking
Torres distinguishes outcomes (measurable changes in customer behavior that indicate value) from outputs (features and code you ship). The distinction is common in product discourse; Torres's contribution is making it operational. In the OST, the team names a specific outcome — not "improve engagement" but "increase 30-day retention from 40% to 50%" — and every opportunity, solution, and experiment on the tree is evaluated against whether it plausibly moves that metric.
This matters because it changes what counts as success. A team shipping a feature on schedule is not succeeding. A team that shipped a feature that moved retention by eight points is. The shift from measuring output (did we ship it?) to measuring outcome (did it work?) requires a different kind of organizational contract — one that Cagan's INSPIRED describes at the team level but CDH operationalizes at the individual discovery decision level.
The most citable lines
Torres writes in plain, instructor-grade prose — clear, patient, specific. Several lines function as standalone principles that practitioners have returned to repeatedly:
"Building is very cheap now. That doesn't mean we should build every idea we have." 4
"The most common antipattern right now is lazy AI interview synthesis." 4
"We don't want to produce AI-generated opportunity solution trees and have you take them as fact. We want you to engage with them, correct them, collaborate with the AI. We want to scaffold cross-interview synthesis, not do it for you." 5
"Too many product managers are waiting for permission to adopt the discovery habits. But this is a mistake. Everyone can start working this way today." 6
The first two quotes are from 2026 but they distill the book's core argument — Torres has not modulated the message with AI's arrival, she has sharpened it. The book itself is less quotable than it is operational: Torres writes to be applied, not cited. The chapter on the OST is thirty pages of worked examples, not aphorisms. Jan Srutek (design director at Outreach.io, who has followed Torres's work since reading her 2016 OST article) put it plainly: CDH earns its keep because it's "cross-disciplinary, practical, and tells you where to begin. And for that last point, she fully walks you through it." 7
Where CDH sits in the PM canon
CDH occupies a distinct and almost necessary position relative to the books that precede it in this series:
| Book | Core question | What it leaves open |
|---|---|---|
| INSPIRED (Marty Cagan) | How should empowered product teams organize? | How do teams actually do discovery, week to week? |
| Hooked (Nir Eyal) | How do you design habits into a product? | How do you discover which habits customers want? |
| Don't Make Me Think (Steve Krug) | How do you build UIs that require no cognitive effort? | How do you decide which UI to build in the first place? |
| The Mom Test (Rob Fitzpatrick) | How do you ask customer questions that produce honest answers? | What do you do with what you learn, systematically? |
| High Output Management (Andy Grove) | How do you cause a team to produce more and better output? | What exactly should a PM-led team produce in discovery? |
CDH answers what all five books leave open. INSPIRED describes the organizational conditions for good discovery but doesn't prescribe the practice. The Mom Test teaches interview technique but stops at data collection. CDH provides the connecting tissue: a system for running interviews, synthesizing what you learn into a structured opportunity map, generating and testing solutions against that map, and repeating every week.
The relationship with INSPIRED deserves a closer look because Torres and Cagan are in active dialogue. Cagan's model of an empowered product team that owns an outcome and decides how to achieve it is exactly the organizational structure CDH assumes. Torres's trio is Cagan's team condensed to its discovery-capable core. Both books treat feature factories — teams that build what stakeholders tell them — as the primary failure mode to escape.
The tension is with The Mom Test. Fitzpatrick's book argues against asking customers what they want and for asking about their past behavior. Torres agrees completely and goes further: the weekly interview cadence is designed to accumulate behavioral evidence across multiple conversations, not extract a single "validated answer" from one session. Where Fitzpatrick's book is about avoiding bad data, CDH is about what to do with good data when you're collecting it all the time.
High Output Management complements CDH at the organizational layer. Grove's leverage formula — a manager's output equals the output of their organization — implies that a PM's highest-leverage discovery activities are the ones that compound across the team's decisions. The OST is leverage. A well-maintained opportunity tree embeds shared understanding that eliminates dozens of micro-decisions downstream. Torres makes this argument implicitly; Grove makes the leverage concept explicit.
正在加载链接预览…
Real-world cases
Grailed: 4-5x GMV growth from OST adoption
Grailed (the peer-to-peer fashion resale marketplace) is the most quantified CDH case in the public domain. The discovery team — Group PM Rajiv Chopra and Staff iOS Engineer DJ Mitchell — started a CDH book club, built their first OST by dumping everything the team knew into an initial tree, and then ran weekly customer interviews to validate and refine it for nine months.
The results from November 2021 to August 2022: Feed Discoveries and GMV grew 4–5x from baseline. 3 Users who first made a purchase through the feed opened the app about 30% more than the average user, discovered 40% more items, and had a ~20% lift in lifetime value. 3 Users unprompted told the team "I gotta tell you. This feed is awesome."
Before the OST work, the team had spent eight months on a feed feature that launched to underwhelming response. Chopra's diagnosis: "We had a total 180 in impact, both in terms of business impact and the reception from our users." The mechanism was not better execution — it was the discovery of a different problem worth solving.
Doodle: breaking a feature factory through problem-space mapping
Doodle (the scheduling SaaS) is a textbook feature-factory transformation case. CPO Stephanie Leue described the starting state: "We were literally a top-down product organization. Someone had a feature idea — mainly someone from the board or the CEO or the former CPO. They told the teams what to build, the teams built it." 8 Despite having data, customer feedback, and interview access, "the connection between discovery and delivery was completely nonexistent." 8
The breakthrough came from a 1.5-day workshop in early 2024 where the underlying problem surfaced: the team couldn't write a problem statement, couldn't distinguish a problem from a hypothesis, and equated continuous discovery with just interviewing customers. After the workshop, each team mapped its problem space in 2–3 hours. In Leue's words: "Magic. Literally magic." Release frequency tripled. 8
Sauce Labs: 76 people through Master Class, GPM to SVP in 18 months
Sauce Labs (enterprise automated testing SaaS, customers including Verizon Media and Walmart) enrolled 76 product team members through the CDH Master Class in 2021. Mike Donovan, who joined as Group Product Manager in December 2020, used discovery as a career engine: he advanced to Director (six months), VP (another six months), and Senior VP (twelve months), attributing the trajectory directly to "really listening to what people were asking for, and using every opportunity from sales and support conversations to discover their true needs." 9
The product outcome was a new offering called Hosted Test Orchestration that made testing "50% faster" and put Sauce Labs back on a competitive footing. 9 Donovan's rule: "I think that my impact or influence at this organization is directly correlated with the number of customer calls I had." 9
Stack Overflow: building to learn, even when you have to roll it back
Ellen Brandenberger formed Stack Overflow's AI team in early 2023, after the ChatGPT launch, starting from "we knew nothing." The team built four iterations of conversational AI search over several months — moving from chat over keyword search to semantic search to RAG with full attribution — and couldn't get above 70% accuracy. They rolled the product back entirely. 10
The failure was not wasted. The learnings directly informed Stackoverflow's next product: a data licensing offering with industry-grade benchmarking (250 golden questions, refreshed monthly). A team member: "I think we had to go through that because otherwise we would have never been able to get where we are." 10 CDH's "build to learn" framing is exactly this: shipping a result is not the point of a test. Understanding something is.
What practitioners say now
Torres's own position in 2026
Torres spent the five years since the book's publication extending rather than revising it. She has not published a second edition; instead, she launched a year-long CDH book club in January 2026 — one chapter per month, with discussion questions, team exercises, and quarterly live sessions. 11 The format implies she views the core framework as stable, with evolution happening through application and community discussion rather than rewriting.
What has changed is her own practice. By 2026, Torres runs three Claude-powered autonomous agents on a Mac Mini for podcast production, sales administration, and coding work. She built an AI product from scratch — Interview Coach, an AI-driven interview feedback tool replacing a group coaching program she'd run since 2017. 4 She partnered with Vistaly to build AI-generated OSTs: a user uploads three customer interview transcripts and receives a first-draft opportunity tree, which the tool is designed to make collaborative rather than authoritative. 5
Her core message on AI hasn't softened: "Building is very cheap now. That doesn't mean we should build every idea we have." 4 And the failure mode she watches most closely is what she calls "lazy AI interview synthesis" — using AI to summarize interview transcripts and treating the output as insight, without the PM's own interpretation and comparison layer. 4 "The most common antipattern right now is lazy AI interview synthesis." 4
David Hoang (VP of Design/AI at Atlassian) offers the sharpest articulation of why discovery's relative importance grew with AI: when AI compresses feasibility, viability, and usability risks, desirability becomes the remaining differentiator. 12 "When AI can build almost anything quickly, the question changes from 'Can we build this?' to 'Should this exist?' And that's a question only customer insight can answer." 12
正在加载链接预览…
Legitimate critiques
The Product Trio structure is under pressure. João Carlos Matos, a UX researcher writing in February 2026 as part of Torres's own book club, put it directly: "Personally, I don't agree with this structure and even think it may be outdated by 2026 — at least in terms of the skills expected from each role, especially given the growth of AI." 13 The point isn't that trios are wrong in principle but that the specific skill bundles assumed for each role (a generalist PM, a visual-design-focused designer, a shipping-focused engineer) may not match how AI-augmented teams actually organize today.
CDH is being weaponized to eliminate UXR headcount. This is the most structurally damaging critique, because Torres didn't cause it but also hasn't fully resolved it. The doctrine that PMs should do their own discovery has been selectively used to justify cutting dedicated user research roles. Torres acknowledged the discomfort publicly in a 2024 LinkedIn post, after a discussion in r/UXResearch described product teams "kick[ing] UXR out of the discovery process." 14 Megan Scheminske (Senior UX Researcher at Teachable, supporting 8 designers, 13 PMs, and 60+ engineers) draws the line clearly: "Continuous discovery is not a great way to make decisions or validate decisions. It's a great way to build empathy for users and generate ideas." 15 Dedicated researchers run rigorous evaluative studies. Product trios run exploratory, generative discovery. The two are not substitutes.
Vocabulary without behavioral change. The freshest and most resonant critique came from Reddit in June 2026: a post titled "Cagan, Torres and the product influencer era actually broke teams' ability to innovate rather than empower them" received 121 upvotes (83% ratio). 2 The author u/Superbureau: "The product thinking movement didn't just professionalise PMs. It created a shared vocabulary that organisations could adopt as proof of capability without actually developing it." 2 The diagnostic: "Teams that are fluent in the language but can't articulate what they actually learned from their last ten customer conversations." 2 Torres has not responded publicly. The critique is worth sitting with, because the book itself anticipates it: Torres emphasizes repeatedly that the goal is to build habits, not to adopt the language. But she cannot control how organizations use the vocabulary.
Ken Norton (former Google PM and GV partner) still lists CDH as a "TOP PICK" in his 2026 PM reading list, writing: "Teresa Torres is the best in the business at helping teams build products and services that their customers want." 16 This is not a counterargument to the vocabulary critique; it reflects the book's actual depth, which is available to teams willing to implement rather than perform.
Five experiments to run this week
These are the highest-yield implementations of CDH's frameworks, each designed to produce a real result in five days without requiring organizational permission.
1. Commit to one customer conversation before Friday. Don't schedule it as a "research session." Find one customer in your user base, email them personally, and ask for 25 minutes to hear about their experience. Use the Mom Test's past-behavior questions: "Walk me through the last time you [relevant activity]." Don't mention your roadmap. Take notes by hand or record with permission. The goal isn't to validate anything — it's to break the pattern of weeks passing without direct customer contact.
2. Draw your current OST, however rough. Open a blank Miro or FigJam and put your team's current product outcome at the top. Then write every customer problem, complaint, need, or goal you're aware of on sticky notes. Branch them off the outcome. You'll discover immediately that you have solution-shaped items masquerading as opportunities ("improve the dashboard" is a solution; "I can't tell if my work is having any impact" is an opportunity). Sorting these reveals where your team is working from assumptions rather than evidence.
3. Run an assumption audit on your next roadmap item. Take the next item on your team's roadmap and list every assumption that must be true for it to succeed — about customer behavior, technical feasibility, the business model, adoption. Rate each assumption: how important, and how confident are you? Anything that's high-importance and low-confidence is a test you need to run before investing in production code. Find the cheapest way to test it this week.
4. Do one interview as a trio, then debrief together. Invite your design counterpart and an engineer to your next customer conversation. Sit together afterward and each share the three things you found most surprising. You'll often discover you heard the same conversation differently. That difference matters — it's the raw material of synthesis, and it happens in the debrief, not in the interview itself.
5. Rephrase one solution as an opportunity. Find a feature request on your roadmap or backlog that came from a customer, stakeholder, or sales call. Rewrite it in the customer's words, describing the underlying problem rather than the proposed fix. Ask: if you solved this problem a completely different way, would the feature request still make sense? If the answer is yes, you've identified an opportunity worth staying in for multiple solution options. If the answer is no, you probably have a solution looking for a problem.
Reading this book
Continuous Discovery Habits was published in 2021 by Product Talk Press. Teresa Torres writes it as a coach — patient, directive, worked-example-rich. The book is structured around building discrete habits sequentially, with the assumption that readers are practicing each one before adding the next. It doesn't read well as a quick skim.
The chapters on the OST (Chapters 4–6) and on assumption testing (Chapter 8) are the most technically dense and the highest-return reading for a working PM. Torres's companion website, producttalk.org, contains more than forty case studies of teams applying the frameworks in practice.
Ken Norton's verdict from 2026 stands: "Teresa Torres is the best in the business at helping teams build products and services that their customers want." 16 The book is not for teams performing discovery. It's for teams willing to practice it.
Cover: AI-generated illustration
参考来源
- 1Perspective AI: The 2026 Continuous Discovery Report
- 2Reddit r/ProductManagement: Hot take on Cagan, Torres and the product influencer era
- 3Product Talk: Opportunity Mapping Led to a 20% Lift in LTV at Grailed
- 4airfocus: "Building is cheap now, but don't build everything": Teresa Torres on AI product management
- 5Product Talk: Behind the Scenes: Building AI-Generated Opportunity Solution Trees
- 6Product at Heart: Teresa Torres speaker page
- 7Jan Srutek, Bootcamp/Medium: Reflections on Continuous Discovery Habits
- 8Product Talk: Shifting from a Feature Factory to Continuous Discovery at Doodle
- 9Product Talk: Continuous Discovery Fuels Innovation at Sauce Labs
- 10Product Talk: Lessons from 9 AI Product Teams
- 11Product Talk: CDH Book Club June 2026
- 12David Hoang, Proof of Concept: How Product Discovery changes with AI
- 13João Carlos Matos, Bootcamp/Medium: Continuous Discovery Habits by Teresa Torres
- 14Reddit r/UXResearch: T Torres, author of continuous discovery, recognize the unease behind her book
- 15Rally UXR: Megan Scheminske on the pros and cons of continuous discovery
- 16Ken Norton: Best Books for Product Managers 2026
围绕这条内容继续补充观点或上下文。