How organisations implement it
Investigate how organisations typically run continuous discovery, and identify the practices and methodologies they share.
Continuous product discovery is the practice of doing discovery as an ongoing, weekly activity rather than a one-off phase at the start of a project. This thesis asks whether it can be turned into a consistent method that organisations are able to adopt, and what happens to the teams that do.
I reviewed the frameworks the field already uses, interviewed eight practitioners who run continuous discovery week to week, and ran a workshop with a twelve-person organisation that does research but had never tried it. Both data sets went through thematic analysis. The work ends with twelve guidelines for building discovery into road-mapping and delivery.
The question
The aim was to evaluate how well continuous discovery works in the organisations that have implemented it, find the gaps, and propose improvements.
The background story
Product discovery is where a team works out whether the problem it wants to solve is real, and how it should be addressed.
I picked the topic from my own work in product teams. In my organisation we were struggling with discovery and wanted to move towards talking to customers every week. With little room to experiment, it was hard to tell which version of the process would fit our structure and produce better results.
So the study set out to examine the process itself: the common methods, the variations between teams, the challenges, how organisations get past them, and where the gaps still are.
Four objectives
How organisations implement it
Investigate how organisations typically run continuous discovery, and identify the practices and methodologies they share.
Where they differ, and why
Explore the variations between organisations, and the factors that produce them.
What gets in the way
Identify the main challenges teams face, and the strategies they have developed to get past them.
How it joins delivery
Explore better ways to integrate discovery into product road-mapping and delivery.
The continuous research process and how organisations adapt it to their own products.
Organisations running continuous discovery as a full methodology.
Organisations that have adopted parts of it.
Adaptation, team involvement, the insights backlog, challenges and recommendations.
The study does not evaluate the methodology itself or rank it against others.
Organisations that do not practise continuous discovery in any form.
Comparisons against other user research methodologies or frameworks.
Before speaking to anyone, I reviewed the models that shape how discovery is practised, to find out what exists and where the gaps are.
The research a team does to understand user problems and confirm a solution works before development starts.
Six stages: alignment, research, ideation, creation, validation and refinement, with a confirmed backlog as the outcome.
Herbig’s survey of 75 product managers named the blockers: no access to users, unclear priorities, confirmation bias and predetermined solutions, and no product strategy.
Scrum, Kanban and Extreme Programming set the delivery rhythm that discovery has to fit into.
Agile keeps organisations competitive in fast-moving markets, but its cadence is built around delivery, not learning.
Any continuous discovery method has to work inside that cadence rather than beside it.
The Design Council model: discover, define, develop and deliver.
It shows divergent and convergent thinking at each stage of the design process.
It describes the shape of the work well, but treats discovery as a phase with an end.
Two models that push research closer to the team and closer to every week.
Lean UX (Gothelf) splits the work into think, make and check: form a hypothesis, build something small, test it against the assumption.
Teresa Torres frames discovery as weekly research run by a small cross-functional trio, using opportunity solution trees.
The gap: every framework describes how to run discovery well. None of them describe how to keep it continuous and consistent from one organisation to the next. That is what sent the study towards real practice.
A qualitative study, because the question is about process and reasoning rather than anything that can be measured at a distance.
People recruited from organisations already running continuous discovery, or helping others adopt it.
Eight participants, 60 minutes each, all online through Microsoft Teams.
Balanced by gender (four male, four female) and varied by age and occupation.
Roles: Principal UX Researcher, UX Researcher (Ops), Product Owner, Senior Staff Research Consultant.
Semi-structured, focused on how effective the process is, what gets in the way, and how they get past it.
An organisation that does user research but has not adopted continuous discovery.
Twelve participants, split into two teams of six, with two facilitators.
Eight male, four female, of different ages, occupations and nationalities.
Roles: product managers, product designers, UX designers, engineers and UX researchers.
Run on Miro across eight sections, balanced by time and question across both teams, with participants voting inside each section.

Ethics and recruitment
Recruitment was deliberately mixed: B2B, B2C and consulting companies, and a multidisciplinary group by age, role and background, to keep the picture from tilting one way.
Informed consent
Everyone received an information sheet covering the study and how data would be collected, including any recording, and signed a consent form before taking part.
Free to withdraw
Participants could leave at any point without consequence, and were told so up front.
Confidential and GDPR compliant
Data was anonymised and stored in line with GDPR, so the findings could be published without exposing anyone who took part.

