Continuous Discovery: Habits, Process and Examples

Continuous discovery is a strong product management practice in which enterprise teams learn about their customers and problems on an ongoing basis, rather than only doing research at the beginning of a given project. Continuous product discovery involves constantly interacting with users, understanding problems and opportunities, testing assumptions, and collecting evidence before making product decisions.

One proven way to do continuous discovery is through the Continuous Discovery Habits framework by product discovery coach Teresa Torres. This continuous discovery framework provides enterprise teams with a disciplined approach to embedding discovery into their daily product work through regular conversations with customers, opportunity mapping, assumption testing, small experiments, and working together in a cross-functional product trio.
Key Highlights of Continuous Discovery:

• Continuous discovery means that research is an active part of the product lifecycle, not just the beginning of a project.

• Teresa Torres suggests that product teams make a habit of having weekly customer touchpoints. 

• Discovery often brings together product, design, and engineering perspectives from the product trio.

• An opportunity solution tree links a desired outcome to customer opportunities, alternatives, and experiments.

• Assumption mapping is a way for teams to uncover what needs to be true for a solution to work.

• Small experiments can help teams test risky assumptions before investing heavily in development.

• Discovery and delivery are best as connected, parallel activities, not as separate phases.

• DORA’s 2024 research found that in its 2023 data, user-centred teams had a 40% higher level of organizational performance, demonstrating the importance of understanding and responding to user needs. 

• Continuous discovery is especially useful in Agile environments because teams can incorporate learning into backlog refinement, prioritization, product increments, and future experiments

Introduction

Imagine a product team spending six months building a new feature. The requirements are complete, the designs are polished, engineering has delivered the functionality, and the launch date arrives. Then customers barely use it. The problem may not have been poor engineering. The team may simply have solved the wrong problem.

This is one of the reasons continuous product discovery has become an important practice in modern product management. Instead of asking customers what they want once at the beginning of a project, teams continuously investigate customer behavior, needs, pain points, and desired outcomes while they are making product decisions.

That distinction matters. Traditional product development can create a sequence such as

Research → Requirements → Design → Development → Launch.

The continuous discovery process creates a more iterative loop:

Learn → Identify opportunity → Explore → Test → Build → Measure → Learn again.

Teresa Torres's work on Continuous Discovery Habits puts this idea into a repeatable operating model. Her continuous discovery framework emphasizes regular customer interviews, opportunity mapping, assumption testing, experiments, and collaboration across the product trio. 

This approach also aligns with broader evidence about user-centred product development. DORA's 2024 research reported that organizations with a strong focus on user needs performed better organizationally, with user-centred teams showing a 40% higher level of organizational performance in the 2023 data cited in the report. The goal is not to spend every day conducting continuous discovery research. It is to make learning frequent enough that customer understanding keeps pace with product decisions.

In this guide, we'll explore the continuous discovery framework, its five core habits, the product trio, the opportunity solution tree, weekly customer interviews, assumption testing, discovery cadence, practical examples, common challenges, and how continuous discovery fits into Agile and SAFe environments.

What Is Continuous Discovery?

Definition and the At-Least-Weekly Principle

Continuous discovery is the ongoing practice of learning about customers and using that learning to guide product decisions throughout development.

Teresa Torres defines a practical benchmark around frequent customer touchpoints. Her framework encourages product teams to interview customers regularly, with an at-least-weekly rhythm being a central principle. Product Talk describes continuous interviewing as a keystone habit because it helps teams connect research findings with product decisions.

The important word is continuous. A team does not conduct 20 customer interviews during a research phase and then stop talking to customers for six months. Instead, customer conversations become part of the team's normal operating rhythm.

For example, a product trio might schedule one or two customer conversations every week. Those conversations could reveal:

• A recurring workflow problem. 

• A workaround customers have created.

• An unmet need. 

• A confusing part of the product.

• A new opportunity the team had not considered.

• Evidence that an existing assumption is wrong.

Over time, these small interactions create a richer understanding of the customer.

