If your team keeps shipping features that do not quite land, the problem is often not the design or the code. It is that the research happened too late, or only once, at the very start of the project.
Continuous product discovery is a way to fix that. This guide explains what it is, how it works, and how to begin, based on my MSc research into how real teams run it.
What does continuous product discovery mean?
Product discovery is the work of figuring out what to build and why, before you build it. You research the problem, understand your users, and check that your idea is worth the effort. Münch, Trieflinger and Heisler describe it as six stages: alignment, research, ideation, creation, validation and refinement. The outcome you are aiming for is a confirmed product backlog that can feed a real roadmap.
Continuous product discovery takes that work and spreads it out. Instead of doing all the research at the start of a project, you do a little every week, all the time. Customer feedback then shapes the product at every step, not just at the beginning.
The term was made popular by Teresa Torres. Her definition is that continuous discovery means doing research in small steps throughout the process of making a product, instead of doing all the research at the beginning, so customer feedback informs product decisions continuously.
Why teams need it
Product discovery has a poor track record. Herbig surveyed 75 product managers about what stops them running effective discovery, and the top four answers were revealing: not enough access to users and research, no clarity on priorities, confirmation bias and predetermined solutions handed down by management, and no clear product strategy.
Notice that only one of those is about research skill. The rest are about access, priorities and organisational habits, which is exactly what continuous discovery tries to change.
How is it different from a one-off research project?
Traditional research often works like this: a request comes in, a researcher runs a study, writes a report, and hands it over. It can take weeks, and by the time it lands the moment may have passed.
Continuous discovery is different in three ways:
- It is always on. You talk to customers regularly rather than waiting for a big project.
- It is customer led. Decisions stay close to real user needs because you are always hearing from real users.
- The feedback loop is short. You learn something on Monday and can act on it the same sprint.
| One-off research | Continuous discovery | |
|---|---|---|
| When it happens | At the start of a project | Regularly, all the time |
| Who runs it | A dedicated researcher | The whole product team |
| Speed to insight | Weeks, ending in a report | Days, ending in a decision |
I go deeper on this comparison in continuous discovery vs traditional user research.
What the process looks like
In practice, teams who do this well tend to follow a loop:
Torres sets it out in six steps. You start with your business goals, then define the product outcomes that would move them. You hold regular conversations with customers, led by key members of the product team, usually the product manager, the design lead and the tech lead. You turn what you hear into opportunities, focus on one, and brainstorm solutions. Then you pick three solutions to test rather than committing to the first idea.
Cadence matters more than the exact steps, and it varied a lot in my research. Teams reported running discovery on two, four and six week rhythms. The most common pattern was a two week sprint with two to three user conversations a week. For a full breakdown, see the continuous product discovery process, step by step.
Why teams are adopting it
The teams in my research pointed to a few clear gains: shorter feedback loops, whole-team ownership of the product, earlier removal of risk, and a steady closeness to customers that keeps the roadmap honest. I cover these in the benefits of continuous product discovery.
It is not free. It takes time, buy-in and a change of habit, which is why so many teams struggle to keep it going. I wrote about those hurdles in 11 challenges of continuous product discovery.
Where to start
You do not need a research team or a big budget to begin. Start very small:
- Pick one product outcome you care about.
- Book two customer conversations for next week.
- Bring one other person from your team to listen in.
- Write down one thing you learned, and one assumption you want to test.
Do that for a month and you will have the beginnings of a continuous discovery habit. Small, steady steps beat a grand plan that nobody keeps up.
Further reading
If you want to go deeper, these are good places to start:
- Teresa Torres, Product Talk. The clearest writing on continuous discovery and the opportunity solution tree. producttalk.org
- The Double Diamond, Design Council. A simple map of the wider design process behind discovery. designcouncil.org.uk
- My MSc research. Eight expert interviews and a team workshop, analysed with Braun and Clarke’s six-phase thematic analysis. Read the case study
From here, keep going with the continuous product discovery process or the 11 challenges to expect.
This post draws on my MSc User Experience Design thesis on continuous product discovery. You can read about the research itself in the case study.
