Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value

Why this book exists

Teresa Torres spent years as a product manager and consultant watching the same painful pattern across companies: teams that nominally did "user research" but whose research never actually changed what they shipped. The researchers handed reports to the PMs. The PMs nodded politely. The roadmap, defined three months earlier, continued unchanged. The shipped features were the same features that would have shipped without any research at all.

The pattern was so consistent that Torres became convinced the problem was not with the researchers and not with the PMs. The problem was the structure. Research was a separate function done by separate people on a separate cadence, producing artifacts that arrived too late and at the wrong altitude to influence actual product decisions. As long as research and product decisions were separated by time, by people, and by deliverable format, the research would continue to be theater.

The fix was to fuse them. The PM, designer, and engineering lead — the trio that actually makes product decisions — had to be the ones doing the discovery work, weekly, as a habit, and the discovery work had to flow directly into the prioritization decisions they were already making. Discovery should not be a phase. It should be the way the team breathes.

Torres developed the discipline at first by coaching a handful of teams personally. The practice worked. Teams that adopted weekly customer touchpoints, an Opportunity Solution Tree, and assumption testing saw their feature hit rates climb dramatically. The discipline scaled. She founded Product Talk to teach it more widely. After training tens of thousands of PMs and refining the practices through several years of feedback loops, she wrote Continuous Discovery Habits in 2021 to codify the system.

The book has become, in the four years since publication, the most widely-adopted modern discovery playbook in the field. Where INSPIRED tells PMs they should be doing discovery, Continuous Discovery Habits tells them exactly how, with templates, worked examples, and the hardest-won lessons about what to do when the practice meets organizational reality.

The book in one sentence

Continuous discovery is a weekly habit, run by the product trio (PM, designer, tech lead), structured around an Opportunity Solution Tree, in which the riskiest assumption behind every candidate solution is tested with the cheapest possible experiment before any meaningful engineering commitment.

That sentence is the entire book. The rest is detail on how to actually do it.

What "continuous discovery" actually means

Torres opens the book with a precise definition that anchors everything to follow:

"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."

Unpack each phrase. Each one is doing real work.

At a minimum, weekly. Not monthly. Not quarterly. Not "when we have time." Weekly. The frequency is not arbitrary. Torres argues that anything less than weekly cannot become a habit, and anything that is not a habit will be skipped under deadline pressure. Monthly research becomes quarterly research becomes annual research becomes no research. Weekly is the lowest-frequency cadence that survives organizational gravity.

Touchpoints with customers. Not surveys, not data analyses, not feedback from sales. Direct conversations with real customers or prospects. The texture and judgment that come from real conversation is irreplaceable.

By the team building the product. The PM, designer, and tech lead. Not the researcher. Not a delegated agency. The people who will make the decisions are the people who do the discovery, because there is no faithful way to transmit the texture of a customer conversation to someone who was not in it.

Small research activities. Not large studies. Not 6-week research projects. 15-30 minute interviews, 30-minute usability tests, 2-hour analysis sessions. Small enough that they fit into a normal week.

In pursuit of a desired outcome. Discovery is not random. It is structured by a specific business or customer outcome the team is trying to move. Every interview, every test, every analysis is pointed at the outcome.

The definition is one sentence. It is also the most contested sentence in modern PM. Most teams that claim to do continuous discovery do not actually do it; they do occasional discovery and call it continuous. Torres is unwilling to soften the definition. Either you touch customers weekly with your trio, or you are not doing continuous discovery, regardless of what you call it.

The Opportunity Solution Tree

The central artifact of the practice is the Opportunity Solution Tree (OST). Torres devotes several chapters to it because everything else hangs off of it.

The OST has four levels, top to bottom:

Level 1: Desired outcome. A measurable business outcome the team is on the hook to move this quarter or this half. "Increase the percentage of new users who reach the activation event within 7 days from 32% to 50%." Specific, measurable, time-bounded. The OST is anchored here; everything below exists to move this number.

Level 2: Opportunities. Customer needs, pains, and desires that, if addressed, would move the outcome. Not solutions — opportunities. "Users abandon onboarding at step 4 because the value proposition isn't clear yet." "Users who reach the dashboard feel overwhelmed by choice." "Users who invite a teammate within day 1 retain at 3x the rate." Each opportunity is grounded in real interview evidence and represents a hypothesis about a leverage point.

