Run a round of open-ended interviews and the first thing that hits you is the sheer variety of the answers. You asked one plain question — why did you stop using it? — and a hundred people answered it a hundred different ways. One says the setup “took forever.” Another says they “never got it off the ground.” A third “bounced off the onboarding.” A fourth just “ran out of patience before it did anything.” Read them side by side and it’s obvious to you, a human, that these four people are telling you the same thing. Read them to a machine that matches words, and they share almost nothing.
That gap — between what people said and what they meant — is the whole problem of synthesis. It’s the step everyone underestimates. Running the interviews is the part that looks hard, and it used to be: the scheduling, the moderating, the note-taking. Automate all of that and you’re left holding the part that was always the real work — turning the pile into a finding. A stack of true, specific, beautifully-worded answers is not an insight. Somebody still has to notice that four of the hundred ways of saying it are the same way, and that there are only really four of them.
Counting words finds the words, not the meaning
The tempting shortcut is to let the vocabulary do the grouping. Pull the common words, count them, and call the frequent ones the themes. It feels rigorous — it’s just arithmetic on the text — and it falls apart immediately, for a reason that’s almost funny once you see it: people do not reuse each other’s words. They reach for their own.
“Too slow,” “took forever,” “sluggish,” “laggy,” “I gave up waiting” — one complaint, five vocabularies, zero shared keywords between most of the pairs. Count words and this single theme shatters into five piles of one, each too small to look like anything. Meanwhile two people who both happen to say “great” — one meaning the price was great, the other meaning the support was great — get counted together into a “theme” that was never real. Keyword frequency doesn’t find meaning. It finds the accidents of who happened to phrase things alike, and it’s confidently wrong in both directions: it splits things that belong together and joins things that don’t.
The deeper issue is that language is many-to-one and one-to-many at the same time. Many words map to one meaning; one word maps to many meanings. Any method that treats the word as the unit is fighting the grain of the thing it’s measuring.
Place the meaning, then let the groups appear
The move that works is to change the unit. Stop treating each answer as a bag of words and start treating it as a point — a position in a space where nearness means “these two mean nearly the same thing,” regardless of the words each one used to get there. “Took forever” and “bounced off the onboarding” land next to each other not because they share a syllable but because they’re about the same thing: the distance between deciding to try and actually getting value. Put every answer in that space and the ones that mean the same thing pile up in the same neighborhood on their own.
Now the themes aren’t something you impose. They’re something you find. You don’t walk in with a list of four buckets and sort answers into them — that’s the other classic mistake, and it’s worse than keyword counting because it can only ever discover what you already suspected. Decide the themes in advance and every answer that doesn’t fit one gets flattened into the nearest bucket or dropped, and the one finding you didn’t expect — the one that would’ve been worth the whole study — never surfaces, because there was no bucket waiting for it. Let the groups emerge from where the points actually fall, and the surprises survive.
The themes you bring to the transcripts are the only ones you can find. The themes the transcripts bring to you are the ones worth the study.
That’s the reversal at the center of good synthesis. The codebook isn’t the input; it’s the output. You read the map of where meanings cluster, name the clusters after the fact, and the naming is honest because it’s describing a shape that was already there. Four dense neighborhoods, a few loners at the edges worth reading one by one — that’s a findings list, and it wrote itself out of what people meant.
Why this is the hard part to get right
None of this is free. Placing answers by meaning is doing real work under the hood, and it’s the place a synthesis pipeline earns or loses your trust. Put the points in a bad space and you get confident clusters of nonsense — the failure mode of every tool that hands you tidy pie charts of themes nobody would recognize. The clusters look like findings whether or not they mean anything, so the bar isn’t “did it produce groups.” Any method produces groups. The bar is whether a person who sat through those interviews would read the groups back and say: yes, that’s what I heard.
So the details matter more than the diagram lets on. How you decide where one neighborhood ends and the next begins. How many themes you let emerge before you’re just naming noise. What you do with the answer that genuinely belongs to two themes at once, because the person was making two points in one breath. Whether the loners at the edge are outliers to ignore or the early signal of the fifth theme that isn’t dense yet. Get those calls right and the collapse from a hundred wordings to four findings feels less like compression and more like someone finally saying the obvious thing out loud.
That’s the quiet promise under running research at the speed of AI User Interviews. The speed only matters if the last step holds — if what comes out the far end is a short list of things people actually meant, not a word-count dressed up as understanding. The answers were never going to match. The meanings always did. The job is just to place them where a person can see it.