How a product manager cut weekly research synthesis from 6 hours to 40 minutes

Disclaimer first: "Mei" is a composite of three PMs I've worked with this year. The numbers, prompts, and review steps are real. Names and the company are not. Everyone agreed to share on that basis.

The before

Mei's team runs 6–8 user interviews per week — 45 minutes each, recorded, auto-transcribed by the call platform. Every Friday she'd:

• Re-skim each transcript (≈30 min × 7 = 3.5 hours)
• Tag quotes in a spreadsheet (≈1 hour)
• Cluster themes in a doc, write up findings, share with the team (≈1.5 hours)

Six hours. Every Friday. The writeup was solid, but by Wednesday she'd already forgotten half of what was in Monday's call, and the doc reflected that.

The after, in one paragraph

After each call, Mei drops the transcript into a private Claude project that already contains the team's persona docs and the current quarter's discovery questions. She runs one structured prompt that produces five tagged quotes, three observed pains, and any open questions. Friday's job is now: glance through five rolled-up notes, ask Claude to merge themes, write a 3-paragraph "what we learned" intro, and ship.

Step 1 — Build the context once

The leverage isn't in the per-call prompt. It's in the persistent context. Mei set up a Claude Project with three documents pinned:

1. Personas.md — the team's current 4 personas, one paragraph each
2. Discovery-questions-Q2.md — the 6 strategic questions the team is trying to answer this quarter
3. House-style.md — three rules: use direct quotes with timestamps, never invent a pain not stated, flag uncertainty with (?)

Setup time: 45 minutes, once. Total cost across all subsequent calls: zero.

Step 2 — The per-call prompt

After each interview, she pastes the transcript and runs this:

This is a transcript of a user interview with {persona type}.

Using the personas, discovery questions, and house style I've shared:

1. Pull 5 direct quotes that move at least one of the discovery questions forward. Include speaker and timestamp.
2. List 3 pains or jobs-to-be-done the user expressed. Distinguish "stated explicitly" from "implied" — flag implied ones with (?).
3. List any open questions this transcript raises that we should chase in the next call.
4. End with one sentence: "This call mostly tells us about question #__."

Do not summarise the whole call. I'll read the transcript myself if I need to.

The last line is critical. Without it, the model defaults to a generic 400-word summary that nobody reads.

Step 3 — The Friday roll-up

By Friday morning, Mei has 6–8 short structured notes sitting in the project. The roll-up prompt:

Across this week's interview notes, cluster the quotes and pains into 3–5 themes. For each theme:

- Theme name (5 words max)
- Which discovery question(s) it speaks to
- 2–3 representative quotes with attribution
- Confidence level (high / medium / low) based on how many calls it appeared in

Do not include themes that only appeared in one call unless the quote is unusually strong.

This produces a tight starting draft. Mei reads it, deletes anything that doesn't feel right, asks Claude to expand the themes she wants developed, and writes her own 3-paragraph "what this means for the roadmap" closer.

The review step that catches hallucinations

Before sharing the writeup, Mei runs one more prompt:

For every direct quote in the document above, find it in the source transcripts I shared this week. Flag any quote whose wording doesn't appear in any transcript.

In four months of doing this, the model has flagged itself twice — both times it had subtly paraphrased rather than quoted. Zero invented quotes have made it into a shipped doc. This single prompt is the reason her team trusts the workflow.

What didn't work

• Auto-summarisation tools that run on the call platform. They produced shallow, generic summaries with no persona awareness.
• One giant Friday prompt with all 8 transcripts pasted in. Context limits aside, the model started to blur callers — quotes got mis-attributed.
• Asking the model to "rate quote importance 1–10." The ratings looked confident and meant nothing. Better to ask which discovery question a quote moves.

What stuck

Three things Mei now does on every project, not just this one:

1. Build the context once. Persona, goal, and style docs that the model sees every time.
2. Tell the model what not to do. "Don't summarise the whole call" did more work than every "be concise" she'd ever written.
3. End with a verifier prompt. Cheap, fast, and the difference between "AI-assisted" and "AI-trusted" output.