Free template

Free PRD template, written to be checked

A product requirements document that a team can build from and an auditor can test against. Problem, users, scope, numbered requirements with acceptance criteria, and the things you are deliberately not doing. Copy it or download it as Markdown.

Get the template Do this with Atrix AI

Free · Markdown · no sign-up

prd-template.md

Product requirements: [Product name]

Overview

Two or three lines. If you cannot say what this is and who it is for this briefly, the rest of the document will not fix it.

Product: [Name]
Owner: [The person who decides scope questions]
Status: [Draft / In review / Agreed]
Last updated: [Date]
Summary: [What it is, who it is for, and what it replaces]

Problem

Describe the problem as the user lives it, not as a missing feature. Say what they do today instead, and how you know.

Today, [who] [does what workaround] when they need to [get something done]. It costs them [time, money or risk you have actually observed].

Evidence: [Interviews, support requests, sales calls, your own use. Say which, and how many.]

Target user

One primary user. Name the moment they go looking for a solution, and who this is not for.

Primary user: [Role, company size, context]
Trigger: [The event that makes them look for something new]
Current alternative: [Spreadsheet, another tool, a person, nothing]
Not for: [Who this deliberately does not serve, and why]

When to use it

Write a PRD before anyone opens an editor, and keep it short enough that people read it. It is the document the rest of the work refers back to.

Before the first line of code on a new product or a large feature
When you hand a build to a contractor, a studio or a coding agent
When two people disagree about what the first release includes
Before an audit, so there is something agreed to audit against

The template

The complete template

Everything below is included when you copy or download it. Replace the [bracketed] blanks and delete the guidance lines as you go.

prd-template.md

Product requirements: [Product name]

Replace everything in [brackets] and delete each guidance line once its section is written. The document is done when someone outside the team could build the first release from it, and someone else could check that they did.

01Overview

Two or three lines. If you cannot say what this is and who it is for this briefly, the rest of the document will not fix it.

Product: [Name]
Owner: [The person who decides scope questions]
Status: [Draft / In review / Agreed]
Last updated: [Date]
Summary: [What it is, who it is for, and what it replaces]

02Problem

Describe the problem as the user lives it, not as a missing feature. Say what they do today instead, and how you know.

Today, [who] [does what workaround] when they need to [get something done]. It costs them [time, money or risk you have actually observed].

Evidence: [Interviews, support requests, sales calls, your own use. Say which, and how many.]

03Target user

One primary user. Name the moment they go looking for a solution, and who this is not for.

Primary user: [Role, company size, context]
Trigger: [The event that makes them look for something new]
Current alternative: [Spreadsheet, another tool, a person, nothing]
Not for: [Who this deliberately does not serve, and why]

04Jobs to be done

What the user is trying to get done, in their words. Three to five, most important first.

Job 1: When [situation], I want to [action], so I can [outcome].
Job 2: When [situation], I want to [action], so I can [outcome].
Job 3: When [situation], I want to [action], so I can [outcome].

05MVP scope

What the first release does. Each line should be something a person could watch working.

[First capability the release cannot ship without]
[Second capability]
[Third capability]

06Requirements

One checkable statement per row. Acceptance says how someone would verify it on the running product; a requirement without it cannot be audited. Priority is MoSCoW: Must, Should, Could, Won't. Kind is functional (behaviour), non-functional (speed, uptime, accessibility) or constraint (a regulation, platform or budget).

Keys are permanent. Never renumber or reuse one: tasks, commits and audits refer to them.

Key	Requirement	Acceptance	Priority	Kind
REQ-001	Users can [do something observable]	[Steps that show it working on a live system]	Must	Functional
REQ-002	[Page or action] responds within [time] at [load]	[How and where it is measured]	Should	Non-functional
REQ-003	[Regulation, platform or budget limit]	[Evidence that it is respected]	Must	Constraint
REQ-004	[Something named but deferred]	[How it would be checked later]	Won't	Functional

07Success metrics

How you will know the release worked. Name the metric, where it is measured and the target. Leave a target blank rather than invent one.

Primary metric: [What] measured in [tool], target [value, or set after a baseline]
Secondary metric: [What] measured in [tool], target [value]
Guardrail: [A number that must not get worse, such as error rate or refunds]

08Non-goals

What this release deliberately does not do. This section settles more arguments than any other.

[Something people will assume is included, and why it is not]
[A second non-goal]

09Open questions

Everything still undecided, with a person and a date. A question with no owner stays open.

[Question] (owner: [name], needed by: [date])
[Question] (owner: [name], needed by: [date])

10Sign-off

Who agreed to this version. After this point, scope changes are proposed and recorded, not slipped in.

Agreed by: [Names]
Agreed on: [Date]
Changing scope: [How a change is proposed, and where it is recorded]

Atrix AI

Do this with Atrix AI

Develop mode writes this document for you from your project's brief, ideas and pages, then keeps it useful after the first draft.

Draft the requirements
The agent writes the PRD into your workspace: problem, target user, jobs to be done, MVP scope, success metrics and non-goals. One run, and it updates the same document rather than piling up copies.
Turn it into checkable rows
Atrix extracts each commitment as a keyed requirement with acceptance and a MoSCoW priority, quoting the sentence it came from. Everything lands as proposed until you accept it.
Plan it and hand it over
Accepted requirements break into issues on your board, and the handover bundle gives a coding agent the documents and the keys, so the work can be audited afterwards.

FAQ

Questions, answered

What should a PRD include?

The problem and who has it, the jobs the user is trying to get done, what the first release includes, numbered requirements with a way to check each one, success metrics, non-goals, open questions and who signed it off. This template has a section for each.

How long should a PRD be?

As short as it can be while still letting someone build the first release without asking you. For most first releases that is two to five pages. Length usually comes from describing solutions; keep it on problems and checkable requirements.

Why does every requirement need acceptance criteria?

Because without it nobody can say whether the requirement was met. Acceptance describes how a person would check it on the running product, which is what turns a document into something an audit can test.

Can I use this template with Notion, Google Docs or GitHub?

Yes. It is plain Markdown, so it pastes cleanly into any editor that understands Markdown, and it reads well as a file in a repository next to the code.

Is the template free?

Yes. Copy it or download it without signing up. Atrix AI is optional: it drafts and maintains the document for you if you want that.

Keep exploring

Run the whole company from one place.

Start on the free plan. Bring your team, your calendar and your code when you are ready.

Start free See pricing