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. A PM who's excited about a feature idea tends to start writing the mechanics of how it should work, the exact fields, the exact button placement, long before stopping to write down what problem it's actually solving.
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. The requirements section is concrete and satisfying to write, since it's a list of specific, checkable things. The problem statement requires stepping back and articulating why any of it matters, which is a different, harder kind of thinking, and it's the part that gets skipped first under time pressure.
Take a one-line idea like "let users export their data as a CSV." A PM excited about the idea might spend twenty minutes detailing exactly which fields should be included in the export and what the button should say, and only realize while sending the doc for review that there's no sentence anywhere explaining why this matters, that support has been fielding manual export requests for months. A reviewer opening that doc has no way to judge whether the proposed requirements actually solve the real problem, because the real problem was never written down.
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 an 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.
”If the feature idea originated from a specific, known source, a cluster of support tickets, a customer request, a competitive gap, it's worth telling Claude that explicitly, since a problem statement grounded in a real, named source reads as far more credible to a reviewer than a plausible-sounding but generic one.
This idea came directly from 15 support tickets over the last month, all asking for a way to get their data out without contacting support. Rewrite the problem statement to reference that real source specifically, not a generic description of the need.
”
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. A goal like "reduce support burden" paired with a metric like "number of exports performed" sounds related but doesn't actually prove the goal, since users could export data constantly without a single support ticket being avoided.
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.
”If a metric turns out to be genuinely hard to track with existing tooling, it's worth surfacing that constraint early rather than shipping a PRD with a success metric nobody can actually measure once the feature is live.
One of these metrics would require tracking that we don't currently have in place. Suggest a metric that proves the same goal but is realistic to measure with our existing analytics setup.
”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.