Researching how teams run continuous product discovery

Turning continuous product discovery into a repeatable practice.

Continuous product discovery means talking to customers regularly, so their feedback shapes every step of building a product and not just the start. It is a good idea that teams find hard to keep going. My MSc thesis asked whether it could be turned into a consistent method that organisations can adopt, and what actually happens when they try.

The question I set out to answer.

The whole study was built around a single research question, taken straight from the thesis.

Aim

To evaluate the effectiveness and usability of continuous product discovery in organisations that have implemented it, identify any existing gaps, and propose potential improvements.

Objectives

A qualitative study with two groups.

I chose a qualitative approach, as it best fitted the questions I was asking. Recruitment ran in two stages. First I built a list of organisations on LinkedIn that carry out product discovery, deliberately spanning B2B, B2C and consultancy so the sample would not skew to one kind of company. Then I ran a screening survey through Microsoft Forms, alongside polls on LinkedIn, Reddit and Slack, to find people genuinely involved in continuous discovery. The most relevant respondents were invited to interview.

I aimed for a deliberately multidisciplinary group, spanning different ages, roles, nationalities and professions, to reduce the risk of one perspective dominating the findings. That produced two participant groups: professionals who already practise CPD, and a team at an organisation that does not.

Research ethics

Because the study involved real practitioners talking about how their organisations work, the ethics had to be handled properly before any session took place.

Eight in-depth interviews.

I ran individual, semi-structured interviews with the eight practitioners, each around 45 to 60 minutes and held online on Microsoft Teams, recorded through the summer of 2024. I followed a pre-defined discussion guide of fourteen open-ended questions so I could cover the key topics while still letting people elaborate and raise things I had not thought to ask.

Semi-structured interviewing suited this well: enough structure to compare answers across participants, enough flexibility to follow whatever emerged. Qualitative research is iterative, so early analysis fed back into later interviews. Questions that were not producing useful information got dropped, and new ones were added as topics surfaced.

The tool chain was simple. Teams recorded both audio and video, Dovetail produced the transcripts and held the first round of tagging, and the deeper thematic analysis happened on a Miro board where I could physically move codes around.

A two-hour ideation workshop.

The interviews told me what practitioners who already do this believe. The workshop was there to pressure-test those themes against a team that had not adopted CPD yet, and to find out what they would actually need to make it work.

It ran for two hours with the twelve participants, split into two rooms of six with a facilitator each, working on a Miro board over Microsoft Teams. Each room took four of the eight themes, giving twenty-five questions in total. The board was laid out simply: a theme, its questions, and space for sticky notes underneath.

The rhythm mattered. Each question got about four and a half to five minutes of ideation, where everyone added sticky notes at once, and then three votes per person to surface what the group thought mattered most. That kept quieter people from being talked over, and it produced something the interviews could not: a ranked answer to each question. The whole session was recorded, and the answers were then analysed the same way as the interview data, sorted by the number of votes each one received.

From 23 codes to six themes.

I analysed the interview and workshop data with thematic analysis, following Braun and Clarke’s six-step method. After transcribing and categorising the data into 23 initial topics, I reviewed and grouped them into six main themes.

The coding worked on two levels. Semantic codes captured what participants said directly. Latent codes captured what was implied underneath, which is where a lot of the useful material sat, particularly around why teams quietly abandon the process. I looked for repeated concepts, words that carried emphasis, and points where participants contradicted each other, then compared responses across all eight to see which patterns held.

What the research showed.

The analysis produced six themes that run across the whole discovery lifecycle, from how teams run research to how they feel its impact and where it breaks down. The clearest lesson across all of them is that the hardest parts of continuous discovery are rarely about research technique. They are about alignment, buy-in, and keeping up a habit.

I am writing up the detailed findings as a series of posts, so the depth lives there rather than here. The first one covers the challenges: 11 challenges of continuous discovery, and how teams overcome them →

Twelve guidelines, now in practice.

From the themes I wrote a set of twelve guidelines for building continuous discovery into product roadmapping and delivery. The research did not stay on the page. In my current role I have since embedded a continuous research framework into the product roadmap, so the thesis is being put into practice on live work.

Where the research goes next.

The thesis points to clear next steps: longer-term studies of how continuous discovery affects product success, work on scaling it across large organisations and many teams, comparisons across different industries, and a closer look at how best to train non-researchers to take part. I am carrying the approach forward in practice and refining it as I go.