How to write a PRD with AI (without it reading like AI)
A working process for drafting product requirements documents with Claude: what to feed it, where AI drafts go wrong, and how to keep your judgment in the document.
Asking an AI to "write a PRD for feature X" produces something that looks like a PRD: the right headings, confident sentences, plausible metrics. It's also nearly useless, because everything that makes a PRD worth reading — the constraint you discovered in customer calls, the option you rejected and why — lives in your head, not the model's. The fix isn't better prompting tricks. It's a better order of operations.
Step 1: dump before you draft
Open a chat and unload everything you know about the problem, in whatever order it comes out. Half-sentences are fine. The customer quote you keep repeating in meetings. The engineering constraint from last week's sync. The metric that made this a priority. Two or three messy paragraphs of real knowledge beat any template.
If the raw material already exists as files — interview notes, a strategy doc, support tickets exported to CSV — put them in your workspace folder and tell Claude to read them first. Grounding the draft in your actual evidence is the single biggest quality lever you have.
Step 2: let Claude structure, not invent
Now ask for the draft, and be explicit about the boundary: "Structure this into a PRD — problem, evidence, proposed solution, out of scope, open questions. Use only what I gave you. Where something is missing, leave a marker instead of filling it in." The out-of-scope and open-questions sections are where AI drafts usually lie by omission, so force them to exist.
The markers matter more than they look. A PRD with six honest "OPEN: we haven't validated this" flags is a working document. A PRD with six invented answers is a trap that costs you a sprint.
Step 3: review with comments, like an editor
Read the draft the way you'd read a colleague's. In Sofos, select the weak sentences and leave comments — "we actually decided against this in March", "add the churn number", "this is engineering's call, not ours". Then apply the comments in one pass. This loop, two or three times, is where the document stops being an AI draft and starts being yours. Your judgment enters the doc through the comments.
Step 4: the reads that catch what you missed
- The skeptic read: "You're an engineer seeing this for the first time. What's underspecified? What would you push back on?"
- The scope read: "List everything in here that isn't strictly needed for the first release."
- The evidence read: "Which claims in this document have no source behind them?"
Each of these takes under a minute and regularly surfaces the question you'd otherwise hear for the first time in the review meeting.
What to keep for yourself
The decision. AI is genuinely good at structuring, compressing, and stress-testing; it has no idea whether this feature is worth building, and it will never tell you "don't ship this." Use it to make the document sharper, and keep the call that the document argues for. That division of labor is also, not coincidentally, what makes the result read like a person wrote it — because the parts that matter, a person did.