Level 3: Solutions. Specific things you could build or do to address each opportunity. Each opportunity typically has 3-5 candidate solutions. The solutions compete; only one or a small number will ultimately ship for each opportunity. Generating multiple solutions per opportunity is critical — it prevents the team from latching onto the first idea and missing better ones.

Level 4: Assumption tests. For each candidate solution, the assumptions that must be true for it to work, and the experiments that would validate or invalidate the riskiest assumption. Tests come before commitments; if a riskier assumption fails its test, the solution is killed before any meaningful engineering goes in.

The visual of the tree is itself part of the discipline. Torres recommends teams maintain it as a literal whiteboard or in a tool like Mural, FigJam, or Whimsical, updated weekly. The visual makes the team's mental model explicit. New team members can be oriented in 15 minutes. Stakeholders can be shown why the current bet was chosen over alternatives. Disagreements about prioritization become visible — "we should attack this opportunity, not that one" is a much sharper conversation than "we should build this feature, not that one."

Torres is careful to distinguish the OST from an idea repository or a feature backlog. The OST is structured by the customer's world (opportunities) rather than the team's world (features). This is the move that prevents the OST from collapsing into a glorified backlog. When the team asks "which opportunity matters most?" they are forced into the customer's frame.

Interviewing for stories, not opinions

A long section of the book covers how to actually run customer interviews. This is the most-tactical part of the book and the most directly transformative for most PMs.

Torres's central rule is to interview for stories of real past behavior, not opinions about hypothetical futures. Humans are notoriously bad at predicting what they will do. They are reasonably good at describing what they actually did. The bridge from "did" to "would do" is the PM's job to construct, not the user's.

Practically this means the interview structure is:

1. Establish the focus area. "I'm trying to understand how teams handle invoice reconciliation today."
2. Ask for a specific recent story. "Walk me through the last time you reconciled invoices." Past, specific, narrative.
3. Probe for details. "What did you do first? Then? What got in the way? What did you do when X happened? How long did that take? Who else was involved?"
4. Extract the underlying pain or opportunity. "When you said you had to copy-paste 200 line items into a spreadsheet, how did that feel? How often does that happen?"

What you do not ask:

• "Would you use a feature that automated this?"
• "Do you think you'd pay for a tool that solved this?"
• "How important is this problem to you on a scale of 1-10?"
• "What features would you want in an ideal product?"

Each of those produces flattering, useless answers. The user is being polite. They are guessing. They have no idea what they would actually do.

The story-based approach extracts something stronger: evidence of behavior that has already happened, in the customer's own words, that you can use to design solutions with confidence. After 5-10 such interviews, patterns emerge across customers that become genuine opportunities on the OST.

Torres also emphasizes that the trio should do interviews together, at least until the practice is established. The PM, designer, and engineer each notice different things from the same conversation. The PM hears the business pain. The designer hears the workflow friction. The engineer hears the technical context. After the interview, the three synthesize what they each heard and the picture is richer than any one of them could produce alone. Pairing also speeds skill transfer — the junior member learns the craft of interviewing by watching the senior member do it.

Recruiting customers continuously

A practical objection to weekly interviews is: where do you find five customers to talk to every week?

Torres dedicates a chapter to this. The mechanism she recommends is continuous interview recruiting — a self-service flow embedded in the product or website that lets willing customers schedule a 30-minute conversation with the team at their convenience. Once the flow exists, you set it once and then have an ongoing stream of recruits indefinitely.

The implementation is simple. A Calendly (or similar) link. An in-product banner or email invitation. A modest incentive ($50-100 gift card per session, or for B2B, an offer of early access to features). The mechanism removes the per-week coordination overhead that otherwise kills the practice — once recruiting is automated, the only weekly work is conducting the interviews and synthesizing them.

For B2B teams without large customer bases, Torres recommends a complementary approach: weekly outreach to specific named prospects via LinkedIn or warm intro. The volume is lower but the targeting is tighter. Either way, the principle is the same: the recruiting mechanism has to be a standing system, not a per-interview scramble, or the weekly cadence collapses.

Assumption mapping and testing

Torres devotes some of the book's most important chapters to assumption testing — the practice of taking each candidate solution, listing the assumptions that must be true for it to work, identifying the riskiest one, and designing the cheapest possible test to validate or invalidate it.

