Research operations as a discipline has gotten serious about the front half of the research pipeline. Participant recruiting — finding the right people, getting them scheduled, compensating them correctly. Consent management — documentation, data handling, compliance. Note-taking templates, recording workflows, repository hygiene. These are the visible operations problems, and a lot of smart people have been working on them.
Synthesis is the part that almost nobody has built an operations layer for.
By synthesis I mean the step between raw data — interview recordings, transcripts, notes — and a usable research artifact: a set of findings, a quote bundle, a JTBD evidence file, a report. That step is almost entirely artisanal in most research programs. It's manual, it's variable in quality from researcher to researcher and from study to study, and it has no systematic quality gate or output standard.
The result is a strange situation: product teams have invested in research operations infrastructure that efficiently produces raw data they can't consistently turn into decisions.
Where the Time Actually Goes
If you track a senior UX researcher's time across a typical discovery cycle, the distribution is roughly: recruitment coordination and scheduling (20–30% of study time), the interviews themselves (25–35%), and synthesis — including note review, tagging, theme extraction, report writing — somewhere between 35–50% of total study time, often more.
Those ranges vary by team and tooling, but the synthesis proportion is consistently underestimated by research leaders when they scope studies. Teams that build in two hours per interview for synthesis are usually underestimating. The realistic range for careful synthesis — not quick-pass clustering but rigorous JTBD-anchored analysis — is three to five hours per interview depending on interview length and the complexity of the synthesis framework. For a ten-interview study, that's thirty to fifty researcher-hours in synthesis alone.
That time is largely invisible to stakeholders. They see the calendar: interviews happen Tuesday and Wednesday. The report appears Friday. What happened in between looks like one day's work. What actually happened was a researcher carrying forty pages of transcript through a manual classification process, making judgment calls at every step, with no systematic way to validate or audit those calls afterward.
The Quality Problem in Artisanal Synthesis
Artisanal synthesis produces inconsistent output. Not because researchers are careless — most qualitative researchers are deeply careful — but because the process is underdetermined. Two researchers running the same interviews through the same synthesis process will produce different themes, different quote selections, different confidence assessments. That's not a bug; it's a property of interpretive methods. But it becomes a bug when the output needs to be consistent enough to compare across studies, or when the PM team is evaluating whether the current study confirms or contradicts findings from six months ago.
Sam Ladner's work on research methods in organizational settings addresses this directly. In Mixed Methods: A Short Guide to Applied Mixed Methods Research, Ladner describes the tension between interpretive richness — which requires researcher judgment and can't be fully systematized — and analytical reliability — which requires enough consistency that a finding can be revisited, built upon, or contested by someone who wasn't in the original synthesis session. Most research programs prioritize interpretive richness at the expense of reliability. The output is often deep and interesting, and hard to build on incrementally.
The synthesis bottleneck is where this tension becomes acute. If synthesis takes three hours per interview and produces output that's highly researcher-dependent, you're paying a high labor cost for output with low institutional durability. The insights don't compound — each new study produces findings that sit alongside previous findings rather than building on them.
What Research Ops Actually Needs to Tackle Synthesis
Building an operations layer for synthesis requires solving a different class of problem than recruiting or scheduling. Recruitment is primarily a coordination and vendor management problem. Synthesis is a knowledge management and quality assurance problem.
The first component is a synthesis framework: a defined set of categories, jobs, or hypotheses that every synthesis run is evaluated against. Without this, there's no consistent unit of analysis across studies. With it, a researcher doing synthesis on interview seven can compare their output to a database of outputs from the previous twelve studies, and differences are meaningful rather than just variations in framing.
The second component is a minimum output standard: every synthesis artifact includes source traceability (participant ID, session date, timestamp), evidence weight (how many sessions generated this finding), and a framework mapping (which job or category does this finding belong to). Not all synthesis artifacts need to be comprehensive research reports — sometimes you need a quick quote bundle. But even the quick bundle should meet minimum traceability standards.
The third component is an audit trail: a record of what was synthesized, when, by whom, and against what version of the framework. Research governance is an increasing concern for product organizations operating in regulated industries or with significant enterprise customers. An audit trail isn't overhead — it's evidence that your research practice has the same rigor you expect from your engineering practice.
Why This Is Harder to Solve Than Recruitment
Recruitment operations are well-served by existing tooling: research panels, scheduling software, consent management platforms. The problem is known, the solutions are mature, and most research ops investments in this area are straightforward to implement.
Synthesis operations are harder because the tooling hasn't caught up with the problem. Most transcript and note-taking tools produce raw text with minimal structure. Most repository tools (Dovetail, EnjoyHQ, and similar) are good at storing and tagging synthesis artifacts but don't create them — they assume the synthesis has already happened. The step between "transcript" and "structured finding" is where the tooling gap is widest.
The gap matters because it means every research team has to solve synthesis operations from scratch. They build their own tagging conventions, their own output templates, their own quality checks. These are often reasonable solutions, but they're local — they don't compound, and they don't transfer when researchers change roles.
The Synthesis Bottleneck as a Recruiting Constraint
There's a secondary effect that research operations leaders rarely discuss: synthesis throughput constraints limit how much research an organization can run. If your team can process eight interviews per researcher-week through synthesis, you can run two studies simultaneously or one larger study per quarter. If synthesis throughput doubled, you could run more studies or run the same studies in less time, freeing research capacity for more questions.
Philippe Boutros built GetWhys around exactly this problem: the observation that interview capacity — the number of customers willing to talk to you — is rarely the constraint on research velocity. The constraint is what happens to interviews after they happen. A team that can run ten discovery sessions in a week but takes three weeks to synthesize them effectively has a two-week research delay built into every cycle. That delay shows up as "research takes too long" — and it usually triggers calls to reduce the number of interviews rather than to improve the synthesis step.
Reducing interview count to match synthesis throughput is solving the wrong problem. The right opportunity is in synthesis capacity.
What an Operations Layer for Synthesis Looks Like
The research teams that have made the most progress here share a few characteristics. They have a shared JTBD framework or category system that every study maps against — not as a constraint on what researchers can find, but as a shared vocabulary that makes outputs comparable. They treat quote traceability (participant ID, session date, timestamp) as a non-negotiable output standard rather than a nice-to-have. And they have a mechanism for aggregating evidence across studies — not just collecting research reports but building a cross-study evidence layer that grows with each new round.
None of this requires a large research ops team. Erika Hall's argument in Just Enough Research — that research should be proportionate to the decisions it's informing — applies to research ops as much as to research itself. You don't need a research operations function to implement a consistent ID system and a JTBD synthesis template. You need those as a starting point, and then a way to ensure they're applied consistently rather than abandoned when the next study kicks off under time pressure.
We're not saying synthesis should be automated out of existence, or that interpretive judgment is a bottleneck to be eliminated. The rigor of a skilled researcher reading across interview data and noticing a pattern the framework didn't anticipate is irreplaceable. The argument for treating synthesis as an operations problem rather than a craft problem isn't that synthesis should be mechanical — interpretive rigor is real and valuable. It's that synthesis has operational requirements (consistency, traceability, durability) that craft practices don't reliably produce. Getting both requires designing synthesis as a process with standards, not just as an activity that skilled people do in their own way. That design work is what research ops exists to do — and it's time the field started applying it to the step that's actually the bottleneck.