How to Write a Product Requirements Document (PRD) With AI
A PRD earns its keep by separating the feature somebody asked for from the problem they actually have — then fixing scope, numbering the requirements, and handing the open questions to the people who own them.
Build the PRD Structure PromptThe request was never the problem
"Add a CSV export." It arrives in a ticket, survives a planning meeting, and lands in the PRD, which is where it stops being a suggestion and starts being the plan. Six weeks later the export ships and finance carries on doing what they were doing before — pulling the numbers by hand — because their ledger has eleven columns and your product knows about six. No export of any format was going to fix that. Nobody hid it. It just never got asked, because the document that would have asked started from the answer.
That is the specific thing a PRD is for, and it is why a longer requirements list does not get you there. A requirement says what should happen. A PRD says who has the problem, what it costs them now, what you are choosing to change and what you are pointedly not, and how anyone would know afterwards whether it worked. Requirements written without that sit there looking reasonable while three people build three different products from them, each filling the missing why with their own.
What AI can do here, and where the document stops being its business
AI is good at the parts of this that are shaping. Hand it your scattered notes and it will produce a document with the sections in the right places, push back on the fields you left vague, catch the requirement on line nine that contradicts the scope on line four, and turn "make it faster" into something with a number-shaped hole where a number should go. That is real work and it is most of the typing.
None of it is knowledge the model has. What NewPrompt assembles is a prompt, in your browser, and nothing past that line — which is blunter than usual because product work fakes convincingly: no customer interviews, no reading your analytics or your product database or your issue tracker, no market research, no confirmation that anyone wants this, no running the model on your behalf, no schedule and no sprint, nobody assigned anything, no decision made, and nothing built. Every fact in the PRD is one you supplied. What comes back from your own assistant is a candidate draft — the product owner and the stakeholders confirm the scope, the requirements, the metrics and the decisions; technical, legal and security review go to the people who own those; and a PRD proves nothing about correctness, is not evidence that anyone wants the product, and does not make it ship.
The failure mode this creates is specific, and it is the one to watch for all the way down. A model asked for a document with a Timeline section will write you a timeline. Asked for a success metric, it will produce a plausible percentage. It is not lying. It is filling a slot you left open, and it has no way to tell you the number came from nowhere. Anything in the draft that looks like a fact and did not come from you is the model being helpful in the most expensive available way.
Step 1: Separate the ask from the problem before anything else
Write the request down. Then, underneath it and separately, write the problem — whose it is, what they do today because of it, and what that costs. Keep both. The request is real evidence of something. It is just evidence that somebody wanted a thing badly enough to file a ticket, which is a different claim from the thing helping.
Then label what you have, because these are different kinds of claim and a document that flattens them is how a guess gets built:
The last two labels are the ones people skip and the ones that matter. An assumption written as a finding is indistinguishable from a finding six weeks later, when everybody who was in the room has moved on. And why now deserves its own line: a real problem that has been a real problem for two years and will be one next year is not urgent, and the honest answer here is sometimes "no reason — it came up." That is legitimate, and useful to have written down.
- Verified product fact — it is true and you can point at where you checked.
- User research finding — somebody said it, and you know how many somebodies and when.
- Analytics observation — a number from a system, with the query or the report behind it.
- Stakeholder decision — a person chose this. Which person.
- Assumption — you believe it, nothing under it.
- Open question — nobody knows yet.
Step 2: Goals, non-goals, and the number you did not make up
A goal is an outcome you want. It is neither a feature nor a metric, and the discipline that keeps a PRD honest is keeping four things apart:
Non-goals get treated as filler and they are the opposite. A non-goal is the small set of things a reasonable reader would otherwise assume was included, written down so they stop assuming — not the infinite list of everything you are not building, which is worthless. If a non-goal would not surprise anyone, delete it. If it would start an argument, it is the most valuable line in the document, and that argument is cheaper here than in a code review.
One caution on the vocabulary. A non-goal in a product document means something the product deliberately will not do — a scope decision people can disagree with. In a prompt it means an instruction to a model about what to leave alone. Same words, different documents, and readers who live in both will cross the wires unless you say which one you mean.
- The goal — what changes for the user, stated so it could be false.
- The metric — how you would observe whether it changed.
- The measurement source — where that number comes from. If you cannot name the table, the log, or the report, the metric is a wish.
- The target — the threshold. This one comes from the owner, or it says TBD.
- The instrumentation gap — the case where the metric is right and the data to compute it does not exist yet. Write it down; it is usually work nobody has scoped.
Step 3: Fix the scope before you write a single requirement
Scope is a decision, and requirements are downstream of it. Reverse the order and you get a list that grows every time somebody reads it, because with no boundary there is no principled reason to say no to anything. Each addition is individually sensible and the sum is a year of work.
Write the core journey first, in plain sentences: the user does this, then this, then this, and here is the state they end in. It is the cheapest consistency check in the document. Every requirement should be traceable to a step in it, and any requirement that is not is either a step you forgot to write down or a requirement that does not belong here — both worth finding before the estimating starts.
This is also where a PRD stops and other documents begin, and the boundaries hold better if you name them out loud. Cutting the whole idea down to a first release is scope planning. Deciding how to build it is design. Ordering the work and putting dates on it is a plan. A PRD that starts doing any of the three has stopped being reviewable by the people whose review it needed.
Step 4: Number the requirements, and keep them requirements
Number them. R1, R2, R3. It is a small thing that changes how a document gets reviewed: "R4 conflicts with the non-goal" is a comment somebody can act on, and "I think there's a contradiction somewhere in the requirements" is not. Once they are numbered they can be referenced, argued with individually, and traced afterwards.
Then keep each one a requirement, which mostly means noticing the three things they drift into:
Non-functional requirements go in where there is a real product need with a real reason behind it. "Fast, secure, scalable" as a standing trio is decoration — every reviewer's eye slides over it, and it reaches launch having constrained nothing. "The window has to apply within a minute of being saved, because agents set it as they go to bed" is a requirement. It has a number, a reason, and a way to fail.
Markdown Output Builder is where the prompt for this gets built, in your browser. Its PRD document type is worth reaching for because the domain rules are already in it: it ships the requirement-numbering rule, and the rule that every requirement must be testable rather than "should be fast" with no number. Load its PRD preset and it also pins a section list and an order — and it is a builder, so change them. The shipped shape is Problem, Goals, Non-Goals, Requirements, Risks, Timeline, and there is room for a dozen sections in total.
Two things to know before you use it. It formats; it does not check. It will hold your headings in place and cannot tell you a requirement is genuinely measurable or that your non-goals are the right ones. And the shipped shape ends with a Timeline of phases and milestones, which is the section this guide has been arguing is not a PRD's job — under the preset's strict consistency setting the model is told to use every section and omit no heading, so it will fill it. If you have real dates from real planning, use it. If you do not, spend the slot on what the default leaves out: target users, the evidence, why now, the metric and where it is measured, the dependencies, the open questions, and who owns which decision.
- A requirement, which says what must be true: "routine notifications are not delivered during the window."
- A solution preference, which says how: "use a scheduled job to suppress them." That is a design decision wearing a requirement's clothes, and it takes an option away from the people who should be choosing.
- A task, which says who does what by when. That belongs in a plan, and once a PRD is full of them the people who came to argue about scope find themselves approving a schedule.
Step 5: Send it out with the open questions still open
The instinct at the end is to tidy. Resist it on exactly one axis: do not close the open questions. A PRD with none in it is rarely finished. It is usually a document where somebody — often the model, occasionally you at 6pm — quietly decided a thing that was not theirs to decide, and the decision is now invisible because it reads like everything around it.
So each open question gets a name attached: who answers this, and what it blocks. "Timezone: agent-local or workspace-fixed?" is a question. "Timezone handling should be considered" is a requirement with a question mark on the end, and nobody will ever answer it. Same for the constraints, the dependencies, the assumptions and the risks — all four are only useful when they are specific enough to be wrong. "There are integration risks" costs nothing to write and nothing to ignore.
Then hand it over, and be clear about what has been handed. A PRD goes for review to the people who can say the scope is wrong — the product owner, and the owners of whatever it depends on. Engineering, legal and security reviews are separate errands to separate people; a section acknowledging that a thing needs legal review is a note to a lawyer, never a substitute for one. And what comes back approved is agreement about what to build and why. Whether anybody wanted it is a different question with a different way of being answered, and this document cannot settle it no matter how good it is.
Common mistakes
Most of these are one error at different sizes: something nobody knew got written in a tone that implies somebody did.
- Treating the request's popularity as evidence for its solution. Forty people asked for the CSV export, so R1 says CSV export. Forty people are excellent evidence that something hurts and no evidence at all about what fixes it — and the count makes the leap feel rigorous.
- The metric that arrived with a target attached. The model wrote "reduce ticket volume 30%" and the number is from nowhere. You have no baseline, and now you have a goal you will be measured against that was generated to fill a slot.
- A requirement with its acceptance criteria bolted underneath. It looks thorough and it quietly changes the document's altitude — write out every test for R1 and the reader stops seeing a product decision and starts reviewing a spec.
- Dependencies that are courtesies. "Depends on Finance" is not a dependency. "The ledger's eleven columns live in Finance's system, nobody owns the mapping, unresolved" is one, because it can block something and somebody has to move.
- Non-goals nobody would have assumed anyway. "We are not building a CRM." Nobody thought you were, and the line reads as diligence while costing the reader a decision they never had to make.
A quiet-hours request, turned into a PRD
One line in a ticket — the same shape as the CSV export, and this time somebody looked underneath. The interesting part is R3: it is not in the request, and without it the requested feature would sanction the exact behavior causing the problem. Note also that twenty-odd blocks here go well past the builder's twelve-section cap; the builder pins a skeleton, and the document is the rest. All data below is fictional sample data.
A one-line request opened up: the problem separated from the ask, evidence labelled by what kind of claim it is, seven numbered requirements that name no mechanism, a target left at TBD because three hand-counted breaches are not a baseline, and every open question still carrying a nameTHE REQUEST AS FILED #4417, Support lead
"Can we add quiet hours so people stop getting notified at night?"
THE PROBLEM UNDERNEATH IT
Fourteen support agents across three timezones share one alert queue.
Every notification arrives at the same priority, so the only control an
agent has is all-or-nothing. Eleven of them have muted the mobile app at
the OS level. They now sleep through the 3am escalations too.
^ read those two boxes together. Quiet hours ALONE — silence a window,
no other change — does not touch the reported problem. It blesses it.
Eleven agents already built this feature themselves with the OS mute,
and that mute is precisely why the 3am pages get missed. Shipping it
as a product feature mostly gets it adopted by the three who so far
declined to. This is why the request does not enter as the requirement.
EVIDENCE SUPPLIED (fictional sample data)
[survey] 11 of 14 agents run the mobile app muted at OS level.
Support-team survey, 2026-05, n=14. Self-reported.
[hand count] 4 escalations in Q1 acknowledged >30 min after paging;
3 of the 4 were overnight. Counted by hand from the
escalation log — not instrumented, not queryable.
[ASSUMPTION] That agents would leave notifications on if only escalations
came through overnight. Nobody has tested this. Not evidence.
^ the label is doing real work. Row 3 is the load-bearing belief of the
whole document and it is the one with nothing underneath it.
TARGET USERS Support agents on the shared escalation queue (14 today, 3 tz).
Not admins. Not customers. Not the desktop client's users.
WHY NOW The on-call rotation goes 24/7 in Q3.
[ASSUMPTION — came out of a planning conversation. Nobody has
agreed it. See OWNER DECISIONS.]
If it holds: today's all-or-nothing mute is survivable because
a daytime shift catches what was missed overnight, and with no
daytime overlap it stops being.
^ the document's why-now and its load-bearing belief are both unbacked.
Label them both, or the first reader banks this one as a fact.
GOAL An agent can be unreachable for routine notifications without
being unreachable for escalations.
NON-GOALS - Changing what counts as an escalation. That is the routing
rules, owned by Platform. We consume the classification.
- Per-customer notification preferences.
- Any change to the desktop client. Muting happens on mobile.
CORE JOURNEY Agent sets a window on their profile -> sleeps -> routine
notifications do not arrive -> an escalation does -> agent
acknowledges it -> in the morning the routine ones are waiting
in-app, none lost. A second agent, no window set, sees none of
this: same night, same queue, delivery unchanged.
IN SCOPE Per-agent window; suppression of routine notifications during
it; unchanged delivery of escalations; the in-app catch-up.
OUT OF SCOPE Rota coverage rules. Classification accuracy. Desktop. Digest
emails. Anything per-customer.
REQUIREMENTS
R1 An agent can set a quiet-hours window (start, end, timezone) on their
own profile.
R2 During an agent's window, notifications classified routine are not
delivered to that agent.
R3 During an agent's window, notifications classified escalation are
delivered unchanged.
R4 An agent's window has no effect on what any other agent receives.
R5 Routine notifications suppressed during a window are present in the
agent's in-app queue afterwards. Nothing is dropped.
R6 With no window set, delivery behavior is identical to today's.
R7 A notification with no classification, or an unrecognized one, is
delivered unchanged. Silence is never the default.
^ R3 is the requirement the request did not ask for and the problem
statement demands. R7 exists because R2 and R3 between them only
cover two of the three states a notification can be in — the first
draft had no rule at all for the third, and an engineer building
R1-R6 would have had to invent one. Trace each back to the journey:
R4 and R6 are why its last sentence is there. None of the seven names
a mechanism — no cron job, no flag, no schema. Those belong to design.
CONSTRAINT Classification (routine vs escalation) already exists and is
owned by the routing service. This PRD does not change it.
R2 and R3 inherit its accuracy, whatever that turns out to be.
DEPENDENCY The classification field must be readable at delivery time.
Today it is applied at queue time. Unresolved.
Owner: Platform. <- a real blocker, not a courtesy mention
RISK Classification is not ours and R2 inherits its errors. An
escalation misclassified as routine gets suppressed by R2 — a
missed page we caused rather than one a mute caused. Nothing
here prevents that: it is accepted, and it is why the metric
below is ack time. Raise with Platform.
^ note what this risk is not: R7 does not save it. A misclassified
escalation is classified, just wrongly, so it never reaches R7's
unknown case. The first draft of this document claimed R7 as the
mitigation and it was a non-sequitur.
SUCCESS METRIC Median acknowledge time for overnight escalations.
MEASUREMENT SOURCE The escalation log's ack timestamp.
INSTRUMENTATION GAP Ack time is recorded but not queryable by hour. The
metric does not exist until someone builds that view.
TARGET TBD — owner decision.
^ three overnight data points, hand-counted, and they are only the ones
that breached 30 minutes — not a sample of ack times at all. You
cannot take a median of the slow half. "Cut ack time 40%" would read
beautifully on this line and would be invented. TBD is the true value.
OPEN QUESTIONS
Q1 Does a window suppress routine notifications for an agent who is the
only one on call, or should the window not apply at all? R3 is not at
issue — escalations deliver either way. This is about the routine rule
under solo cover. Sits next to rota coverage, which is out of scope;
flagged in case it turns out to be a rota decision wearing this one's
clothes. Owner: Support lead. Blocks: R2's edge behavior.
Q2 Window in agent-local time or workspace-fixed? Affects R1 and every
test of R2. Owner: Support lead. Blocks: R1.
OWNER DECISIONS NEEDED
- Support lead: Q1, Q2, and the target.
- Platform: the delivery-time classification dependency.
- Nobody has agreed to the Q3 rotation this document's WHY NOW rests on.
Recorded as an assumption so it is somebody's to confirm, rather than
everybody's to assume.
HANDOFF
For review: Support lead (scope, Q1, Q2), Platform (the dependency).
Not in here: who builds it, in what order, by when. R2 alone is probably
three stories; slicing them and writing their acceptance criteria is the
next artifact.Where this fits in NewPrompt
The PRD Prompt is the artifact form of the hero above: a ready-made output contract — Problem, Goals, Non-Goals, numbered Requirements, Risks, Timeline — that pins the structure so two PRDs by two authors come out the same shape. Its own copy is admirably blunt about the limit: it enforces the wording, not the truth. It can't confirm a requirement is genuinely measurable or that your Non-Goals are right, and it carries the Timeline section from Step 4. Use it as the skeleton and supply the document.
Upstream of it, the Product Requirements Assistant is a different tool for a different moment — a standing system prompt that takes one rough feature idea and structures it into a problem statement, acceptance criteria and an explicit out-of-scope. Note the grain: one requirement, not a product. It is what you reach for when a single ask needs sharpening; a PRD is what you reach for when a set of them needs a reason to exist together. The Feature Request Template is the intake form for the ask, and it is more opinionated than intake usually is: its variables are the fields Step 1 pulls apart — user problem and proposed solution, kept in separate boxes — but it also asks you to arrive with the acceptance criteria, the out-of-scope list and the success metric already decided, and it outputs a single-feature spec. Which makes it a good forcing function and a poor place to work out what you think.
The broader path is the AI Product Requirements Workflow: interrogate the need into requirements, shape them as user stories, then assemble those into the document. Worth knowing that its order and this guide's are not the same — the workflow shapes stories first and gathers them up at the end; this guide starts from a raw problem, writes the document, and leaves the slicing for after. Either way the document is where decisions get recorded rather than made. NewPrompt gives you the prompts and the sequence; running them and deciding what goes in are yours. If the product is a build rather than a feature, Build a SaaS MVP with AI opens on exactly this — define what you are actually building, before any code — and every stage after it is downstream of the answer.
A PRD is the last document in the chain where "we do not know yet" is still allowed to be an answer. Stories have to be estimable, acceptance criteria have to be checkable, tasks have to be assigned — by the time the work starts, every open question has been closed by somebody, usually whoever got there first and had a deadline. Writing them down while they are still questions is most of what the document is for. Because an open question in a document is a decision somebody still gets to make, which is exactly what it stops being once the building starts.