Product requirements document template for teams and AI coding tools

Most product requirements document template pages give you a blank form inside a document tool. The form is quick to fill and still leaves the builder guessing. This template adds what those forms skip: the question each section must answer, a quality check for every requirement, and the detail an AI coding tool needs before it writes a line.

You get a blank copy, a filled-in example and the mistakes that send work back. If your last product manager left and took the context with them, a fractional product manager can write and own these documents with your team until a permanent hire is in place.

What is a product requirements document?

A product requirements document, or PRD, states the problem, the users, the goals and how success is measured, what is in and out of scope, and each requirement with a test for it. Its job is to let a team build without guessing what was meant.

Atlassian's guide to product requirements describes the PRD as the document that defines a product's purpose, features and behaviour, and gives cross-functional teams a single source of truth. That last part matters most. A PRD is the one page a designer, a developer and a founder can all point at when they disagree.

A PRD is not a roadmap, a design file or a technical design. The roadmap says what comes when, and our guide on how to build a product roadmap covers that. The PRD says what one release or feature must do and how you will know it works. How the team builds it belongs to engineering.

The product requirements document template

The template has nine sections, written in this order. Each row of this product requirements document template gives a section, the question it must answer and the way it usually fails.

Here is the blank version. Copy it into your own document tool and keep the section order.

PRODUCT REQUIREMENTS DOCUMENT
Title:            [feature or release name]
Owner:            [one person]      Decider: [one person]
Status:           draft / in review / approved     Last changed: [date]

1. PROBLEM AND EVIDENCE
   Problem:       [what goes wrong, for whom]
   Evidence:      [interviews, support tickets, usage data, with counts]

2. USERS AND SCENARIOS
   User:          [role, situation]
   Scenario:      [what they are trying to do, start to finish]

3. GOALS AND SUCCESS METRICS
   Goal:          [the change we want]
   Metric:        [number today] -> [target] by [date]

4. SCOPE AND NON-GOALS
   In scope:      [list]
   Non-goals:     [what we are not doing, and why]

5. REQUIREMENTS
   R1 [must]      The product shall [one behaviour].   Why: [rationale]
   R2 [should]    ...

6. ACCEPTANCE CRITERIA
   R1  Given [starting state], when [action], then [observable result]

7. CONSTRAINTS AND ASSUMPTIONS
   Constraint:    [platform, budget, legal, deadline]
   Assumption:    [what we take as true] (checked: yes / no)

8. OPEN QUESTIONS
   Q1 [question]  Owner: [name]   Needed by: [date]

CHANGE LOG:       [date] [who] [what changed]

The header counts as the ninth section, and the change log belongs with it. Keep both at the top or the bottom, as long as every reader can find the owner and the status in five seconds.

How to write a product requirements document

Write the problem first and the requirements last, with the builders in the room. Six steps take a team from a blank page to a document that engineering can estimate.

1. Start from evidence. Fill the problem section from interviews, support tickets or usage data, with counts. If you have no evidence yet, the next step is discovery, not a PRD.
2. Name one user and one scenario. A user persona template built from interviews gives you the role and the situation. Write the scenario as a short story with a start and an end.
3. Set the goal and its metric. State the number today, the target and the date. If the feature should move your north star metric, say which input it moves.
4. Draw the scope line. List what is in. Then list the non-goals, each with a reason. Non-goals stop the same debate from restarting each week.
5. Write requirements, then criteria. One numbered statement per behaviour, each with its rationale. Then write at least one acceptance criterion for each requirement.
6. Review with the people who build and test. A developer and a tester read every requirement and ask how they would prove it. Record what they asked under open questions.

On small teams the person who writes the PRD is often the founder. Our guide to product owner vs product manager explains who usually owns the document once a team has both roles.

Four checks for every requirement

Test each requirement against four checks before anyone estimates it: necessary, unambiguous, verifiable and traceable. A requirement that fails one check goes back to the author, because a builder will otherwise fill the gap with a guess.

The checks are not ours. ISO/IEC/IEEE 29148, the international standard for requirements engineering, defines the construct of a good requirement and the characteristics requirements should have. The IEEE Standards Association lists its 2018 edition as an active standard, as of November 2026. NASA publishes a public working version in Appendix C of its Systems Engineering Handbook, How to Write a Good Requirement.