The assumption categories Torres uses:

• Desirability. Does the customer actually want this? (Most commonly fatal.)
• Viability. Will it work for the business — pricing, channel, sustainability?
• Feasibility. Can engineering build it within constraints?
• Usability. Can the customer figure out how to use it?
• Ethical. Are there harms we are missing — to the user, the business, third parties?

For any candidate solution, the team writes down 5-10 specific assumptions across these categories. "Customers will be willing to pay $20/month for this." "Engineering can ship the MVP in 6 weeks." "The fraud team will approve the workflow." Each is stated as a falsifiable claim. The team then rates each by risk: how likely is the assumption to be wrong, and how badly does the solution fail if it is wrong.

The highest-risk assumption goes to test first. The test is designed to be as cheap as possible while still actually testing the assumption. A common pattern:

• For a desirability assumption: a smoke test (fake landing page with intent capture), a concierge test (deliver the value manually to 5 users), a Wizard of Oz prototype (UI that simulates the product, human behind the scenes).
• For a viability assumption: a pricing interview, a sales-team conversation, a partnership inquiry.
• For a feasibility assumption: a 1-day engineering spike, a code prototype, a technical interview with the architect.
• For a usability assumption: a 30-minute prototype test with 5 users, a clickable Figma.
• For an ethical assumption: a structured review with diverse stakeholders, a "pre-mortem" exercise.

The test produces a clear go/no-go on the riskiest assumption. If no-go, the solution is dead before engineering commits weeks to it. If go, the next-riskiest assumption is tested. After three or four assumptions are tested green, confidence is high enough to commit.

Torres is emphatic that most teams test the easiest assumption, not the riskiest. The easiest assumption is the one where the team is already confident the answer is yes. Testing it produces theater of validation — the team feels they have "done research," but no actual decision has been informed. The riskiest assumption is the one the team is afraid to test because they suspect the answer might be no. That is exactly the one that must be tested. Discovery is the practice of seeking out the inconvenient evidence.

The role of business outcomes

One of the most quietly important moves in the book is Torres's insistence that the team's outcome — the top of the OST — must be a business outcome, not a feature output or a vanity metric.

A bad team outcome: "Ship the new onboarding flow by end of Q3." This is an output, not an outcome. The team can ship the flow on time and still fail entirely.

A bad team outcome: "Increase total app sessions by 20%." This is a metric, but it is not necessarily tied to value — sessions go up if users get confused and click around more.

A good team outcome: "Increase the percentage of new users who reach the activation event within 7 days from 32% to 50%." Specific, measurable, tied to value the user actually receives, and tied (via downstream causal links the team has validated) to business impact.

Torres argues that the team's autonomy depends on the quality of the outcome they own. A team given a feature to ship has no autonomy — the decision is already made. A team given a metric to move has full autonomy to discover the best way to move it. Empowerment is meaningless without a properly-framed outcome to be empowered toward.

She also emphasizes that the outcome is not chosen by the team alone. Leadership owns the company's strategy, which cascades to team outcomes. The team owns how to move the outcome, but the outcome itself is set in collaboration with the team's manager and stakeholders. This nuance prevents the common failure mode where "empowered" teams pick easy outcomes to make themselves look good.

How discovery integrates with delivery

A chapter near the end of the book addresses the practical question: if discovery is happening continuously, when does the team actually build things?

Torres's answer is dual-track, echoing Marty Cagan's framing. Discovery and delivery happen in parallel on the same team, with the same trio, continuously. At any given moment, the team has:

• Solutions in discovery (being assumption-tested)
• Solutions being designed and engineered (in delivery)
• Solutions shipped, being measured (in learning)

The three loops feed each other. Discovery generates the next solutions to commit to. Delivery ships the previously-validated solutions. Learning from delivered solutions updates the OST — sometimes confirming an opportunity matters more than the team thought, sometimes revealing that a "fix" didn't actually move the outcome.

The mechanical question of how to split a team's calendar between the loops is one Torres handles pragmatically. Different teams will land on different ratios — 30% discovery / 70% delivery is common; some experimentation-heavy teams go higher on discovery. The exact ratio matters less than the principle: discovery has to be a standing reservation on the calendar, not a residual that gets squeezed out when delivery is busy.

