Continuous discovery: the complete guide for 2026
Continuous Discovery
✓ Weekly customer touchpoints, built into how you ship
On this page
- TL;DR
- What is continuous discovery?
- The five continuous discovery habits Teresa Torres defines
- Continuous discovery vs project-based discovery
- Who runs continuous discovery? The product trio
- Why run a continuous discovery program?
- How to set up a continuous discovery program
- How to structure continuous discovery for your team
- Setting up the weekly cadence
- Why teams start the habits and why they stall
- What makes the habits stick
- Risks to watch
- How to measure whether it's working
- Scaling continuous discovery as you grow
- How Great Question supports continuous discovery
Customer needs don't stand still, so product decisions shouldn't rely on research conducted months ago. Continuous discovery helps product teams make decisions based on an ongoing stream of customer insight instead of occasional research projects.
Rather than talking to customers only before a major launch, continuous discovery encourages regular customer conversations to validate ideas, identify opportunities, and keep product decisions grounded in real user needs. Whether you're a product manager, designer, researcher, or engineer, this guide explains what continuous discovery is, how it differs from project-based research, and how to build a sustainable program.
TL;DR
Continuous discovery is the practice of conducting at least weekly customer touchpoints with the team building the product through small research activities focused on a specific outcome. The approach, popularized by Teresa Torres in Continuous Discovery Habits, helps teams make better product decisions by staying connected to customer needs.
A successful continuous discovery program includes:
- A clearly defined product outcome
- A consistent process for recruiting participants
- A habit of testing assumptions before building
- A repeatable system for synthesizing research findings
Common challenges include information overload, limited stakeholder buy-in, and relying too heavily on feedback from a narrow group of users.
What is continuous discovery?
Continuous discovery is the practice of conducting at least weekly customer touchpoints with the team building the product through small research activities focused on a desired outcome. That definition comes from Teresa Torres, author of Continuous Discovery Habits.
“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.”
The idea is straightforward: products evolve continuously, so customer research should too. Four parts of Torres's definition are especially important.
- Weekly customer touchpoints. Regular conversations help teams stay current with changing customer needs instead of relying on research conducted months earlier.
- The team building the product. Product managers, designers, and engineers participate directly in customer conversations. Hearing feedback firsthand builds shared understanding and reduces the risk of insights becoming diluted as they're passed between teams.
- Small research activities. Continuous discovery favors lightweight methods such as user interviews, usability tests, and short surveys over large, infrequent research projects. Keeping studies manageable makes a weekly cadence achievable.
- A desired outcome. Every activity should support a specific product goal, whether that's validating a feature, understanding user behavior, or identifying new opportunities.
The five continuous discovery habits Teresa Torres defines
Before getting into what goes wrong, it's worth being precise about what Torres is actually proposing. The word "habits" is doing real work here: she's describing a way of working that becomes automatic over time, not a process to follow on a project-by-project basis.
The core habits from the book:
1. Interview at least one customer per week Each product trio (product manager, designer, engineer) should talk to at least one customer per week. Not one researcher per week. The whole trio. Together. The goal is for the people building the product to have a continuous, direct connection to the people using it, not filtered through a research report that arrives six weeks later.
2. Map your opportunities in an opportunity solution tree Rather than jumping from a problem to a solution, Torres asks teams to map the opportunity space first. An opportunity solution tree is a visual framework that connects your desired outcome to the opportunities you've discovered, the solutions you're considering, and the experiments you're running. It keeps the team in discovery mode rather than building before they've understood the problem.
3. Surface your assumptions before you build Most product decisions rest on untested assumptions. Torres' habit is to make those assumptions explicit: write them down, rank them by risk and importance, and test the most dangerous ones first. This is what makes continuous discovery genuinely useful. You're not just collecting opinions; you're stress-testing the reasoning behind product decisions.
4. Run small experiments Testing assumptions doesn't require shipping features. Torres describes a range of experiment types (customer interviews, surveys, prototypes, fake doors) that help teams learn faster and with less risk. The habit is to always have experiments running, not just when a major decision is approaching.
5. Involve the whole product trio, not just researchers This is probably the hardest habit for research-heavy organizations to adopt. Torres is explicit that discovery should not be delegated entirely to a single researcher. The PM, designer, and engineer should all be part of the weekly customer conversations. Researchers can support and scale the work, but they shouldn't be the only ones doing it.
These five habits are what distinguish continuous discovery from a well-run research practice. You don't need a research ops team to implement them. You need a product team that takes the practice seriously.
What you do need (and what most teams underestimate) is infrastructure.
Continuous discovery vs project-based discovery
Many organizations still approach discovery as a series of standalone research projects conducted before major product launches. While this approach can answer strategic questions, customer insights often become outdated as products and user needs change.
Continuous discovery takes a different approach. Instead of treating research as a one-time project, it becomes an ongoing part of product development. Discovery and delivery happen in parallel, allowing customer insights to inform decisions throughout the product lifecycle.
Factor | Project-based discovery | Continuous discovery |
|---|---|---|
| Cadence | Project-based discoveryOccasional, tied to launches | Continuous discoveryAt least weekly |
| Who runs it | Project-based discoveryDedicated research phase, often led by a specialist | Continuous discoveryThe product team |
| What it produces | Project-based discoveryOne large research report | Continuous discoveryOngoing product decisions |
| Main risk | Project-based discoveryFindings may become outdated before they're applied | Continuous discoveryRequires an effective system for organizing and synthesizing data |
| Best for | Project-based discoveryStrategic, one-time research questions | Continuous discoveryContinuous product improvement |
Project-based research still plays an important role for large strategic initiatives. Continuous discovery complements that work by providing a steady flow of customer insight to guide day-to-day product decisions.
Who runs continuous discovery? The product trio
According to Teresa Torres, continuous discovery should be led by the team building the product. In practice, that often means the product trio: a product manager, designer, and engineer participating in customer conversations together.
When the people responsible for product decisions hear customer feedback firsthand, they develop a shared understanding of user needs and spend less time debating how to interpret research findings.
Researchers continue to play an important role. Rather than owning every customer conversation, they help teams improve research quality by advising on study design, interview techniques, and more complex research methods while supporting the product trio's ongoing discovery work.
Why run a continuous discovery program?
Continuous discovery helps product teams make better decisions by keeping customer insights current. Key benefits include:
- Stay aligned with changing customer needs. Regular conversations help teams identify changing priorities before they're reflected in usage data or support requests.
- Reduce the curse of knowledge. The longer teams work on a product, the easier it is to assume customers think the same way they do. Frequent customer conversations provide a more accurate view of the user experience.
- Reduce wasted development effort. Testing ideas early helps teams identify potential issues before investing significant engineering time.
- Improve backlog prioritization. Ongoing customer feedback provides better context for deciding what to build next and which opportunities deserve the highest priority.
- Build stronger customer relationships. Customers who see their feedback reflected in the product are more likely to remain engaged and invested.
- Balance customer and business goals. Continuous discovery helps teams evaluate customer feedback alongside business priorities to make more informed product decisions.
How to set up a continuous discovery program
Define your desired outcome
Start with a clear product outcome. It provides a shared focus for the team and helps distinguish meaningful customer feedback from information that isn't relevant to the decision you're trying to make.
Recruit participants continuously
Recruitment is often the biggest obstacle to maintaining a consistent discovery practice. If every study requires finding participants, coordinating schedules, and sending reminders from scratch, it's difficult to sustain weekly customer conversations.
Instead, build participant recruitment into your existing workflows. Invite customers while they're actively using your product, work with sales and customer success teams to identify potential participants, and automate scheduling wherever possible.
Great Question supports this process by helping teams recruit participants, send study invitations, manage incentives, and maintain a consistent participant pipeline. AI Moderation can also help teams conduct more customer conversations without requiring a researcher to moderate every session.
Organizations using this approach have significantly expanded their research capacity. One enterprise customer increased its annual customer interviews from 10,000 to 100,000. ServiceNow reduced participant recruitment time from 118 days to six, while Asana shortened recruitment timelines from approximately two weeks to just two or three days.
Test your assumptions before you build
Every product idea is based on assumptions. Before committing engineering resources, identify the assumptions that must be true for the idea to succeed and validate the most important ones first.
A useful framework is to evaluate each assumption against three questions:
- Desirability: Do customers actually want this?
- Feasibility: Can we build it?
- Viability: Does it support the business?
Continuous discovery helps answer these questions early through customer conversations, prototype testing, and lightweight research before development begins.
Ask better interview questions
A weekly cadence is only as good as the questions you ask in it. Two habits do most of the work.
The quality of your insights depends on the quality of your questions. Prioritize questions about past behavior over hypothetical scenarios. For example, asking, “Walk me through the last time you tried to do X” generally produces more reliable insights than “Would you use a feature that does X?”
Avoid leading questions that encourage participants to agree with your assumptions. Instead of asking, “How useful was this?” ask, “What did you do next?” Neutral, open-ended questions are more likely to uncover authentic customer behavior.
Visualise what you learn
As research accumulates, organizing and synthesizing findings becomes increasingly important.
Frameworks such as the Opportunity Solution Tree and experience maps help teams connect research findings to product opportunities and better understand the customer journey. Tools like Miro and FigJam make these frameworks easy to create and maintain.
As the volume of research grows, synthesis can become time-consuming. Great Question automatically groups recurring themes across interviews and links each finding back to the supporting transcript, making it easier to review evidence and identify patterns across studies.
Prioritise, act, and track
Research creates value only when it influences product decisions.
Prioritize findings based on their impact, feasibility, and alignment with your desired outcome. Then track both product metrics, such as Net Promoter Score and retention, and research health metrics, including customer participation and stakeholder engagement.
Regularly sharing findings and decisions helps maintain visibility and reinforces the value of continuous discovery across the organization.
How to structure continuous discovery for your team
There's more than one way to run this, depending on team size and how much you want to centralize.
The dedicated research track model
One researcher owns continuous discovery for a specific area: activation, onboarding, or churn. They recruit weekly, interview alongside a PM or designer, analyze, and share findings.
This works because the researcher builds real context over time. They spot trends that someone doing ad-hoc studies would miss. It requires dedicated time and good recruitment infrastructure, or the researcher ends up spending half their week on logistics.
The embedded researcher model
Researchers sit within product teams and treat continuous discovery as part of how those teams operate.
This works well when there's already strong research culture and enough researchers to go around. It requires clear participant sourcing so embedded teams aren't all drawing from the same pool, and good research management so findings flow between teams.
The hybrid model
A research ops team manages recruitment, the participant database, and analysis infrastructure. Individual researchers or embedded researchers use that infrastructure to run their own studies.
This is the model that scales. Research ops handles the operational parts. Researchers do the parts that require judgment. Asana cut research setup from two weeks to 2-3 days using this kind of structure.
Setting up the weekly cadence
Continuous discovery is really about regularity. Weekly is the most common rhythm, but bi-weekly works for some teams. Some run two parallel study tracks. The point is picking something sustainable and building a system around it.
A rough setup timeline:
Week one: Define your research questions. What are you trying to understand continuously? Pick one area to start: onboarding, activation, or churn. You can expand later.
Week two: Set up recruitment. Define who you need. Build a screening form. Decide whether you're recruiting from your customer base, an external panel, or both. Great Question's recruitment features connect to your customer data if you want to recruit from existing users.
Week three: Build your research management setup. Decide where findings will live, who can access what, and how insights will reach the people who need them. If your team lives in Slack, findings should get to Slack.
Week four: Run your first study. Five or six participants, open-ended questions. Treat this as a test of the infrastructure, not a search for perfect findings.
Week five: Analyze and share. Use AI-assisted analysis for the heavy lifting. Note what worked in the process and what didn't.
Weeks six onward: Run the system. Recruit, interview, analyze, share. Adjust as you go.
The first three weeks are setup. Then the rhythm takes over.
Why teams start the habits and why they stall
The appeal is immediate. Instead of quarterly research sprints that feed into decisions already half-made, you talk to customers every week. You catch problems early. You kill bad ideas before committing three months to them.
In practice, the pattern looks like this.
Weeks one through three go well. Researchers recruit a handful of participants. Analysis happens at night and on weekends. Findings get shared Monday morning. Something changes. Product leadership actually adjusts their thinking based on what the team learned. People are excited.
By weeks four through eight, cracks appear. Recruiting the next batch takes longer because you've already contacted most of your panel. Researchers are tired. Analysis takes two weeks now instead of one. There's a backlog of interviews waiting to be coded.
By week twelve, someone asks if you're still doing weekly research. The answer is: not really. The team has settled back into ad-hoc studies whenever a specific decision needs validation.
The teams that describe this pattern aren't lazy. They hit a structural wall. The habits require a rhythm, and the rhythm requires infrastructure that most teams haven't built.
What makes the habits stick
Torres' book focuses on what to do. The infrastructure question is how to do it consistently, week after week, without burning out the people responsible. Great Question's continuous discovery features are built specifically to support this layer.
Habit one requires recruitment that takes days, not weeks
The weekly interview habit falls apart first.
You need one new participant per week, per product trio. That sounds manageable until you realize most teams have a pool of ten to fifteen people they know and trust, and classic recruitment takes three to four weeks. If you're running weekly research, you'll exhaust your panel by week four.
What works is automation. ServiceNow cut recruitment from 118 days to 6 days by building automated qualification workflows. Candidates self-qualify through a short screening form. You get a vetted list ready to schedule the same week.
You also need diversity controls. Running weekly interviews from the same participant pool means you end up talking to your most enthusiastic customers repeatedly. A good recruitment system tracks who you've spoken to, when, and about what. It surfaces people you haven't reached yet.
Great Question's recruitment features connect directly to your customer data and automate qualification and scheduling. You define your criteria once; it handles the rest.
Habits two through four require AI-assisted analysis
The opportunity solution tree, assumption testing, and experiment habits all depend on analysis. You can't spot patterns across five weekly interviews if you're still manually transcribing and coding interview three.
One hour of interview typically requires three to four hours of analysis: listening back, coding themes, pulling highlights, forming patterns. Five interviews a week means roughly twenty hours of analysis before anyone has written a word of findings. Most researchers can't sustain that workload alongside everything else.
AI doesn't eliminate the judgment calls. Those still need a human. But it handles the mechanical work: transcription, initial coding, highlight extraction. Teams using AI-assisted analysis have cut their research workload roughly in half. That's the difference between sustainable and not.
The habit of surfacing assumptions also becomes more practical with good tooling. When transcripts are automatically coded and searchable, you can ask what customers have said about onboarding friction across every interview you've ever run, not just this week's batch.
Habit five requires a research management layer
The whole-trio habit creates a coordination problem that grows with team size. If the PM, designer, and engineer are all conducting interviews, where do findings go? How does the researcher know what the PM learned last Tuesday? How do you prevent three different people from contacting the same participant in the same week?
A research management system (sometimes called a research CRM) solves this. One place where every study lives: transcripts, findings, participant history. An insights view that surfaces what the team is learning without requiring people to dig through raw transcripts. And because contact history is tracked centrally, no one accidentally reaches out to the same person twice in a week.
Brex scaled from a handful of researchers to over a hundred by centralizing research this way. When everyone can see what's being learned, more of the organization can act on it.
Great Question's research CRM is built for this: studies, participants, and findings all in one place. Contact history is tracked automatically.
Risks to watch
Like any research practice, continuous discovery comes with challenges.
- Information overload. Frequent customer conversations generate a large volume of qualitative data. Without an effective system for organizing and synthesizing findings, important insights can be overlooked.
- Limited stakeholder buy-in. Teams may hesitate to adopt continuous discovery without seeing its value. Sharing early successes and demonstrating business impact can help build support.
- Customer fatigue. Repeated research requests can reduce participation over time. Rotate recruitment strategies, space requests appropriately, and use incentives thoughtfully.
- Sampling bias. Relying on the same participants repeatedly can skew research findings. Recruit participants from different customer segments to ensure broader representation.
- Over-reliance on stated feedback. Customer interviews reveal what people say, which doesn't always match what they do. Combine qualitative research with behavioral data whenever possible.
How to measure whether it's working
After three months, check:
How many interviews did you run? A reasonable target is roughly one per researcher per week, sustained.
How many findings did you publish? Roughly one per study, or every two weeks at minimum.
Are insights making it into decisions? At least one decision per quarter should be directly traceable to continuous discovery findings.
Are researchers satisfied? The practice should feel sustainable. If researchers are burning out, something in the infrastructure is broken.
Are you repeating research? If the same questions keep surfacing in new studies, findings aren't reaching the people making decisions.
Scaling continuous discovery as you grow
Three researchers doing this is manageable. Thirty requires systems.
As you scale: centralize participant management so researchers aren't independently contacting the same people. Build research ops so someone owns the infrastructure and maintains quality. Create documentation for what a good research brief looks like, how many participants per study, and what the minimum bar is before publishing findings. New people onboard faster, and consistency improves.
Brex went from a handful of researchers to over a hundred by building this operational structure deliberately. It didn't happen by accident.
How Great Question supports continuous discovery
Maintaining a continuous discovery program requires more than a research repository. Teams also need reliable ways to recruit participants, schedule sessions, conduct research, and organize findings.
Great Question brings these together in one platform, allowing teams to recruit participants, run studies, and analyze research without relying on multiple disconnected tools.
Unlike a standalone research repository, Great Question supports the entire research workflow, from participant recruitment through analysis. Several customers have moved away from Dovetail after adopting it.
For teams running research every week, consolidating these activities into a single platform can make continuous discovery easier to sustain.
Ready to build a continuous discovery program?
Frequently asked questions
What is continuous discovery in product management?
Continuous discovery is the practice of conducting at least weekly customer touchpoints with the team building the product through small research activities focused on a specific outcome. The goal is to keep product decisions grounded in current customer needs rather than relying on outdated research.
How is continuous discovery different from regular user research?
Traditional user research is often conducted as a standalone project tied to a product launch or major initiative. Continuous discovery is an ongoing practice that runs alongside product development, allowing customer insights to inform decisions throughout the process.
How often should you talk to customers in continuous discovery?
Teresa Torres defines continuous discovery as at least weekly customer touchpoints. The exact number of interviews is less important than maintaining a consistent cadence. Even one or two customer conversations each week can support an effective continuous discovery practice.
Who should run continuous discovery?
Continuous discovery is typically led by the product trio: a product manager, designer, and engineer. Researchers continue to play an important role by advising on research methods, interview design, and more complex studies while supporting the team's ongoing discovery work.
What tools do you need for continuous discovery?
At a minimum, teams need a reliable way to recruit participants, schedule and conduct research sessions, and organize research findings. Using a single platform for these activities can make it easier to maintain a consistent continuous discovery practice.
What are the continuous discovery habits Teresa Torres defines?
The five continuous discovery habits Teresa Torres defines are: (1) interview at least one customer per week as a full product trio, (2) map opportunities using an opportunity solution tree, (3) surface and test assumptions before building, (4) run small experiments to validate ideas, and (5) involve the full product trio (not just researchers) in weekly discovery. Torres describes all five in her book Continuous Discovery Habits, including how to start when teams are skeptical or overstretched.
How is "continuous discovery habits" different from just doing more user research?
The main difference is who owns it and when it happens. Traditional user research is typically researcher-driven, project-scoped, and delivered as a report. The continuous discovery habits model has the full product trio interviewing together every week and connecting what they learn directly to the opportunity solution tree and product decisions in real time. The insights don't go through a report. They shape the next week's work.
Does this replace the need for dedicated UX researchers?
No. Torres is clear that researchers have an important role: they support the practice, train non-researchers to interview well, run more in-depth studies when needed, and help teams avoid common pitfalls. What changes is that researchers aren't the only people doing discovery.
Should we interview our own customers or external users?
Both, for different reasons. Existing customers tell you what's working and what isn't once they're using the product. Prospects and people in your target market who don't yet use you tell you whether you're solving a real problem at all. Rotating between them keeps the picture complete.
How many participants do we need per study?
For qualitative research: five to eight. You'll spot the major themes by five. Eight gets you a bit more nuance. Beyond ten, you're spending time for diminishing returns.
How do we prevent participant fatigue?
Track every interaction. Know when each person was last contacted. Don't interview the same person more than once a month. Great Question's research management system tracks this automatically.
What if executives don't see the value?
Show them decisions it changed. "We were about to build this. Three customer conversations in week two told us nobody wanted it. We built something else, and it's our most-used feature." Frame it as risk reduction. That language tends to land.
