Deadlines don't wait for synthesis. Why the rigor-versus-speed dilemma is built on a false assumption, and how PMs under time pressure can turn a backlog of interviews into evidence-linked problems.
You did the discovery work you were supposed to do. You found the users, got the calls scheduled, asked the open questions, and resisted pitching your own solution. Now two or three interviews - maybe five - sit in your notes, and each one holds at least one moment where you thought: there it is, that's the real problem. Then the deadline moved closer, and the interviews stayed where they were.
This is worth pausing on, because the interviews themselves were never the hard part. A conversation can be begged, borrowed, or scheduled into existence. What resists scheduling is the work that comes after: reading a transcript back, pulling the quotes that matter, noticing that two people described the same struggle in different words, and writing the problem statement a teammate could act on. That work - synthesis - asks for long, uninterrupted attention, and long, uninterrupted attention is precisely what a delivery deadline consumes first. The backlog is not evidence that you skipped a step. It is evidence that synthesis, as normally practiced, costs a kind of time you no longer have.
The raw material does not make it easier. One product lead we interviewed, describing what she was actually synthesizing from - customer requests, support threads, competitor notes, fragments of calls - reached for a phrase we haven't been able to improve on:
"It's a hotpot of everything - everything is everywhere, all at once."
- a product lead at a developer-tools company
If synthesis were merely reading, a hotpot would be manageable. It is the combination - scattered material, and a kind of work that demands unbroken hours - that turns three interviews into a debt.
What happens when the time runs out is remarkably consistent across our interviews, and it is not that discovery stops. The roadmap does not pause for synthesis. Instead, quietly, the evidence gets downgraded.
A senior PM at a B2B software company described the trade without flinching:
"I'll sacrifice the quality of the insights so that we can move on and produce suggestions more quickly. I think if the process is this slow, then we're all gonna be fired."
Another product lead walked us through how a recent feature reached the market in a few weeks. Interviewing actual users never entered the plan - "không có cái luxury cho cái việc đó," she said; "we don't have the luxury for that." Her team ranked its information sources by how quickly they could be reached, not by how much they revealed:
"Obviously we have to save time, so the sources that are easiest to get come first - not the sources with the highest quality of information."
And a head of product at an edtech startup described what synthesis looks like on most teams, most of the time:
"Everyone who joined the interview takes notes, then we sit down and brief each other. We don't sit down and synthesize properly."
It would be easy to read these as confessions, and the people saying them half-treat them that way. But none of this is negligence. It is a rational response to a real constraint, made by people who know exactly what they are giving up. A PM in a Reddit thread about doing discovery without a researcher stated the constraint as if it were a law of nature: "Researchers optimize for rigor. PMs need speed-to-insight." Put that way, the situation looks like a permanent dilemma - rigor or the deadline - and every PM quoted above has, at some point, picked a side.
But a dilemma is only as solid as the assumption underneath it, and the assumption underneath this one is that synthesis is a single, indivisible kind of work - that the hours of re-reading and the seconds of recognition come as a package, so that losing the hours means losing the recognition too. The most experienced people we spoke to had stopped believing that, and the rest of this essay is about what they believe instead.
The first crack in the dilemma is a question about diminishing returns. The most rigorous practitioner in our corpus put numbers on it. Synthesizing manually, her team captured perhaps 90–95% of what an interview contained; the one time she tried a fully automated pass, it captured 70–80%. What is interesting is the question she drew from that comparison. It was not "how do we close the gap." It was:
"Did we need to interview that many stakeholders? Should we focus on covering 80% of insights instead of extracting insights until nothing new emerges?"
The question matters because exhaustiveness - extracting until nothing new emerges - is exactly what makes synthesis unaffordable, and exhaustiveness is rarely what the decision in front of you requires. Most product decisions turn on the pattern that shows up loud and repeated across interviews, not on the subtlety hiding in the last fifth of one transcript. If the bar is "enough coverage to make this decision well" rather than "everything these interviews contain," then much of the rigor-versus-speed dilemma was never about rigor at all. It was about a bar nobody had consciously set.
Lowering the bar from 95% to 80%, though, only shrinks the problem - it doesn't change its nature. Synthesis at 80% coverage, done by hand, is still hours of work per interview. The deeper crack in the dilemma is elsewhere.
The product lead with "no luxury" for traditional research described what AI had actually changed about her week, and the sentence rewards a slow reading:
"With AI, what takes my time now is reviewing the output - not producing the work itself."
Buried in that remark is a distinction the word "synthesis" hides. Synthesis, as normally practiced, fuses two different kinds of work. There is production: re-reading transcripts, copying quotes out, sorting them into themes - clerical, slow, measured in hours. And there is judgment: looking at a candidate insight and knowing whether it is real - whether this is felt pain or polite noise, whether two quotes describe one struggle or two. Judgment is fast, it draws on everything you know about your users and your market, and it is the part of the work that is genuinely yours. The deadline destroys production. It never had any quarrel with judgment.
Seen through this distinction, the trade described in the section above becomes precise. When time ran short, those PMs were forced to abandon production - and because judgment has no material to work on without it, the judgment went too, replaced by whatever the easiest sources happened to say. The fix is equally precise: hand production to a machine and keep the judgment. That is what "covering 80%" means in practice. The automated pass produces the candidates; your scarce attention decides which of them are true.
But this arrangement holds only under one condition, and the condition is the whole game: judgment needs the source. An AI summary floating free of its transcript cannot be judged, only trusted - and unverifiable trust is exactly what made the PMs above uneasy about automating in the first place. The 80% pass is safe when every extracted insight remains attached to the words the user actually said, so that checking a claim costs seconds rather than a re-read. Break that attachment and you have not separated production from judgment; you have merely automated the production of things nobody can judge.
That condition - evidence that stays attached - is the specific thing CLRA is built around.
Here is what separated synthesis looks like for one interview in CLRA. It is designed to fit the time you actually have - the gap between two meetings - because each step is one side of the distinction: the machine produces, you judge, and the anchoring holds the two together.
Add your notes or transcript to CLRA as an interview. If you ran the session against a research plan (CLRA's question templates), the notes arrive organized question by question; a raw transcript works too. And if your notes live in markdown somewhere else, the CLRA MCP server pipes them into the workspace without copy-pasting.
Ask CLRA's assistant to summarize the interview and extract highlights. This is the production pass: the AI reads the full note and surfaces candidate insights as highlights, each one anchored to the exact place in the interview it came from. This step is the part that used to be your evening.
Walk the extracted highlights with the source pinned beside them. Keep what is real; discard what is plausible but hollow; add the one or two moments the AI missed - the place where the user's voice changed, the aside that answered no question you asked. Because each highlight anchors to the interview, verifying a claim takes seconds. This is where the 80% becomes trustworthy - not because the machine was right, but because you checked.
Promote what survived into a problem, framed as a job story:
When I'm doing discovery for a big feature and the deadline won't move, I want to be confident my spec solves the right user problem, so that I don't become the bottleneck to the business goal.
That example is real - it is the problem in our own workspace, synthesized from the interviews quoted throughout this essay. The problem stays linked to the highlights that justify it, which means the judgment you exercised today remains auditable next quarter: when someone asks "says who?", the answer is verbatim quotes, one click away.
It is worth being honest about the nearest alternative, because most teams under pressure have already tried it: paste the transcript into a Notion page, ask ChatGPT for the themes, paste the themes into another page. Notice that this performs the same separation - the machine produces, you skim - and it works, exactly once, at the moment you do it, while your memory still connects each theme to the conversation it came from. Then the connection decays. The summary sits in a page with no live link back to the words underneath it; the page drifts away from the roadmap; and three weeks later the theme is something the team believes without being able to say why. The condition from earlier - evidence that stays attached - fails, and with it the safety of the whole arrangement.
Unlike a general-purpose doc tool, CLRA gives user problems a home that is structurally tied to its evidence: job stories linked to tagged, verbatim highlights, accumulating across every interview you synthesize rather than decaying in a page nobody reopens. The point is not storage. The point is that traceability is what makes fast synthesis defensible.
Return to the interviews sitting in your notes. The argument of this essay is that they are a smaller debt than they feel like, because the feeling was priced at the old cost - hours of production per interview - and the production is no longer yours to do. What remains yours is judgment, and judgment fits inside the time you actually have. Covering 80% of an interview, verified against the verbatim, framed as a problem your team can trace - that is not discount discovery. Done interview after interview, it is how understanding accumulates at the speed a roadmap actually moves.
Pick the most recent interview and run the loop.
Start with a free workspace - and if your discovery begins in online communities rather than scheduled calls, the CLRA extension feeds the same loop.