The hardest parts of the practice

Torres is honest throughout the book about the failure modes of continuous discovery. The practice sounds simple. It is extraordinarily hard to maintain over time. Several failure modes she names:

Skipping weeks under pressure. The team has a launch on Friday. Interview week gets canceled. "We'll pick it up next week." Next week is also busy. Three months later, the practice has quietly died. The fix is to treat the weekly interview slot as immovable, like a sprint ceremony — the calendar holds.

Drifting toward output focus. The OST starts pristine but over time the team starts adding features to the tree as if they were opportunities. The discipline of "opportunities are framed in the customer's words, not ours" erodes. The fix is a quarterly OST audit by someone outside the team — usually a PM peer or a manager — to catch the drift.

Skipping assumption tests. The team gets excited about a solution and skips straight to building it. The assumption test feels like a delay. The fix is leadership reinforcement: the team's manager refuses to approve significant engineering commitment without seeing the assumption test results.

Testing only the easy assumptions. Already discussed. The cure is the team having the courage to test the inconvenient ones, which is partly a cultural thing — does the team feel safe surfacing a "we found out our idea is wrong" result?

Discovery without commitment. The opposite failure mode: the team discovers forever and never ships. The fix is enforcing a discovery-to-delivery handoff cadence — solutions that pass enough assumption tests must move to delivery within a fixed window, or they get killed and the team revisits the opportunity.

One member of the trio doing all the discovery. Usually the PM. The designer and engineer are "too busy." The trio practice collapses into solo PM research, which then has to be re-translated to the rest of the team. The fix is leadership protecting designer and engineer time for discovery, and treating it as a non-negotiable part of their job — not a nice-to-have.

The hit rate metric

Torres argues that the long-run scoreboard of a discovery practice is the team's hit rate — the percentage of shipped features or solutions that actually achieve the impact the team hypothesized.

Without discovery, industry benchmarks suggest hit rates around 30%. Most features ship and do not move metrics. With disciplined continuous discovery, hit rates climb to 60-70%+. The improvement is not marginal — it is foundational. A team that ships 10 features per quarter at 30% hit rate produces 3 wins. The same team at 60% hit rate produces 6 wins for the same engineering effort. Doubling team output without doubling team headcount.

Torres is explicit that the hit rate improvement does not appear immediately. The first quarter of practice produces little change — the team is learning the craft. The second quarter typically shows modest improvement. By the third or fourth quarter, the compounding shows up. This timeline is a warning to leaders: do not pull the plug on discovery in month 3 because "we haven't seen results yet." The practice is a long-term investment.

Frameworks worth memorizing

A few specific frameworks from the book have become widely adopted in PM vocabulary.

The Opportunity Solution Tree. Outcome at the top. Opportunities below (in the customer's words). Solutions below those (in the team's words). Assumption tests below those.

Story-based interviewing. Ask about specific past behavior. Probe for detail. Never ask about hypothetical futures or opinions.

Assumption mapping. For every candidate solution, list assumptions. Rate by risk. Test the riskiest with the cheapest possible experiment.

Continuous recruiting. A standing self-service flow that produces a weekly stream of willing interviewees with minimal coordination overhead.

Dual-track development. Discovery and delivery in parallel on the same team continuously.

The trio. PM, designer, tech lead, doing discovery together. None reports to the others.

Outcomes over output. Teams own metrics to move, not features to ship.

Hit rate. Percentage of shipped solutions that achieve hypothesized impact. The scoreboard of the practice.

What Torres gets right

The continuity insight is foundational. Once you have internalized that discovery is a weekly habit and not a project, almost every other failure mode self-corrects. Teams that try to "do better research" by running bigger research projects fail. Teams that switch to weekly touchpoints, even at modest depth, succeed.

The OST is a genuinely new artifact in the field and an excellent one. Backlogs are organized around the team's frame (features). The OST is organized around the customer's frame (opportunities). That reframe alone changes prioritization conversations from "which feature next" to "which opportunity matters most," which produces better answers.

The story-based interviewing protocol is unimprovable. Read just the interviewing chapters and you will become measurably better at customer conversations within a week of practice.

The assumption mapping discipline scales beautifully from solo PM work to team-of-trios coordination. Once a team is fluent, every prioritization conversation includes "what assumptions are we making, and have we tested the riskiest one?"

