Product

PRD Template (Product Requirements Document)

A PRD (product requirements document) says what problem a release solves, for whom, how you will know it worked, and what it deliberately will not do. This template keeps it short enough to be read, and adds what most PRD templates leave out: a status, a decision log, and open questions with owners and dates.

Updated 2026-10-27

Copy and adapt

The template

Product requirements documentTemplate

PRD: [Feature or product name]

Owner: [product manager] Team: [design lead], [engineering lead], [others who must agree] Status: [Draft / In review / Approved / Building / Shipped] Target release: [month or quarter, not a day] Links: [[Roadmap item]], [design file], [epic in the tracker] Last updated: {{date}}

Summary

[Two or three sentences. A reader who stops here should know what is being built and why.]

Problem

Who has it: [segment, with a number]
Evidence: [tickets, interview quotes, usage data, lost deals]
Why now: [what changed]

Goals and success metrics

Goal	Metric	Today	Target	Check on
[goal]	[metric]	[baseline]	[target]	YYYY-MM-DD

Non-goals

[What this release will not do, and why]

Users and use cases

[Role] needs to [job] when [situation].

Requirements

#	Requirement	Priority	Acceptance criteria
R1	[what the product must do]	Must	[testable condition]
R2	[requirement]	Should	[testable condition]
R3	[requirement]	Could	[testable condition]

Non-functional: [performance, security, privacy, accessibility, cost]

Design

[Flow, prototype, key screens]

Assumptions, risks and dependencies

Assumption: [what we believe] (we will know we were wrong if [signal])
Risk: [risk]. Mitigation: [plan]
Depends on: [team or system], needed by YYYY-MM-DD

Open questions

[Question] (owner: [name]) @due(YYYY-MM-DD)

Decision log

YYYY-MM-DD: [decision] because [reason]. Decided by [name].

Release plan

[Beta group, rollout steps, launch criteria, who announces]

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.B2B feature: enforced SSO for enterprise workspaces

When it fits: Use this when sales has a list of blocked deals, enterprise buyers are asking for one specific capability, and engineering suspects the scope will grow the moment the PRD is shared.

B2B feature: enforced SSO for enterprise workspacesExample 1

PRD: Enforced SAML SSO for workspace admins

Owner: Renata Silva Team: Joon Park (design), Theo Marsh (eng lead), Alicia Grant (sales engineering) Status: Approved 2026-10-20 Target release: January 2027 Links: [[Enterprise readiness]], SSO epic PLAT-412

Summary

Workspace admins on the Business plan can require SAML sign-in for every member and block password logins. Without this, security reviews at companies above 500 employees fail on the first questionnaire.

Problem

Who has it: Business-plan prospects with a security review, 14 deals in Q2 and Q3
Evidence: those 14 deals total $410,000 in annual contract value; 9 named "SSO enforcement" as a blocker in writing
Why now: two of the 14 renew their evaluation in February

Goals and success metrics

Goal	Metric	Today	Target	Check on
Unblock security reviews	Deals lost to "no SSO enforcement"	9 in two quarters	0 in Q1	2027-04-01
Adoption	Business workspaces with SSO enforced	0	25	2027-03-31

Non-goals

SCIM user provisioning. Asked for by 3 of 14 prospects; separate PRD in Q2.
OIDC. No prospect has asked for it.

Requirements

#	Requirement	Priority	Acceptance criteria
R1	Admin uploads IdP metadata and tests it before enforcing	Must	A failed test shows the IdP's error text and does not enforce
R2	Enforcement blocks password and email-link sign-in for members	Must	A member with a password gets "Sign in with your company account"
R3	Break-glass: workspace owner keeps password access	Must	Owner can sign in if the IdP is down
R4	Audit log entry when enforcement changes	Should	Entry shows who, when, old and new value

Non-functional: SAML assertions validated server-side only; sign-in adds under 500 ms at p95.

Assumptions, risks and dependencies

Assumption: Okta and Entra ID cover most prospects (12 of 14). We will know we were wrong if a pilot customer uses another IdP.
Risk: admins lock themselves out. Mitigation: R3 and a mandatory test step.

Open questions

