You've just finished interviewing ten customers about their biggest frustrations. You have a 200-page transcript. Now comes the hard part: turning raw feedback into a product roadmap without mangling what people actually said.
The usual process is painful. You paste transcripts into ChatGPT, get back a vague bullet list, and later realize you can't remember which customer said what. Or you spend hours manually copying quotes into a spreadsheet, then lose track of them when requirements change.
Here's a better way: a linear workflow that keeps every requirement anchored to its original quote all the way through to your final PRD.
Start by reading your transcript systematically. As you find a problem the customer describes, write it down exactly as they said it—not your interpretation. Tag each quote with a line number from the transcript.
Example:
Pain Point: Hard to track which features we've already built
Quote (Line 47): "I spend 20 minutes every week scrolling through our app just to see if we've shipped the thing I asked for three months ago."
Do this for every distinct problem you hear. Don't filter yet—just capture. Use a simple Google Sheet or a text file with consistent formatting: line number, verbatim quote, and a one-sentence pain summary.
Now group similar pains together. You might notice five customers all mentioned "hard to find what's new" in different words. That's one theme. Two customers talked about "takes too long to onboard new team members"—that's another.
Name each theme clearly. Keep the original line numbers attached to every pain point as you move it into its cluster. This is the critical step: if you lose the line numbers here, you'll never find the quotes again.
Your sheet now has columns: Theme | Pain Point | Quote | Line Number.
For each theme, write one or more product requirements. These should be concrete enough to build. But before you write them, always start with the quote. Write it at the top of the requirement block so your team sees the customer voice first.
Theme: Visibility
Quote (Line 47): "I spend 20 minutes every week scrolling through our app just to see if we've shipped the thing I asked for three months ago."
Requirement: Build a "What's New" feed showing features shipped in the last 30 days, sorted by request date.
This keeps the customer problem front and center. Write 2-4 requirements per theme. You'll end up with 6-15 total requirements from a typical round of five to ten interviews.
For each requirement, write acceptance criteria—the concrete tests that tell you when it's done. Reference the original quote again so reviewers know what customer behavior the criteria serve.
Requirement: Build a "What's New" feed
Linked Quote (Line 47): Customer is frustrated by time spent searching for shipped features.
Acceptance Criteria:
Each criterion ties back to the pain point. A criterion that doesn't solve the original customer frustration shouldn't be there.
Before you ship the PRD, do a final check. Read each requirement and its acceptance criteria. Then go back to your transcript and verify the quote actually says what you claim it does. Paraphrase-drift is real: you'll convince yourself a requirement matches a quote when it doesn't.
If a requirement doesn't anchor clearly to a real customer statement, either rewrite it or delete it. Your PRD is not a wish list—it's a summary of what customers actually asked for.
Format your final PRD as a document (Google Doc, Notion, or Markdown) with this structure:
Theme Name
Linked Quote(s) + Line Numbers
Requirement 1
—Acceptance Criteria
Requirement 2
—Acceptance Criteria
Share the PRD alongside a PDF or link to the original transcript so your team can click through from any quote to the source. If you're using Notion, create a linked database: one table for interviews, one for requirements, with backlinks to quotes.
Now your PRD is traceable. Engineers building the feature can read the original customer frustration. Designers know exactly which problem they're solving. No one has to guess what the customer actually meant.