Blog
.jpg)
Key takeaways:
Somebody has decided to build something. Maybe you. Now a designer, two engineers and whoever signs the invoice all need the same picture in their heads, and right now they have three different ones.
That is the job a product requirements document does. Not ceremony, not a gate to pass, just the shared answer to what are we building, for whom, and how will we know it worked.
This guide covers what belongs in one, gives you a complete template you can copy straight into a doc, and shows how to write requirements specific enough to be tested rather than argued about. It also covers the honest case against PRDs, which is stronger than most templates admit, and where the document genuinely changes shape when the feature involves AI.
A PRD is the artifact that fixes intent before implementation. It names the problem, the people who have it, the response you intend to build, the measure of success, and the work you are explicitly leaving out.
A product requirements document is not a design. It is not an architecture document, and it is not a project plan with dates. Those are separate artifacts owned by different people, and folding them in is the fastest route to a document too long for anyone to read.
The strongest single rule comes from an unlikely place. NASA's Systems Engineering Handbook tells writers to state WHAT is needed, NOT HOW to provide it. That line does more work than any template. The moment your document says "use a Redis cache," you have made an engineering decision in a product document, and you have made it with less information than the engineer will have.
The test of a good PRD is whether somebody can disagree with it. "The app should be intuitive" is unarguable and therefore worthless. "A first-time user completes signup in under 90 seconds without contacting support" is something a person can push back on, estimate, and later verify.
Four documents get confused for each other, usually because a company has adopted two of the four and uses one name for both. They answer different questions and are typically written by different people.
| Document | Written by | Answers |
|---|---|---|
| MRD (market requirements) | Product marketing | Is there a market, how big, who else is in it |
| BRD (business requirements) | Business analyst or stakeholder | What is the business case, what does it return, what must it comply with |
| PRD (product requirements) | Product manager or founder | What are we building, for whom, and what counts as done |
| Technical spec | Engineering lead or architect | How will it be built, with what, and what are the trade-offs |
The four documents run roughly in that order, and each narrows the one before it. A team that skips straight to a technical spec usually discovers halfway through that nobody agreed on the problem. A team that writes all four for a two-week feature has invented paperwork.
The boundary between the third and the fourth is the one that costs money.
For most of the small and growing companies we work with at VAULT, the PRD and the technical spec are the only two that earn their keep, and the first one often runs to two pages.
Below the PRD sit epics and user stories. An epic groups a body of work toward one goal; a user story is one slice of it from the user's point of view, conventionally written as "as a [type of user], I want to [do something] so that I can [achieve a goal]." The PRD is the layer above both, and it is where the reasoning lives.
Nine sections cover what almost every published product requirements document template agrees on. Copy this skeleton, delete what does not apply, and keep it to two pages if you possibly can.
1. Problem and Context
2. Target Users
3. Goals and Success Metrics
4. Requirements
5. Out of Scope
6. Assumptions, Constraints and Dependencies
7. Acceptance Criteria
8. Open Questions
9. Change LogThe sections below explain what each one is for and show a filled line, so you can see the difference between a heading and an answer.
One or two paragraphs on the pain, who has it, and what it currently costs. Resist writing the solution here. If you already know the answer, say so in Requirements and leave this section honest about the problem.
> Produce distributors reorder from suppliers by phone and email, then rekey the order into their own system. A 40-line order takes about 25 minutes and errors surface at delivery, when they are most expensive to fix.
Working out whether the pain is real belongs before this document exists. Skip that and you get an immaculate specification for something nobody wanted.
Name the specific people, not a demographic. If you have real personas, reference them; if you have interview notes, quote them.
> Primary: the buyer at a mid-size distributor, 30 to 200 orders a week, comfortable with spreadsheets, not with new software. Secondary: the supplier's sales rep, who currently confirms orders by phone.
This is the section most often filled in from imagination, which is why the personas that hold up are the ones built from real customer research rather than a workshop whiteboard.
Pair every goal with the number that would prove it. A goal without a metric is a wish, and a metric without a goal is a dashboard nobody reads.
> Goal: cut the time a buyer spends placing a repeat order.
> Metric: median time from order start to submission under 5 minutes, down from about 25, measured 60 days after launch.
Two or three of these is plenty. Ten means you have not prioritized.
The baseline number is the one people invent. Twenty-five minutes for a 40-line order is a figure somebody timed, not estimated, and a metric measured against a guess proves nothing later.
The functional list: what the product must do. Write each as a discrete, testable statement. Group them if there are more than about a dozen.
> The system shall let a buyer duplicate any order from the previous 12 months into a new draft.
> The system shall flag any line whose price has changed by more than 10% since the duplicated order.
Include non-functional requirements here too, and be specific about them: performance targets, uptime, accessibility standards, data retention, and anything a regulator cares about. "Must be fast" is not a requirement. "Search results return in under 400ms at the 95th percentile" is.
The section teams skip and then regret. Write down what you are deliberately not doing, so the question does not resurface in week six as a surprise.
> Not in v1: partial shipments, multi-warehouse routing, supplier-side price negotiation, any mobile app.
Naming the exclusions is also how you protect the timeline without a difficult conversation later, because the difficult conversation already happened when somebody read this section.
Three different things, worth separating. An assumption is something you expect but have not confirmed. A constraint is a hard limit you must design within. A dependency is something outside your control that you rely on.
> Assumption: buyers will accept prices that refresh nightly rather than in real time.
> Constraint: the launch must not require suppliers to change their existing ERP.
> Dependency: supplier catalog feeds arrive as CSV via SFTP.
Each of these is a place the project can break. Writing them down is what lets somebody check them before they do.
How you will know each requirement is met. The Given/When/Then structure from behavior-driven development is the clearest form, because it forces a starting state, an action, and an observable result.
> Given a buyer with at least one order in the last 12 months, when they select that order and choose Duplicate, then a new draft appears containing every line, with any line whose price moved more than 10% marked for review.
If you cannot write the Then clause as something a person could watch happen, the requirement above it is not finished.
List what you do not know yet, with an owner and a date against each. A PRD that pretends to have every answer is either dishonest or was written after the fact.
> Do buyers want price-change flags on every line, or only above a threshold they set? Owner: product. Needed by: design kickoff.
A dated list of what changed and why. It costs one line per edit and it settles the arguments that otherwise consume a whole meeting six weeks in.
> 2026-03-14: removed partial shipments from v1 after supplier interviews showed it affects under 5% of orders. Requested by ops.
The single most useful page in this whole subject is NASA's checklist for writing a good requirement, which includes a list of words that make one untestable. Their examples: flexible, easy, sufficient, safe, ad hoc, adequate, accommodate, user-friendly, usable, when required, if required, appropriate, fast, portable, light-weight, small, large, maximize, minimize, plus, as they put it, other words ending in "ly" and "ize."
The pattern is that every one of them describes a feeling rather than an observable fact.
| Instead of | Write |
|---|---|
| The interface must be user-friendly | A new user completes their first order without opening help documentation |
| Search must be fast | Search returns results in under 400ms at the 95th percentile |
| The system should handle large orders | The system accepts orders of up to 500 line items without pagination |
| Notifications should be sent when appropriate | A notification is sent within 5 minutes of an order status change |
| Minimize manual data entry | A repeat order requires no more than 3 fields to be typed |
NASA also gives the convention that separates a requirement from a note: "shall" marks a requirement, "will" states a fact or a declaration of purpose, and "should" marks a goal. Using them consistently means a reader can tell at a glance what is binding.
Their traceability test is worth stealing too. Ask what is the worst that could happen if this requirement was not included. If the answer is nothing much, delete it, and your document gets shorter and more useful at the same time.
The banned words all fail the same way, and the fix is always a number.
Numbers specific enough to pass that test have to come from somewhere, and the honest source is watching the work rather than asking about it, since user interviews routinely surface a gap between what people say and what they do.
There is an international standard for this, and almost nobody writing about PRDs mentions it. ISO/IEC/IEEE 29148:2018 covers requirements engineering across the life cycle, and its stated scope is unusually direct: it defines the construct of a good requirement and provides attributes and characteristics of requirements.
Its nine characteristics for an individual requirement are widely reproduced in the engineering literature as: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming. A further six apply to the set as a whole, including that the set is consistent and can be validated.
Two of the nine do most of the work in practice. Singular means one requirement per statement, so anything containing "and" is usually two requirements wearing one number, and it will be half-implemented. Verifiable means somebody can demonstrate it was met, which is the same bar NASA's word list is enforcing from the other direction.
Singular is the one you can check with a search for the word "and".
The full text is paywalled, which is why you rarely see it cited. You do not need the document to use the list.
Every source that discusses failure names the same handful of causes, and they are worth knowing because three of the four are avoidable by editing rather than by working harder.
It goes stale. The build diverges from the document in week two, nobody updates it, and by launch the PRD describes a product that does not exist. The change log is the cheapest fix available.
It gets too long. A PRD that balloons past a few pages stops being read, at which point its length is actively harmful, because people assume the answers are in there somewhere. One product manager described exactly this on Reddit, watching a document grow past 30 pages of acceptance criteria and become unusable.
Nobody else contributed. A document written alone and circulated for approval gets approved without being read. One written in a room with the engineer and the designer gets argued with, which is the point.
It specifies the solution. The most common failure and the hardest to see in your own writing, because a solution feels like clarity. Every implementation detail you fix in the PRD is a decision made before the person with the most information gets to weigh in.
A fifth failure sits outside the document entirely and outranks all of them: the thing described is not worth building. No amount of structure rescues a well-specified answer to a problem nobody had.
Four of them are editing problems. The fifth is not a document problem at all.
The honest counter-argument deserves airing. In that same thread, a commenter made the case that on genuinely novel work you cannot anticipate everything up front, and that believing you can is a sign a team is not set up for rapid feedback.
That is a fair critique of a 30-page PRD and a weak one against a two-page document that names the problem, the users, the metric and the boundary. Write the short version and the objection mostly evaporates.
The phrase means two different things, and it is worth being clear about which you need, because the search results are dominated by the less interesting one.
The common meaning is drafting a PRD with an LLM. That works reasonably for structure and badly for judgment. The failure mode is consistent and easy to miss: AI-generated requirements smuggle in implementation detail, cheerfully proposing a specific database or caching strategy in a document that should stay solution-neutral. Draft with it if you like, then read the output specifically hunting for "how" that has crept in where "what" belongs.
The second meaning is the one that changes the document itself.
The more useful meaning is a PRD for a feature that is itself AI-powered, and that genuinely needs sections a normal PRD does not have.
Getting those five written down is most of the difference between an AI feature that ships and one that demos well and stalls. Data readiness is usually the binding constraint rather than model choice, which is why we push for these answers early on AI implementation engagements.
If the PRD's audience is an agency or a contract team rather than colleagues, the bar goes up, because they cannot absorb context from sitting near you.
An engineer asked to write a spec at a company that had never used them answered on Reddit with what a spec actually needs to contain, rather than reaching for a template. It is a better checklist than most published ones, and it comes from the person receiving the document:
Points four and five are the ones internal PRDs skip most often, and they are exactly what an outside team needs. Without them the team either implements your instruction literally, including the parts that were guesses, or spends the first fortnight reverse-engineering your reasoning.
When we scoped the subscription model behind ProduceDesk, a logistics platform now adding new revenue streams for its operator, the decisions that mattered most were the ones about what the first version would refuse to do. Those belong in writing before anybody estimates anything.
A PRD is worth maintaining for exactly as long as people are making decisions from it, which is usually through the first release and rarely much beyond.
Three habits keep it honest. Log every material change with a date and a reason. Move answered questions out of Open Questions rather than deleting them, so a reader can see what was decided. And when a requirement is dropped, mark it dropped instead of removing the line, because the reason will be asked for again.
What you are protecting against is the version-in-someone's-head problem, where four people each remember a different scope and all of them are partly right. The document does not need to be beautiful. It needs to be the thing everybody points at.
That habit pays off most after launch, when real usage starts contradicting your assumptions and you need to know which ones you actually made. Reading the original metrics next to what users do after release is a much shorter conversation when the metrics were written down.
If you take one thing from this: write the short version of your product requirements document first. Problem, users, two metrics, the requirements you are sure about, and a clear list of what you are not building. Circulate that, let people argue with it, and expand only where the argument shows you were vague.
Most bad versions of this document are not bad because they missed a section. They are bad because they were written to look thorough rather than to be disagreed with. A document somebody can push back on is doing its job, and a template only helps once you have accepted that the writing, not the structure, is the work.
For an idea that has not been committed to yet, a lean canvas gets you to the same clarity in less time, which is why we keep one alongside the forecasting models in our startup hub.
It is a short document that states the problem you are solving, who has it, what the product will do about it, how you will measure success, and what you are deliberately leaving out. It fixes intent before anyone writes code, and it is written by whoever owns the product decision, typically a product manager or a founder.
Two pages for most features, and rarely more than five. Length correlates with being ignored rather than with being thorough. If yours is running long, the usual causes are implementation detail that belongs in a technical spec, or a scope that should have been split into two documents.
The PRD covers what and why; the technical spec covers how. The PRD says a repeat order must take under five minutes and flag price changes over 10%; the spec decides the data model, the caching, and which service owns the job. Different authors, different audiences, and mixing them means the engineering decision gets made by whoever wrote first.
Yes, and reading real ones beats reading templates. Figma's PRD template is published openly and organizes around problem alignment, solution alignment and launch readiness rather than a flat section list. Lenny Rachitsky's newsletter collects nine of these from companies including Square, Asana, Intercom and Product Hunt, each with a line on what he takes from it. Both are worth reading precisely because they differ from each other.
At minimum the engineer who will build it and the designer who will design it, because they are the two people most likely to find the ambiguity. Add whoever owns the budget if the scope has cost implications, and anyone whose team inherits support for the thing. Reviewing means arguing with it, not approving it.
A requirements document is easiest to fix before anyone estimates against it. If you have written one and want to know where an engineering team will find it ambiguous, that is a short conversation and a useful one.
Contact us and we will read it with the questions a build team would ask.
