Continuous Discovery Habits

The What and Why of Continuous Discovery

Continuous discovery is a minimum habit: the people who decide what to build talk to customers, in some small way, every single week, all year, not in one concentrated phase before a launch. Most teams still treat discovery as a project with a start and an end, research the space, hand a report to the roadmap, then build for months without checking back in.

That model breaks because customer understanding decays. A team that interviewed ten users in January is working from a picture that's stale by June, and by then the backlog reflects that January snapshot, not what's actually true now.

• Weekly cadence, not a research sprint: at least one meaningful customer interaction per week, every week.
• Owned by the people building the product: the trio, not a separate research team producing reports for others to act on.
• Structured and sustainable: consistent enough to compound, not a burst of energy that fades after the first few weeks.

Torres frames the goal plainly: build products that create customer value and business value at the same time, continuously, rather than betting a big release on a single upfront guess.

Weekly customer contact is a commitment, not a preference. A PM deciding whether to protect thirty minutes a week for a customer call, against a dozen other asks competing for that slot, is making the exact tradeoff worth making every time, because the cost of stale customer understanding compounds silently until a roadmap is built on assumptions nobody has checked in months.

The habit doesn't require an elaborate research operation. Torres rejects the idea that only trained researchers should talk to customers; a fifteen-minute conversation squeezed into a Tuesday, run by whoever is building the feature, counts, as long as it happens every week rather than only when someone finally schedules a formal study.

The habit assumes customers are reasonably reachable on a weekly cadence, which is easier for a consumer product than for an enterprise seller gated by sales, legal, or a regulated industry. Torres's fix is enlisting sales and customer success as a standing pipeline of contacts, not treating limited access as a reason to abandon the habit.

A Common Framework for Continuous Discovery

The opportunity solution tree gives continuous discovery a shape. At the top sits one desired outcome, a measurable change in customer or business behavior. Below it branch the opportunities, real customer needs and pain points surfaced through interviews. Below each opportunity branch the candidate solutions competing to address it. Below each solution sit the assumption tests that check whether it will actually work before it gets built.

The core move: everything in the tree has to trace upward. A solution that doesn't sit under a real opportunity, and an opportunity that doesn't sit under the outcome, doesn't belong on the tree, no matter how promising it looks in isolation.

• Outcome: what change are we actually trying to cause.
• Opportunities: the needs and problems, found through real conversations, that stand between customers and that outcome.
• Solutions: the ideas competing to resolve a given opportunity, several at once, not one favorite fast-tracked to build.
• Assumption tests: the cheap experiments that check a solution's riskiest bets before real engineering time is spent.

The tree replaces two bad habits at once: a flat backlog where every idea looks equally plausible, and a single-solution mindset where the first idea pitched becomes the only idea considered. Comparing several branches side by side is what actually produces better decisions, not more analysis of one option in isolation.

For a PM, the tree is the artifact that finally lets a roadmap conversation start from "which opportunity is worth solving" instead of "whose feature request do we do next." A tree redrawn every few weeks, as new interviews add or prune opportunities, keeps that conversation grounded in what customers actually said this month.

A tree drawn once and forgotten becomes exactly the stale artifact it was meant to replace. Its value comes specifically from being redrawn as each week's interviews confirm, contradict, or add a branch, which is why Torres frames it as a living map, not a one-time strategy document produced for a single planning cycle.

Focusing on Outcomes Over Outputs

Part Two turns the framework from Chapter 2 into practice, starting with the input that sits at the top of every tree: the outcome itself. Get the outcome wrong and everything built underneath it, however well executed, is aimed at the wrong target.

Torres splits outcomes into three tiers. Business outcomes, revenue, retention, sit furthest from a single team's control and are usually owned above the product level. Product outcomes are metrics a specific team can meaningfully move, like activation rate, and are the right altitude for most trios to own. Traction metrics track usage of one specific feature and work best for junior teams building confidence, or for optimizing something already proven.

• Business outcomes: too broad and too lagging for one team to steer week to week.
• Product outcomes: the right altitude, specific enough to test against, big enough to require real discovery.
• Traction metrics: fine for narrow feature-level optimization, too narrow to organize a whole discovery practice.

