# Product requirements document (PRD) template

Six linked documents that take a feature from the problem to the launch: who it is for, what it must do, how it flows, how you will know it worked, and every decision on the way. Download them as Markdown files: they open in any editor, show their diagram on GitHub and in Obsidian, and import into Nodary as a map.

Free, no account, no email. Use it, change it, share it.

[Download the template (.zip)](https://nodary.ai/downloads/prd-template.zip)

## Read every page before you download

The overview fits on one screen and links to five parts, so engineering, design and support each find their page and a change stays small. Italic lines say what to write; the examples follow one sample feature, share links that expire.

- Product requirements document: The page everyone reads first: the problem, the goals, what is in and out, and a link to every part.
- Users and evidence: Who the feature is for, what they do today without it, and the research behind the problem.
- Requirements: What the feature must do, each requirement with its priority and the check that proves it.
- Design and flows: How the user moves through the feature: the flow, the screens, the states and the edge cases.
- Launch and metrics: How you will know it worked, how it rolls out, and what would make you roll it back.
- Decisions and open questions: Every decision that changed the PRD, with who decided and why, and the questions still open.

### Product requirements document

_How to use this template: italic lines are guidance. Replace them with your own words, then delete them. Values in square brackets are yours to fill in. Keep this page to one screen: it is what a busy reader, a new teammate or an AI agent reads first._

#### At a glance

| Field | This feature |
| --- | --- |
| Feature | [Name] |
| In one sentence | [What the user can do once it ships] |
| Product owner | [name] |
| Engineering lead | [name] |
| Design lead | [name] |
| Status | [draft, in review, approved, shipped] |
| Target release | [date or version] |

#### Problem

_Who has the problem, what it costs them today, and how you know. A problem without evidence is a guess: link the research in_ [Users and evidence](https://nodary.ai/templates/prd#doc-users).

_Example (a sample feature): People share a document with a client for a review, then forget the link exists. Months later it still opens. Three customers asked last quarter how to make a link stop working on a given date._

[The problem, in two or three sentences]

#### Goals and non-goals

_Goals say what changes for the user, not what the team builds. Non-goals are the decisions that stop scope from growing quietly._

- Goal: [what the user can do, or no longer has to do]
- Goal: [...]
- Non-goal: [what this release deliberately leaves out]
- Non-goal: [...]

#### Success in one line

_The one measure that tells you, a month after launch, whether this worked. The full list lives in_ [Launch and metrics](https://nodary.ai/templates/prd#doc-launch).

[Metric] moves from [baseline] to [target] by [date].

#### The rest of the PRD

_Each part is its own document. Link to it rather than copy from it, so every fact lives in one place and changes in one place._

- [Users and evidence](https://nodary.ai/templates/prd#doc-users): who the feature is for, and the research behind the problem
- [Requirements](https://nodary.ai/templates/prd#doc-requirements): what it must do, with priorities and acceptance criteria
- [Design and flows](https://nodary.ai/templates/prd#doc-design): the flow, the screens, the states and the edge cases
- [Launch and metrics](https://nodary.ai/templates/prd#doc-launch): metrics, rollout and the launch checklist
- [Decisions and open questions](https://nodary.ai/templates/prd#doc-decisions): what was decided, by whom and why, and what is still open

_This template is free to use, change and share. It comes from_ [Nodary](https://nodary.ai)_, where these files import as a map of linked documents._

### Users and evidence

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_Who the feature is for and what you know about them. Every statement here should point to where it comes from._

#### Who it is for

| Who | What they are trying to do | What gets in the way |
| --- | --- | --- |
| [Primary user] | [...] | [...] |
| [Secondary user] | [...] | [...] |

_Example (a sample feature): An account manager shares a draft proposal with a client for one week of comments. Today they set a reminder to switch the link off, and sometimes miss it._

#### Today, without the feature

_What users do now, step by step, workarounds included. The workaround is often the best spec you will get._

1. [Step]
2. [Step]
3. [Workaround]

#### Evidence

| Source | What it says | Date | Link |
| --- | --- | --- | --- |
| [Customer interview] | [...] | [date] | [...] |
| [Support tickets] | [...] | [...] | [...] |
| [Usage data] | [...] | [...] | [...] |

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Product requirements document](https://nodary.ai/templates/prd#doc-overview) · [Requirements](https://nodary.ai/templates/prd#doc-requirements) · [Design and flows](https://nodary.ai/templates/prd#doc-design)

### Requirements

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_One row per requirement, written as something the user can do. Priority is must, should or could: a release ships when every must passes._

#### User stories

| ID | As a | I want to | So that | Priority |
| --- | --- | --- | --- | --- |
| R1 | [user] | [...] | [...] | [must, should, could] |
| R2 | [...] | [...] | [...] | [...] |
| R3 | [...] | [...] | [...] | [...] |

_Example (a sample feature): R1. As someone sharing a document, I want to choose the day a link stops working, so that a client loses access when the project ends. Must._

#### Acceptance criteria

_For each must, the checks that prove it works. Write them so that a tester, or an AI agent, can run them without asking you._

| Requirement | Given | When | Then |
| --- | --- | --- | --- |
| R1 | [a starting situation] | [an action] | [the result someone can check] |
| R1 | [...] | [...] | [...] |

#### Non-functional requirements

| Area | Requirement |
| --- | --- |
| Performance | [...] |
| Security and privacy | [...] |
| Accessibility | [...] |
| Languages | [...] |
| Compatibility | [browsers, devices, versions] |

#### Out of scope

- [What this release does not do, and why]
- [...]

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Users and evidence](https://nodary.ai/templates/prd#doc-users) · [Design and flows](https://nodary.ai/templates/prd#doc-design) · [Launch and metrics](https://nodary.ai/templates/prd#doc-launch)

### Design and flows

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_Link to the design files rather than pasting them. Keep here the flow and the decisions behind it, so the text and the screens never disagree._

#### User flow

_The main path, from where the user starts to what they get. If the team cannot draw it, it is not settled yet._

```mermaid
flowchart LR
  n0["Entry point"]
  n1["First action"]
  n2["Key choice"]
  n3["Confirmation"]
  n4["Result"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_The main flow, from [where the user starts] to [what they get]_

#### Screens

| Screen | Purpose | Design link | Status |
| --- | --- | --- | --- |
| [Screen] | [...] | [...] | [sketch, mockup, final] |
| [Screen] | [...] | [...] | [...] |

#### States

_Every screen has more states than the happy path. Tick each one once it is designed, or write why it cannot happen._

- [ ] Empty: nothing to show yet
- [ ] Loading
- [ ] Error, with what the user can do next
- [ ] No permission
- [ ] Slow or lost connection
- [ ] Very long text and very large numbers

#### Edge cases

| Case | What happens |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_Example (a sample feature): Someone opens a link one minute after its end date: they see that the link has expired and whom to ask, never an error page._

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Requirements](https://nodary.ai/templates/prd#doc-requirements) · [Launch and metrics](https://nodary.ai/templates/prd#doc-launch)

### Launch and metrics

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_One primary metric, two or three secondary ones, and a guardrail: something that must not get worse while the primary one improves._

#### Metrics

| Metric | Kind | Baseline | Target | Measured by | Review date |
| --- | --- | --- | --- | --- | --- |
| [...] | [primary] | [...] | [...] | [...] | [date] |
| [...] | [secondary] | [...] | [...] | [...] | [...] |
| [...] | [guardrail] | [...] | [...] | [...] | [...] |

#### Rollout

| Stage | Who gets it | Date | Moves on when |
| --- | --- | --- | --- |
| [Internal] | [the team] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Everyone] | [...] | [...] | [...] |

#### Launch checklist

- [ ] Help article written
- [ ] Support team briefed
- [ ] Release note drafted
- [ ] Analytics events checked
- [ ] Rollback tested

#### Rollback

_What would make you turn the feature off, and how. Decide it before launch, while nobody is attached to the result._

- We roll back if: [...]
- How: [a flag, a release, a script]
- Who decides: [name]

Related: [Product requirements document](https://nodary.ai/templates/prd#doc-overview) · [Requirements](https://nodary.ai/templates/prd#doc-requirements) · [Decisions and open questions](https://nodary.ai/templates/prd#doc-decisions)

### Decisions and open questions

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_When a decision changes the PRD, add a line here and update the page it affects. The log says why; the page says what is true now._

#### Decision log

| Date | Decision | Decided by | Why | Page changed |
| --- | --- | --- | --- | --- |
| [date] | [...] | [...] | [...] | [...] |

_Example (a sample feature): Links keep working until the end of their last day in the owner’s time zone, not at midnight UTC. Decided by the product owner and the engineering lead, because clients in other time zones lost access a day early in the beta. Page changed: Requirements._

#### Open questions

| Question | Who answers it | By when | Answer |
| --- | --- | --- | --- |
| [...] | [name] | [date] | [...] |

Related: [Product requirements document](https://nodary.ai/templates/prd#doc-overview) · [Requirements](https://nodary.ai/templates/prd#doc-requirements) · [Launch and metrics](https://nodary.ai/templates/prd#doc-launch)

## How to use it

### Write the problem before the solution

Fill in the overview’s problem, goals and non-goals first, with the engineer and the designer who will build the feature. If the three of you disagree on the problem, stop there.

### Make every must testable

Give each must-have requirement acceptance criteria that someone else can check. A requirement nobody can test is a wish.

### Review it, then keep it true

Ask for a review when the requirements are ready, and update the PRD when a decision changes them. A PRD that stops at kickoff is wrong by launch.

### Log what changed and why

Each decision goes in the decision log with who made it. When someone asks why the feature works this way, the answer is one link away.

## Import it into Nodary as a map

Nodary is an AI-native workspace where a team’s documents link instead of piling up. Import the .zip and the PRD arrives with its five parts filed under it, the links between pages kept and the diagram drawn. Mark it in review and ask an owner or admin of the workspace or project to approve it, see what changed since your last visit, and let AI agents connected over MCP read the requirements before they write code against them.

1. Open a project’s map and choose Import.
2. Choose the Folder or ZIP tab, then Choose a ZIP.
3. Pick the downloaded file, check the tree, and import.

The Free plan holds ten documents per workspace, the project’s own page included: the template’s six fit in a new workspace with room for three more. Nodary also has a one-page Product Spec (PRD) template built in.

## Writing a PRD the team actually uses

A PRD fails in one of two ways: it describes a solution nobody questioned, or it stops being updated after kickoff. These habits prevent both.

### Start from the problem

Write who has the problem and what it costs them before any solution. Teams that agree on the problem argue less about the screens.

### Say what you will not do

Non-goals are decisions too. Writing them down is what stops a feature from growing a week at a time.

### Make requirements testable

“Fast” and “easy” cannot be checked. “The link stops opening within a minute of its end date” can be built and tested.

### Prioritize with must, should and could

A release ships when every must passes. Shoulds and coulds are what you trade when the date gets close.

### Link the evidence

Each claim about users links to the interview, the ticket or the data behind it, so a reviewer can check it instead of trusting it.

### Keep it alive

Update the PRD when a decision changes it, and log why. In the end it should describe what shipped, not what was planned in week one.

## Questions about PRDs

### What is a PRD?

A product requirements document, or PRD, describes a feature or a product before it is built: the problem it solves, who it is for, what it must do, how success is measured and what is out of scope. A product manager usually owns it; engineers, designers, support and, more and more, AI coding agents read it.

### What should a PRD include?

At least the problem and the evidence for it, goals and non-goals, the users, requirements with priorities and acceptance criteria, the main flows and edge cases, success metrics, the rollout plan, and a log of decisions and open questions. This template has one document for each group.

### How long should a PRD be?

Long enough that the team can build and test the feature without asking you the same question twice. The overview should fit on one screen; the requirements grow with the decisions, not with the ideas.

### What is the difference between a PRD and a technical design document?

The PRD says what the feature must do and why. The technical design document says how the system will do it: architecture, data, interfaces and risks. Write the PRD first, then link the two.

### Can AI agents use the PRD?

Yes. A PRD in linked documents gives an agent the context it needs. In Nodary, agents connected over MCP, such as Claude, ChatGPT or Cursor, read the requirements and the decision log with your permissions before they write.

### Can I use the template outside Nodary?

Yes. The files are plain Markdown: Obsidian opens the unzipped folder as a vault with every link working, and GitHub shows the files with their diagram. Tools that import Markdown one file at a time keep the text and the tables; check how they handle links between files.

The page: https://nodary.ai/templates/prd