Thematic analysis is the method most product and research teams are using when they say they "synthesized" their interviews — whether or not they call it that. It is a way of finding, naming, and reporting the patterns that repeat across qualitative data: interview transcripts, open survey answers, support conversations, usability-test debriefs. This guide explains the method as it applies to customer and user interviews specifically, walks through thematic coding on a real example, and is honest about where it takes judgment and where software can carry the load.
What is thematic analysis?
Thematic analysis identifies themes — patterns of meaning that recur across a dataset — by systematically coding the data and then grouping the codes. The most widely used framing is Braun and Clarke's six-phase approach from psychology, and it transfers to product research almost unchanged: familiarize, code, build themes, review themes, define themes, report.
It differs from a summary in one crucial way. A summary tells you what each interview said. Thematic analysis tells you what the interviews together say — which is the only thing you can build a decision on.
Inductive vs deductive thematic analysis
- Inductive (bottom-up): the themes come from the data. You code what you find and let the themes emerge. Right for discovery and anything exploratory.
- Deductive (top-down): you start with a framework — say, the five stages of your onboarding flow — and code the data against it. Right for evaluative work where the question is fixed.
Most product research is a hybrid: a few deductive buckets you know you need (pain points, requests, workarounds), inductive within each.
Semantic vs latent themes
Semantic themes stay at the surface of what was said ("users want exports"). Latent themes interpret what lies under it ("users don't trust the in-app numbers, so they export to check"). Product teams usually stop too early, at the semantic level; the latent theme is where the actual product decision lives.
The six phases, applied to interviews
1. Familiarize
Read every transcript once before coding anything. Note the moments where the participant's tone shifted — frustration, relief, a laugh — because that is usually where the meaning is. Get transcripts first: how to transcribe an interview covers the fast way.
2. Generate initial codes (thematic coding)
A code is a short label attached to a specific passage: rebuilds report weekly, distrusts dashboard numbers, wants change alerts. Go through every transcript and code every passage that bears on your research question. Two rules make coding usable later:
- Keep the quote attached. A code without the passage it came from can't be checked, and you will need to check.
- Code the meaning, not the words. Two people describing the same problem in different language get the same code.
On a first study you will generate far more codes than themes — 40–80 codes across eight interviews is normal. That is fine; consolidation comes next.
3. Search for themes
Group the codes. Codes that describe the same underlying pattern become a candidate theme. Rebuilds report weekly, copies numbers into Sheets, keeps a parallel tracker are three codes and one theme: the product's reporting isn't trusted or complete enough to use directly. This is the step people mean by "affinity mapping" — see affinity mapping in UX research for the hands-on version.
4. Review themes
Check each candidate theme two ways. Against the coded extracts: do the quotes actually support it, or did you group by resemblance? Against the whole dataset: does the theme hold across participants, or is it one vivid interview? Merge themes that turn out to be the same thing, split ones that are two things, drop ones with a single source.
5. Define and name themes
Write each theme as one sentence that states the pattern and the evidence: Ops leads at 50–200-person companies rebuild the weekly report by hand because the in-app numbers lag and can't be filtered by team — 5 of 8 interviews. A name like "Reporting friction" is a label; the sentence is a finding.
6. Report
For product work, the report is rarely a document. It is the set of themes with their evidence counts, carried into prioritization. Each theme should be able to open to the quotes behind it, because the first thing a skeptical stakeholder will ask is "who said that?".
Thematic analysis example
Eight discovery interviews with operations leads. After familiarization and coding, 61 codes. Grouping produced eleven candidate themes; review merged them to six and dropped one with a single source. The top three, defined:
- Weekly report is rebuilt by hand (5/8) — because in-app numbers lag and can't be cut by team.
- Nobody knows what changed since last week (4/8) — leads to Monday-morning archaeology; two participants asked unprompted for a "what moved" summary.
- Tried a tool for this and abandoned it (3/8) — setup cost outweighed the benefit for a team of this size.
Those three sentences, each one click from the quotes, are the entire deliverable — and they are already most of a roadmap. Theme 1 is a feature; theme 2 is a feature; theme 3 is a constraint on how both must be built.
Common mistakes
- Coding by keyword. Searching transcripts for "export" and calling the hits a theme. Themes are patterns of meaning; the keyword is at best a clue.
- Themes that are topics. "Reporting" is a topic. "Reporting is rebuilt by hand because numbers aren't trusted" is a theme.
- Counting instead of weighing. Frequency matters, but so does strength and who said it. One enterprise champion's dealbreaker may outweigh three mild complaints.
- Losing the link to evidence. The moment a theme is separated from its quotes, it becomes an opinion with a research-shaped label.
- Stopping at semantic themes. If your themes are feature requests, you haven't analyzed yet; you've transcribed the backlog.
Where software helps — and where it doesn't
Thematic analysis is labor-intensive in a specific way: the coding is exhaustive and mechanical, the theme-building is judgment. That split maps neatly onto what AI is good at.
Software carries: transcription, first-pass coding of every transcript (pain points, requests, quotes, with timestamps), proposing groupings across interviews, and keeping every theme linked to its evidence so the report is checkable.
You carry: deciding what the research question is, judging whether a proposed theme is real or a resemblance, naming the latent theme under the semantic one, and deciding what to do about it.
Dedicated thematic analysis tools range from academic QDA suites built for the manual method to research platforms that automate the coding. For customer and user interviews specifically, Intervool does the first-pass coding on every interview automatically, proposes the themes across them, and carries the ones you accept into a prioritized roadmap — with every theme still one click from the customer who said it.