The process
Braun and Clarke’s six-phase method, run separately on the interviews and on the workshop so neither coloured the other.
I transcribed and categorised the data into 23 initial topics, then looked for both semantic and latent themes, from what people said outright and from what they implied. That meant finding common responses, noticing the words that carried stress, grouping similar topics by colour, and comparing answers across participants.
One participant described exporting every screen in a user flow, organising them with sticky notes, marking the areas holding something valuable, and going back to the video and transcript for the exact quote. Six themes came out of the interview data, and I mapped the connections between topics and themes as I went.
Each theme came out of the six-phase analysis of the interview transcripts, and each one has its own map.

Everyone described their existing research in detail, and compared it to continuous discovery. Methods were chosen for specific objectives, and engagement had moved from second-hand feedback through stakeholders towards working directly with engineers.
Research disconnected from problem identification when it is not grounded from the start.
A technical focus rather than a user-centred one, with research treated as a non-strategic function.
Research often waits for a request from design or product, and then happens on the back of it, still testing prototypes.

Participants walked through how they run it, stage by stage.
Team, leadership and roles. Product managers and developers join sessions. Buy-in from leadership, a VP of Product for example, is what makes the commitment stick. Researchers guide and oversee rather than run everything.
Goals and data collection. Discovery is increasingly outcome-driven, with each activity tied to a strategic goal and several ways of gathering evidence.
Cadence. Weekly, fortnightly, or a four-week discovery project, depending on the team’s rhythm.
Recruitment. A steady stream of participants is what keeps the whole thing running.

How insights are captured, analysed, shared and stored, which is where most of the effort goes.
Capturing. Interviews worked from transcripts to keep verbal and non-verbal nuance. Valuable insights went into an opportunity solution tree, with user snapshots made from a template every time someone was interviewed.
Analysing. Some shared raw data with AI engineers and data scientists, while staying aware that AI-generated insights are not always actionable.
Sharing. Concise high-level takeaways and recommendations, with snapshots showing opportunities in a digestible form.

What teams get back for the effort.
For the team. The people making decisions hear from customers constantly. Adjustments happen sooner, resources go further, the risk of product failure drops, and regular feedback builds stakeholder buy-in.
For the method. Continuous learning replaces large, slow projects. It is proactive and always on, and opportunity solution trees make the reasoning behind backlog items visible.

Despite training and plans, continuous discovery is rarely fully implemented in practice.
What goes wrong. Holding a consistent cadence is hard. The wrong KPIs make progress look better than it is. Stakeholders often start with little knowledge of the method, teams default to high-fidelity prototyping instead of testing assumptions, and the volume of insights becomes unmanageable.
What helps. AI and automation for the manual work, structured frameworks, regular communication with stakeholders, cross-functional collaboration, participant management systems, regular reflection, and investment in training.

