Continuous Discovery Habits: The Weekly Interview System
Continuous discovery is the practice of engaging customers weekly — as a product trio — to steadily inform product decisions, rather than running one big research project each quarter. In Teresa Torres's framework, those touchpoints are organized by an opportunity solution tree that connects a desired outcome to opportunities, solutions, and small assumption tests.
Quick Answer: Continuous discovery means weekly customer touchpoints run by the product trio — a product manager, a designer, and an engineer — structured by an opportunity solution tree. You map customer opportunities to a desired outcome, then test the riskiest assumptions behind each solution instead of shipping and hoping.
If you came up through product management before starting your own company, you already know the failure mode: a quarterly research readout that lands three weeks after the decisions it was supposed to inform. Torres's Continuous Discovery Habits is the antidote. It reframes discovery as a set of small, repeated habits — not an event — so that customer evidence arrives at the same cadence as the decisions you make. This guide walks through the whole system, one habit at a time.
Why Weekly Customer Touchpoints Beat Occasional Research Projects
Weekly touchpoints win because discovery is a continuous decision-making problem, not a one-time information-gathering event. Torres defines continuous discovery as, at minimum, weekly touchpoints with customers by the team building the product, conducting small research activities in pursuit of a desired outcome.
Read that definition closely, because every clause is doing work. The cadence is weekly — frequent enough that no decision goes more than a few days without fresh input. The people are the team building the product, not a separate research group that hands findings across a wall. And the activities are small — a couple of interviews, one assumption test — rather than a months-long study.
Occasional research projects fail founders in a predictable way. You commission a big study, wait, receive a polished deck, and by then the roadmap has moved. Worse, the insights are owned by whoever ran the study, so the people making daily trade-offs never internalize them.
Continuous discovery collapses that gap. Because the trio does the research itself, the evidence and the decision live in the same heads. You are never acting on a stale snapshot; you are acting on last week's conversation. For a broader foundation on structuring these conversations, our complete guide to customer research for founders pairs well with the habits below.
Who runs discovery: the product trio
Discovery is the job of the product trio — a product manager, a designer, and a software engineer who make discovery decisions together. Torres is deliberate about this. The three roles bring desirability, usability, and feasibility judgment into the same room, so trade-offs get made once, with all three perspectives present, instead of being relitigated after a spec crosses a wall.
For a founding team, the trio might be two people wearing three hats — or even one. That is fine. What matters is that all three perspectives are represented when you choose which opportunity to pursue and which solution to test, not that three separate people attend every single call.
The shift is less about doing more research and more about doing smaller research, more often, closer to the decision.
The Continuous Discovery System: Core Habits at a Glance
The system is a set of interlocking habits, not a single technique — each one replaces a heavier, slower ritual most teams inherited by default. No single habit carries the framework; they reinforce each other, which is why adopting one in isolation tends to disappoint.
The table below maps each core habit to the older practice it displaces and the reason the swap matters. It is qualitative on purpose — this is about behavior change, not benchmarks.
| Continuous discovery habit | What it replaces | Why the swap matters |
|---|---|---|
| Weekly customer interviews | Quarterly research sprints | Keeps evidence fresh and owned by the decision-makers |
| Opportunity solution tree | An undifferentiated backlog of feature ideas | Makes the team's reasoning visible and outcome-anchored |
| Assumption testing | Big-bang launches and end-of-project usability tests | Surfaces the riskiest unknowns before you build |
| Outcome focus | A roadmap measured in features shipped | Grants autonomy to find the best solution, not just build the planned one |
| Product trio collaboration | A solo PM writing specs and handing them off | Puts engineering and design judgment into discovery, not just delivery |
The takeaway: continuous discovery is a mindset expressed through habits. You can recognize a team that has adopted it not by a document they produce, but by what they do every week. The rest of this guide unpacks the two habits that do the heaviest lifting — the opportunity solution tree and continuous interviewing — plus the assumption testing that keeps them honest.
The Opportunity Solution Tree: Outcome, Opportunities, Solutions, Experiments
The opportunity solution tree is a visual model with four layers that connect a business goal to the everyday work of discovery. Reading top to bottom: a desired outcome at the root, opportunities branching beneath it, solutions under each opportunity, and assumption tests under each solution.
Its job is to make your thinking visible. When the whole trio can see how a specific experiment ladders up to a customer need and, ultimately, to the outcome, prioritization stops being a matter of who argues hardest.
What each layer of the tree represents
Each layer answers a different question, and keeping them distinct is the discipline that makes the tree work. Founders most often stumble at the opportunity layer by smuggling solutions into it.
| Layer | What it represents | How to phrase it |
|---|---|---|
| Desired outcome | The product outcome the trio is asked to move | A measure of customer behavior, e.g. "more users complete setup" |
| Opportunity | A customer need, pain point, or desire | In the customer's words, e.g. "I can't tell if it's working" |
| Solution | A way to address a specific opportunity | A concrete idea, e.g. "add a progress indicator" |
| Assumption test | A quick experiment probing one solution | A small simulation, e.g. "fake the indicator, watch behavior" |
Opportunities are needs, not features. "I never know whether my changes saved" is an opportunity. "Add an autosave badge" is a solution. If your opportunity already names a feature, you have quietly skipped the most valuable step — the space of possible solutions to a real need.
You do not chase every branch at once. Torres's approach is to map many opportunities from your interviews, then use structured techniques — assessing how much of the outcome an opportunity could move, how many customers it touches, how often — to select a single target opportunity to focus on. Only then do you generate and compare solutions within that branch.
The tree is never finished. It grows every week as new interviews surface new opportunities, and it prunes as you resolve or de-prioritize branches. That living quality is the whole point. A diagram drawn once in a workshop and never revisited is not an opportunity solution tree — it is a snapshot of a single afternoon's thinking.
For a concrete build-out of a real tree, see this opportunity solution tree example walkthrough, which shows the layers filled in for an actual product.
Continuous Interviewing and Automating Interview Recruiting
Interview weekly, and interview for stories about specific past behavior — not opinions or predictions about the future. This is the single most important interviewing shift in the book, because people are unreliable narrators the moment they generalize.
Ask about the last time something happened. "Tell me about the most recent time you tried to share a report with your team." A story like that surfaces the real workflow, the real friction, and the real workaround — the raw material from which you mine opportunities for the tree.
Avoid the questions that feel like interviews but produce fiction. "Would you use a feature that…?" invites a polite yes. "How often do you usually…?" invites a tidy average that no real Tuesday ever matched.
The contrast is worth keeping in front of you while you draft an interview guide:
| Ask this (story-based) | Avoid this (generalization or hypothetical) |
|---|---|
| "Walk me through the last time you did X." | "How do you usually do X?" |
| "What happened right before that?" | "Would you use a tool that did X?" |
| "Tell me about a time X went wrong." | "Do you think X is important?" |
The takeaway: specific past behavior is evidence; generalized opinion is guesswork wearing a lab coat.
Capturing each interview in a snapshot
Synthesize every conversation into a one-page interview snapshot while it is fresh. It captures who you spoke with, the key story, and the opportunities you heard — a shareable artifact that lets the whole trio learn from an interview none of them attended in full, and it feeds new opportunities onto the tree.
The snapshot also fights recency bias. Without it, the loudest or most recent conversation quietly dominates the team's memory. With a stack of comparable snapshots, patterns across many customers become visible, instead of one vivid anecdote standing in for everyone.
Automating recruiting so the habit survives
The reason teams fall off the weekly cadence is almost never interviewing itself — it is recruiting. Chasing down a participant every week is exhausting, so the habit quietly dies.
Automate it. Torres recommends building a recruiting mechanism that runs without you — for example, an in-product prompt that invites qualifying users to book time, feeding a steady pipeline. When the next interview is always already scheduled, weekly becomes sustainable. Our guide to setting a weekly customer interview cadence goes deeper on making the rhythm stick.
Assumption Mapping and Assumption Testing
Do not test whole solutions — decompose each into its underlying assumptions and test the riskiest ones first. A solution is a bundle of bets, and most of those bets are safe. Testing the bundle wastes effort on the parts that were never in doubt.
Start by generating several solutions for your target opportunity, not just the first idea. Then, for each promising one, brainstorm the assumptions that must hold true for it to work. Torres organizes these into distinct categories so a trio doesn't over-index on one kind of risk.
| Assumption type | The question it asks |
|---|---|
| Desirability | Do customers actually want this? |
| Viability | Does this work for our business? |
| Feasibility | Can we build and support it? |
| Usability | Can people figure out how to use it? |
| Ethical | Could this cause harm we're not seeing? |
The takeaway: naming assumptions by category keeps you from testing only whether people like an idea while ignoring whether you could ever ship or sustain it.
Next, map assumptions to find the leap-of-faith ones. Plot each assumption by how important it is and how much evidence you already have. The dangerous quadrant is important-but-unknown — high stakes, low evidence. Those are your leap-of-faith assumptions, and they earn a test.
An assumption test is a small, fast simulation that probes one assumption without building the real thing. You are not shipping a feature to see what happens; you are staging the narrowest possible experiment to gather evidence on a single risky belief. This is the same evidence-before-building discipline behind any rigorous complete guide to startup idea validation — here, applied continuously to individual features rather than once to the whole idea.
When several solutions compete, run tests against the assumptions that most distinguish them, and compare the results — but only among solutions that serve the same opportunity, never across different branches of the tree.
Outcomes Over Outputs: Measuring Behavior, Not Features Shipped
An outcome is a measure of customer behavior that drives business results; an output is a feature you ship. The whole framework hangs on preferring the former, because it is the only thing that grants a team the autonomy to discover the right solution.
When leadership hands a team an output — "build the referral widget" — the team's job is reduced to construction. When leadership hands a team an outcome — "increase the share of users who invite a teammate" — the team owns the problem and can bring discovery to bear on it.
Product outcomes are the layer you can actually influence. A product outcome is a leading indicator of a business outcome: it sits close enough to your work that a good week of discovery can move it, yet it still ladders up to revenue, retention, or growth. That product outcome is exactly what sits at the root of your opportunity solution tree.
This is what keeps continuous discovery from becoming a feature factory. Every opportunity you explore, every solution you weigh, every assumption you test traces back to a single outcome — so the question is never merely "did we ship it?" but "did customer behavior change?"
It also changes how you set direction. Instead of negotiating a list of features to build this quarter, the trio agrees on one outcome to move and lets the tree, the weekly interviews, and the assumption tests reveal which features earn a place. The roadmap becomes a hypothesis you keep testing, not a contract you're obligated to deliver.
Common Mistakes When Adopting Continuous Discovery Habits
The most common failure is adopting the artifacts without the habits — drawing a tree, running a few interviews, and calling it continuous discovery while the underlying behavior stays the same. Watch for these specific anti-patterns:
- Framing opportunities as solutions. If your tree's opportunity layer is full of feature names, you've collapsed the space of possibilities before exploring it.
- Asking hypothetical or opinion questions. "Would you use this?" and "How important is X?" generate agreeable fiction. Anchor every question to a specific past event.
- Treating discovery as a project. A one-off research sprint every quarter is exactly what the weekly cadence exists to replace.
- Testing whole solutions instead of assumptions. Building the feature to see if it works is the slowest, most expensive test available. Isolate the risky assumption first.
- Doing discovery solo. When one person interviews and then reports back, engineering and design judgment never enters the room where opportunities are chosen. The trio decides together.
- Confusing outputs with outcomes. A roadmap of shipped features feels like progress but says nothing about whether customer behavior moved.
- Comparing solutions across different opportunities. Solutions are only comparable when they serve the same customer need — comparing across branches is comparing apples to outcomes.
Most of these share a root cause: reaching for the visible artifact while skipping the habit that makes it meaningful. The tree is only as good as the interviews feeding it, and the interviews are only as good as the stories you actually collect.
Key Takeaways
- Continuous discovery is weekly, not quarterly. The defining habit is at least weekly customer touchpoints, run by the team building the product, in pursuit of a specific desired outcome.
- The product trio does discovery together. A product manager, a designer, and an engineer share the research and the decisions, so no insight gets lost in a handoff.
- The opportunity solution tree connects everything. A desired outcome branches into opportunities, then solutions, then assumption tests — making the team's reasoning visible and prioritization defensible.
- Opportunities are customer needs, not features. Phrase them in the customer's words; the moment an opportunity names a solution, you've skipped the most valuable thinking.
- Interview for specific past behavior. Collect stories about the last time something happened; avoid opinions and hypotheticals, which produce agreeable but unreliable answers.
- Test assumptions, not whole solutions. Break each solution into desirability, viability, feasibility, usability, and ethical assumptions, then run small tests on the important-but-unknown ones.
- Optimize for outcomes over outputs. Measure whether customer behavior changed, not merely whether a feature shipped — the outcome is what grants a team room to find the best answer.
Frequently Asked Questions
What is continuous discovery in product management?
Continuous discovery is the habit of engaging customers at least weekly to inform product decisions, run by the team building the product rather than a separate research group. Coined and detailed by Teresa Torres, it replaces occasional, project-based research with small, ongoing research activities aimed at a specific desired outcome.
How often should you talk to customers in continuous discovery?
At least once a week. Torres sets weekly customer touchpoints as the minimum bar because that cadence keeps evidence fresh enough to inform the decisions a team makes constantly. The activities stay small — often just a couple of interviews — so weekly is sustainable, especially once you automate participant recruiting.
What is the difference between an opportunity and a solution?
An opportunity is a customer need, pain point, or desire expressed in the customer's own words; a solution is a specific way to address it. "I can't tell whether my work saved" is an opportunity, while "add an autosave badge" is a solution. Keeping them separate on the opportunity solution tree is what preserves your space of possible answers.
Who should be involved in continuous discovery?
The product trio: a product manager, a designer, and a software engineer. Torres argues these three should make discovery decisions together so that customer desirability, design usability, and technical feasibility are all weighed in the same conversations, rather than one person researching and handing conclusions to the others.
Do you need special software to do continuous discovery?
No — the habits work with interviews, a shared tree, and simple notes. Tooling helps mainly with sustaining the cadence and keeping opportunities organized as they accumulate. A lightweight validation workspace like Edmired can hold your interview snapshots and opportunity map in one place, but the discipline matters far more than the tool.