Product Requirements Document (PRD) Markdown Template
Define a product problem, users, goals, scope, requirements, acceptance criteria, metrics, dependencies, risks, rollout, and open questions.
# Product Requirements Document (PRD): [Product or Feature]
**Owner:** [Name]
**Status:** [Draft / In review / Approved under team process / Shipped]
**Last updated:** YYYY-MM-DD
**Reviewers:** [Names or roles, if your team uses formal review]
## Summary
[Briefly state the user problem, proposed direction, and intended outcome.]
## Problem and evidence
- **Problem:** [Observed need]
- **Evidence:** [Research, data, support themes, or explicit assumption]
- **Why now:** [Timing or constraint]
## Users and jobs to be done
| User or segment | Situation | Job to be done | Evidence or confidence |
| :--- | :--- | :--- | :--- |
| [User] | When [context] | I want to [job], so I can [outcome] | [Source or confidence] |
## Goals
- [Outcome this work should enable]
## Non-goals
- [Related outcome deliberately excluded]
## Scope
### In scope
- [Capability or workflow]
### Out of scope
- [Excluded capability or workflow]
## Requirements and acceptance criteria
| ID | Priority | Requirement | Acceptance criteria |
| :--- | :---: | :--- | :--- |
| R1 | Must | [Testable behavior] | Given [context], when [action], then [observable result] |
## User experience
- **Primary flow:** [Link or outline]
- **Accessibility and content needs:** [Relevant requirements]
- **Design references:** [Link]
## Success metrics
| Metric | Baseline | Target or decision threshold | Measurement window | Source |
| :--- | :--- | :--- | :--- | :--- |
| [Metric] | [Verified baseline] | [Target] | [Period] | [Dashboard or method] |
## Dependencies
- [Team, system, policy, vendor, or prerequisite]
## Risks and mitigations
| Risk | Likelihood or impact | Mitigation | Owner |
| :--- | :--- | :--- | :--- |
| [Risk] | [Context] | [Plan] | [Name] |
## Rollout and monitoring
- **Release approach:** [Phases, eligibility, or feature flag]
- **Monitoring:** [Signals and owner]
- **Rollback or stop condition:** [Verified plan]
## Open questions
- [ ] [Question] - Owner: [Name] - Due: YYYY-MM-DD
## Decision record
[Record the review or sign-off process your team actually uses.]
Product Requirements Document (PRD): [Product or Feature]
Owner: [Name]
Status: [Draft / In review / Approved under team process / Shipped]
Last updated: YYYY-MM-DD
Reviewers: [Names or roles, if your team uses formal review]
Summary
[Briefly state the user problem, proposed direction, and intended outcome.]
Problem and evidence
- Problem: [Observed need]
- Evidence: [Research, data, support themes, or explicit assumption]
- Why now: [Timing or constraint]
Users and jobs to be done
| User or segment | Situation | Job to be done | Evidence or confidence |
|---|---|---|---|
| [User] | When [context] | I want to [job], so I can [outcome] | [Source or confidence] |
Goals
- [Outcome this work should enable]
Non-goals
- [Related outcome deliberately excluded]
Scope
In scope
- [Capability or workflow]
Out of scope
- [Excluded capability or workflow]
Requirements and acceptance criteria
| ID | Priority | Requirement | Acceptance criteria |
|---|---|---|---|
| R1 | Must | [Testable behavior] | Given [context], when [action], then [observable result] |
User experience
- Primary flow: [Link or outline]
- Accessibility and content needs: [Relevant requirements]
- Design references: [Link]
Success metrics
| Metric | Baseline | Target or decision threshold | Measurement window | Source |
|---|---|---|---|---|
| [Metric] | [Verified baseline] | [Target] | [Period] | [Dashboard or method] |
Dependencies
- [Team, system, policy, vendor, or prerequisite]
Risks and mitigations
| Risk | Likelihood or impact | Mitigation | Owner |
|---|---|---|---|
| [Risk] | [Context] | [Plan] | [Name] |
Rollout and monitoring
- Release approach: [Phases, eligibility, or feature flag]
- Monitoring: [Signals and owner]
- Rollback or stop condition: [Verified plan]
Open questions
- [Question] - Owner: [Name] - Due: YYYY-MM-DD
Decision record
[Record the review or sign-off process your team actually uses.]
When to use this template
Use this before or during product delivery when product, design, engineering, and other partners need a shared statement of the problem, boundaries, and testable requirements.
Section guide
- Problem, users, and goals
- Explain the need and distinguish desired outcomes from proposed features.
- Scope and requirements
- Define boundaries and make behavior testable with acceptance criteria.
- Delivery and learning
- Capture dependencies, risks, rollout, metrics, and unresolved decisions.
How to use this template
- 1
Copy the Markdown
Click the Copy button above to put the full template on your clipboard.
- 2
Paste into your editor
Paste into the mdkit editor, a repository, a notes app, or another Markdown editor. Check tables and task lists in your target renderer because Markdown support varies.
- 3
Fill in your content
Replace bracketed examples with verified information, adapt fields to your context, and remove sections that do not apply.
- 4
Check before you use it
- A PRD records current alignment; discovery, design, technical planning, and validation still require collaboration.
- Approval or sign-off practices vary by team and should be documented only when they apply.
Template details
What it solves
A PRD gives collaborators a testable account of what problem is being addressed, what is in and out, and how outcomes will be assessed.
Key features
- Goals, non-goals, users, and jobs to be done
- Scope plus prioritized requirements
- Acceptance criteria and success metrics
- Dependencies, risks, rollout, and open questions
Pro tips
- >Link requirements back to research or a stated assumption.
- >Keep implementation choices out unless they are genuine constraints.
- >Record the team's own review or sign-off convention rather than assuming one.
Useful Markdown tools
Start in the Markdown editor, then use a relevant tool when you need to format or export the finished document.
Related templates
Research-Based User Persona
Synthesize user research into behaviors, context, jobs to be done, needs, barriers, evidence, and confidence without demographic stereotypes.
SWOT Analysis
Assess strengths, weaknesses, opportunities, and threats with evidence and priority, then turn findings into testable strategic actions.
Weekly Status Report
Report weekly outcomes, overall RAG status, milestones, metrics, blockers, decisions, and next-week commitments in one concise update.