Where participants expect the practice to go next.
Quality and validation. AI summaries are inconsistent. They should be proofread and checked against your own insights, and human synthesis remains essential. As one participant put it, use AI to summarise everything, but proofread it and check it against what your assumption was.
Where it helps. Writing scripts faster, planning research, and turning a large pile of interview data into a starting point, so you never begin from a blank canvas.
Where it does not. Generating the insight itself. AI assists the work rather than replacing the thinking.
Two teams of six worked through eight sections on Miro and voted on the options they thought mattered most. These are the answers that won.
What it showed
The workshop was the part that surprised me. A team that had never run continuous discovery arrived at the same motivations and the same worries as the practitioners who had been doing it for years.
That suggests the appetite and the underlying need are already shared. What is missing is a method that fits the way a particular organisation is put together, which is what the guidelines at the end of this study try to give.
Motivation
What it could do for them
Notice market trends and adapt, identify real user problems, develop against real data and feedback, and validate the assumptions behind the roadmap.
Process
What it should include
Iterative by default, success criteria agreed with stakeholders upfront, outputs communicated back to internal teams and to the people interviewed, GDPR compliance, and clear documentation.
Team
Who should be involved
The product owner for that product, product owners and scrum teams, internal experts who know the existing process, and user researchers with the design team.
Wider business
Non-product team members
Anyone who understands the service the product affects. They can request research from skilled researchers and work alongside them, directly or through the product team.
Analysis
How to get insights quickly
Review analytics regularly, use AI to summarise responses and spot trends, consolidate social media feedback, and read support tickets for repetition.
Recruitment
How to find participants
An opt-in on the site, trusted users the organisation already knows, focus groups, and A/B testing.
Backlog
What findings should look like
Insights written as actions or recommendations with the evidence behind them, prioritised by impact, tied to a product or feature, and split into positive, neutral and negative.
AI
How AI can support it
Analyse submission and decision data, collate findings that are not usable as they stand, and read qualitative wording to identify trends and draft reports.
The short answer
Yes, with a caveat. It is feasible and it is worth doing, but only if a few essentials hold: iterative process, stakeholder alignment, and communication that actually reaches people.
Continuous discovery helps organisations understand user needs and work in a more user-centred way. The workshop organisation named four things it could do for them straight away: spot market trends, adapt faster, identify the real user problems, and use real data to validate the assumptions sitting behind the roadmap.
Time, resources and keeping users engaged remain the recurring difficulties, and getting past them takes planning and genuine stakeholder buy-in rather than enthusiasm alone.
Objective 01
Discovery gets folded into the product framework that already exists, with the details set by size, resources and team need. What recurs: opportunity solution trees, outcome-driven research, activities scaled to team capacity, a strong emphasis on testing assumptions, and AI used for discussion guides, summarising and recruitment.
Objective 02
Cadence, how much of the team takes part, the tools and methods, and how stakeholders are engaged. The drivers are culture, resources, team structure, how mature the existing practice is, and the pace of the industry. User-centred, well-resourced organisations run it more often and include more people.
Objective 03
Limited access to users and data, time and resource constraints, stakeholder alignment, confirmation bias, keeping momentum, and inconsistent methods producing inconsistent outcomes. Teams answer with automation, structured frameworks, regular communication, participant management, reflection and training.
Bringing the interviews and the workshop together, these are the twelve things that decide whether continuous discovery survives contact with a real roadmap.
Agree the goals and expectations at the start, so everyone understands the value and supports its place in the product strategy.
Put discovery tasks into sprints, and use ceremonies such as retrospectives to review and iterate on what discovery found.
Product managers, designers, engineers and researchers all take part, so insights reach product decisions directly.
Shared templates and tools for capturing and sharing insights, so findings stay accessible and actionable across the organisation.
Update the roadmap from discovery insights, so it reflects real user needs and current market conditions.
AI and automation for analysis, recruitment and feedback collection. Sensitive user data should not go into public tools to generate insights.
Regular surveys, in-app feedback or customer advisory boards, so the product stays aligned with user needs between studies.
A framework such as an opportunity solution tree or a value-versus-effort matrix, so the most useful insights drive development.
Teach research, analysis and how to use findings. Until people are trained, they join as observers or note-takers rather than running interviews.
Schedule a debrief after each activity to review insights and agree next steps, and refine the process from what worked.
Measure insights generated, the speed of iteration, or the effect of discovery on decisions, so its importance is visible.
Encourage teams to test assumptions continuously and learn from what fails, which is where the innovation comes from.
Future work
Longitudinal studies
The long-term effect of continuous discovery on product success and organisational performance.
Scaling across contexts
How it scales across large organisations and many teams, balancing a standard process against local flexibility.
Cross-industry comparison
Sector-specific challenges and practices across technology, healthcare, finance and consumer goods.
Training effectiveness
Which training methods best equip people who are not researchers with continuous discovery skills.
It can be made consistent, as long as it stays adaptable.
The evidence from eight practitioners and a twelve-person workshop says a shared method is possible, resting on iterative process, stakeholder alignment and clear communication, while flexing to each organisation’s culture, resources and maturity. The twelve guidelines are the practical form of that, and the recommendations mark where the evidence is still thin.
I write about this on the blogIts own data first, then the published work the literature review drew on.
Semi-structured interviews with eight continuous discovery practitioners, anonymised P1 to P8, 60 minutes each, online via Microsoft Teams. Every participant quote in the findings comes from these sessions.
A workshop with twelve participants, two teams of six plus two facilitators, at an organisation that does research but had not adopted continuous discovery. Run on Miro.
Questionnaires and online polls used to gather initial data on experience, choices, requirements and preferences.