An outcome has to be negotiated, not handed down. A team accepts leadership's ambition, then argues for the resources and risk tolerance that ambition actually requires, rather than silently absorbing an unrealistic target and hoping outputs will eventually catch up.

Torres names the recurring failure modes: chasing too many outcomes at once, switching outcomes every quarter before any of them mature, letting each function set its own outcome instead of the whole trio owning one, and quietly reverting to counting shipped features once the pressure to show progress builds.

The practical test for a PM: can you state, in one sentence, the specific behavior change your team is trying to cause this quarter, in a way a customer or the business would actually feel? If the honest answer is a list of features instead, the outcome hasn't actually been set yet, it's just been assumed.

Visualizing What You Know

Before the trio interviews anyone new, Torres has them draw an experience map: the customer journey around the outcome, as the team currently understands it, entirely from existing knowledge. The point isn't to be right, it's to expose exactly where the gaps are before spending a single new conversation confirming things everyone already agrees on.

Building it well means resisting three temptations. Scope creep, mapping a journey so broad it stops connecting to the actual outcome. Wordiness, describing steps in dense sentences instead of simple visual nodes a group can scan in seconds. And groupthink, one person mapping out loud while the rest of the trio nods along instead of surfacing their own, possibly different, mental model.

• Each trio member maps independently first, alone, before comparing notes.
• Nodes are distinct moments in the journey; links are the connections between them; context is the thoughts and feelings attached to each moment.
• Comparing three independent maps surfaces disagreement fast, exactly the disagreement a single shared map would have silently papered over.

The map isn't precious. It gets redrawn as interviews correct it, and its real value is diagnostic: the places where the trio's three independent maps disagree most are the places worth interviewing about first, because that's where the team's actual knowledge is thinnest.

A PM running this exercise learns something interviews alone wouldn't show: where the team's shared story about the customer is actually three different stories wearing one label. Surfacing that disagreement before interviewing saves a team from confirming three different assumptions with the same three interviews.

A useful experience map for a subscription product, for example, might run from realizing a need exists, through comparing options, to a first month of use, to a renewal decision, with each node annotated by what the customer is likely thinking and feeling at that moment, not just what they're doing.

Continuous Interviewing

The keystone habit gets its own chapter: at least one interview per week, every week, indefinitely, with everyone on the trio present to interpret it live rather than reading a summary later. Torres calls this the single highest-leverage habit in the whole book, because everything downstream, the tree, the assumptions, the solutions, is only as good as what these interviews actually surface.

The technique that makes the difference is story-based interviewing. Instead of asking what a customer wants or would use, Torres has interviewers dig for a specific past instance: "tell me about the last time you tried to do X." A real story, tied to one moment, is far more reliable than an opinion about hypothetical future behavior, which customers are notoriously bad at predicting for themselves.

• Explicitly invite a full story, not a one-line answer: "walk me through what happened."
• Use temporal prompts to keep the story moving: "what did you do next," "what happened after that."
• Ask about the supporting cast and the obstacles, not just the customer's own actions.
• When a customer requests a specific feature, ask what that feature would actually do for them, which usually reveals the real underlying need hiding behind the request.

