How to Use AI to Write a PRD (and Requirements That Hold Up in Review)

Use AI to create a PRD by giving it the raw material you already have, the ticket, the research notes, the transcript, then asking it to list the decisions nobody has made yet. Get those answered by the people who own them. Draft afterwards. AI is fast at structure and confident about things your team has not decided.

This is for product managers who are going to use ChatGPT, Claude or whatever sits in their doc tool for this anyway, and would rather the output survive a review with engineering in the room. It covers the workflow, what the models reliably get wrong, how to handle requirements specifically, and what “PRD for AI” actually means.

What AI gets wrong when it writes a PRD

Three failures show up in almost every AI-drafted PRD, and none of them look like errors on the page.

The first is confident prose over undecided questions. The model has no way of knowing which parts of your input were decisions and which were placeholders, so it writes them all in the same voice. A sentence you agonised over in a design review and a sentence the model produced to fill a heading are typographically identical.

The second is invented acceptance criteria. These are the most dangerous output because they are plausible. Ask for acceptance criteria on an export feature and you will get a clean Given/When/Then for the happy path, which is the one case nobody was ever going to get wrong.

The third is that nobody argued about it. A PRD is not a writing task with a research problem attached. It is a decision record with a writing task attached, and a document produced in ten seconds from one person’s prompt has recorded exactly one person’s assumptions. It reads finished, so it gets approved rather than interrogated.

What the draft says	What is actually happening
”Users can export their data as CSV or PDF.”	A scope decision has been made by a model, not by you
”Success metric: 20% lift in weekly active users.”	A target has been fabricated because the heading needed filling
”Out of scope: mobile.”	An exclusion has been guessed at, and it will be disputed
”Given a logged-in user, when they click Export, then a file downloads.”	The happy path is being presented as the acceptance criteria

None of that is an argument against using AI here. It is an argument for using it in the right order.

How to use AI to create a PRD

Work in this order and the model spends its time on structure and stress-testing rather than on inventing product decisions.

1. Gather the context first. The ticket, the customer conversation, the analytics question, the last PRD for an adjacent feature, the support threads. Paste it all in. A model with no context does not tell you it lacks context. It writes around the hole.
2. Ask for the questions, not the draft. Your first prompt should be some version of: read this and list every decision that has not been made, plus who would have to make it. Do not let it answer them. This one instruction removes most of the fabrication risk.
3. Take the open list to the people who own it. Usually five to fifteen questions, most answerable in a thread. The ones that need a call are the ones that would have surfaced in review anyway, three weeks later.
4. Draft with your own headings. Paste in the actual PRD template your team uses rather than accepting whatever structure the model prefers. If you do not have one, the structure, best practices and mistakes guide to writing a PRD covers what the sections are for.
5. Mark every sentence you did not verify. Bold, highlight, whatever you like. Anything still unmarked at the end is a guess going out with your name on it.
6. Turn the model on the draft. Prompt it as the engineer who has to build this, and ask what is ambiguous enough that two developers could implement it differently. It is much better at finding gaps in text than at filling them.
7. Cut. AI drafts run long because length is cheap for them and reads like effort. Delete anything you would not defend out loud.

The step people skip is the second one, because it feels like a delay when a full draft is one prompt away. Review comments are the most expensive place to discover that nobody agreed the scope.

How do you use AI to write requirements?

Use it to expand and pressure-test requirements you have already decided, never to originate them. The distinction matters more at requirement level than anywhere else in the document, because a requirement is the sentence an engineer implements literally.

AI is genuinely good at four things here: normalising phrasing across a list, generating candidate edge cases for you to accept or reject, spotting requirements that contradict each other, and converting between formats when your team wants Given/When/Then instead of prose. On acceptance criteria formats and how they differ from a definition of ready, it will follow whichever convention you show it.

It is bad at everything involving a number. Timeouts, retry counts, page sizes, permission levels, retention periods, rate limits. It will supply all of them and they will look reasonable.

A pass that works, once you have a draft list:

1. Ask it to extract every requirement into a flat numbered list, stripped of narrative. Seeing them separated from the prose is usually the first shock.
2. Ask which of them can be tested. Anything that cannot be tested gets rewritten or deleted, and “the interface should be intuitive” gets deleted.
3. Ask for the contradictions between them. This is the strongest use of the whole exercise and takes about a minute.
4. Ask for the negative cases it thinks are missing, then decide each one yourself. Half will be irrelevant. The other half are the ones that would have become bugs.
5. Put the numbers back in by hand. Every threshold in the document should be one you can trace to a person or a measurement.

