You've finished your tenth customer interview. You have 10 hours of recordings, 40 pages of notes, and a demo in three days. The instinct is to open a fresh Notion doc and start writing. Don't.
The synthesis step is where most PMs lose the thread. They write a summary from memory, anchor on the last three calls, and miss the quiet signal buried in interview four. Here's the framework to avoid that.
Step 1: Transcribe and tag before you synthesize
Before any synthesis, you need raw material in a searchable, taggable form. If you're doing this manually:
- Transcribe each call (Rev, AssemblyAI, or Zoom's built-in)
- Create a single spreadsheet: one row per insight, columns for
participant,quote,theme,sentiment,job-to-be-done - Fill it in immediately after each call, not in bulk at the end
With AI (StrongRoot or similar): drop in the transcript, get structured themes and quotes back in ~2 minutes per interview. The point isn't the tool — it's getting insights out of your head and into a structured format.
Step 2: Cluster by job-to-be-done, not by feature request
This is the mistake most PMs make. Customers say "I want a CSV export." They mean "I need to share this data with my finance team who won't use your tool." Those are different problems with very different solution spaces.
Group your tagged insights by the underlying job:
- Collaboration jobs — sharing, handoffs, visibility across teams
- Confidence jobs — validating decisions, reducing uncertainty
- Speed jobs — cutting time from discovery to action
Feature requests almost always collapse into 3–5 jobs. Once you see that pattern, the roadmap starts writing itself.
Step 3: Count signal strength, don't just cite quotes
A theme mentioned by 2 of 10 customers is a signal. Mentioned by 7 of 10, it's a mandate. Your synthesis doc needs to convey frequency, not just presence.
Use a simple table:
| Theme | Frequency | Representative quote | |-------|-----------|---------------------| | Sharing findings with eng | 7/10 | "My dev lead never reads Notion docs" | | Losing context between cycles | 6/10 | "We do research and then just... forget" | | PRD quality inconsistency | 5/10 | "Every PM writes them differently" |
This table is the first thing a skeptical stakeholder will look at. Make it scannable.
Step 4: Write the synthesis doc in three sections only
A good synthesis doc has exactly three sections:
What we heard — The themes, with evidence (quotes + frequency). No editorializing yet.
What it means — Your interpretation. What jobs are underserved? Where is the current product failing them?
What we should do — One or two concrete recommendations with explicit links back to the evidence. Not a full roadmap. A direction.
Anything else — participant bios, methodology notes, raw transcripts — goes in the appendix. The three-section doc is what you present. The appendix is what you share when challenged.
Step 5: Validate before you ship
Before you call the synthesis done, do one final check: can every claim in the "what it means" section be traced back to specific evidence in "what we heard"? If not, you have an opinion masquerading as insight. Cut it or go find the evidence.
Done well, this process takes about 45–60 minutes for 10 interviews, assuming you tagged in real time. Done with AI assistance, closer to 20. Either way, the output is a document your engineering lead will actually read — and that's the whole point.
The best synthesis docs aren't comprehensive. They're decisive.