Discovery vs. Delivery Running in Parallel
 

Discovery and delivery are often presented as separate stages, but continuous discovery treats them as parallel activities. Discovery asks:

• What problem should we solve?

• Who experiences it?

• How important is it?

• What outcomes matter?

• Which solution might work?

• What assumptions are risky?

On the other hand, delivery asks:

• How do we build the chosen solution?

• How do we test it technically?

• How do we release it?

• How do we operate and improve it?

These two activities continuously inform each other. A product team might discover during interviews that customers struggle with invoice reconciliation. While engineers build a small solution for one aspect of that problem, the team can continue interviewing customers and testing other potential approaches.

Torres has explicitly argued that discovery and delivery should not be treated as phases but as activities that happen continuously. This approach reduces the risk of having a large gap between what a team learned when it started a project and what customers actually need when the solution reaches them.

Continuous vs. Project-Based Research

Project-based research usually begins with a defined research question and ends with a research deliverable. For example:

"Interview 15 customers before designing the new reporting dashboard."

That research may be valuable, but the team can become disconnected from customers once the project moves into development. Continuous discovery works differently.

Instead of:

Research project → Findings → Handoff

the team creates:

Customer conversation → Insight → Product decision → Experiment → New question

This does not make formal research obsolete. Large market studies, usability programs, quantitative research, and specialized research still have important roles. For a wider view of the methods available, see this guide to types of product discovery techniques. The difference is that continuous discovery research keeps learning connected to everyday product decisions.

The Five Continuous Discovery Habits

The five continuous discovery habits represent a practical interpretation of Teresa Torres's approach. This includes maintaining frequent customer contact, mapping opportunities, identifying assumptions, testing solutions through small experiments, and involving the product trio throughout discovery.

Interview at least One Customer Per Week
 

An interview of a customer is the foundation of many continuous discovery practices.

The objective of this is not to ask:

"Would you use this feature?"

Instead, good interviews explore real experiences. For example:

"Tell me about the last time you had to prepare this report."

Story-based questions investigate what customers really did, what happened, what frustrated them, and what else they considered. Weekly interviews also stop customer understanding from going stale.

Product Talk is a keystone habit that places a premium on ongoing client engagement because teams that build it are more likely to build other discovery behaviors such as experimentation and linking research to product decisions.

Map Opportunities on an Opportunity Solution Tree
 

An opportunity solution tree is a visual way of organizing discovery. A typical tree links:

• Experiments 

• Solutions 

• Opportunities 

• Desired Outcome

For example:

Outcome: More activations in the first week

Opportunity 1: Users do not understand the initial setup

Opportunity 2: Users have difficulty importing legacy data

Opportunity 3: Core Flow is Not Discovered by Users

This allows the team to explore multiple solutions for each opportunity instead of jumping to the first feature idea. Teams can explore the concept further through thisOpportunity Solution Tree.

Surface and Test Assumptions Before Building

Every product idea contains assumptions. Suppose a team proposes an AI assistant for customer support. The idea might assume that:

• Customers want automated responses

• Customers trust AI-generated answers

• AI can produce accurate responses

• Customers will use the feature regularly

• The feature will save enough time to justify development

The team does not need to build the entire assistant to test these assumptions. Instead, it can identify which assumptions are most risky and test them individually. This is where assumption mapping becomes useful. Teams can map assumptions according to factors such as importance and uncertainty, then focus discovery effort on the assumptions that could invalidate the solution.

Run Small, Fast Experiments

A good experiment does not necessarily require production software. Teams can use:

• Prototypes

• Fake-door tests

• Concierge services

• Landing pages

• Usability tests

• Manual workflows

• Concept tests

• Data analysis

• Small controlled releases

The aim is to reduce uncertainty. Torres refers to interviewing as generative discovery and testing assumptions as evaluative discovery. They collaborate to help teams discover opportunities and pinpoint solutions worth pursuing. Teams exploring how AI can speed up this work can look at the ICAgile AI for Product Discovery micro-credential.

