DotMDA PRD template in Markdown:copy it and fill it in.
A product requirements document is easiest to keep in a .md file next to the code. This template is short, uses numbered requirements and checkable acceptance criteria, and is written so an AI agent can build from it.
macOS 14 or later. Reading is free; editing and reviews are one payment.
Quick answer
A good PRD states the problem, the goals and what is out of scope, then lists numbered requirements with acceptance criteria that can be checked. Save it as prd.md or docs/prd/feature-name.md, copy the template below, and fill in each section in plain sentences.
# PRD: <Feature name>
## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria·
The template
Copy this into a new file and replace everything in angle brackets. Delete a section only if you are sure it does not apply, and write "none" instead of leaving it empty, so a reader can tell it was considered.
# PRD: <Feature name>
Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>
## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.
## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>
## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>
## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.
## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.
## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.
## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>
## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>
## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.
## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>
## 11. Open questions
- [ ] <Question> (owner: <name>)
## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.Why it is written this way
A PRD for an AI agent has the same job as one for a person, with less room for guessing. A person asks you in the hallway what you meant. An agent fills the gap with its best guess and keeps going.
- Non-goals are the cheapest protection against scope creep. Agents add "helpful" extras unless told not to.
- Numbered requirements (R1, R2) let a plan, a test and a review comment all point to the same thing.
- Acceptance criteria as task-list checkboxes turn into a to-do list that can be ticked off. See Markdown task lists for the syntax.
- Edge cases are where generated code fails first: empty data, bad input, a lost connection.
- Rollback forces you to think about how to undo the change before you ship it.
How to fill it in
-
Write the problem without the solution
If you cannot describe the problem without naming a feature, the feature is a guess. Say who is affected and what happens today.
-
Make every goal measurable
"Faster checkout" is a wish. "Median checkout under 30 seconds" is a goal.
-
Write requirements as behavior
"The system must show an error when the file is larger than 10 MB" can be tested. "Good error handling" cannot.
-
Pair each requirement with a criterion
Use Given, when, then. If you cannot write the check, the requirement is vague.
-
End with open questions
Name the owner of each. An agent should ask about them, not decide them.
Diagrams help for flows and states; a Mermaid block in the file is easy to change. See Mermaid flowchart syntax.
Handing the PRD to an AI agent
Point the agent at the file rather than pasting it: "Read docs/prd/export.md and propose a plan; do not write code yet." Ask for a plan first, check it against the numbered requirements, then let it build. A PRD, a plan and a task list are usually three separate files. The PRD says what and why, the plan says how, and the tasks are the steps.
Keep project-wide rules (commands, style, folders) out of the PRD and in CLAUDE.md or AGENTS.md, so the PRD holds only what is specific to this feature.
Common mistakes
- A solution disguised as a problem. "We need a dropdown" is not a problem.
- No non-goals. Everything nearby becomes in scope.
- Requirements that cannot fail. If no test could ever fail it, it says nothing.
- A PRD nobody reads again. Update the status and the open questions as you go.
- Ten pages for a small change. A feature a day long needs half a page.
Product managers can read and review PRDs in DotMD as rendered documents, with comments on the exact passage. Reading is free; see pricing for editing and reviews.
Questions about PRD templates in Markdown
What goes in a PRD template?
The problem, goals, non-goals, user scenarios, numbered requirements, acceptance criteria, edge cases, data and interfaces, success metrics, rollout and rollback, and open questions.
Why write a PRD in Markdown?
A Markdown file lives next to the code, has a readable history in Git, is easy for an AI agent to read, and can be reviewed and changed like any other file.
What should I name the file?
prd.md for a single product, or docs/prd/feature-name.md when there are several. Keep one feature per file.
How is a PRD different from a spec?
A PRD says what to build and why, from the user's view. A spec or plan says how it will be built. Keep them separate so each can be reviewed on its own.