What Torres understates

The book is comparatively quiet on strategic discovery — the work of figuring out which outcomes to chase in the first place. Torres assumes that team outcomes are already set (via the broader company strategy and leadership cascade) and that the team's discovery is in service of moving those outcomes. This is true for established product teams. It is less true for early-stage teams trying to figure out what business they are in. For those teams, complement Continuous Discovery Habits with The Mom Test (Rob Fitzpatrick) and The Lean Startup (Eric Ries), both of which are more focused on the founder-stage problem of figuring out which problem to attack.

The book is also relatively quiet on discovery in B2B enterprise sales-led contexts. When deals are large and customer access is gated by account executives, the weekly-interview cadence is harder to maintain. Torres acknowledges this and offers workarounds, but the playbook is more clearly fit to consumer and SaaS contexts. For enterprise PMs, the book is still essential reading but requires adaptation.

The book does not address AI products specifically. The discovery practices Torres describes apply directly to AI features, but the AI craft adds wrinkles — assumption testing for hallucination, evals as a form of continuous validation, vibe-coded prototypes as a faster discovery tool — that the 2021 edition does not cover. The principles transfer; the toolset has expanded since publication.

How to actually apply this

The hardest part of applying the book is starting. The practice looks like a lot in aggregate, but the first weekly step is simple. Pick one outcome your team is trying to move this quarter. Schedule three customer conversations for next week. Do them with at least one other trio member. Take notes. Identify one or two patterns. Add them as opportunities to a whiteboard OST. Repeat next week.

After eight weeks of that, you will have an OST with 10-15 opportunities, 20-30 candidate solutions, a handful of assumption tests run, and a tangible sense of which solutions are worth committing to. The practice has become a habit. Leadership has started to see the team make sharper bets. The hit rate is creeping up.

If you read Continuous Discovery Habits and do exactly one thing differently, schedule three customer conversations for next week and run them with your trio. The rest of the practice grows from there.

If you read it and do five things differently:

1. Schedule weekly recurring customer conversations. Calendar-block them like sprint planning.
2. Build a continuous interview recruiting flow (Calendly link, in-product invitation, modest incentive).
3. Build an OST for your team's current outcome. Update it weekly with what the interviews surface.
4. Write down assumptions for each candidate solution. Identify the riskiest. Design a test.
5. Track your hit rate. % of shipped solutions that moved the hypothesized metric. Look at the trend over six months.

The compounding effect of these five practices over two years is dramatic. Teams that sustain them ship genuinely better products.

How this book fits with Cagan, Lin, Eyal, and the rest of the canon

INSPIRED gives you the worldview: empowered teams, the four risks, the product trio. Continuous Discovery Habits gives you the weekly practice that operationalizes the worldview. Read INSPIRED first, then this book.

Hooked and Lean UX are complementary toolkits — Hooked for retention mechanics, Lean UX for design integration. They live downstream of the discovery work this book describes.

The Lean Startup is the philosophical ancestor — Ries's experiment-driven worldview is the soil out of which Torres's specific practice grew. Read Ries for the why; read Torres for the how.

The Mom Test by Rob Fitzpatrick is the strongest complement on the interview craft specifically. Fitzpatrick's three rules ("talk about their life not your idea, ask about specifics in the past not generics in the future, talk less and listen more") map directly onto Torres's interviewing protocol.

For B2B specifically, pair Torres with Bob Moesta's Demand-Side Sales 101 and Ryan Singer's Shape Up. For consumer growth, pair with Brian Balfour's Reforge writing and Andrew Chen's The Cold Start Problem.

The passage to underline

If you underline one passage in the book, make it Torres's definition of continuous discovery:

"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."

Every word in that sentence is earning its place. Take "weekly" out and the practice collapses under organizational gravity. Take "by the team building the product" out and the insights stop flowing into decisions. Take "in pursuit of a desired outcome" out and the discovery becomes meandering ethnography. The sentence is the contract; if your practice does not match the sentence, it is not continuous discovery, whatever you are calling it.

Final word

Continuous discovery is the single most-leveraged habit a modern product team can establish. The compounding effect over years is the difference between teams that ship products their customers love and teams that ship features their roadmap demanded. The book that teaches the habit is Teresa Torres's Continuous Discovery Habits.

