Article type

Analysis methods piece / Research synthesis guide

The one thing this piece is trying to say

A lot of teams are not failing to do research.
They are failing to really begin the analysis.

The interview was recorded, the notes exist, the Miro board is full, and yet the output somehow collapses into one of a few familiar forms:

  • a handful of dramatic quotes
  • vague claims that “lots of people mentioned this”
  • plausible-sounding interpretations with unclear evidence behind them
  • a whiteboard labelled pain points

That kind of material may create energy, but it rarely supports serious product judgement.

Research analysis is not about making the material look tidier.
Its real job is this:

to turn dense, messy, context-heavy qualitative data into an evidence structure that can be compared, traced back, and used for judgement.

That is why I care so much about one thing:

if the work ends with good quotes, the analysis probably did not get finished.

Start by separating analysis from synthesis, otherwise they blur immediately

Teams often collapse these two activities together:

  • analysis
  • synthesis

Once that happens, people start drawing conclusions the moment they open the transcript, and the work slides into solution mode far too early.

A steadier sequence is this:

Analysis

Break the material apart. Tag it, sort it, and organise it. Work out what observations, behaviours, wording, and contexts are appearing repeatedly.

Synthesis

Then rebuild those pieces into higher-level themes, structures, patterns, explanations, and next-step judgements.

This distinction matters because many so-called insights are really just synthesis happening too early on top of thin analysis.

Why qualitative data is so easy to mishandle

Because it is rich, and because it tempts you.

Unlike a dashboard, qualitative data does not arrive as a neat number.
It arrives as:

  • long transcripts
  • partial notes
  • field observations
  • the participant’s own language
  • your in-session impressions
  • observer additions

The difficulty is not that there is too little. It is that there is a lot, and almost every part of it feels meaningful.

That is why the most common analysis errors are often not technical at all:

  • being overly influenced by the participant who spoke most clearly
  • over-weighting the most dramatic case
  • deciding the conclusion first and then hunting for supporting quotes
  • confusing your interpretation with an observation
  • collapsing very different frictions into one safe category

So if you asked me for the single most important first step in qualitative analysis, I would say:

slow down the feeling that you already understand it.

Thematic analysis matters not because “coding” sounds rigorous, but because it helps patterns emerge

The term thematic analysis can sound remote from day-to-day PM work.

But said plainly, it is doing something PMs should find very familiar:

taking mixed-up raw signals, breaking them apart, tagging them, and seeing which patterns are strong enough to support a judgement.

Three layers are worth keeping separate:

1. Observation

What happened in a concrete sense.

For example:

  • the participant repeatedly switched into an external chat while comparing listings
  • the participant paused before payment and searched for the cancellation policy
  • the operations user handled exception bookings in a spreadsheet before returning to the back office

2. Code

A short, reusable label for a type of phenomenon.

For example:

  • external confirmation
  • pre-payment risk check
  • back-office tool cannot handle exception flow

3. Theme

A higher-order pattern that connects multiple codes.

For example:

  • users actively rebuild safety before making high-risk decisions
  • exception cases are being absorbed by manual workarounds rather than the system
  • the product does not provide enough comparison and confirmation scaffolding

Without those layers, it becomes dangerously easy to promote a single memorable quote into an “insight”.

Coding is not about colouring every sentence; it is about creating units that can be compared later

There is a common misunderstanding here.
People often think coding means diligently highlighting every line of a transcript.

That is not the point.

Useful coding is not there to make the research look thorough. It is there to help you:

  • compare participants against one another
  • see under what conditions a problem appears
  • distinguish one kind of friction from another
  • trace evidence later without rereading the entire corpus

So the quality of codes usually matters more than the quantity.

If codes are too broad, everything turns into labels like pain point, inconvenient, or needs reassurance.
If they are too narrow, you end up with a hundred tiny labels that cannot be compared.

A simple test I use is this:

does this label help me compare across sessions?
If not, it is probably not a useful code yet.

Affinity mapping is valuable not because the wall looks full, but because patterns become visible

Affinity mapping is often misused as a kind of ceremony.

People cover a wall in sticky notes, move things around, take a photo, and stop there.
It looks productive, but it does not necessarily produce synthesis.

