When you convert customer interview transcripts into a PRD, quotes drift. A customer says "I spend more time reorganizing my ideas than working on them," but by the time it reaches your requirements doc, it becomes "users need better task organization." The original tension is gone.
A prompt chain solves this by treating quotes as anchors. Each stage preserves the source line number and verbatim text, then passes both the requirement and its quote forward. This takes discipline, but it's the only way to avoid the generic outputs that generic ChatGPT prompts or Notion AI produce.
Start with your raw transcript. Your first prompt should ask the model to pull every statement that signals friction, frustration, or unmet need—then tag each with its line number and full quote.
This is not a summary. You are creating a reference table. Each row is: [Line #] [Verbatim quote] [Pain category]. Do not paraphrase. If the customer said it awkwardly, copy it awkwardly. This precision now prevents drift later.
Export this as a structured list (CSV or markdown table). You will loop back to this table in steps 4 and 5.
Group pain points by theme—e.g., "Organization," "Motivation," "External accountability." But do not merge quotes. Each quote keeps its line reference. You now have themes with multiple quotes attached, not themes with one merged statement.
A theme might have 3–5 quotes under it from different customers or different moments in the same interview. Keep all of them. This is where you catch patterns without losing the texture of individual frustrations.
For each theme, write one or more PRD requirements. But do not write a requirement alone. Write it as a pair: [Requirement text] → [Source quotes, with line numbers].
Example:
Requirement: System must reduce time spent organizing task batches.
Source quotes: [L12] "I spend more time reorganizing my ideas than working on them"; [L47] "Even when I try to focus and narrow the list, life gets in between."
This step forces you to ensure every requirement maps back to something a customer actually said. If you cannot find a quote, the requirement is not validated.
For each requirement, prompt the model to write acceptance criteria. But include the source quotes in the prompt. Tell the model: "Write acceptance criteria that would satisfy this pain point: [quote]."
This grounds acceptance criteria in customer reality, not in feature abstraction. A test that passes the acceptance criteria should resolve the friction the customer described.
After the model generates criteria, manually re-check them against the original quote. Do they address it? Or have they drifted into generic product-speak?
Before finalizing, run one final check: pick 5 random requirements and trace them back to their source quotes. Read the quote. Read the requirement. Read the acceptance criteria. Are they still connected? Or has meaning leaked out?
If drift has happened, rewrite the requirement or criteria using the quote as your north star. Then export your PRD template with a "Sources" section that lists every requirement and its associated quote lines. This becomes your accountability layer.