NASA's checklist adds three habits worth copying. It reserves "shall" for requirements, "will" for statements of fact and "should" for goals, so a reader knows which sentences are binding. It asks for one thought per requirement statement. And it says a requirement states what is needed, not how to provide it.

The same checklist has a rule for unknowns. Keep "to be determined" to a minimum. Write your current estimate, mark it "to be resolved", and record who resolves it and by when. That is the open questions section of the template doing its job.

Acceptance criteria that can be tested

An acceptance criterion is testable when it names a starting state, one action and a result someone can observe. The Given, When, Then format forces all three, which makes it a common choice.

The format comes from Gherkin, the language behind the Cucumber test tool. Its reference describes Given as the initial context, When as an event or action, and Then as an expected outcome. It also says the outcome should be something that comes out of the system, such as a message or a screen, not a value buried in a database.

Requirement R2: The product shall expire an invite link 7 days after it is sent.

Scenario: An invite link is used after it expires
  Given an invite was sent 8 days ago
  When the invited person opens the link
  Then they see "This invite has expired"
  And they can ask the sender for a new one

Compare that with "invite links should expire after a while". The second version cannot fail a test, so it cannot pass one. Write one scenario for the normal path and one for each way the requirement can go wrong.

Product requirements document example

Here is a sample product requirements document for an invented feature: email invites for Rota, an invented shift-scheduling app for small clinics. The product, the numbers and the evidence are made up to show the structure. Only the shape carries over to your own document.

Read the assumption row first. "Every staff member has a work email" is unchecked, and the whole feature depends on it. One call to three clinics settles it before any design work starts. That is the cheapest fix in the document.

Notice the non-goals too. Bulk import is the first thing a stakeholder will ask for in review. Because it is written down as out of scope with a reason, the answer takes ten seconds and the release keeps its size.

Writing a PRD for AI coding tools

An AI product requirements document needs everything above, plus the context a human colleague would already carry in their head. An AI coding tool reads the page literally, has no memory of your last meeting, and will build the wrong thing with full confidence.

The tool makers say so in their own documentation. Anthropic's Claude Code docs state that each session begins with a fresh context window, which is why the tool reads instruction files at the start of every session. The AGENTS.md format calls itself a README for agents: a predictable place for build steps, tests and conventions. Its site says more than 60,000 open-source projects use it, as of November 2026.

Spec-first tools go further and turn the PRD into the first step of the build. Amazon's Kiro generates three files for every spec: requirements with user stories and acceptance criteria, a technical design and a task list. GitHub's open source Spec Kit follows the same order: define what to build and why, then turn the specification into a plan, tasks and working code.

The data and security row deserves the most care. Our comparison of vibe coding platforms shows that access rules are among the things those tools leave for you to check before real users arrive. If an AI tool has already built from a thin brief, an AI code audit finds what the missing requirements cost.

Common PRD mistakes

Most PRD failures come from writing the document alone, too early, or once. Seven show up again and again.

• A solution in the problem section. "We need a dashboard" is a solution. The problem is what people cannot see or do today.
• No non-goals. Without a written "not this release", every review adds scope.
• Compound requirements. "Users can invite, remove and re-invite staff" is three requirements with three tests.
• Vague words. "Fast", "simple" and "user-friendly" cannot be tested. Replace each with a number or an observable result.
• The whole product specified before any build. Atlassian lists this among its anti-patterns, along with iron-clad sign-off before work starts.
• Written without the team. Requirements the builders never questioned are requirements they will misread.
• Never updated. A PRD that still describes last month's plan is worse than none, because people trust it.

Scope is the mistake that costs the most on a first version. Our MVP scope planner sorts a feature list into must-have and later before you write requirements for any of it. Teams that want the build done with them can hand the finished PRD to our MVP development services.

How we write and review PRDs

We write PRDs with founders who have the product in their head and nobody to write it down, and we review specs and plans before they reach engineering. As your fractional product manager and CPO, we run the interviews behind the problem section, write the requirements with your developers, and keep the document current as the release changes.

Every engagement is under an NDA, and the IP is always yours. Each project is different, so we quote it after a short call.

Frequently asked questions