What is the “PRD method in AI”?

There is no established method by that name, and any article presenting one as standard practice has made it up. The phrase turns up in search because two separate ideas have collided.

The first is using AI to produce the PRD, which is what most people mean and what the workflow above describes. The second is treating a written spec as the primary artefact that AI coding tools then work from, which does have a name and a growing set of practices around it. That is covered in what spec-driven development is and whether it actually works.

Worth saying plainly: neither is a methodology in the sense that Scrum is. They are working habits, and treating them as a formal framework is how teams end up with ceremony instead of a decision.

How to write a good PRD for an AI feature

Specify the behaviour band and the failure handling, not the output. This is where PRDs for AI features break, because the usual approach of writing exact expected results does not survive contact with a probabilistic system.

Five things an AI feature PRD needs that a normal one does not:

• What good enough looks like, expressed as a rate or a band rather than a single correct answer. “Correctly extracts the invoice total on at least 95 of the 100 documents in the evaluation set” is a requirement. “Extracts invoice totals accurately” is a wish.
• An evaluation set that exists. Name it, say who assembled it, say where it lives. A PRD that assumes someone will produce one later has deferred the hardest task in the project.
• What wrong looks like, and what happens then. Silent failure, visible failure, human review queue, refusal. Pick one per failure type.
• The fallback when the model is unavailable or too slow. It will be both at some point.
• Data handling. What goes to the provider, what is retained, what the customer has been told.

If the PRD’s real audience is a coding agent rather than a person, the constraints are different again and the phrasing gets stricter. That is a separate craft, covered in how to write requirements an AI coding agent can actually follow.

Which AI tool is best for writing PRDs?

No single tool wins, and the useful question is not which one writes the best prose. It is which one can see what your team already knows.

Category	What it is good at	Where it falls down
General assistants (ChatGPT, Claude, Gemini)	Drafting, restructuring, edge-case lists, playing the sceptical reviewer	Knows only what you paste, and will not tell you what is missing
AI inside your doc tool (Notion, Confluence, Google Docs)	Drafting in place, summarising a comment thread, keeping format	Fluent about whether anything was actually decided
Coding agents and IDE tools	Turning an agreed spec into tickets or scaffolding	Will build the invented requirement as cheerfully as the real one
Planning tools that run the conversation	Getting the open questions answered before a draft exists	Still needs the people who own the answers to show up

That last category is small and worth knowing about. Projan is one example: it works in Slack, Microsoft Teams or its own workspace, pulls in an existing ticket or document so the session does not start from a blank page, and puts the questions a PRD has to answer to the team rather than to one person. The answers become the document, and the tasks go out to Jira, Linear or Notion.

For most teams the honest answer is a general assistant plus discipline. The discipline is the part that transfers between tools.

Frequently asked questions

Which AI is best for PRD? Test it rather than trust a ranking. Take a PRD you already shipped, strip the decisions out of it, and ask each model to reconstruct it from the same context you had at the time. The one that asks you questions instead of confidently filling the gaps is the one to keep. Model quality moves faster than any recommendation stays accurate.

Can AI draft a PRD from a meeting transcript? Yes, and it is one of the better uses, because a transcript contains decisions people actually made rather than guesses. Ask for a decision list first, with the person who made each call, then check that list against your memory of the room. Anything the transcript does not support is still invented, whatever the model says about it.

Should you tell reviewers a PRD was drafted with AI? Tell them what you verified, which is more useful than a disclosure. Reviewers do not need a label. They need to know which sections are settled and which are proposals waiting on an answer, so mark those two states in the document. A PRD where every sentence reads as decided gets skimmed, whatever produced it.

Does an AI-drafted PRD need a different review? It needs one extra pass before the normal one. Go through the draft and separate what you supplied from what the model supplied, because reviewers cannot tell the difference and will assume all of it came from you. Numbers, thresholds and exclusions are where invented content hides. After that pass, review it like any other PRD.

AI removes the blank page and the formatting work, which was never the hard part of a PRD. The hard part is getting four people to agree what is in scope, and no model can do that on your behalf. Use it to find the questions, answer them with humans, and let the document be the record of what you settled.