Do guests have to use SSO too? Answered 2026-10-17: no, guests are exempt and labeled in the member list (Alicia, from 6 prospect calls).
Is the audit log in scope for January or February? (owner: Theo) @due(2026-11-06)

Decision log

2026-10-20: SCIM moved out of scope because it doubles the estimate and only 3 deals need it. Decided by Renata with sales sign-off.

2.Consumer mobile feature: offline maps

When it fits: Use this when the evidence comes from app reviews and support, the main tension is a device constraint (storage, battery), and the PRD needs to say plainly what users will not get.

Consumer mobile feature: offline mapsExample 2

PRD: Download routes for offline riding

Owner: Callum Reid Team: Saoirse Byrne (design), Femi Adebayo (iOS), Lukas Weber (Android) Status: In review, comments close 2026-11-05 Target release: March 2027, before the spring riding season Links: [[Rider retention 2027]], prototype in the Routes design file

Summary

Riders can save a planned route, with its map tiles and turn cues, before they leave signal. Today the map goes blank mid-ride and the route line disappears.

Problem

Who has it: riders on routes through rural areas, about 31 percent of rides last summer had at least one signal gap over 2 minutes
Evidence: 22 percent of one-star reviews since June mention losing the map; 140 support tickets in August alone
Why now: our largest competitor shipped offline routes in September and reviews compare us directly

Goals and success metrics

Goal	Metric	Today	Target	Check on
Fewer abandoned rides	Rides ended within 5 min of a signal gap	8.4 percent	4 percent	2027-05-15
Fewer complaints	One-star reviews mentioning maps	22 percent	under 8 percent	2027-05-15

Non-goals

Offline route planning or rerouting. Riders follow the saved route only.
Whole-region downloads. Storage cost is too high for a first version.

Requirements

#	Requirement	Priority	Acceptance criteria
R1	Save a route with tiles for a 2 km corridor	Must	Route renders and cues play in airplane mode
R2	Show download size before saving	Must	Size shown within 10 percent of actual
R3	Auto-delete saved routes after 30 days unused	Should	Deleted routes free their storage
R4	Save routes over Wi-Fi only by default	Could	Toggle in settings

Non-functional: a 100 km route under 60 MB; no extra battery drain versus an online ride (within 5 percent on the test devices).

Open questions

Corridor width: 2 km or 5 km? Answered 2026-10-22: 2 km. 5 km tripled the size for 4 percent more coverage of detours.
Do free users get offline routes, or only subscribers? (owner: Callum) @due(2026-11-12)

Decision log

2026-10-22: no offline rerouting in v1 because it needs on-device routing, a separate 3-month project. Decided by Callum and Femi.

3.Internal tool: refund approval queue

When it fits: Use this when the users are colleagues, the problem shows up as time lost and Slack threads rather than revenue, and the hardest requirement is an approval rule finance will sign.

Internal tool: refund approval queueExample 3

PRD: Refund approval queue for support

Owner: Nadia Haddad Team: Pete Lindgren (eng), Grace Liu (finance), Owen Tran (support lead) Status: Building, sprint 2 of 3 Target release: December 2026 Links: [[Support tooling]], finance refund policy v3

Summary

Refunds above $200 go to a queue in the admin tool where a finance approver approves or rejects them in one click. Today agents post them in a Slack channel and wait.

Problem

Who has it: 46 support agents and 3 finance approvers
Evidence: 31 percent of refunds over $200 wait more than 24 hours; 12 were approved twice in September because two approvers answered the same thread
Why now: refund volume is up 40 percent since the price change on Sep 1

Goals and success metrics

Goal	Metric	Today	Target	Check on
Faster refunds	Median wait for approval	19 hours	under 4 hours	2027-01-31
No double refunds	Duplicate approvals per month	12	0	2027-01-31

Non-goals

Automatic approval rules. Finance wants three months of queue data first.
Changing the refund policy itself.

Requirements

#	Requirement	Priority	Acceptance criteria
R1	Agent submits refund with order, amount and reason	Must	Submission appears in the queue within 5 seconds
R2	Only one approver can act on a request	Must	Second approver sees "Already approved by Grace, 14:02"
R3	Agent is notified of the decision in the ticket	Must	Internal note added to the ticket on approve or reject
R4	Weekly export for finance	Should	CSV with request, approver, timestamps

