CaretHow to write a PRD from customer feedback engineers will read
It's Thursday planning. The feedback doc has grown to a few hundred lines: pasted Slack messages, notes from calls, three support tickets, a long email from your biggest customer. Someone says "everyone wants better exports", and someone else says that was one customer, twice. An engineer asks the only question that matters: what problem are we solving, and for whom? Nobody can answer it in one sentence.
A pile of feedback isn't a spec. You need one problem, one user and one way to tell whether you fixed it. And it has to be written so an engineer can read it in five minutes and start.
Step 1: get it all in one sheet
Feedback lives in five places, and nobody reads five places. Move it into one sheet, one row per piece of feedback, with these columns:
| Column | Example |
|---|---|
| Quote | "I export to CSV every Friday and fix the dates by hand" |
| Source and link | Support ticket, call notes, Slack thread |
| Who | Company, role, plan |
| Date | 9 Oct |
| The moment | Preparing the Friday report for their boss |
| What they asked for | "Excel export" |
| Workaround today | Fixes dates by hand in a spreadsheet |
The "moment" column matters most. "Excel export" is a solution the customer guessed at. "Preparing the Friday report and fixing dates by hand" is a problem you can design for, and there may be a better fix than the one they asked for.
Step 2: group by moment, then count
Sort the sheet by the moment column and group what's similar. Then, for each group, count three things: how many rows, how many different companies, and how many from the kind of customer you're building for. Ten rows from one loud account and four rows from four target customers are different signals.
Score each group on this table before you choose:
| Score 1 | Score 3 | Score 5 | |
|---|---|---|---|
| Spread | One company | A few companies | Many target customers |
| Cost of the problem | Annoying | Takes real time each week | Blocks them or loses money |
| Workaround | Easy | Tedious | None |
| Fits where you're going | Sideways | Partly | Directly |
Pick the top group. One. The second one goes in a "next" list, and you tell the customers in it that you heard them.
| Moment (group) | Rows | Companies | Target customers | Spread | Cost | Workaround | Fit | Score |
|---|---|---|---|---|---|---|---|---|
| Friday report prep | 18 | 11 | 8 | 5 | 3 | 3 | 5 | 16 |
| Onboarding a teammate | 10 | 6 | 4 | 3 | 3 | 3 | 3 | 12 |
| API access | 9 | 3 | 1 | 1 | 3 | 3 | 3 | 10 |
| Sharing a dashboard | 8 | 5 | 3 | 3 | 1 | 3 | 3 | 10 |
| Date formats | 6 | 4 | 3 | 3 | 3 | 1 | 3 | 10 |
| Setting up alerts | 5 | 4 | 2 | 3 | 1 | 1 | 3 | 8 |
| Billing questions | 4 | 4 | 2 | 3 | 1 | 1 | 1 | 6 |
Step 3: write one page
Engineers read PRDs that are short and make decisions. Use this one-page shape:
- Problem. Two or three sentences, with two or three real quotes linked back to the sheet.
- Who it's for. One named kind of user. "Ops leads at 10-50 person companies who send a weekly report" beats "users".
- Evidence. The counts from step 2, plus the workaround people use today.
- Goal and one metric. What changes for the user, and the number that will tell you. Pick a number you can measure next month.
- Out of scope. What you're not doing in this version, written down so nobody builds it by accident.
- Proposed solution. A sketch, a few bullets or a mockup. Keep it loose enough for the engineer to improve.
- Open questions. What you don't know yet, with an owner for each.
Before it goes to engineering, check it against this list:
- Someone who wasn't in the calls can say the problem back in one sentence.
- Every quote links to its source row.
- There is exactly one metric, and you know where you'll read it.
- Out of scope has at least two items.
- Decisions read as decisions. Open questions are labeled as open.
- It fits on one page.
An example: from 60 rows to one PRD
The company, customers and numbers in this example are made up.
A PM at a small analytics startup asks: "go through this week's feedback threads and the support tickets tagged 'export', put each piece in the feedback sheet with a moment, and group them."
Back came a sheet with 60 rows in seven groups. The largest group, 18 rows, was "Friday report prep", from 11 companies, 8 of them in the target segment. The bot flagged that 7 of the 9 rows in a group called "API access" came from one account.
The PM merged "date formats" into "Friday report prep", since every row described the same moment. They moved "API access" to the next list and wrote to that account directly. Then they asked for the PRD: "write a one-page PRD as a Word doc for Friday report prep, using the seven-part shape in your notes, quotes linked."
Before it went to the team, the PM asked the engineering bot to read it: "list what's unclear before anyone starts." It asked two things. Should a scheduled email be in scope? Which time zone do the dates use? The PM moved scheduled email to out of scope and answered the time zone question in the doc.
The last step was posting the PRD to the team's product channel. Like any post, it waited for the PM's click.
write a one-page PRD as a Word doc for Friday report prep, using the seven-part shape in your notes, quotes linked
Attached prd-friday-report-prep.docx. Evidence: 18 rows from 11 companies, 8 in the target segment. Asked the engineer bot to list what's unclear.
Two questions. Should a scheduled email be in scope? Which time zone do the dates use?
Scheduled email is out of scope. I've answered the time zone in the doc.
Post PRD to #product
ApproveDenyApproved.
An example thread, shortened.
How to set it up in Caret
A product bot in Caret has a written job, memory that lasts between conversations, and a seat in the threads where feedback already lands. It makes Word docs and Excel sheets and attaches them there.
- Create a product bot and write its job: "keep the feedback sheet, group feedback by the customer's moment, and draft PRDs in our one-page shape".
- Put the sheet columns, the scoring table and the seven-part PRD shape in its files.
- Add it to the threads where feedback shows up. They're bridged to Slack both ways, so it reads feedback where people already post it.
- Connect GitHub so it can see what shipped, and connect other apps only if they hold feedback.
- Give it a schedule: "every friday 16:00 add this week's feedback to the sheet and post the top three groups with counts".
- Have it hand the draft to your engineering bot by @handle: "read this PRD and list what's unclear before anyone starts".
- Leave approvals on. Before it posts or sends anything, it asks, and an admin approves or denies with one click.
Caret's Team plan is $40 a bot a month, with a 7-day trial. Bots keep working when your laptop is off, and the whole team can join the thread.
FAQ
What should a PRD include when it's based on customer feedback? The problem in the customer's words, with linked quotes, who it's for, the evidence (counts and workarounds), one metric, what's out of scope, a rough solution and the open questions. Keep it to a page.
How do you prioritize customer feedback before writing a PRD? Group it by the customer's moment, then score each group on spread across target customers, cost of the problem, how bad the workaround is and fit with your direction. Pick one group. Watch for many rows from a single account.
How long should a PRD be for a small team? One page for most features. If it needs more, it's usually two features, or the open questions aren't answered yet. Engineers read short PRDs. Long ones get skimmed.
If you're the PM, or the founder acting as one, here's what a product bot can take on. Put a bot on it: start your 7-day trial or download the Mac app.