Every interview gets distilled into an interview snapshot rather than a full transcript: a photo, a vivid quote, a few facts, and two short lists, opportunities (needs and pain points, phrased as problems, never as solutions) and insights (interesting behavior that doesn't map to a known need yet).

Weekly interviewing only survives contact with a busy quarter if it's genuinely load-bearing, not optional polish. A PM who treats the weekly interview as the first thing cut when a sprint gets busy has, in practice, decided the tree can run on stale information, which is exactly the failure mode Chapter 1 warned about.

Mapping the Opportunity Space

Interview snapshots pile up fast, and without structure they turn into an undifferentiated list nobody can act on. This chapter is the discipline for organizing them into the opportunity branch of the tree: a hierarchy of customer needs, general at the top, increasingly specific as you go down, each one framed as a problem the customer has, never as a solution in disguise.

Torres gives concrete rules for a healthy tree. Sibling opportunities under the same parent should be independent of each other, not just different phrasings of the same need. A parent opportunity should genuinely be addressed by solving any one of its children, not require all of them at once. Opportunities get pruned when they're specific to a single customer, or when solving them plainly wouldn't move the outcome at the top of the tree.

• Frame every opportunity as a customer need, never as a feature: "I can't tell if this payment went through" is an opportunity; "add a confirmation screen" is a solution wearing a disguise.
• Avoid vertical chains, one opportunity with exactly one child with exactly one child, which is really just one opportunity described three times at decreasing levels of vagueness.
• Watch for a single opportunity claimed under two different parents; that usually means the tree's categories are drawn wrong, not that the opportunity is unusually important.
• Prune feelings framed as opportunities ("customers feel confused") without the underlying need attached ("customers can't tell whether their order shipped").

A tree that's never pruned becomes worse than no tree: a six-month-old structure nobody trusts enough to actually use for prioritization. The habit that keeps it honest is small and boring, a few minutes after every interview updating the tree, not a quarterly overhaul.

For a PM, the discipline here is the same one that makes any prioritization defensible later: an opportunity that can't be traced to a specific interview, in a specific customer's words, is exactly the kind of opportunity that gets challenged and can't be backed up in a roadmap review.

Prioritizing Opportunities, Not Solutions

Most teams prioritize a list of proposed features. Torres argues the far more important, and far more skipped, decision is choosing which opportunity to pursue in the first place, before any solution is on the table at all, because a mediocre solution to the right opportunity usually beats a brilliant solution to the wrong one.

There's no formula, deliberately. Torres lays out four factors a trio weighs against each other in a genuinely messy, compare-and-contrast judgment call, not a scored spreadsheet that manufactures false precision.

• Opportunity sizing: how many customers does this affect, and how often does it come up for them.
• Market factors: is this table stakes customers now expect everywhere, or a real differentiator if you get it right.
• Company factors: does this play to strengths your team or business already has, or fight against them.
• Customer factors: how much does this specific opportunity actually matter to the customers who raised it, relative to everything else they mentioned.

Torres pushes teams toward reversible choices where possible, favoring what she frames as a "two-way door": commit to an opportunity you can act on quickly and back out of cheaply if the assumption tests in later chapters prove it wrong, rather than a one-way commitment that's expensive to reverse once resources are sunk into it.

The habit this replaces is dangerous precisely because it feels rigorous: scoring a list of pre-baked solutions on effort and impact looks like prioritization, but it silently assumes the opportunity underneath each solution was already the right one to chase, a step this chapter insists has to happen first, deliberately, and separately.

A team debating whether to build a full loyalty program versus test a simple discount code for a month is choosing between a one-way and a two-way door in exactly this sense, and the discount code, cheap to reverse, is usually the right opening move even if the loyalty program eventually proves necessary.

Supercharged Ideation

Part Two's second half shifts from finding the right opportunity to generating strong solutions for it, and starts with how ideation actually works versus how most teams run it. Torres draws on creativity research: good ideation needs fluency, raw volume of ideas, flexibility, genuinely different categories of idea, and originality, and the most original ideas in any session tend to show up only after the obvious ones are exhausted.

Group brainstorming, run the usual way, actively suppresses all three. People wait their turn instead of thinking, production blocking, and quietly anchor to whatever idea the most senior voice in the room offered first, downward norm setting, which is why unstructured brainstorms reliably converge on the safest, least original ideas in the room.

• Generate independently first, silently and separately, before anyone shares out loud, so no one's idea list is contaminated by someone else's opening pitch.
• Deliberately look outside the immediate category: what would an analogous product, in a totally different industry, do here.
• Consider extreme users, not just the average customer, since their exaggerated needs often expose an idea the average case would never surface.
• Anchor every idea explicitly back to the target opportunity from the tree, so ideation stays generative without drifting into solving a different problem entirely.
• Use dot voting, a fast, low-ego way to narrow a long list down to two or three genuinely promising candidates worth developing further.

The PM-relevant shift here is procedural, not just creative: running a five-minute silent brainstorm before a group discussion, instead of jumping straight to open discussion, is a small process change with an outsized effect on how many genuinely different ideas actually make it onto the tree.

Torres recommends generating at least three genuinely different solutions per opportunity before committing engineering time to any one of them, since a trio that stops at its first workable idea rarely discovers whether a cheaper or more effective alternative was sitting one round of ideation away.

Identifying Hidden Assumptions

Every solution idea is really a bet on several things being true at once, and most of them are invisible until you deliberately go looking. Torres has the trio storyboard the solution as if it already existed: walk through it step by step, actor by actor, and at each step ask what has to be true for that step to actually work.

Each assumption gets sorted into one of several categories, and naming the category tells you what kind of test it needs.

• Desirability: will customers actually want this, once it exists.
• Feasibility: can the team actually build it with the time, skill, and technology available.
• Viability: does it make the business money, or otherwise justify its cost.
• Usability: can customers figure out how to use it without being told.
• Ethical implications: could this cause real harm, to the customer or to someone else, even if it tests well on every other axis.

One technique does a lot of work here: the pre-mortem, phrased as a certainty rather than a hypothetical. Not "might this fail," but "it's six months later and this failed, why." Framing it as already-true short-circuits the instinct to defend a favorite idea and surfaces assumptions people would otherwise talk themselves out of naming.

Not every assumption deserves a test. The chapter's real payoff is finding the "leap of faith" assumption, the one thing that, if false, sinks the whole idea, so limited testing time goes toward the assumption that actually matters instead of the one that's easiest to check.

The ethical category is the one most teams skip, because it's the hardest to score and the easiest to assume away. A PM who never asks it is the same PM whose team eventually ships something that tests well on desirability while quietly exploiting a customer's inattention, which is a failure this framework exists specifically to catch before it ships.

Testing Assumptions, Not Ideas

Once the riskiest assumption is named, the chapter's central discipline is testing that one assumption cheaply, not building a version of the whole idea to see if it works. A purpose-built test simulates just enough of the experience that a real person can behave for or against the assumption, without the cost of actually building the feature behind it.

Torres pushes for testing several competing ideas' riskiest assumptions in parallel rather than committing engineering time to one favorite early, and for defining success criteria before running the test, not after seeing the results: "at least three of ten people will attempt to do X," decided in advance, so results can't be quietly reinterpreted to match whatever answer the team already wanted.

• Fake-door tests, smoke tests, concierge experiments, and unmoderated usability tests all substitute for a real build at a fraction of the cost.
• One-question surveys can validate a narrow assumption fast without the overhead of a full research study.
• Start with the audience most likely to say yes, not a representative sample, because the point at this stage is finding an early signal, not statistical proof.
• Expect false positives and false negatives; a cheap test is a filter, not an oracle, and its job is narrowing the field, not delivering certainty.

Torres is blunt about the purpose: "you're not discovering new universal truths, you're mitigating risk," which reframes the whole exercise away from research-for-its-own-sake and toward a specific, bounded decision about whether to keep investing in this particular idea.

The PM lesson generalizes past this book's context: any expensive, hard-to-reverse decision, not just a product build, usually has one dominant risk hiding inside it. Naming that risk explicitly, and designing the cheapest possible test aimed only at it, is a habit worth carrying into pricing decisions, hiring calls, or a go-to-market bet just as much as a feature build.

Measuring Impact

An assumption test that passes still isn't proof the solution will move the outcome at the top of the tree; that connection has to be measured directly, and Torres treats this as its own skill, distinct from the testing covered in the previous chapter.

One practical question does a lot of the work: does a single customer performing this action many times count the same as many different customers each performing it once? If yes, count actions. If no, count people. Getting this backwards is a common way teams celebrate a metric that moved for the wrong reason, a handful of power users driving the whole number while adoption among everyone else stayed flat.

• When the outcome is genuinely hard to instrument directly, use a proxy: a follow-up email asking what happened, a small pilot partnership willing to share real numbers, a support-ticket count as a stand-in for a friction metric.
• An early, narrow solution doesn't need to measure the full scope of the outcome on day one; it needs a believable, if partial, signal that it's moving in the right direction.
• Impact measurement is a discovery activity in its own right, not an afterthought handed to analytics once the feature ships.

The quiet risk here is Goodhart's: an outcome metric, once it becomes the thing a team is measured on, can start moving for reasons that have nothing to do with genuine customer value, whether through gaming, novelty effects, or a metric that was simply a poor proxy for the outcome all along. A PM should treat a moving metric as a hypothesis to interrogate, not a result to immediately celebrate.

A concrete instance: a team improving onboarding might not yet be able to measure long-term retention directly, so it tracks a nearer-term proxy, whether a new user completes a specific setup step within the first session, treating that as a believable early signal while the longer-term outcome data accumulates.

Managing the Cycles

This chapter is where every earlier habit runs together as one repeating loop, illustrated through real product teams cycling through opportunities, solutions, and assumption tests again and again, not as a tidy one-pass process but as a genuinely iterative one with dead ends along the way.

Torres shows teams pivoting fast off an opportunity once early tests reveal it isn't viable, deferring a promising but currently infeasible opportunity rather than forcing it, and converging on a hybrid solution only after two competing ideas each partially, but not fully, held up under testing. Impact, in these examples, accumulates through a series of small validated improvements more often than through one decisive breakthrough.

• Overcommitting: sinking real engineering time into an opportunity before its riskiest assumption has been tested at all.
• Avoiding the hard opportunity: cycling endlessly through easy, low-stakes opportunities while skipping the ambiguous one that would actually move the outcome most.
• Shallow learning: drawing a firm conclusion from one small test result instead of treating it as one data point among several needed.
• Quitting early: abandoning an opportunity after one weak result, before enough small iterations have had the chance to accumulate into real impact.

Managing the cycle well means holding two things in tension: moving fast enough that a bad bet gets killed within weeks, not quarters, while also giving a genuinely promising but imperfect early result enough further iteration to actually prove itself before writing it off.

A PM reading a stalled roadmap review should ask which of these four anti-patterns is actually at play, since "we're not seeing traction" often disguises one of them specifically, and the fix looks different depending on which one it is.

One example Torres returns to: a team chasing an activation opportunity discovers midway that the feasible version of its favorite solution only partially addresses it, so rather than declaring failure it layers a second, smaller solution on top, and it's the combination, not either piece alone, that finally moves the outcome.

Show Your Work

All of this discovery activity is invisible to stakeholders unless the trio deliberately makes it visible, and Torres treats that visibility as a discipline in its own right, not an afterthought squeezed into a slide before a launch. The sequence matters as much as the content.

• Start by aligning stakeholders on the outcome at the top of the tree, before showing anything else, so later disagreements have a shared reference point to resolve against.
• Share the opportunity space next, and invite stakeholders to point out gaps, rather than presenting it as a finished, unchallengeable map.
• Share how opportunities got prioritized, and why, before any solution enters the conversation.
• Only then bring in interview snapshots for the specific opportunity being pursued, so a stakeholder hears the customer's own words before hearing the team's proposed fix.
• Share the generated solutions, the storyboarded assumptions, and the test results last, as the natural conclusion of everything shown before it, not as a conclusion presented cold.

The underlying reframe: "we are inviting our stakeholders along for the journey with us," not "presenting our conclusion, this is the roadmap." A stakeholder who has watched the reasoning unfold in order is far less likely to fight the destination, because they arrived at roughly the same place the trio did.

The anti-patterns are familiar to any PM who has sat through a bad roadmap review: telling instead of showing, burying the actual decision in slide after slide of detail, arguing why a stakeholder's pet idea won't work instead of showing the opportunity map it doesn't trace back to, and re-litigating ideology instead of pointing at a specific decision on the tree. Showing the tree itself usually settles an argument faster than any amount of persuasion.

A trio that skips straight to sharing solutions, without walking stakeholders through the opportunity map and prioritization first, routinely gets the same objection Torres warns against: a stakeholder challenging the solution itself, when the real disagreement was actually about which opportunity deserved attention in the first place.

Start Small, and Iterate

Part Three closes the book by returning to a stark point of realism: no team, including Torres's own case studies, adopts all thirteen preceding habits at once. The keystone habit, the one to protect above all others if a team can only sustain one, is the weekly customer touchpoint from Chapter 5; everything else builds outward from that single, non-negotiable anchor.

For teams that don't control their own outcome yet, and are simply handed a specific solution to build, Torres's advice is to work backward: storyboard the given solution, identify its hidden assumptions, and test the riskiest one, even without a full opportunity tree in place. Partial adoption of the framework still beats none.

• Resist the trap of "this would never work here" as a reason not to start; most objections turn out to be about scope, not feasibility, once actually tried at a small scale.
• Don't wait for permission to talk to customers weekly; in most organizations that's already within an individual contributor's own control, not a decision requiring executive sign-off.
• Add habits one at a time, in whatever order the team's current biggest gap suggests, rather than attempting a wholesale process overhaul in one quarter.

The chapter's real message for a PM stuck at the start: pick the single habit most likely to expose your team's biggest blind spot right now, run it for a month before adding a second one, and treat the other thirteen chapters as a reference to return to as each specific problem actually shows up, not a checklist to clear in order.

Torres is explicit that a team assigned a fixed roadmap of features by leadership isn't exempt from this practice, it just enters the loop one step later, treating each assigned feature as a solution to reverse-engineer an opportunity for, rather than waiting for permission to run the full tree from scratch.

What's Next?

The book closes by naming continuous discovery for what it actually is: a multi-year practice, not a technique mastered by finishing the book. Torres is candid that even experienced teams keep discovering new failure modes in their own opportunity trees years into practicing this.

The chapter's practical function is pointing toward continued practice, further reading, and community, rather than introducing new material of its own; it's a genuinely short, transitional close, and Torres treats it that way rather than padding it with new content.

The honest note it ends on matters more than its length: expect early attempts at any of these habits to feel clumsy, expect a tree to look messy before it looks useful, and expect the payoff to show up in the quality of decisions made six months from now, not in the first week a team tries this.

For a PM finishing the book, the takeaway isn't a new tool, it's a permission slip: starting badly and iterating on the practice itself is exactly what continuous discovery asks of the product, applied to how the team runs discovery in the first place.

The Entire Book in One Framework

Every habit in this book attaches to one structure: the opportunity solution tree, kept alive by a trio that talks to customers every week. The tree gives the practice its shape, weekly interviewing gives it its supply of real information, and assumption testing gives it a cheap way to fail fast before engineering time is spent on the wrong branch.

Read as a system rather than a list of thirteen separate techniques, the book argues that good products aren't the output of one big research phase followed by months of blind building. They're the output of a visible, constantly-updated trail from one outcome down through opportunities, solutions, and the assumptions each solution survives, redrawn every week as new customer conversations correct it.

A roadmap tells stakeholders what you've already decided. An opportunity solution tree shows them how you're deciding, and invites them to catch what you missed before it ships.

10 Most Important Takeaways

• Talk to customers at least once a week, every week, for as long as you're building the product; this single habit is the foundation everything else rests on.
• Build discovery with a trio, a PM, a designer, and an engineer, deciding together, not one function researching and handing conclusions to the others.
• Anchor the team to a measurable outcome, not a list of features to ship, and negotiate that outcome explicitly with leadership rather than inheriting it silently.
• Draw an opportunity solution tree and keep it current; anything on your roadmap that doesn't trace back to a real branch on that tree doesn't belong there yet.
• Interview for specific past stories, never for opinions about hypothetical future behavior; a real story is more reliable than a guess.
• Capture each interview as a short snapshot built for comparison across dozens of conversations, not a transcript nobody will reread.
• Generate several competing solutions per opportunity, independently first, before group discussion narrows the field.
• Name the single riskiest assumption behind an idea, across desirability, feasibility, viability, usability, and ethics, and test that one thing cheaply before building anything real.
• Measure whether a shipped solution actually moved the outcome, watching for a metric moving for the wrong reason, not just moving.
• Show stakeholders the reasoning in order, outcome, opportunities, prioritization, evidence, solution, so they arrive at the decision with you instead of being asked to accept it cold.

The single deepest idea in the book, worth remembering long after the specific techniques fade: a product organization's real skill isn't picking the right feature, it's building a repeatable, visible habit of finding out what's actually true about customers often enough that being wrong gets caught in days, not quarters.