Open questions

Threshold $200 or $150? Answered 2026-10-15: $200, matches the policy Grace's team audits against.
What happens to requests left over a weekend? (owner: Grace) @due(2026-11-04)

Decision log

2026-10-15: built in the existing admin tool, not a new app, because agents already work there all day. Decided by Nadia and Pete.

4.AI feature with evaluation and cost requirements

When it fits: Use this when the feature depends on a language model, quality cannot be judged from a demo, and the PRD has to set an accuracy bar, a cost ceiling and what happens when the model is wrong.

AI feature with evaluation and cost requirementsExample 4

PRD: AI handoff summaries for escalated tickets

Owner: Marta Kowalczyk Team: Sunil Rao (ML eng), Elena Petrova (design), Jamal Wright (Tier 2 support) Status: Draft Target release: Q1 2027, behind a flag for Tier 2 only Links: [[Support AI]], eval set "handoff-200"

Summary

When a ticket is escalated, Tier 2 sees a five-line summary of what the customer asked, what was tried and what is still unknown. Today they read the whole thread, a median of 23 messages.

Problem

Who has it: 18 Tier 2 agents handling about 400 escalations a week
Evidence: median 9 minutes from pickup to first reply, most of it reading; 2 in 10 Tier 2 replies repeat a step Tier 1 already tried
Why now: escalations doubled after the October release

Goals and success metrics

Goal	Metric	Today	Target	Check on
Faster pickup	Median time to first Tier 2 reply	9 min	5 min	2027-03-31
Accuracy	Summaries with a factual error, on the eval set	not measured	under 3 percent	before beta

Non-goals

Suggested replies. Separate decision after the summary is trusted.
Summaries visible to customers.

Requirements

#	Requirement	Priority	Acceptance criteria
R1	Summary has four labeled parts: asked, tried, unknown, customer mood	Must	All four present on 200 of 200 eval tickets
R2	Every claim links to the message it came from	Must	Clicking a claim scrolls to the source message
R3	Payment details and passwords are redacted before the model sees the thread	Must	Zero card numbers in model inputs in a 1,000-ticket log sample
R4	Agent can mark a summary wrong with one click	Must	Feedback stored with ticket ID and reason

Non-functional: under $0.004 per summary at current volume; generated in under 6 seconds at p95.

Open questions

Do we store summaries, or regenerate on each view? Storing is cheaper but goes stale when the thread grows. (owner: Sunil) @due(2026-11-14)
Who reviews the eval set labels besides Jamal? (owner: Marta) @due(2026-11-07)

Decision log

2026-10-24: Tier 2 only for the first release because Tier 2 can judge summary errors; Tier 1 cannot yet. Decided by Marta and Jamal.

5.Deprecation: retiring a legacy export

When it fits: Use this when the release takes something away, the users who depend on it are a small loud group, and the PRD is mostly a migration and communication plan.

Deprecation: retiring a legacy exportExample 5

PRD: Retire CSV export v1, move accounts to scheduled exports

Owner: Benjamin Cole Team: Ayesha Karim (eng), Rosa Delgado (customer success), Ian Fletcher (docs) Status: Approved 2026-10-09 Target release: v1 off on 2027-02-01 Links: [[Export platform]], migration dashboard

Summary

The v1 CSV export endpoint is switched off on Feb 1, 2027. Accounts that use it move to scheduled exports, which already cover the same data with column names that match the app.

Problem

Who has it: 340 accounts called v1 at least once a week in September; 41 of them are on annual contracts over $20,000
Evidence: v1 caused 6 of the 11 data-platform incidents this year; it reads from the primary database
Why now: the database migration in Q1 cannot keep v1 working without a rewrite

Goals and success metrics

Goal	Metric	Today	Target	Check on
Clean shutoff	Accounts still calling v1	340	under 10	2027-01-25
Keep customers	Churn citing exports	0	0	2027-04-30

Non-goals

Rebuilding v1's column format in the new export. Customers map columns once, with the guide.

Requirements

