People often ask whether continuous discovery is just user research with a new name. It is a fair question. The methods overlap a lot. What changes is the rhythm, and that change has real consequences.
Here is how traditional user research and continuous product discovery differ, based on eight semi-structured interviews with senior practitioners, analysed using Braun and Clarke’s six-phase thematic analysis, for my MSc thesis.
| Traditional research | Continuous discovery | |
|---|---|---|
| Cadence | A project, run now and then | A steady weekly habit |
| Who runs it | A dedicated researcher | The whole product team |
| Speed to insight | Weeks, ending in a report | Days, ending in a decision |
| Relationship to the team | Runs in its own lane | Sits inside the team |
| Best for | Big, strategic questions | The steady flow of product calls |
How traditional research usually works
In many organisations, research is a service. A product or design team has a question, they raise a request, and a researcher picks it up. The researcher runs a study, analyses it, writes a report, and presents the findings.
It is thorough, and for big strategic questions it is exactly right. But the practitioners I spoke to were honest about where it falls down day to day. Their answers grouped into a clear set of problems:
- It is reactive. Research waits for a request instead of running ahead of the team. As one participant described it, research often waits until a request comes in through design or product, and then reacts to it.
- Design and problem-finding get separated. When design is not grounded in research from the beginning, you get products that miss both user needs and business goals.
- Technical detail crowds out user needs. In companies led by technical architects, teams tend to focus on the technical build and overlook whether people actually want the thing.
- It is treated as a tick box. Several participants said research is not seen as a strategic function, and that findings may be ignored if they contradict existing plans.
- Research teams work in isolation. Communication barriers were a recurring theme, including marketing teams blocking direct contact with customers.
- Stakeholders bypass it. Product managers sometimes skip research because of what it might do to an existing plan, even though poor discovery can lead to significant financial losses.
- Data protection law limits access. GDPR in Europe and LGPD in Brazil came up as real barriers. Compliance restricts what data can be collected, which affects the quality of the insights.
- It arrives too late. Research is often introduced so late that usability problems which could have been caught early are already built.
What continuous discovery changes
Continuous discovery keeps the same core methods, such as interviews and careful analysis, but changes the cadence and who takes part.
- It runs continuously. Instead of one big study, you talk to a few customers every week.
- The team takes part. Product managers, designers and engineers join the conversations, so insight reaches the people making decisions directly.
- The loop is short. You can act on what you learn within the same sprint.
- It stays customer led. Because you are always listening, the roadmap keeps answering to real needs.
- It builds buy-in. Regular user feedback increases buy-in from both users and stakeholders. As one participant put it, if you do not have buy-in from your user, your product is dead in the water and millions of dollars are wasted.
Of the eight practitioners I interviewed, four pointed to this customer-led rhythm as the real difference. Two felt the underlying research methods are not really different at all, and that only the cadence changes. Both views are worth holding: the techniques are familiar, but running them as a habit changes what the team does with them.
The trade-offs
Continuous discovery is not automatically better. It brings its own risks.
- Bias from a small, repeated group. Talking to the same handful of users can reinforce what you already believe. You have to rotate participants and stay honest.
- Volume. Weekly conversations produce a lot of raw material that has to be turned into decisions.
- It is hard to sustain. Keeping the habit alive over months takes real commitment.
Traditional projects still have clear strengths. They are time-bound, which suits broad questions that guide the roadmap rather than the next sprint.
Do you have to choose?
No. The strongest teams in my research ran both. Participants described this as dual research paths: a continuous, always-on stream tied to product outcomes, plus more focused, time-bound projects for the big questions. The example one participant gave was deciding how to incorporate AI into the product, which needed its own time-bound study to answer.
A good rule of thumb:
- Use continuous discovery for the steady flow of product decisions.
- Use a focused research project when the question is large, strategic or unfamiliar.
New to the idea? Start with what is continuous product discovery. Ready to run it? See the continuous product discovery process.
Further reading
- Teresa Torres, Product Talk. The clearest writing on running continuous discovery. producttalk.org
- My MSc research. Eight expert interviews and a team workshop on how teams actually do this. Read the case study
Keep going with what is continuous product discovery or the process, step by step.
This post is based on my MSc thesis on continuous product discovery. More about the research is in the case study.
