Talking to users every week produces a mountain of notes, quotes and observations. The real challenge is not gathering all of that. It is turning it into decisions before it goes stale.
This came up in all eight interviews I ran for my MSc thesis. Here is what the teams who did it well actually did.
Capture insights as you go
Every practitioner I interviewed used a template to capture sessions, rather than writing them up from scratch. The common pattern was a short snapshot for each interview, holding three things: the high-level takeaways, the recommendations that follow from them, and direct user quotes as evidence.
A few habits made this work:
- Get the transcript. Recording and transcribing lets you catch both what was said and the non-verbal detail around it.
- Keep the user’s own words. A real quote carries far more weight than a paraphrase.
- Put the good ones somewhere structured. Several teams moved valuable insights straight onto an opportunity solution tree so they stayed connected to an outcome.
- Do not document dead ends. Participants deliberately skipped writing up ideas that went nowhere, to keep the record focused.
- Get consent, and anonymise. Consent for recording and sharing anonymised data is part of the capture step, not an afterthought.
Debrief straight after every session
The habit that came up most consistently was a short debrief right after each interview. The team spends ten minutes together while the session is fresh, agrees what they heard, and notes what to ask next time.
These quick debriefs act like mini-retrospectives. They surface the important points immediately, improve the next interview, and get the whole team to a shared understanding without anyone having to read a long report.
They are not effortless. Participants were clear that debriefs take time and patience, and that the team has to work at separating what they actually observed from what they assumed. For deeper questions, teams followed up with proper thematic analysis, grouping feedback into common themes.
Analyse quickly, with help
Nobody has unlimited analysis time. Participants named five things that sped it up:
- AI transcription and summary tools. One team used a tool called Listen Up, which produced a card holding both the transcript and an AI-generated summary. Others used AI to record, transcribe and summarise calls, which cut the time to a first set of key points considerably. It still needs checking.
- Surveys and forms during sessions, which capture structured data in real time and auto-generate reports.
- Shared note-taking in Miro, so everyone’s observations are in one place before the debrief.
- Sharing straight after the session, often into Slack, or as a mobile-friendly image on WhatsApp, so insight travels while it is fresh.
- The snapshot approach, which links each insight back to the interview notes it came from.
One caveat worth carrying. Some teams shared raw data with AI engineers and data scientists to generate findings at scale, but noted that AI-generated insights are not always actionable. I go into that more in continuous discovery and AI.
Keep an insight backlog that stays useful
Insights are only worth collecting if you can find and act on them later. Most of the teams I studied kept an insight backlog or repository, and revisited it on a regular schedule, often every quarter or every six months. One participant described the opposite situation, working without a research repository at all, and named it as a real problem.
What made a backlog useful:
- Actionable items, not raw data. Insights framed as recommendations, with the evidence attached.
- Two levels. Higher-level opportunities, and smaller actionable items underneath them.
- Tags and structure, so you can retrieve related insights quickly. Simple tools work: some teams used Excel sheets, others a dedicated repository.
- Regular reviews, so patterns surface over time instead of getting buried.
- A tool the whole team can reach. Participants named Notion for documentation, Dovetail for research data, Jira for integration and automation into delivery, and Miro for visual synthesis. Handwritten notes and Word documents still had a place alongside them.
A warning that came up more than once: do not let a pattern become an opportunity on its own. A recurring comment might just be a bug to fix. Insights should inform decisions, not automatically dictate them, and they should line up with business goals.
Share insights so they get used
An insight nobody sees changes nothing. The teams who had impact made sharing effortless:
- Short, visual share-outs. One-pagers, or a handful of slides, rather than long documents. One researcher aimed for seven to twelve slides at most, usually built in Miro.
- Workshops, not just documents. Several teams presented research in a workshop and worked through how to use the findings together, which is what made them actionable.
- Regular rhythms. Insights went into weekly updates or monthly stand-ups so they stayed in front of the team.
- Easy access. Mobile-friendly summaries and clickable links, so people could dip in when they wanted.
- The right people in the room. When product, design and engineering join the sessions themselves, you need far less communication afterwards.
Someone has to decide
Sharing is not the finish line. The product manager or product owner reviews the insights and makes the call, and not every insight leads to a new feature. Being explicit about who decides is what stops a well-run research process from quietly stalling.
Expect some friction here. Participants described leadership who did not believe in working from objectives and hypotheses, limits on tools and time, resistance to new methods, and the plain difficulty of making sure shared insights are actually read and understood. Balancing feature delivery against discovery takes diplomatic conversation with stakeholders, not just better documentation.
The mindset that ties it together
Across all of this, one principle stood out: prioritise actionable insight over raw data. Collecting more is easy. The work that pays off is distilling what you have into something a team can act on, and making it impossible to ignore.
Next in the series: the benefits of continuous product discovery. Or step back to the continuous product discovery process.
Further reading
- Teresa Torres, Product Talk. producttalk.org
- My MSc research. Read the case study
Next, read the benefits of continuous product discovery.
Based on my MSc thesis on continuous product discovery. See the case study for the research behind it.
