How to write a PRD (product requirements document)

What is a PRD, and what is it not?

A PRD describes the product from three sides: the user’s, the commercial and the technical. It names the problem and the people who live it, the product and the first version worth releasing, the evidence and the assumptions behind the case, the requirements engineering will build and test, and the measures that will say whether it worked. Everyone involved reads the same document, so a question raised in a review is answered by turning to a section rather than by calling a meeting.

In our experience, a PRD that only specifies is rarely enough. A sponsor, an investor and an engineer ask different questions of the same product, and a document written for engineers seldom wins the decision that funds them. So we recommend two views of the PRD on one structure: a deck that makes the case to the people who decide, and a document that holds the detail for the people who build, with the same sections and the same numbers.

It also helps to be clear about what a PRD is not. The documents around it answer different questions.

A PRD names the technology the product relies on and how mature it is, but leaves the design of the system to the technical specification. It draws the line between the first version and everything after it, while the backlog keeps every feature on record.

When do you need a PRD?

When a validated opportunity is about to receive a budget and a team. The trigger is a decision: a sponsor or product leader asks for an opportunity to be built after it has been tested with real-world evidence. From that point the cost of ambiguity rises fast: several teams start work, partners and budgets are committed, and every open question turns into a meeting.

Not every idea needs one. An idea headed for a patent filing, a feature that joins an existing product’s backlog, or a concept still being tested needs something lighter: a one-page idea, a business experiment or a user story with acceptance criteria. A full PRD for an untested idea only specifies the wrong things in more detail.

A practical test: if the product needs a funding decision, involves more than one team, or will be used by real customers, it needs a PRD.

What goes in a PRD? Four parts, from discovery to launch

A PRD has to answer the questions the people who fund and build the product will ask, roughly in the order they ask them. We organise it in four parts that follow the product’s life, with 29 sections in all, each answering one question. An executive summary opens the PRD; the requirements, the quality requirements and the sources close it. The full map of the sections, with the question each one answers, is on the Product Toolkit page.

1. Discover: is there an opportunity worth pursuing?

Start with the problem, told from the side of the people who live it and with no solution in it: who is affected, what goes wrong, in what situation, and what it costs them. Then the users, built from research: who you build for first, who pays and who influences the purchase. Size the market as the buyer sees it, from the bottom up, rather than as a share of a large number. Map the competition, starting with what people do today without you, and say where you win in terms a competitor cannot copy with a sentence. The part ends with the opportunity in numbers: what it costs, what it earns and when it breaks even.

Two failures are common at this stage: personas invented without research, and a top-down share of a huge market that nobody can argue with or verify.

2. Define: what exactly is the product?

State the vision in one sentence that names a place and a mechanism, then the value proposition: for whom, what, and unlike what. Describe the happy path, the experience when everything works, step by step and as outcomes rather than screens, and tie every step the product performs to a feature. List the features of the first version, each linked to a persona and marked Must or Should.

At the heart of this part is the minimum viable product: what it must prove and how you will know, what comes later and on what condition, and what you will deliberately not do. Writing down what is out is what stops the scope from growing by default. The part closes with the business model and the revenue model: who pays whom, for what, and at what price.

Deciding what stays out is the harder half of the work. The book puts the test for each feature this way:

How to define an MVP walks through the method, from the complete product to its first instance.

3. Build: what could make it fail, and how will you find out early?

This part takes the risk out of the plan before the money is spent. Write the value hypothesis and the growth hypothesis so that they can fail, each with a measurable signal and a date. List the silent assumptions, the decisions the team is making without noticing, each with an owner and a date by which it will be answered. Rank the risks by likelihood and impact, starting from the evidence rather than from a generic register.

Then plan the experiments that retire the riskiest assumptions first, and write each decision rule before the data arrives; the Business Experiment Template sets one out on a page. The part closes with the technology the product relies on and how mature it is, the route to the first version in phases that end in gates, each gate a decision rather than a date, and the team that will build and run it.

4. Launch: how will it reach the market, and how will you know it works?

Go-to-market starts from a beachhead, the first segment you can reach, and a sequence of moves to the next. Describe success one year after launch as the headline you would want to read, about the user’s outcome rather than the launch itself. Choose one north star measure with a target, a date and a definition precise enough to build a dashboard from: a count of sign-ups or page views is a vanity measure, not a north star. Then the loops that make growth compound, what comes after the first version and on what condition, and the ask: the amount, the time, what it will prove, and how it is released against the gates.