Involve the Full Product Trio

Discovery should not become a handoff from researcher to product manager to designer to engineering. The product trio brings different perspectives into the same conversation. A product manager contributes business and product context. A designer contributes customer experience and interaction expertise. An engineer contributes technical feasibility and implementation knowledge. When these perspectives are present during discovery, the team can identify trade-offs earlier.

The Product Trio

Who Sits in the Trio

The classic product trio consists of

• Product manager.
• Product designer.
• Engineer.

The exact titles can vary by organization.

For example, a company may have a product owner instead of a product manager, or a UX researcher may participate as an additional discovery specialist. Product owners building these skills often start withCertified Scrum Product Owner (CSPO) training. The important characteristic is not the job title. It is that product, design, and technology perspectives are involved in making discovery decisions. Torres specifically describes the product trio as a product manager, designer, and engineer working together on customer interviews and discovery.

Why Shared Discovery Beats Hand-offs

Consider two approaches.

Approach A:

A researcher interviews customers, writes a report, sends it to the product manager, and waits for a feature request.

Approach B:

Product, design, and engineering participate directly in selected customer conversations and interpret the evidence together.

The second approach reduces interpretation layers.

The engineer may notice a technical constraint that changes the solution direction. The designer may recognize a usability problem. The product manager may connect the issue to the desired business outcome.

Torres argues that the product trio should conduct its own interviews because discovery needs to be timely, actionable, and believable enough for the team to act on. 

Specialist research teams still provide enormous value. Shared discovery simply ensures that product decisions are not completely separated from customer evidence.

The SAFe Product Owner and Product Manager in the Trio

In SAFe environments, product responsibilities can be distributed across product owners and product management. SAFe terminology distinguishes roles such as Product Owner and Product Management, with the Product Owner working closer to the Agile Team and Product Management working at a broader product or solution level. The SAFe glossary also definescontinuous exploration as the ongoing exploration of market and customer needs and defines vision, roadmap, and features. 

In this way, an SAFe team can practice continuous discovery without the need to isolate discovery into a separate function. The product owner can bring team-level customer knowledge to backlog decisions while product management introduces broader customer and market learning to the product direction. Professionals looking to enhance these skills may want to consider SAFe POPM Certification Training.

The Opportunity Solution Tree

Linking Outcome, Opportunities, Solutions, and Experiments

The opportunity solution tree is one of the most recognizable tools associated with the continuous discovery framework.

Its basic structure is

Imagine a subscription software company wants to increase the percentage of new users who become active within seven days. The outcome becomes:

Increase seven-day activation.

Customer interviews reveal opportunities:

• Users do not know where to begin.
• Users cannot easily import existing information.
• Users do not understand the product's main benefit.

The team can now explore several solutions for each opportunity.

For the "do not know where to begin" opportunity, possible solutions might include:

A designer contributes customer experience and interaction expertise.

• Guided onboarding
• A setup checklist
• A sample project
• Contextual prompts

The team can then test the riskiest assumptions behind these solutions. Product Talk describes the tree as a way to connect an outcome with opportunities and possible solutions while helping teams maintain alignment around discovery work.

Prioritizing Which Opportunity to Pursue Next

The tree does not automatically tell a team which opportunity is "the winner." Instead, it gives the team a shared view of the opportunity space. Teams can prioritize using evidence such as

• Frequency of the problem
• Severity of the problem
• Customer importance
• Business relevance
• Strategic alignment
• Technical feasibility
• Existing product data
• Confidence in the evidence

For example, if customer interviews repeatedly reveal that onboarding is confusing while only one customer mentions an advanced reporting problem, the team has a reason to investigate onboarding more deeply.

This is more robust than prioritizing solely because a stakeholder suggested a feature. Once an opportunity is chosen, MoSCoW prioritizationcan help the team sort the backlog items that come out of it.

Running Weekly Customer Interviews

Recruiting and Scheduling Without Draining the Team