If you have read INSPIRED and want to know what to do on Monday morning to actually be a better PM, this is the book. It is short, dense, and practical. The practices it describes are hard to maintain over time and worth every gram of effort to maintain. Few books in the field deliver more practical value per page.

Read it. Then, more importantly, do what it says.

Annotated passages — what to underline

A few passages in the book deserve close reading and frequent re-visiting.

On the cost of skipping discovery. Torres makes the point repeatedly that the alternative to continuous discovery is not "no discovery" — it is ad hoc discovery, where the team occasionally talks to a customer when there is a fire, then ships from gut. Ad hoc discovery is worse than systematic discovery not because the data quality is lower (it usually is, but that is not the main point), but because the team never builds the muscle. Discovery is a craft that improves with weekly reps. A team that talks to 100 customers a year, spaced evenly, gets dramatically better at interviewing, synthesis, assumption testing, and prioritization than a team that talks to 100 customers in three crash research sprints. The compounding effect on the team's judgment is what continuous discovery is really about.

On the difference between solutions and opportunities. Torres is precise that the middle layer of the Opportunity Solution Tree must be framed in the customer's words and customer's frame, not in the team's frame. "Users abandon onboarding at step 4 because the value isn't clear" is a customer-framed opportunity. "Add a value proposition explainer to step 4" is a team-framed solution. The two get confused constantly. The discipline of forcing the opportunity into the customer's frame is what produces multiple competing solutions per opportunity — because once you see the opportunity clearly, several different solutions become obvious, and the team can compare them. Teams that skip this discipline collapse the OST into a feature backlog and lose the strategic leverage of comparing solution alternatives.

On weekly cadence as identity. A subtle but important point Torres makes is that the weekly cadence is not just a tactical choice — it becomes an identity for the team. A team that has talked to customers every week for two years thinks of itself as a customer-centric team. A team that talks to customers when it has time does not. The identity matters because identity drives the dozens of small daily decisions that no playbook can prescribe. The team that has internalized "we are the team that talks to customers" instinctively reaches for a customer conversation when faced with a hard question; the team that has not, instinctively reaches for a meeting with stakeholders.

Common critiques and Torres's responses

Critique: the practice sounds great in theory but is impossible to maintain at deadline-pressured companies. Torres's response is that the practice is designed for exactly those companies. The point of making discovery a weekly habit, rather than a research project, is that habits survive deadline pressure better than projects do. A research project gets cut when sprint planning is intense; a weekly recurring interview slot gets kept because it is on everyone's calendar like sprint planning itself. The practice is harder to start than to sustain; teams that get past the first quarter generally maintain the cadence indefinitely.

Critique: the OST is a fancy artifact that adds overhead without adding value. Partially fair if implemented badly. An OST that is built once and never updated is theater. An OST that is updated weekly with what interviews surface, referenced in every prioritization conversation, and visible on a wall the whole team passes daily is genuinely load-bearing. The difference is whether the team treats it as a working artifact or a deliverable.

Critique: the practice requires more PM bandwidth than most companies provide. True in some companies, less true than it seems in many. Torres argues that the PM time spent on discovery substitutes for time that would otherwise be spent on stakeholder management and rework — both of which decrease as the team's roadmap becomes evidence-based and stakeholders trust the team's judgment. The net time investment, after the first 90 days of building the practice, is often roughly neutral.

Critique: the model assumes B2C or PLG-style direct customer access; it does not transfer to enterprise B2B. Partially true. Enterprise B2B teams have to adapt the recruiting mechanism (account-executive-mediated rather than self-service Calendly) and accept lower interview volume (3-5 per week, not 10-15). The principles transfer; the logistics differ.

Critique: assumption tests can become their own kind of theater. True if the team tests the easy assumption rather than the riskiest one. Torres dedicates a chapter to this trap and is unsparing — testing the convenient assumption is worse than not testing, because it gives false confidence. The discipline of identifying the riskiest assumption requires the team to be honest about what scares them.

How specific companies have applied the model

Productboard. Productboard's own product team treats continuous discovery as their operating system. Customer interviews are scheduled weekly across the trio; the OST sits on every wall; the team's roadmap reviews always reference the tree. The discipline is partly why Productboard ships at the pace it does.

