Most product requirements documents fail for the same reason: they are written to look complete, not to be used. They balloon to fifteen pages, nobody on the engineering team reads past the summary, and two sprints later half the “requirements” turn out to be assumptions no one validated.
I have written, reviewed, and torn apart PRDs for close to thirty years — as a developer first, then across two decades of product and project management, and through ten years of running startups. The single biggest improvement I have made to the practice recently is not a new template. It is using AI to do the parts of PRD writing that humans are slow and inconsistent at, while keeping the judgment where it belongs: with the person who understands the customer.
This guide shows exactly how to write a PRD with AI — end to end. You will get a one-page PRD structure, the specific prompts that turn a rough idea into a review-ready document, and the failure modes to watch for — because AI makes some PRD mistakes faster, not fewer.
What a PRD is actually for
A PRD is not a contract and it is not documentation. It is an alignment tool. Its only job is to get design, engineering, and stakeholders to a shared understanding of what we are building, why, and how we will know it worked — before anyone writes code.
If your PRD does not reduce the number of “wait, I thought we were building X” conversations, it is decoration. Keep that test in mind for every section below: does this line remove ambiguity, or just add length?
The one-page PRD structure
A good PRD for a single feature fits on one page. Here is the structure I use, and the reason each part exists:
- Problem — the user problem in one or two sentences, with evidence. Not “users want dark mode.” Instead: “40% of support tickets about eye strain come from users working after 8pm; three enterprise accounts named it in renewal calls.”
- Goal & non-goals — what success looks like, and explicitly what this feature will not do. Non-goals prevent scope creep better than any process.
- Success metrics — one primary metric, at most two guardrail metrics. If you cannot name the metric, you are not ready to build.
- Users & use cases — who this is for and the two or three concrete situations they are in.
- Requirements — the actual behavior, written as user stories or acceptance criteria. This is the core.
- Open questions & risks — what you still do not know. A PRD that admits its unknowns is more trustworthy than one that pretends to have none.
Notice what is missing: no twelve-paragraph background essay, no speculative future roadmap, no wireframe dump. Those belong elsewhere. The PRD stays sharp.
Where AI genuinely helps — and where it doesn’t
AI is excellent at the mechanical parts of PRD writing:
- Turning a messy brain-dump into the structure above
- Converting a vague feature description into testable acceptance criteria
- Pressure-testing your requirements for gaps and edge cases you missed
- Rewriting for a specific audience (an exec summary vs. an engineering spec)
AI is dangerous at the judgment parts:
- Inventing “evidence” and metrics that sound plausible but are fabricated
- Confidently filling in user problems it has no way to know
- Producing generic requirements that fit any product and therefore commit to nothing
The rule I follow: AI drafts, the human decides. Every number, every user problem, every priority call gets verified by someone who actually talked to the customer. Used this way, AI cuts PRD writing time by more than half without lowering quality. Used carelessly, it produces confident, well-formatted nonsense — which is worse than a rough honest draft.
The prompts that actually work
Here are three prompts you can use today. Fill in the brackets, paste into Claude, ChatGPT, or Gemini, and always review the output against what you actually know.
1. Idea → one-page PRD
Act as a senior product manager with 10+ years in B2B SaaS.
Turn the rough notes below into a one-page PRD with these sections:
Problem, Goal & Non-Goals, Success Metrics, Users & Use Cases,
Requirements (as user stories with acceptance criteria), Open Questions & Risks.
Rules:
- Do NOT invent metrics or evidence. Where I haven't given data, write
"[NEEDS DATA]" so I can fill it in.
- Keep it under one page. Cut anything that doesn't reduce ambiguity.
Rough notes: [PASTE YOUR NOTES]2. Requirement → acceptance criteria
Convert this requirement into Given/When/Then acceptance criteria.
Include the unhappy paths and edge cases most PMs forget.
Flag any requirement that is ambiguous enough that two engineers
could build it differently.
Requirement: [PASTE ONE REQUIREMENT]3. Gap check (the one people skip)
You are a skeptical staff engineer reviewing this PRD before estimation.
List every ambiguity, missing edge case, and unstated assumption you'd
raise in review. Rank them by how much rework they'd cause if missed.
PRD: [PASTE YOUR DRAFT]That third prompt is the one that has saved me the most pain. Running your own draft through an adversarial review before the sprint-planning meeting catches the ambiguities that otherwise surface as mid-sprint rework.
The mistakes AI makes worse
Three failure modes I see constantly now that everyone drafts with AI:
- Fabricated confidence. The model writes “increase activation by 15%” and it looks like a real target. Delete every number you did not measure or explicitly choose.
- Generic requirements. AI defaults to requirements that fit any product. If your PRD could describe a competitor’s feature unchanged, it commits to nothing. Force specificity.
- Skipping the problem. It is tempting to prompt straight to “write the requirements.” But a PRD without a validated problem is a solution looking for a justification. Start with the problem, always.
A repeatable workflow
Put it together and the loop looks like this:
- Brain-dump everything you know into rough notes (5 minutes).
- Prompt 1 → structured one-page draft.
- Replace every
[NEEDS DATA]with real evidence, or cut the claim. - Prompt 2 on each core requirement → acceptance criteria.
- Prompt 3 → adversarial gap check, then fix the top issues.
- Human read-through for judgment: is the problem real, is the metric right, is the scope honest?
Ten minutes of prompting plus twenty minutes of judgment beats an afternoon of writing — and produces a tighter document.
Skip the setup. The three prompts above are a starting point. If you want the full, battle-tested library — 16 prompts covering PRDs, sprint planning, effort estimation, retrospectives, and stakeholder communication, each engineered with the guardrails above — that is exactly what the PM’s AI Toolkit is. It is part of the complete PM’s AI Productivity Bundle (42 prompts across the full PM workflow), built by a product manager, not a prompt farm.
FAQ
Can AI write a PRD by itself?
No — and you should not want it to. AI can structure and pressure-test a PRD in minutes, but the problem definition, evidence, metrics, and priority calls require someone who understands the customer. Treat AI as a fast drafting and review partner, not the decision-maker.
How long should a PRD be?
For a single feature, one page. Length is not thoroughness. If a section does not reduce ambiguity for the team building the feature, cut it.
Which AI tool is best for PRDs?
Any capable model works. In practice, tools that produce well-structured, controllable output are best for documents — Claude, ChatGPT, and Gemini all handle the prompts above. The quality difference comes from your prompt and your review, not the logo.
What’s the biggest mistake when using AI for PRDs?
Trusting fabricated specifics. AI will confidently produce metrics, user problems, and evidence it has no basis for. Verify every concrete claim against what you actually know before the document leaves your hands.