#	Requirement	Priority	Acceptance criteria
R1	In-app banner for accounts that called v1 in the last 30 days	Must	Shown to admins only, links to the guide
R2	v1 responses carry a deprecation header from 2026-11-15	Must	Header present with the shutoff date
R3	Column mapping guide, old name to new name	Must	Every v1 column listed
R4	Brownouts: v1 off for one hour on 2027-01-12 and 2027-01-19	Should	Announced 7 days ahead

Open questions

Extension for the 41 large accounts? Answered 2026-10-09: no blanket extension; customer success can grant 30 days case by case, logged here.

Decision log

2026-10-09: shutoff date fixed at Feb 1 because the database migration starts Feb 8. Decided by Benjamin, Ayesha and the VP of engineering.

What a PRD is for

A PRD template is not a form to fill in. It is a checklist of the arguments a team will have anyway, so they happen on paper before the code. Each section exists to settle one:

Problem and evidence settle whether this is worth doing. If the evidence is one loud customer, the PRD makes that visible.
Goals with baselines settle what "worked" means, before launch, when nobody has a reason to move the bar.
Non-goals settle scope. The second example shows a team ruling out rerouting in one line, and saving three months.
Requirements with priorities settle what to cut when the date slips.
Open questions and the decision log settle who decides, and stop decisions being reopened every time someone new joins.

The PRD describes what and why. How it is built belongs in the technical design or an RFC, written by engineering after the PRD is approved.

How to write one in an afternoon

Start with the problem and the evidence. If you cannot write three bullets with numbers, stop and gather them, or run interviews first with the user interview notes template.
Write goals and non-goals together. Each non-goal should be something a reasonable stakeholder would ask for.
Draft requirements as outcomes, not screens. "Admin can test the IdP connection before enforcing" survives a redesign; "a Test button on the settings page" does not.
Add one testable acceptance criterion per requirement. Engineering cannot estimate a requirement they cannot test.
List the questions you cannot answer yet, with an owner and a date. A PRD with no open questions is either trivial or hiding something.
Share it with a comment deadline. "Comments close Nov 5" turns a document into a decision.

Who owns it and when it is done

The top PRD guides call the document "living," then stop. In practice a PRD has four states, and the status line at the top should say which one it is in.

Draft. The owner edits freely.
In review. Comments are open until a stated date. Changes are tracked in the decision log.
Approved. Scope is frozen. Changes still happen, but each one gets a dated entry in the decision log with who agreed. This is the step most teams skip, and it is why nobody can later say when a requirement was dropped.
Shipped. Add the actual launch date and, on the check-on dates from the goals table, the actual numbers. Then the PRD becomes a record, not a plan.

The PRD has one owner, usually the product manager. Ownership means keeping the status current and the decision log honest, not writing every line.

When a PRD is the wrong document

Not every change needs one. A bug fix needs a bug report. A small, well-understood change needs a user story with acceptance criteria. A bet you have not got a yes for needs a one-pager. Use a PRD when several people must agree on scope, the work spans more than a sprint or two, or someone will later ask why it was built this way.

Common mistakes

Solution first. A PRD that opens with screens skips the argument about whether the problem is real.
Every requirement is a Must. Then none of them are, and the cuts happen silently in code review.
Goals without baselines. "Increase engagement" cannot fail, so it cannot succeed either.
Answered questions deleted. Move them to the decision log with the reason. The answer is the part people come back for.
Never updated after approval. The document then describes a feature that was never built, and the next team trusts it.

Customization tips