More useful affinity mapping usually depends on a few principles:

  • what goes on the wall should be observations, quotes, or codes, not solution ideas
  • grouping should be based on underlying patterns, not superficial wording
  • material that does not fit should be preserved, not forced into the biggest cluster
  • the final clusters should still be traceable back to evidence

One thing I care about here is this:

do not turn affinity mapping into a consensus machine too early.

Teams often feel pressure to name clusters quickly, align quickly, and decide quickly.
If that happens before the evidence has stabilised, the cleanest-sounding story can easily replace the truest one.

A good insight is not a quote; it can answer four questions at once

When I judge whether a qualitative insight is actually standing up, I look for whether it can answer four questions:

1. What is the pattern?

What exactly are we seeing?

2. In what context does it happen?

Not with everyone, and not always.
So in what task, flow stage, decision condition, or risk context does it show up?

3. What evidence supports it?

Which observations, quotes, and behavioural context are doing the lifting?

4. What judgement does it change?

Does it change the priority, the framing, the target user, the problem definition, or the next research step?

If something only answers the first question, it may still sound sharp, but it is usually just a well-phrased impression.
If it can answer all four, it is much closer to decision-ready evidence.

Do not only look for commonality; deliberately look for negative cases

This is one of the most important and least respected parts of the work.

Analysis naturally drifts towards “what everyone mentioned”.
That matters, but qualitative research cannot only be about the lowest common denominator.

Sometimes the real correction comes from the exceptions:

  • the same flow exists, but one group is not blocked at all
  • everyone complains about one issue, but the actual drop-off happens elsewhere
  • most users work around the problem, but one segment simply abandons the task
  • the same wording appears across interviews, but it points to different underlying issues

Negative cases force your themes to become more precise.
Without them, you can end up with conclusions that are broad, agreeable, and much less useful than they look.

The point of qualitative analysis is not to produce “research-like” artefacts; it is to produce decision-ready evidence

I have very little patience for research outputs that look substantial but are hard to use.

For example:

  • fifty quote cards
  • an entire wall of sticky notes labelled pain points
  • a long appendix of transcripts
  • a dozen elegantly written insight statements with no clear consequence

These things are not worthless. But if they do not improve decision-making, research slowly starts to be seen as interesting but non-decisive.

That is why the final stage is not only about naming themes. It is also about asking:

  • what level of problem does this pattern represent
  • who does it affect
  • which quantitative signals could triangulate with it
  • what next step should it trigger
    • more research
    • better tracking
    • reframing the problem
    • solution testing
    • a change in priority

That is how research moves off the wall.

A practical analysis workflow for PMs can look like this

If you want a minimum viable process a PM could actually follow, I would suggest this:

  1. do a short debrief immediately after each session
  2. consolidate observations, quotes, recordings, and field notes
  3. run a first round of rough coding without rushing to name big themes
  4. compare across participants, contexts, and user types
  5. cluster related codes
  6. identify patterns and deliberately search for negative cases
  7. lift the clusters into themes
  8. connect each theme back to the product problem and decision space
  9. only then write the insight memo or readout

Notice what this really is.
It is not a journey from notes to report. It is a journey from raw material to judgement.

When should you avoid rushing into a big affinity workshop?

I have become much more cautious about this over time.

Some teams love workshops so much that the moment data arrives, they gather everyone in a room and start clustering sticky notes. That is not always wrong, but there are situations where I would slow down:

  • the number of sessions is still too small
  • most people in the room have not seen the raw material
  • the team is already impatient to move into solutioning
  • the room has obvious power dynamics that will shape the clusters too quickly
  • the sticky notes contain interpretations rather than evidence

In those cases, it is usually better to do a smaller round of disciplined analysis first, then invite wider participation afterwards.

Closing thought

The hardest part of moving from transcript to insight is not the tool, and it is not the Miro template.
It is whether you are willing to let the evidence acquire structure before you rush it into the conclusion you already wanted.

That is the heart of qualitative analysis for me.

It is not there to make research look professional.
It is there to stop teams from mistaking the most memorable sentence for the most important truth.

In the next piece, I will move into one of the most useful and most over-sloganised parts of product research:

how PMs can use research to confirm JTBD, switching moments, and pain intensity without jumping prematurely into solutions.