One of the biggest practical obstacles to continuous discovery is customer access. Teresa Torres has noted that access to customers is the number-one hurdle frequently reported by teams adopting continuous discovery. She argues that sustainable discovery requires a repeatable or automated recruiting process rather than starting recruitment from scratch every week. A team can create a lightweight recruiting system using:

• Customer panels
• Opt-in research programs
• In-product invitations
• Customer success referrals
• Support-ticket follow-ups
• Email invitations
• Incentives where appropriate

The objective is to make customer access routine rather than exceptional.

Story-Based Interviewing to Uncover Real Needs

Good continuous discovery interviews focus on what customers actually did.

Weak question:

"Would you like an automated reporting feature?"

Better question:

"Tell me about the last time you prepared this report."

The second question asks for a real story.

Follow-up questions can explore:

• What happened next?
• What made that difficult?
• What did you try?
• How often does this happen?
• What tools did you use?
• What was the consequence?  

This style helps uncover customer needs without prematurely pushing respondents toward a proposed solution. It can also work alongside frameworks such as the Jobs to Be Done framework, which focuses on understanding the progress customers are trying to make in a particular situation. Many of the same questioning skills appear in the requirement elicitation techniquesbusiness analysts use.

Synthesizing Interviews Into Opportunities

An interview transcript is not itself an insight. After several conversations, the trio should look for patterns. Suppose five customers describe different situations:

• One manually exports data
• Another copies information into spreadsheets
• A third takes screenshots
• A fourth asks a colleague for help
• A fifth uses a third-party tool

The surface behaviors differ, but they may point toward a shared opportunity. Customers struggle to move information between systems. That opportunity can then be added to the opportunity solution tree and explored further.

Testing Assumptions and Running Experiments

Turning Solutions Into Testable Assumptions

A solution is usually built on several assumptions. Suppose a team proposes:

"Add an AI-powered recommendation panel."

Possible assumptions include:

• Users want recommendations
• Users will understand the recommendations
• Recommendations will be accurate
• Users will trust them
• Recommendations will change behavior
• The resulting benefit is valuable enough to matter

Rather than debating the feature in a meeting, the team can identify which assumptions are both important and uncertain. This is the practical connection between assumption mapping and continuous discovery. For more guidance, see Assumption Mapping.
 

Choosing the Smallest Risk-Reducing Experiment

The best experiment is often the smallest one that can meaningfully reduce uncertainty. For example, a team might build a clickable prototype and test whether users understand and value the recommendations before building an AI recommendation engine. If users consistently misunderstand the concept, the team has learned something important without building the underlying technology. Other examples include:

The goal is not to prove an idea correct. It is to reduce the uncertainty that matters most.

Deciding Based on Evidence, Not Opinion

Discovery can still fail if teams collect evidence but ignore it. Imagine leadership strongly prefers Solution A, while customer research and prototype testing consistently point toward Solution B. 
A continuous discovery culture gives the team a mechanism for discussing that evidence openly. 
Evidence does not eliminate judgment. Product decisions still involve strategy, constraints, business economics, technology, and risk.

But evidence changes the conversation from:

"I think this will work."

to:

"Here's what we observed, here's what we still don't know, and here's the next assumption we should test."

That is a much healthier basis for product decision-making.

Continuous Discovery Cadence

Why Weekly Is the Recommended Rhythm

Weekly discovery creates a practical balance between learning and delivery. A team might use a weekly rhythm such as

Monday: Review product metrics and existing evidence.

Tuesday: Conduct customer interviews.

Wednesday: Map opportunities and assumptions.

Thursday: Test a prototype or other assumption.

Friday: Review evidence and update priorities.

This is only an example. The exact schedule should fit the team's operating model. The key is consistency. Torres's current guidance continues to emphasize weekly discovery activities, including customer interviews, opportunity mapping, and assumption testing. 

When Bi-Weekly Works and Why Monthly Fails

Not every team can speak with customers every week. A biweekly cadence can work when:

Suppose five customers describe different situations:

