What Is Continuous Discovery? Teresa Torres’ Framework Explained
Most product teams do user research in bursts — a big research project before a major initiative, a round of interviews when something goes wrong, a usability test before launch. Continuous discovery is a fundamentally different approach: instead of periodic research sprints, the team conducts ongoing, lightweight user research every single week. Teams making this switch consistently report the same sticking point: the hardest part is never the interviewing itself — it’s convincing a team that 20 scrappy minutes a week beats a polished report every quarter.
Understanding what is continuous discovery — and how to implement it — is one of the highest-leverage things a product team can do to make better decisions faster and build fewer things that users do not actually want.
What Is Continuous Discovery in Product Management?
Continuous discovery is a product practice in which the team conducts at least one touchpoint with a customer every week, on an ongoing basis. The term was popularized by Teresa Torres, a product coach and author of Continuous Discovery Habits, and it represents a shift from discovery as a project phase to discovery as a team habit.
What is continuous discovery in practice? It means that instead of running a quarterly research project to inform the next planning cycle, the product team is always in conversation with users. These conversations are typically short, 20 to 30 minutes, and semi-structured. They are not full usability tests or formal research studies. They are lightweight, ongoing conversations designed to keep the team continuously connected to what users are experiencing, struggling with, and trying to accomplish.
The goal of continuous discovery is not to generate a research report. It is to build a living, evolving understanding of the customer so that product decisions are made with current, specific, firsthand knowledge rather than stale assumptions or secondhand summaries from customer success teams.
Continuous discovery works because it closes the feedback loop between what the team builds and what users actually need. Without it, product teams are operating on a delay — making decisions based on research that was conducted months ago, about users whose context may have already changed.
Teresa Torres and the Continuous Discovery Habits Framework
Teresa Torres developed the continuous discovery framework through years of coaching product teams and observing what separated the teams that consistently built products users loved from those that did not. Her book Continuous Discovery Habits (2021) is the definitive resource on the practice.
The core of Torres’ continuous discovery framework has three elements: regular customer interviews, an opportunity solution tree, and assumption testing.
Regular customer interviews are the foundation. Torres recommends that the product trio (PM, designer, and tech lead) conduct at least one customer interview per week together. Interviewing together rather than delegating to a researcher means the whole team builds empathy and hears the same things, reducing the translation problem that happens when research findings get summarized and handed over.
The opportunity solution tree is Torres’ core visual framework for continuous discovery. As she explains in her own writing on opportunity solution trees, it’s a structured diagram that maps the relationship between a desired outcome, the opportunities that could drive that outcome, the solutions that could address each opportunity, and the experiments that test each solution. The opportunity solution tree prevents the most common product mistake, jumping from a problem directly to a solution, by forcing the team to explore the opportunity space before committing to a specific build.
Assumption testing is the discipline of making the implicit beliefs behind each solution explicit and then testing the riskiest ones before committing to building. Every product solution rests on assumptions about user behavior, technical feasibility, and business viability. Continuous discovery makes assumption testing a routine activity rather than an occasional exercise.
The continuous discovery habits framework is not a linear process. It is an ongoing cycle: interview, map opportunities, generate solutions, test assumptions, build, learn, repeat — every week, indefinitely.
The Opportunity Solution Tree Explained
The opportunity solution tree is the most distinctive and powerful tool in the continuous discovery framework. Understanding how it works is essential to implementing continuous discovery effectively.
The tree has four levels:
Level 1: Desired outcome. The business or product metric the team is trying to move. This should be specific and measurable: “increase 30-day retention” or “increase activation rate for new users.” The desired outcome is the root of the tree and provides direction for everything below it.
Level 2: Opportunities. The customer needs, pain points, and desires that, if addressed, would help the team achieve the desired outcome. Opportunities are discovered through customer interviews and should be framed from the customer’s perspective, not as solutions. “Users struggle to understand the value of the product in their first session” is an opportunity. “Add an onboarding tour” is not — that is a solution.
Level 3: Solutions. The features, experiments, or changes that could address each opportunity. A single opportunity typically has many possible solutions. The opportunity solution tree makes this explicit by keeping opportunities and solutions as separate levels, which prevents the team from locking onto the first solution that comes to mind.
Level 4: Experiments. The smallest possible test that could validate whether a solution addresses the opportunity effectively. These can be prototypes, surveys, fake-door tests, or any other lightweight experiment that generates a signal without requiring a full build.
The opportunity solution tree is a living document. It gets updated as new interviews surface new opportunities, as solutions get tested and validated or invalidated, and as the team’s understanding of the customer evolves.
Continuous Discovery vs Traditional Research at a Glance
| Traditional Research | Continuous Discovery | |
|---|---|---|
| Cadence | Periodic (quarterly or per-project) | Weekly, ongoing |
| Who talks to users | Researcher, then reports to team | PM, designer, and tech lead directly |
| Output | A research report | An evolving opportunity solution tree |
| Speed of insight to decision | Weeks to months | Days |
| Depth per session | High (formal study) | Low individually, high cumulatively |
How Continuous Discovery Differs From Traditional Research
The contrast between continuous discovery and traditional product research is sharp enough that it is worth making explicit.
Traditional research is periodic, formal, and often siloed. A research team conducts a study, writes a report, presents findings to the product team, and then the product team makes decisions based on those findings — which are already weeks old by the time they are acted on. The research is thorough but slow, and the translation from researcher to product team inevitably loses nuance.
Continuous discovery is ongoing, lightweight, and cross-functional. The product trio does the interviewing themselves, which means there is no translation. Insights flow directly from the customer conversation into the team’s decision-making. The interviews are shorter and less formal than traditional research studies, but because they happen every week, the cumulative understanding built over time is deeper than any one-off study.
For teams that have never done continuous discovery before, the shift feels uncomfortable at first. PMs worry that 20-minute weekly interviews will not generate “enough” data. Torres addresses this directly: the goal is not statistical significance. The goal is directional insight that helps the team make better decisions week over week. A team that has spoken to 50 customers over 12 months has a dramatically richer understanding of their users than a team that commissioned two annual research studies.
See our guide on how to run a product discovery sprint for a complementary approach that works well alongside continuous discovery for deeper explorations of specific opportunity areas, and our guide on how to conduct user interviews for the interviewing mechanics themselves.
Where Continuous Discovery Breaks Down
Continuous discovery is simple to describe and genuinely difficult to sustain. It fails in a small number of predictable places.
The recruiting pipeline dries up. Teams get excited in week one, book five interviews, and then the pipeline runs empty by week four because nobody owns ongoing recruiting. This single cause kills more continuous discovery efforts than anything else — the interviewing habit doesn’t fail, the sourcing habit does.
The tech lead quietly stops showing up. Torres is explicit that the product trio should interview together, but engineers are usually the first to get pulled back into sprint work when things get busy. Once the tech lead drops out, the interviews still happen, but half the point, building shared, firsthand understanding across the whole team, is lost, and it becomes PM-led research with extra steps.
The opportunity solution tree becomes a one-time artifact. A team builds a beautiful tree in a workshop, presents it to leadership, and then never opens the file again. The tree only earns its value if it’s updated after every interview — a static tree is really just a roadmap slide wearing a different outfit.
Interviews turn into pitch sessions. Under pressure to justify the time spent, some PMs start using customer interviews to validate a solution they’ve already decided to build, asking leading questions that confirm what they hoped to hear. The interview stops surfacing real opportunities and starts producing reassurance instead — which is worse than not interviewing at all, because it creates false confidence.
This drift is recognizable once you know what to look for: interview notes that have gotten suspiciously positive over several weeks, every conversation seemingly confirming a roadmap the team already committed to. The questions are the giveaway — “wouldn’t it be helpful if we added X” instead of “walk me through the last time you tried to do X.” Reframing questions around recent, specific behavior instead of hypothetical features typically brings the friction back into view within a couple of interviews.
How to Start a Continuous Discovery Practice
Starting a continuous discovery practice does not require a research budget, a dedicated UX researcher, or a major process overhaul. It requires three things: a recurring weekly slot, a customer recruiting system, and a shared place to capture what you are learning.
Set up a recurring customer interview slot. Block one hour per week for the product trio (PM, designer, tech lead) to conduct a customer interview together. Protect this time the way you protect sprint planning. It will get cancelled in the first few weeks if it is not treated as non-negotiable.
Build a recruiting pipeline. The hardest part of continuous discovery is not doing the interviews — it is getting customers to show up. Set up a simple system: add a recruiting survey to your product (a short in-app prompt asking engaged users if they would be willing to talk), connect it to a Calendly link, and aim to keep 4–6 interviews booked at any given time. Once the pipeline is set up, it becomes self-sustaining.
Use the opportunity solution tree to structure what you learn. After each interview, update the opportunity solution tree. What new opportunities did you hear? Did any existing opportunities get stronger or weaker? Did you hear anything that challenges your current solution direction? The tree is not a deliverable — it is a shared thinking tool that gets more valuable the more consistently it is maintained.
Start with your desired outcome. Before your first interview, align the team on the one outcome you are currently trying to improve. This focus is what makes continuous discovery actionable rather than just interesting. Without a shared desired outcome, interviews generate observations with no clear direction.
For a deeper look at how continuous discovery connects to your broader product metrics, see our guides on product metrics and what is a north star metric. The team that gets the most out of this practice isn’t the one with the most polished tree — it’s the one that still has an interview on the calendar twelve weeks from now, after the initial enthusiasm has worn off.
References
- Torres, T. (2021). Continuous Discovery Habits. Product Talk Press.
- Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love. Wiley.
- Torres, T. Opportunity Solution Trees. producttalk.org
