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.
6 Markdown files in a .zip, 6 kB
Free, no account, no email. Use it, change it, share it.
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.
Documents
File PRD template/Product requirements document.md
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.
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.
[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: who the feature is for, and the research behind the problem
- Requirements: what it must do, with priorities and acceptance criteria
- Design and flows: the flow, the screens, the states and the edge cases
- Launch and metrics: metrics, rollout and the launch checklist
- Decisions and open questions: 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, where these files import as a map of linked documents.
File PRD template/Product requirements document/01 Users and evidence.md
Users and evidence
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.
- [Step]
- [Step]
- [Workaround]
Evidence
| Source | What it says | Date | Link |
|---|---|---|---|
| [Customer interview] | [...] | [date] | [...] |
| [Support tickets] | [...] | [...] | [...] |
| [Usage data] | [...] | [...] | [...] |
Open questions
- [Question], [who answers it], [by when]
File PRD template/Product requirements document/02 Requirements.md
Requirements
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]
File PRD template/Product requirements document/03 Design and flows.md
Design and flows
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.
- Entry pointFirst action
- First actionKey choice
- Key choiceConfirmation
- ConfirmationResult
Mermaid
flowchart LR n0["Entry point"] n1["First action"] n2["Key choice"] n3["Confirmation"] n4["Result"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4
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]
File PRD template/Product requirements document/04 Launch and metrics.md
Launch and metrics
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]
File PRD template/Product requirements document/05 Decisions and open questions.md
Decisions and open questions
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] | [...] |
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.
- Open a project’s map and choose Import.
- Choose the Folder or ZIP tab, then Choose a ZIP.
- 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.
Nodary for product and engineering teams
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.
Keep the requirements where the team works.
Import the template into Nodary and the PRD becomes a map that your team and your AI agents keep current. Free with two members, one project and ten documents, no card needed.