• One manually exports data
• Another copies information into spreadsheets
• A third takes screenshots
• A fourth asks a colleague for help
• A fifth uses a third-party tool.

The surface behaviors differ, but they may point toward a shared opportunity that can then be added to the opportunity solution tree and explored further.

Testing Assumptions and Running Experiments

Turning Solutions Into Testable Assumptions
 

Suppose a team proposes:

"Add an AI-powered recommendation panel."

Possible assumptions include:

• Users want recommendations
• Users will understand the recommendations
• Recommendations will be accurate
• Users will trust them
• Recommendations will change behavior
• The resulting benefit is valuable enough to matter

This is the practical connection between assumption mapping and continuous discovery.

Choosing the Smallest Risk-Reducing Experiment

"I think this will work."

"Here's what we observed, here's what we still don't know, and here's the next assumption we should test."

Continuous Discovery Cadence

Why Weekly Is the Recommended Rhythm

Torres provides a practical structure for doing this. Weekly customer conversations create regular exposure to real customer experiences. The opportunity solution tree structures what the team learns. Assumption mapping displays uncertainty. Small experiments can help to reduce risk before you invest in a big development. And product three synchronizes product, design, and engineering perspectives. 

Regularly engage with customers, identify opportunities, test assumptions, experiment with solutions, and connect findings to product priorities. Teresa Torres’ approach centres on frequent customer touchpoints, plus cross-functional work between product, design, and engineering. 

The aim is to reduce uncertainty continuously rather than discover problems after a substantial amount of development work. interviews, because it makes research more timely and actionable for product decisions. Test a prototype or other assumption. This is only an example. The exact schedule should fit the team's operating model.

When Bi-Weekly Works and Why Monthly Fails

• The product has a small customer base
• Customers are difficult to recruit
• The team has limited research capacity
• The product has long decision cycles
• Research involves specialized participants

The problem with a monthly cadence is not that 30 days is inherently wrong. The problem is that the habit becomes easier to postpone. A team may miss one month because of a release. Then another month because of planning. Eventually, customer research becomes something the team does only when a major project starts. Continuous discovery depends more on habit strength than on a rigid calendar.

Sustaining the Habit Over Quarters

The first few weeks are usually easier than maintaining discovery for a year. Teams can sustain the practice by:

• Blocking recurring interview time
• Maintaining a customer recruitment pool
• Keeping the opportunity solution tree visible
• Recording assumptions explicitly
• Scheduling regular synthesis sessions
• Connecting insights to backlog decisions
• Sharing customer evidence with stakeholders
• Reviewing discovery outcomes during planning

The objective is to make discovery part of the team's operating system rather than an additional project.

Worked Example: Continuous Discovery

Imagine a SaaS business with expense management software. 
The result that is wanted is to increase the number of new customers reporting their first expense within 7 days.

Step 1 – Speak with Customers

Talks to customers weekly - product trio.

A few users are confused about whether they should be manually inputting expenses or importing them from their bank.

Step 2: Find the Opportunity

The team defines an opportunity as new customers not knowing how to input their first expense into the system.

Step 3: Formulate Solutions

The team thinks:

• A wizard to guide you through
• Example of an expense
• A checklist of “initial expenses.”
• Automatic prompts for bank import
• A short intro video

Step 4: Spot Assumptions

The team emphasizes an important assumption:

A clear first-step recommendation helps users complete their first expense faster.

Step 5: Try a Little Experiment

Instead of building a full-fledged onboarding system from scratch, the team creates a lightweight prototype and tests it on representative users. Most participants understand the first step, but some are confused by the terminology.

Step 6: Polishing

The team changes the language. One more test. The new version performs better at completing the task in usability testing.

7. Run & Measure

The team implements the smaller onboarding improvement and measures the 7-day first expense completion.

If the metric improves, the product owner might consider a wider rollout or related experiments. 
If it does not, the team returns to discovery. The heart of the continuous discovery process is as follows:

