Writing a PRD From a One-Line Feature Request
Most PRDs start the same way: a blank doc and a one-line idea like "let users export their data." From there it's easy to free-write whatever comes to mind first, usually the requirements, and realize three paragraphs in that there's no problem statement or success metric anywhere in the doc.
Warning
A blank doc doesn't remind you what sections a PRD needs. It just reflects back whatever order you thought of things in, which is rarely the order a reviewer expects to read them.
A feature idea is a sentence. A PRD is a structure. Free-writing gets you the sentence, expanded.
Why free-writing skips sections without you noticing
Writing from a blank page means you're inventing the structure as you go, and it's easy to write the parts that feel obvious, usually the requirements, while skipping the parts that take more thought, like naming the actual problem or picking a metric that proves the feature worked.
Before: open a blank doc, start writing requirements for the feature idea, realize later that the problem statement and success metrics are missing.
After: give Claude the one-line idea and the problem it solves, and get back a structured first draft, problem, goals, requirements, and metrics, with every section already in place to refine.
A process for a structured first draft
- 1
State the feature idea and the problem it solves
One sentence for each is enough to start. "Let users export their data as a CSV, because support keeps getting asked for it manually" gives Claude both the what and the why.
- 2
Ask for a fixed structure, not an open draft
Ask specifically for a problem statement, a small number of goals, functional requirements, and success metrics, in that order. A fixed structure is what makes the draft reviewable instead of a essay.
- 3
Give a real number for goals and metrics
Ask for a specific count, three goals, two metrics, rather than "some goals." A number forces prioritization instead of an open-ended list that keeps growing.
- 4
Treat the draft as a starting structure, not a final doc
Read back through and rewrite each section in your own voice. The value of the first draft is that nothing's missing, not that the wording is final.
“
We want to let users export their data as a CSV. Draft a one-page PRD with a problem statement, three goals, functional requirements, and two success metrics we could track in the first 30 days.
”
Inside Claude Tutorial
Starting from a fixed structure instead of a blank page is transferable.
Working from a known set of sections, instead of inventing structure as you write, applies well beyond PRDs. The app has a full lesson on it, with practice that carries over to any document with a shape reviewers expect.
When the goals don't match the metrics
A common gap in a first draft is a goal with no metric attached to it, or a metric that doesn't actually prove the stated goal happened. That mismatch is worth catching before the doc goes out, not after someone asks how you'll know the feature worked.
Tip
Ask Claude to check each goal against its metric directly: does hitting this number actually prove the goal, or just something correlated with it? A metric that's easy to measure isn't automatically the right one.
“
Here are the three goals and two metrics from this PRD draft. For each goal, tell me honestly whether the metrics actually prove it happened, or just measure something adjacent to it.
”Continue reading
- Sharpening a PRD Before You Send It for Review: testing the structured draft this article produces before it reaches a reviewer.
- Writing a Roadmap Doc That Explains the Tradeoffs: what happens once this feature idea has to compete with others for a spot on the roadmap.
- Turning Support Tickets Into Prioritized Themes: a source of real feature ideas to write PRDs from in the first place.