Continuous discovery sounds simple until you have to run it. Then the real questions show up: how often, with whom, run by whom, and what do you do with everything you hear?
For my MSc thesis I asked eight senior practitioners exactly that, then ran a workshop with two product teams to test the answers. Here is the process they described, laid out step by step.
1. Start with outcomes, not features
Teresa Torres frames this as setting your business goals first, then defining the product outcomes that will help you reach them. The teams in my research worked the same way. Research without a goal drifts. A clear outcome keeps every conversation pointed at something that matters.
Participants described three kinds of research goal, and it is worth knowing which you are running:
- Traditional research projects. Time-bound studies answering broader questions that guide the roadmap, such as how the organisation should incorporate AI.
- Product outcome focused. Continuous, always-on research tied directly to a product outcome.
- Dual research paths. Both at once, which is what most of the stronger teams did.
2. Decide what to research first
You will always have more questions than time. Participants used structured ways to choose: scoring systems, prioritisation matrices, and revisiting the list as new information arrives.
Anything that cannot be done now goes into a backlog to return to rather than being lost. Several teams kept an opportunity solution tree, Torres’s method for mapping opportunities against outcomes, and treated it as a living document rather than a one-off diagram.
3. Build a cross-functional team
Discovery is not a solo job for a researcher. The people who make product decisions should hear from customers directly. In practice that means a product manager, a designer and an engineer taking part, often with roles assigned for each session: one person leads the interview, one takes notes, one observes. Researchers guide and give oversight rather than being the only ones allowed to do research.
One thing participants were firm about: initial buy-in from leadership matters. Clear direction from someone senior, such as a VP of Product, has a significant effect on whether the team actually commits.
Involving the team does more than share the load. It builds ownership, so the whole team feels responsible for the product and can make decisions without waiting for a report.
4. Set a cadence and protect it
Cadence is what makes discovery continuous. The rhythms varied across the teams I studied, from two weeks to four to six. The most common pattern was a two-week sprint, talking to two or three users a week, with a fixed day reserved, such as a research Friday, so the time did not get eaten by delivery.
The first week of a cycle tends to go on planning: writing the discussion guide, recruiting, and getting the first interviews booked. Recruitment then runs weekly or every two weeks so there is always a flow of people to talk to.
5. Recruit participants continuously
A weekly habit needs a steady supply of the right people. Participants named the tools they use: internal panels and panel management companies such as Rally UX, recruitment platforms such as Respondent and UserTesting, and agencies where the audience is harder to reach. Some organisations have a dedicated research operations team that owns recruitment and scheduling.
One team kept a managed pool of around a hundred users and rotated through it based on relevance, with a cooling period so the same people were not asked too often. Referrals from happy participants widened the pool further.
Two things to plan for. GDPR compliance and unstructured user data make it genuinely hard to reach users directly in some organisations. And third-party tools such as Playbook, QX or UserZoom work well for broad consumer audiences but are often a poor fit for specialised or B2B ones, where agencies help but take longer.
When your own users run thin, widen the net: former users, non-users, prospects, and look-alike audiences in similar roles or industries.
6. Collect data from more than interviews
Interviews are the backbone. Teams used jobs to be done interviews early on to understand what users are really trying to achieve, then regular weekly or biweekly interviews for ongoing insight.
They also pulled signal from support tickets, sales feedback, product analytics, user behaviour data, social channels and app store reviews. Some monitored community spaces, including a Discord server for the people who love the product most. Bringing these together gives a fuller picture than any single method.
7. Test assumptions before you build
This was one of the clearest lessons. Under pressure, teams tend to jump to a high-fidelity prototype to test a solution. The more useful move is to test the assumption behind it first: what would need to be true for this to work? Participants stressed having very clear metrics attached, so you know in advance what would count as success.
My own advice on top of the research: once you have written the assumption and the metric, run the smallest test that would answer it rather than the most impressive one.
8. Adapt the process to fit
No team followed a framework to the letter. They used opportunity solution trees, or Jira, or simple templates, whatever fitted their setup. They treated every project and participant as unique, used templates and automation to save effort, and fitted the work inside whatever scaled agile framework they already had.
Keeping a stable core while flexing the details is what let them sustain it.
What comes next
Running the sessions is only half the job. The other half is turning what you hear into decisions, which I cover in how to turn research insights into action.
New here? Start with what is continuous product discovery. Worried about keeping it going? Read 11 challenges of continuous product discovery.
Further reading
- Teresa Torres, Product Talk. Continuous discovery and the opportunity solution tree. producttalk.org
- My MSc research. Eight expert interviews and a twelve-person workshop. Read the case study
Next, read how to turn research insights into action.
Based on my MSc thesis on continuous product discovery. The research is written up in the case study.
