Before you feed customer interview transcripts into a prompt chain, you need to prepare them. A sloppy brief wastes prompt tokens and introduces paraphrase drift—the moment your requirements lose their original quote anchors. This guide walks you through structuring a customer interview brief that keeps verbatim evidence intact across every PRD generation step.
A brief is a lightweight wrapper around your raw transcript. It does three things: it identifies who spoke, what problem they described, and where in the transcript that problem appears. You're not summarizing yet—you're labeling.
Start with metadata: interview date, participant role (e.g., "Operations Manager at 40-person SaaS startup"), interview duration, and any constraints (e.g., "only spoke about invoicing workflow, not collections"). One sentence per field. This context matters when the prompt chain evaluates how representative a quote is.
Then copy the transcript verbatim into a section labeled [TRANSCRIPT]. Do not edit, clean, or paraphrase it. Filler words, false starts, and tangents stay in. You'll tag relevant segments after.
Read through the transcript once without marking anything. On the second pass, identify moments where the participant describes a frustration, bottleneck, or unmet need. Mark the start and end line number for each pain point.
Next to each line range, write one sentence describing what problem the participant named. Then copy the exact quote—word for word, including verbal tics—into a [QUOTE] field. A tagged pain point looks like this:
Pain Point 1 (Lines 14–18): No visibility into which invoices customers have opened
Quote: "I send an invoice and I literally have no idea if they even looked at it. I'm sitting here wondering if it got lost in their email or if they're just ignoring me. There's no way to know."
Do this for every distinct problem mention, even if the same problem gets described three times in different ways. Repetition is data—it signals importance.
At the end of the brief, note what the participant did not cover. This prevents the prompt chain from inferring requirements about features or workflows nobody actually discussed. Write a [SCOPE] section:
Example: "Participant did not discuss multi-user workflows, mobile app usage, or integration with Stripe. Only spoke about desktop browser experience."
Also note any caveats: "Participant is a power user; may not represent how new operators work" or "This customer recently switched from competitor X; opinions may reflect migration friction rather than long-term needs."
Save the brief as a plain-text or markdown file. Use consistent delimiters so the first prompt can parse it cleanly:
Before you hand the brief to the prompt chain, spot-check three random pain points. Copy the quote from your [PAIN POINTS] section, search for it in the [TRANSCRIPT] section, and verify it matches exactly. If you find a typo or paraphrase, fix it. This one-minute check prevents hours of QA drift downstream.
If a pain point is too long to quote verbatim (more than three sentences), mark it as a summary and include a line-range reference instead of a quote. The prompt will retrieve the exact text later.