Outcome → Opportunity → Solution → Assumption → Experiment → Evidence → Decision

Common Challenges and How to Overcome Them

The Recruiting, Scheduling, and Synthesis Tax

Customer research creates operational work. Someone has to:

• Find participants
• Schedule conversations
• Prepare questions
• Conduct interviews
• Record observations
• Synthesize findings
• Share insights

If all of this happens manually every week, the team can burn out. The solution is to systematize the process. Maintain a customer panel. Create reusable interview templates. Automate scheduling where possible. Store research notes consistently. Use lightweight synthesis techniques. The goal is not to eliminate the work but to reduce unnecessary friction.

Getting Stakeholder and Leadership Buy-in

Stakeholders may ask, "Why are we still researching? We already know what customers want."

This usually indicates a misunderstanding of discovery. The answer is not more research reports. It is connecting discovery to decisions. Here is how a customer insight changed:

• A backlog priority
• A product requirement
• A prototype
• A roadmap assumption
• A feature decision
• An investment decision.

Framing discovery results as measurable goals, as explained in OKR vs KPI, also makes progress easier for leadership to track.

DORA's research provides broader support for user-centred development: its 2024 report found that teams with a strong focus on user needs demonstrated higher organizational performance in the cited data. 

Avoiding Discovery Theater With No Real Decisions

Discovery theatre happens when teams conduct interviews, create journey maps, and run workshops, but product decisions remain unchanged. The cure is to connect every discovery activity to a decision.

Before an interview, ask:

What might we learn that would change our decision?

Before an experiment, ask:

What result would cause us to change direction?

Before research synthesis, ask:

Which product decision will this evidence inform?

If the answer is always "none," the team may be performing discovery without actually using it.

Continuous Discovery in Agile and SAFe

Continuous discovery fits naturally with Agile because Agile teams already work through short cycles of planning, development, feedback, and adaptation. The discovery process adds another feedback loop before and alongside delivery.

A useful Agile product loop is

Customer learning → hypothesis → experiment → backlog decision → delivery → measurement → new learning.

In SAFe, this aligns particularly well with the idea of Continuous Exploration, which SAFe describes as continually exploring market and customer needs and using that understanding to define vision, roadmap, and features.  Product managers who own this at the train level can go deeper with SAFe Agile Product Management (APM) certification training. Continuous discovery can therefore complement:

• Product vision
• Roadmap development
• Backlog prioritization
• PI Planning
• Customer feedback
• Product metrics
• Product increments
• Continuous delivery

It is also crucial to differentiate discovery from continuous delivery. 
Continuous delivery focuses on the ability to release software and changes quickly, safely, and sustainably. DORA defines continuous delivery as the capability to release changes on demand while keeping the process low-risk and sustainable. 

Discovery asks:

Are we solving the right problem?

Delivery asks:

Can we reliably build and release the solution?

Strong product organizations need both. For teams developing their SAFe capabilities, Continuous Delivery Pipeline Managementprovides additional context on the delivery side of the product lifecycle.
 

Conclusion

Continuous discovery is not simply a collection of customer interview techniques. It is a way of organizing product work around continuous learning. The central idea is straightforward: instead of making major product decisions based on assumptions and validating them only after development, teams continuously investigate customer needs, explore opportunities, test assumptions, and use evidence to guide what they build.

The continuous discovery habits associated with Teresa Torres provide a practical structure for doing this. According to this, weekly customer conversations create regular exposure to actual customer experiences. The opportunity solution tree organizes the things a team usually learns. Likewise,  assumption mapping highlights uncertainty, and small experiments help teams in minimizing the risk ahead of substantial development investment. In the end the product trio keeps product, design, and engineering perspectives completely aligned. The approach does not mean every decision needs a research study or every feature requires an experiment. Instead, the goal is to make learning frequent, lightweight, and connected to real decisions.

For modern continuous discovery product management, that distinction is important. A team should not measure success by how many interviews it completed or how many prototypes it created. The meaningful question is whether discovery helped the team make better decisions.