The requirements

The requirements close the PRD and carry it into the build. Write each one as a user story in the persona’s name, with an ID and a priority, and give it acceptance criteria in the form Given, When, Then, with at least one criterion for the failure or the edge case. Quality requirements, such as security, privacy, performance and accessibility, need a threshold that can be tested: “fast and secure” cannot be. User stories in Agile covers the format.

How to write a PRD, step by step

The order in which you write a PRD matters as much as its structure.

1. Start from what validation produced. The problem framing, the product concept, the experiments and the decision are your inputs. Carry the value proposition over unchanged unless new evidence changes it, so that the chain from concept to PRD holds.
2. Frame the complete product, then cut. Capture every feature of the full product as epic user stories in a backlog, then draw the line that defines the first version. Thinking big first is what makes the minimum a deliberate choice rather than the first few obvious features.
3. Draft the document first, part by part. Mark every figure as reported, with its source, or assumed, with what is assumed. The assumed figures are the first things to test.
4. Build the deck from the document. One claim per slide, with the same numbers, so that the case and the detail never disagree.
5. Write the executive summary last. The problem, the product, the market, the plan and the ask, each in a line that stands on its own.
6. Have it challenged before you ask for a decision. Ask readers outside the team to test the scope and the figures, thinking both as users and as investors, and fix what they find before the review.

AI assistants can draft sections and challenge a draft, and Ainna, the agentic innovation platform, can draft a complete PRD on this structure from a framed concept. Neither replaces the evidence: only real users and real experiments can validate what a PRD assumes.

How long should a PRD be, and how do you keep it current?

As long as the decision needs, and no longer. The deck makes the case with one claim per slide; the document holds the detail where someone will use it: requirements and acceptance criteria for engineering, the figures and their basis for the sponsor. A fifty-page document that nobody finishes fails as surely as a slide with no numbers.

Give the PRD an ID and a version from the first draft, so that there is never doubt about which version was approved. Then keep it alive. When an experiment confirms an assumption, the figure becomes reported, with its source; when one fails, the plan changes, and sometimes the failure becomes the product. Record what changed and why. A PRD that stops changing after the funding decision no longer describes the product being built.

What changes in a PRD for an AI product?

When a learned, probabilistic model is responsible for what the user experiences, the same input can produce different outputs, and “correct” becomes a range rather than a yes or a no. Three parts of the PRD change. Acceptance criteria become evaluations: the quality dimensions that matter, such as accuracy, relevance, safety and tone, how each is measured, and the threshold that passes. Guardrails join the requirements: what the system must never do, at input, at output, in the actions it may take, and when it hands over to a person. And the model becomes a dependency to plan for: what happens to quality, availability and cost when a provider changes it, and what keeps the product defensible if a competitor uses the same model.

The document also changes pace. The strategic layer (the problem, the users, the value proposition) changes rarely; the tactical layer (priorities, thresholds, guardrails) changes as you learn from users; the technical layer (models, prompts, evaluation sets) may change with every major model release. Keep the PRD distinct from the instructions you give the AI itself: the PRD aligns people, while the agent specification, with its prompts, evaluations and guardrails, constrains the machine. Rethinking product requirements for the AI era sets out the full framework.

What comes before the PRD?

A PRD is only as good as the work before it. Built on an untested idea, it specifies the wrong things in detail, however good the writing.

That work starts with a problem statement, which frames the problem before anyone proposes a solution. Business ideas describe the candidate solutions in one format, so that they can be compared and scored, and the strongest becomes a product concept: why the product should exist and what it does. Business experiments then test the riskiest assumptions, and a sponsor decides. The PRD picks up from that decision. The Innovation Toolkit covers every step before it, and our guide to product discovery documentation shows how much to write at each stage.

Templates and a worked example

The Product Toolkit puts this structure to work: a PRD deck template and a PRD document template on the same 29 sections, a complete PRD written in both for a realistic venture and annotated by its author, the Field Guide with a twenty-question gate review, and twelve prompts for AI assistants. It costs €349, paid once, with a perpetual licence for one organisation and all its teams; students and educators can request an academic licence.