Atlassian. Atlassian's mission-based teams (each given a customer outcome to own) operate well in the continuous discovery mode. The mission framing combines naturally with the OST — the mission is the outcome at the top of the tree; the team's quarterly OST evolution shows progress against the mission.

Notion. Notion's PM team is known to run heavy continuous research, especially around emerging segments (creators, engineers, students). The OSTs for each segment are kept separate to prevent cross-segment confusion. The discipline has been a contributor to Notion's ability to expand into adjacent segments without losing the core product's coherence.

Many Y Combinator and seed-stage startups. YC's emphasis on "talk to users" maps directly onto continuous discovery; Paul Graham's famous "do things that don't scale" essay is in many ways the founder version of Torres's argument. Seed-stage teams adopt the practice naturally because the founders are doing the interviews themselves; the discipline becomes harder to maintain post-Series-A as PM functions get separated from founders.

Several enterprise B2B teams have adapted the practice with modifications — interview cadence at 3-5 per week rather than 10, account-executive-mediated recruiting, OSTs maintained at the team level but rolled up at the product line level. The adaptations work but require explicit leadership commitment because the natural rhythm of enterprise sales does not produce customer access without deliberate effort.

The five sections of the book to re-read

1. The chapter defining continuous discovery. The one-sentence definition is doing enormous work; re-reading anchors the practice.
2. The chapter on the Opportunity Solution Tree. The central artifact; the discipline of how to structure it deserves periodic re-grounding.
3. The chapter on story-based interviewing. The single most-leveraged skill the book teaches.
4. The chapter on assumption mapping and testing. The discipline that prevents wasted engineering quarters.
5. The chapter on the trio doing discovery together. The cultural shift that determines whether the practice scales or stays one PM's hobby.

How to use this book as a team training tool

The most effective format for spreading continuous discovery in a product organization is a peer book club paired with a pilot team.

The pattern that works: one team commits to running the full practice for 90 days (weekly interviews, OST, assumption testing). The PM leader sponsors the pilot and protects the team from competing demands. In parallel, the broader PM organization runs a weekly book club, one chapter per week, with the pilot team's PM presenting how they applied that chapter's content the previous week. After 90 days, the pilot team shares results (hit rate change, stakeholder confidence shift, team satisfaction). The next quarter, three more teams adopt the practice.

The rollout takes 12-18 months for a mid-sized product org and requires sustained leadership commitment. The compounding effect after two years is dramatic — entire organizations transform their hit rate, their stakeholder trust, and their ability to ship products that move metrics.

The broader research and design tradition

Torres's work sits in a long tradition of design research, ethnography, and product discovery. PMs who want to deepen their craft should read alongside:

• The Mom Test by Rob Fitzpatrick — the most precise short book on customer interviewing. Pair directly with Torres's interviewing chapters.
• Interviewing Users by Steve Portigal — the textbook on the research-interview craft.
• Talking to Humans by Giff Constable — a tight founder-focused complement to Torres.
• The Lean Startup by Eric Ries — the philosophical ancestor of the experiment-driven mindset Torres operationalizes.
• Designing for Behavior Change by Stephen Wendel — for teams whose discovery surfaces behavioral interventions.

Read alongside Cagan's INSPIRED, these form the foundational library for serious product discovery practice.

A closing thought

The hardest part of continuous discovery is not the techniques. The techniques are simple — schedule interviews, build a tree, test assumptions. The hard part is the discipline of doing it week after week when the team is busy, when launches are looming, when stakeholders are asking for features, when discovery feels slow.

Torres's gift to the field is that she did not pretend the discipline was easy. She wrote a book that is as much about overcoming the organizational gravity that pulls teams away from discovery as it is about the techniques themselves. The chapter on common failure modes is, in some ways, the most valuable in the book.

For PMs reading this in 2026, the practice has compounded another four years of refinement since the book was published. The OST is now standard vocabulary. Continuous interviewing is the default expectation at most product-led companies. Assumption testing has been incorporated into the everyday flow of mature product teams. The book's influence on the field has been deep and lasting.

If you are starting from zero with discovery, the right first step is to read this book and schedule three customer conversations for next week. The rest grows from there. The compounding effect over years is the difference between teams that ship features and teams that ship products customers actually love. Torres's book is the field's clearest map to the second kind of team.