Write non-goals before requirements
Scope arguments happen either in the PRD or in sprint three. Listing what you will not build, with a reason, forces the argument early, when changing your mind is cheap.
Every metric needs a baseline and a date
"Improve activation" is not a goal. "Activation from 18 to 25 percent, checked on April 1" is. If you do not know the baseline, measuring it is the first requirement.
Prioritize every requirement
Use Must, Should and Could, and keep Musts to the smallest set that solves the problem. When the date slips, the team already knows what to cut, and you do not need a meeting to decide.
Give open questions an owner and a date
An open question without an owner stays open until engineering answers it by default in the code. Move answered questions into the decision log with the date and the reason, so nobody reopens them.
Add an evaluation section for AI features
If a model is involved, a demo proves nothing. Add an eval set, an accuracy bar, a cost ceiling per call and what the user does when the output is wrong, as the fourth example does.
Shrink it for small features
A two-week feature needs a summary, a problem, three requirements and the open questions. Delete the rest instead of leaving empty headings. Empty sections teach readers to skip sections.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template, paste the template above and set the category to Planning. Or describe the PRD you want in plain words and use Generate with AI to draft a template, then edit it.
Link the roadmap item with [[Enterprise readiness]]. Its backlinks panel then lists every PRD, interview note and meeting that touched it, which is the evidence trail reviewers ask for.
Write open questions as - [ ] Question (owner: Theo) @due(2026-11-06). They show up in the Tasks view until answered, so the questions do not sit unanswered in a document nobody reopens.
Ask the AI chat "why did we take SCIM out of the SSO release?" It answers from your PRDs and meeting notes with citations to the note that holds the decision.
Engineers using Claude Code or Cursor can connect Scribelet's MCP server and have their agent read the PRD while implementing, so the acceptance criteria come from the document and not from memory.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

What is a PRD?

A product requirements document describes what a product or feature must do, for whom, and how the team will know it worked. It is written by the product owner and read by design, engineering and the stakeholders who must agree before work starts. It describes the problem and the requirements, not the technical design.

What should a product requirements document include?

The sections almost every PRD template shares: summary, problem, goals with metrics, users, requirements, design links, assumptions and risks, and out of scope. The template above adds a status, non-goals, open questions with owners and a decision log, which are what keep a PRD useful after the first review.

How long should a PRD be?

As short as the decision allows. For most features, one to three pages. If it runs past five, it is usually two releases or it contains the technical design, which belongs in a separate doc such as an RFC.

Who writes the PRD?

The product manager owns it, but should not write it alone. Engineering writes or reviews the non-functional requirements and dependencies, design owns the flows, and whoever brought the evidence (sales, support, research) checks the problem section. One owner, several authors.

Are PRDs still used in agile teams?

Yes, in a shorter form. Agile teams use the PRD to agree on the problem, goals and scope, then break requirements into user stories for the backlog. The PRD stays the place where the why and the non-goals live.

What is the difference between a PRD, an MRD and a one-pager?

An MRD (market requirements document) argues that a market opportunity exists. A one-pager asks for a yes to explore it. A PRD comes after the yes and specifies what will be built. Many teams skip the MRD and go from one-pager to PRD.

A PRD that still explains itself after launch

Save this PRD template in Scribelet, link it to the roadmap item and the interviews behind it, and track open questions as tasks with due dates. Months later, ask your notes why a requirement was cut. Encrypted, free to start.

Write your first PRD

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Product

User Story Template with Acceptance Criteria

The format is one line: As a [role], I want [capability] so that [outcome]. The line is the easy part. This template adds what makes a story buildable: Given/When/Then acceptance criteria, edge cases, what is out of scope, and an INVEST check before it enters a sprint.

Work

One Pager Template

A one-pager exists to get one decision from a reader who will give it two minutes. This template puts the ask at the top, gives every section a word budget so the whole thing fits on a page, and keeps the detail in a linked appendix. Copy it, or start from the filled-in one-pager closest to yours.

Product

Product Roadmap Template

A roadmap is a promise about priorities, not a schedule. This template ties every initiative to a goal, says how confident you are in each date, keeps a visible list of what you are not doing, and logs every change with its reason. Copy it as-is, or start from the roadmap example closest to your audience.

Projects

Project Brief Template

A project brief fits on one page and gets a yes: what problem this solves, what will be true when it is done, what is in and out, what it costs, and who approves it. Copy the template, or start from the example closest to your project.

Engineering

RFC Template for Engineering Teams

An RFC (request for comments) is a short written proposal that asks reviewers to find the problems before the code does. This template adds what most RFC templates leave out: a named approver, a date comments close, and a Decision section, so the review ends instead of trailing off.

Product

User Interview Template

A user interview note is only useful if a teammate can tell what the participant said from what you concluded. This template keeps verbatim quotes, observed behavior and your interpretation in separate sections, ends with a three-line snapshot, and links every session to one study note for synthesis.