Short answer: a good PRD template has a header, the problem, the users, goals with success metrics, non-goals, the solution, prioritized requirements with acceptance criteria, risks, dependencies, a launch plan and open questions. The free template below has all 14 sections, and it adds the one most templates skip: an AI behaviour and evals section for features built on a model. AllthingsPM gives you more than the template: its AI PM course has a full AI PRD chapter with a graded case, so you practise writing the document, not just copying it.
AllthingsPM is an AI PM course and PM interview prep platform. Copy the template, read the two filled-in examples, then delete the sections your feature does not need.
What is a PRD?
A product requirements document (PRD) is the written agreement on what a team will build and why. ProductPlan defines it as "an artifact used in the product development process to communicate what capabilities must be included in a product release to the development and testing teams" [1].
Marty Cagan of SVPG has argued for years that paper specs alone are weak, and that the full user experience needs to be shown, not just described: "the spec must describe the full user experience, not just the product requirements but also the user interaction and visual design" [2]. The practical answer in 2026 is a short PRD plus a prototype, which is how the template below is built.
How AllthingsPM does this: the AI PRD lesson teaches the PRD as a decision document, and the spec handoff lesson teaches the demo-first order: prototype, then write the spec engineering will own.
The free PRD template (copy it)
Copy everything in the block below into Google Docs, Notion, Confluence or a Markdown file. Each section has a one-line prompt telling you what goes there.
PRD: <feature name>
One line: <what it does, for whom, in plain words>
1. HEADER
Owner (PM): Design: Engineering: Data:
Status: Draft / Problem review / Solution review / Launch review / Launched
Last updated: Links: designs, prototype, research, tickets
2. PROBLEM
What is broken or missing, for whom, and how do we know?
Evidence: 2 to 3 data points, quotes or support tickets.
3. WHY NOW
What changed (data, strategy, competitor, technology) that makes
this worth doing this quarter instead of later?
4. TARGET USERS AND USE CASES
Primary user: Secondary user:
Top 3 use cases, written as "When <situation>, I want to <action>,
so I can <outcome>."
5. GOALS AND SUCCESS METRICS
Goal: Primary metric + target + date:
Counter-metric (what must not get worse):
How we will measure it (event, dashboard, experiment):
6. NON-GOALS
What this release will deliberately NOT do, and why.
7. SOLUTION OVERVIEW
The approach in 3 to 5 sentences, the main user flow as numbered
steps, and a link to the prototype or designs.
8. REQUIREMENTS
| # | Requirement | Priority (Must/Should/Could) | Acceptance criteria |
|---|-------------|------------------------------|---------------------|
9. NON-FUNCTIONAL REQUIREMENTS
Performance, reliability, accessibility, privacy, security,
localization, platforms supported.
10. AI BEHAVIOUR AND EVALS (delete if no model is involved)
What the model does, what it must never do, the eval set,
the pass bar that counts as "done", cost and latency limits.
11. RISKS, GUARDRAILS AND MITIGATIONS
| Risk | Likelihood | Impact | Mitigation | Owner |
12. DEPENDENCIES AND ASSUMPTIONS
Teams, systems, vendors and legal reviews this depends on.
Assumptions we have not yet proven.
13. LAUNCH PLAN AND RELEASE CRITERIA
Rollout stages (internal, % of users, GA), the criteria to move
between stages, the rollback trigger, and who communicates what.
14. OPEN QUESTIONS
| Question | Owner | Due | Answer |Most features fill it in 2 to 4 pages. Past 6, move design or engineering detail to its own document and link it.
What goes in each section of a PRD?
Here is what good looks like in each section, and the mistake that shows up most often.
Header. Names and status on top, so anyone opening the doc knows who decides and how far along it is. Kevin Yien's widely shared Square template made the five-stage status tracker (Draft, Problem Review, Solution Review, Launch Review, Launched) popular [3]. Reviewing the problem before the solution is the point: it stops teams from debating pixels for a problem nobody agreed on.
Problem and why now. Write the problem without your solution: "users cannot find saved jobs", not "we need a bookmarks tab". Add evidence, and add why this quarter. RocketBlocks lists "context and rationale" as the first of the five common PRD sections for exactly this reason [4].
Users and use cases. Name one primary user. Use cases in "When, I want to, so I can" form keep requirements tied to a real situation.
Goals and success metrics. One primary metric with a target and a date, plus a counter-metric: the number that must not get worse. Atlassian's Confluence template gives success metrics their own table [5]. Our post on counter-metrics explains why the second number matters.
Non-goals. Lenny Rachitsky singled out Kevin Yien's template for its "Non-Goals" section [6]. Atlassian calls the same idea "Out of scope" [5]. Every non-goal you write is a scope argument you will not have in week three.
Solution overview. Short, with the flow as numbered steps and a link to a prototype. If you cannot describe the solution in five sentences, it is not ready for a PRD.
Requirements with acceptance criteria. Prioritize with Must, Should, Could. Every Must gets an acceptance criterion a tester could check without asking you. Aha! lists requirements, scope and performance as core PRD components [7].
Non-functional requirements. Speed, reliability, accessibility, privacy. Figma's guide lists "Non-functional requirements" as a core component [8], and these are what break launches when they are missing.
AI behaviour and evals. The section older templates do not have. If a model generates output, say what it must do, what it must never do, and which eval set with which pass bar counts as done. Our AI PRD guide goes deeper on this.
Risks, dependencies, launch plan and open questions. Figma includes "Potential risks" and "Release criteria and timeline" [8]; ProductPlan includes "Assumptions, Constraints and Dependencies" [1]. Open questions with owners and dates keep the PRD a live document instead of a frozen one.
How AllthingsPM does this: each of these sections maps to course lessons. Metrics and counter-metrics are taught with the business case in Prove it paid off, launch plans in delivery planning, and guardrails in the trust chapter.
How do popular PRD templates compare?
Here is how our template compares with the templates people search for most, based on each publisher's own page.
| Template | Sections | Non-goals / out of scope | Success metrics | Risks | AI behaviour and evals |
|---|---|---|---|---|---|
| AllthingsPM (this post) | 14 | Yes | Yes, with counter-metric | Yes, with owners | Yes |
| Figma | 10 | Not a named section | Yes ("Evaluation plan and related success metrics") | Yes | No |
| Atlassian Confluence | 8 | Yes ("Out of scope") | Yes | Assumptions only | No |
| Aha! | 8 | Yes ("Scope") | Objective | Assumptions only | No |
| ProductPlan | 5 | No | Objective | Constraints and dependencies | No |
| RocketBlocks | 5 | No | Yes | No | No |
Sections checked September 28, 2026 on figma.com, atlassian.com, aha.io, productplan.com and rocketblocks.me [1] [4] [5] [7] [8].
Figma's template is the most complete of the others, and Lenny called it "super-comprehensive plug-and-play" [6]. Atlassian's is the best choice if your team already lives in Confluence and Jira, since its requirements table links to Jira issues [5]. None of them has a section for how a model should behave, which is now a core part of the job for many PMs.
How AllthingsPM does this: the template is free here, and the course shows how to fill it for a real feature in the integration case: prototype, spec and delivery plan for one feature you carry through the course.
Example 1: a PRD for a classic feature
The examples below are illustrative. The feature and numbers are made up to show the level of detail each section needs; they are not data from a real company.
PRD: Saved job searches
One line: Let job seekers save a search and get new matches by email.
1. HEADER Owner: PM (Priya) Status: Solution review Links: prototype, 8 user interviews
2. PROBLEM
Returning job seekers re-type the same filters every visit.
Evidence: in interviews, 6 of 8 users said they repeat the same search.
3. WHY NOW
Returning users are this quarter's growth goal.
4. USERS AND USE CASES
Primary: active job seeker, visits weekly.
"When I come back, I want my filters ready, so I can see only new roles."
5. GOALS AND METRICS
Primary: share of returning users who run a search within 7 days (target +10%).
Counter-metric: email unsubscribe rate must not rise.
6. NON-GOALS
No push notifications in v1. No sharing saved searches.
7. SOLUTION
1. User runs a search. 2. Taps "Save search". 3. Names it.
4. Gets a weekly email with new matches. 5. One tap to open results.
8. REQUIREMENTS
| 1 | Save current filters | Must | Saved search restores all filters exactly |
| 2 | Weekly email of new matches | Must | Only roles posted since last email |
| 3 | Edit or delete a search | Should | Change reflected in next email |
| 4 | Daily frequency option | Could | |
9. NON-FUNCTIONAL
Save in under 1 second. Emails honour unsubscribe in one click.
10. AI BEHAVIOUR AND EVALS Not applicable.
11. RISKS Email fatigue (medium, high) -> weekly cap, owner: PM.
12. DEPENDENCIES Email service; legal review of email consent.
13. LAUNCH 10% of users for 2 weeks; GA if counter-metric flat.
Rollback: unsubscribe rate up more than agreed threshold.
14. OPEN QUESTIONS Limit on saved searches per user? Owner: Eng, due Friday.The non-goals remove two scope fights; the counter-metric protects email.
Example 2: a PRD for an AI feature
Same template, now for a feature where a model writes the output. Again, this is an illustrative example with made-up targets.
PRD: AI reply drafts for support agents
One line: Draft a first reply to each support ticket for the agent to edit and send.
2. PROBLEM
Agents spend most of each ticket writing replies to repeat questions.
5. GOALS AND METRICS
Primary: median handle time per ticket (target down 20%).
Counter-metric: customer satisfaction score must not drop.
6. NON-GOALS
The AI never sends a reply without an agent. No refunds or account changes.
10. AI BEHAVIOUR AND EVALS
Must: answer only from the help center and the ticket.
Must never: promise refunds, invent policy, include other customers' data.
Eval set: 200 real past tickets with agent-approved replies.
Pass bar: agents rate 80% of drafts "send with light edits" or better;
0 policy violations in the set.
Limits: draft in under 3 seconds; cost per draft under the agreed cap.
11. RISKS, GUARDRAILS AND MITIGATIONS
| Invented policy | Medium | High | Retrieval from help center only; policy classifier | ML lead |
| Data leak | Low | High | Redact PII before the model call | Security |
13. LAUNCH
Shadow mode (drafts hidden) for 2 weeks, then 10% of agents.
Rollback trigger: any policy violation reaching a customer.The difference from Example 1 is sections 10 and 11. The eval set with a pass bar replaces "it works" as the definition of done, and the guardrails say what stops the model when it goes wrong.
How AllthingsPM does this: the course teaches exactly this move. Golden datasets shows how to turn one complaint into thirty eval examples, and the agent spec you own covers scope, tool contracts and escalation for agent features.
What are the most common PRD mistakes?
Writing the solution as the problem. If the problem statement names a button, rewrite it.
No non-goals. Scope creeps in through every gap you leave open.
Metrics without a target or a date. "Improve engagement" cannot fail, so it cannot guide a decision.
Requirements without acceptance criteria. Engineers then guess what done means, and QA guesses differently.
Skipping a quick test. If you are unsure the problem is real, test demand cheaply before writing anything. Our post on pretotyping covers the $60 test before you spec.
How AllthingsPM does this: these mistakes are what the course's graded cases check for, and the take-home and portfolio lesson shows how to present a PRD in an interview take-home.
How do PRDs come up in PM interviews?
PRD questions appear directly ("What are the key components of a PRD?") and inside take-home assignments, where you may be asked to write a short spec for a feature. Our answer guide for that exact question walks through a strong answer.
For AI PM roles the bar is higher: interviewers ask how you would spec a model feature, measure it and keep it safe. Practise that out loud in a mock interview, or paste a real posting into the JD mock to get questions shaped to that role. The question bank has 4,122 real questions from 260 companies, each with its own page.
Why AllthingsPM is the better choice for learning to write PRDs
A template gives you headings. It does not teach you which problem is worth the document, how to choose a counter-metric, or when an eval pass bar is strict enough. That judgment is what hiring managers look for, and it is what AllthingsPM teaches.
The AllthingsPM course is built from 604 real PM job postings, with 14 chapters, 101 lessons and 14 graded case studies, updated weekly. Chapter 5 is dedicated to the AI PRD, the spec and the road to launch, across five subchapters, and the trust, evals and agents chapters fill in the AI sections of the template above.
Then it connects to interviews. AllthingsPM builds mock interviews from any job description, in text or voice, with follow-ups and scoring, and has 4,122 real questions from 260 companies with answer guides. You also get resume review against a JD, 116 live PM roles at 18 AI companies, book summaries and 455 PM portfolios, for $20 a month or $120 a year, with a free tier.
The alternatives have real strengths. Figma's and Atlassian's templates are good free starting points, and Atlassian's links requirements straight into Jira. But they stop at the document. If you want to write better PRDs and prove it in an interview, AllthingsPM is the stronger choice. Start the AllthingsPM course free.
Frequently asked questions
What is the best PRD template?
The best PRD template for most teams in 2026 is the AllthingsPM template in this post: 14 sections, including non-goals, a counter-metric, risks with owners and an AI behaviour and evals section. Figma's and Atlassian's templates are good alternatives. Whatever you pick, delete the sections your feature does not need.
How long should a PRD be?
Most features fit in 2 to 4 pages. If a PRD runs much longer, it usually contains design or engineering detail that belongs in its own document, linked from the header.
What is the difference between a PRD and an MRD?
An MRD (market requirements document) describes the market opportunity and customer needs. A PRD describes what the product or feature must do to meet them. Many teams now fold the market context into the PRD's problem and why-now sections.
Who writes the PRD?
The product manager owns and writes it, with input from design, engineering and data. Sharing the problem section for review before writing the solution is what makes it a team document.
What should an AI PRD include that a normal PRD does not?
What the model must do and must never do, an eval set with a pass bar that defines done, cost and latency limits, and guardrails with owners. See our AI PRD template and the AI PRD lesson in the AllthingsPM course.
Are PRDs still used in agile teams?
Yes, usually as a shorter living document rather than a long upfront spec. Atlassian's template, for example, links each requirement to Jira issues so the PRD and the backlog stay connected [5].
Ready to write better PRDs? Open the AllthingsPM course free and start with Chapter 5.
Sources
- ProductPlan, "Product Requirements Document (PRD)": https://www.productplan.com/glossary/product-requirements-document/
- Marty Cagan, SVPG, "Revisiting the Product Spec": https://www.svpg.com/revisiting-the-product-spec/
- Kevin Yien's PRD template as described in "The ultimate collection of PRD templates," Edo van Royen, and Kevin Yien on X: https://www.edovanroyen.com/p/the-ultimate-collection-of-prd-templates and https://x.com/kevinyien/status/1263647261961093120
- RocketBlocks, "What is a product requirements document (PRD)?": https://www.rocketblocks.me/blog/what-is-a-prd.php
- Atlassian, Confluence product requirements template: https://www.atlassian.com/software/confluence/templates/product-requirements
- Lenny Rachitsky, "My favorite product management templates": https://www.lennysnewsletter.com/p/my-favorite-templates-issue-37
- Aha!, "What is a good product requirements document template?": https://www.aha.io/roadmapping/guide/requirements-management/what-is-a-good-product-requirements-document-template
- Figma, "Product requirements document": https://www.figma.com/resource-library/product-requirements-document/
- AllthingsPM course, Chapter 5: The AI PRD: https://allthingspm.app/course/the-ai-prd
