Skip to content
Folio

PRD Template (Product Requirements Document) in Markdown

A product requirements document template in plain Markdown. It starts with the problem and the non-goals, not with the feature list, and it makes every requirement testable. Copy it, download the .md file, or open it in a wiki and write the PRD in the same place the team reads it.

Free to use, no attribution required (CC0).

Open in Folio demo

PRD: {{Feature or product name}}
Status {{Draft / In review / Approved / Shipped}}
Owner (PM) {{Name}}
Engineering lead {{Name}}
Design {{Name}}
Approver {{Name}}
Target release {{YYYY-MM-DD or quarter}}
Last updated {{YYYY-MM-DD}}

TL;DR

Three sentences a busy executive can read: the problem, what we will build, how we will know it worked.

{{...}}

1. Problem

Who has the problem? How do we know (data, interviews, tickets)? What happens if we do nothing?

  • Who: {{User segment}}
  • Evidence: {{Data point, quote, ticket count, link}}
  • Cost of inaction: {{...}}

2. Goals and non-goals

Goals

  • {{Goal 1}}
  • {{Goal 2}}

Non-goals (deliberately not in this release)

  • {{Not doing 1, and why}}
  • {{Not doing 2, and why}}

3. Users and use cases

User Situation What they want to do Outcome
{{Persona}} {{When ...}} {{I want to ...}} {{So that ...}}

4. Success metrics

A number, a baseline, a target, a date and the place you measure it.

Metric Baseline Target Measured in Review date
{{Primary metric}} {{X}} {{Y}} {{Tool or report}} {{YYYY-MM-DD}}
{{Guardrail metric — must not get worse}} {{X}} {{no worse than X}} {{...}} {{...}}

5. Requirements

Priority: Must / Should / Could / Won't. Acceptance criteria must be checkable by a tester.

ID Requirement Priority Acceptance criteria
R1 {{The user can ...}} Must Given {{...}}, when {{...}}, then {{...}}
R2 {{The system ...}} Should {{...}}
R3 {{...}} Could {{...}}
Non-functional requirements
  • Performance: {{e.g. page loads in under N seconds at P95}}
  • Security and privacy: {{...}}
  • Accessibility: {{...}}
  • Compatibility: {{browsers, devices, API versions}}

6. User flow

Optional. Replace the example with the main happy path and the main failure branch.

flowchart LR
    A[User opens the feature] --> B{Has access?}
    B -- Yes --> C[Completes the main task]
    B -- No --> D[Sees explanation and request-access link]
    C --> E[Sees confirmation]

7. Design and technical notes

  • Design: {{link to mockups}}
  • Technical design: {{link to design doc}}
  • Analytics events to add: {{event names}}

8. Dependencies and risks

Risk or dependency Likelihood Impact Mitigation Owner
{{...}} Low / Med / High Low / Med / High {{...}} {{Name}}

9. Rollout plan

  • Milestones: {{Design complete YYYY-MM-DD; Build complete YYYY-MM-DD; Launch YYYY-MM-DD}}
  • Rollout: {{Internal, then N% of users, then everyone}}
  • Rollback trigger: {{What result makes us roll back}}
  • Communication: {{Who tells customers, support and sales}}

10. Open questions

  • {{Question}} — {{Name}}, by {{YYYY-MM-DD}}

11. Decision log

Date Decision Reason Decided by
{{YYYY-MM-DD}} {{...}} {{...}} {{Name}}

Want to see it as a real wiki page? Open this template in the Folio demo, where it is a normal Markdown page.

How to use it

  1. Step 1: Write the problem and the non-goals first. Fill in "Problem", "Goals" and "Non-goals" before anything else. If you cannot state the problem in three sentences, the PRD is not ready for requirements.

  2. Step 2: Turn each requirement into something a tester can check. Give every requirement an ID, a priority and acceptance criteria. Cut or defer what you cannot make testable.

  3. Step 3: Share the draft, then log decisions. Send the link to engineering and design, collect questions in "Open questions", and record every resolved question in the decision log so the reasoning survives the thread.

What makes a good PRD

The problem comes before the solution. A PRD that opens with a feature list invites debate about the solution while nobody agrees on the problem. State who has the problem, how you know, and what happens if you do nothing.

Non-goals are as important as goals. Scope creep starts with silence. A short list of things this release deliberately does not do saves more review time than any other section.

Success is a number with a baseline and a date. "Improve onboarding" is a wish. "Raise day-7 activation from {{X}}% to {{Y}}% within {{N}} weeks of launch, measured in {{tool}}" is a target the team can lose.

Requirements are testable and prioritised. Use IDs so reviews can point at them, MoSCoW (Must, Should, Could, Won't) so cuts are quick, and acceptance criteria so "done" means the same thing to product, design and engineering.

More templates

Release notesHighlights, new, improved, fixed, breaking changes and upgrade steps for each release.Meeting notesDecisions and action items first, raw discussion below. One owner and a date per action.SOPPurpose, scope, roles, numbered steps with expected results, exceptions and a review date.
All templates

Questions

What is the difference between a PRD and a design doc?
A PRD says what to build and why, and how success is measured. A design doc says how engineering will build it. The PRD is owned by product, the design doc by engineering, and the design doc links back to the PRD's requirement IDs.
How long should a PRD be?
As long as the decision needs and no longer. A small change may fit on one page; a new product area may need several. A PRD nobody finishes reading has failed, whatever its length.
Who writes and who approves a PRD?
The product manager (or whoever owns the problem) writes it. Engineering, design and any affected stakeholder review it. Name one approver in the header so there is a person who says "go".
Is a PRD still useful for agile teams?
Yes, if it stays a living document. Keep it short, update it as scope changes, and break the requirements into tickets that reference the requirement IDs. What you drop is the idea of a frozen, signed-off specification.
Where should the PRD live?
Where engineers and designers already read and comment, with version history, in a repository or a wiki, not in an email attachment. A link that always shows the latest version prevents people from building from an outdated copy.

Updated 11 October 2026.

Write the PRD where the team can read it, diff it and link it

In Folio a PRD is a Markdown page in Git. Requirement tables, Mermaid flow diagrams and checklists render in the editor; edits by several people appear live; and the history shows who changed which requirement and when. Link the PRD from the design doc and from tickets with a normal relative link.

Open in Folio demoInstall FolioFolio on GitHub