After you've clustered pain points into themes, the next step is to draft the problem statement and requirements for each theme. This is where raw interview data becomes PRD prose—and where most teams lose the thread. You're not writing marketing copy or summarizing broadly; you're building a narrative that stays tethered to what customers actually said, with each requirement traceable back to a verbatim quote.
This guide covers the mechanics of drafting one PRD section per theme, the mistakes that create paraphrase drift, and how to verify your work stays honest to source.
A single PRD section typically has three parts: a problem statement (grounded in clustered quotes), 2–4 specific requirements derived from those quotes, and acceptance criteria tied to each requirement. The entire section must remain linkable back to its source quotes—you tag each requirement with a line reference so anyone reading the PRD can verify it against the original transcript.
For example, if three interviews all mentioned "we waste 15 minutes a day switching between tools," your requirement might read: "Reduce context-switching overhead between task input and reporting" [Quote refs: Interview 2, line 34; Interview 5, line 18; Interview 7, line 22]. That tag matters. It stops requirements from drifting into nice-to-haves that no one actually asked for.
The single largest error in this step is moving too fast from quote to requirement. You read "I hate switching between tools," and your brain immediately says "consolidate workflows," which sounds like a feature, which turns into "build unified dashboard," which is now a solution no customer actually proposed.
Each requirement must stay within the boundary of what the interview subject expressed as a problem or need. If they said friction exists, your requirement is to reduce friction. If they said a task takes too long, your requirement is to reduce time. You are not solving yet—you're restating the problem precisely enough that a designer or engineer could propose multiple solutions.
The remedy: write your requirement sentence, then ask "Did any interviewee use these exact words or concepts?" If the answer is "I'm inferring that," rewrite it closer to the source. Quote drift happens fastest when you're tired or rushed, so build in a verification pass (see below).
Start with your theme and its tagged cluster of quotes. For a theme like "Reporting Friction," you might have five quotes about how long it takes to gather data, export it, reformat it, and send it to stakeholders.
Write your problem statement in one or two sentences by weaving the most specific quotes together: "Stakeholders report spending 30–45 minutes per week manually exporting task data, reformatting it into reports, and sharing updates. This repetitive export-reformat cycle blocks timely communication and wastes engineering time on non-building work." Tag those quotes immediately: [Quote refs: Interview 1, line 42; Interview 4, line 67; Interview 8, line 19].
Then list 2–4 requirements as specific, outcome-focused statements. Each requirement should anchor to one or two quotes from your cluster:
For each requirement, draft one acceptance criterion: a testable statement that confirms the requirement is met. "Reports auto-generate" becomes "A user can create a report from task data in under 60 seconds without leaving the app." Acceptance criteria should reference time, format, or outcome—measurables from the original interviews when possible.
Adding scope that wasn't asked for: If no one mentioned it, don't include it. You're drafting from interviews, not from your feature backlog. If you think something is essential, that's a separate conversation—mark it as "derived assumption" and review with stakeholders.
Bundling too many quotes into one requirement: If your requirement tries to satisfy five different quotes, it's probably two or three requirements. Split them. Each requirement should map cleanly to a small set of related pain points.
Using vague outcome language: "Improve reporting" is not a requirement. "Enable users to generate weekly reports in their chosen format without manual work" is testable and traceable. Specificity prevents misalignment later.
Losing quote references mid-draft: Tag as you write, not after. Once you finish a requirement, immediately add [Quote ref: Interview X, line Y]. You'll forget which quotes belonged to which requirement if you defer this.
Before you finalize a section, run this checklist: Read each requirement aloud. Does it sound like something an interviewee would recognize as their problem? If not, rewrite closer to their language. Cross-check every tag: does the quote reference actually support the requirement? If you're unsure, re-read that line of the transcript. If a requirement has no quote behind it, either delete it or mark it explicitly as an assumption and flag it for stakeholder review. Count your quotes: if your theme had 8–10 related pain points in your cluster, your 3 requirements should touch at least 6 of them. If you've only used 2 quotes to build 3 requirements, you've missed nuance or added inference.
Finally, ask: could someone else read this section and, without seeing the interviews, understand why this matters and what success looks like? If the answer is yes, the section is solid. If it feels like it needs their context or interpretation, tighten the language and add more quote detail.