A product requirements document (PRD) defines what a product or feature shall do, who it serves, and how the team will know it succeeded, without specifying how to build it. PRD templates floating around the internet usually present a Google Doc with eight blank headings. That is enough to fill in the boxes. It is not enough to know which boxes belong to the PRD and which do not. Business requirements own the ones upstream. The design spec owns the ones downstream.
This article gives you a complete PRD template. It explains the decision behind each section and draws the boundary to the neighboring documents. The template is below. The reasoning tells you when a section is missing. It also tells you when a section has metastasized into something it should not be.
What a PRD is and what it is not
A PRD answers four questions in order: what problem are we solving, who has the problem, what shall the product do to solve it, and how will we measure that we solved it. The audience is engineering, design, QA, and product leadership. The product manager holds the pen. The PRD is the binding scope agreement. Engineering builds against it, and QA tests against it.
A PRD is not a marketing brief, a business case, a system architecture document, or a UI specification. Each of those exists in its own document with its own audience. A PRD that pretends to be all of them turns into a 60-page artifact no engineer reads. The discipline of a PRD is restraint. Every section answers a question only the PRD can answer. Every other question goes somewhere else.
Marty Cagan's Inspired (2017) argues that heavy PRDs slow product teams down and recommends prototypes plus a high-level brief. That position holds for small product iterations on consumer software. It does not hold for cross-team features, regulated industries, or contractual deliverables. It fails anywhere someone has to verify what was built against what was promised. The right PRD captures exactly the level of detail your verification step requires. Less is sloppy. More is theater.
The free PRD template (copy this)
Use the structure below for any new feature, product, or release. Replace bracketed placeholders. Keep the section order — reviewers and engineers expect it.
PRD-[NUMBER]
Title: [Feature or product name]
Version: [X.Y]
Status: [Draft | In review | Approved | Implemented]
Author: [PM name]
Stakeholders: [Engineering lead, Design lead, QA lead]
Date: [YYYY-MM-DD]
Target: [Release version or quarter]
1. Problem statement
[One paragraph. The user problem, the business cost, and why now.]
2. Goals and non-goals
Goals:
- [Outcome the feature is intended to achieve]
- [Outcome the feature is intended to achieve]
Non-goals:
- [Outcome explicitly excluded from this PRD]
- [Outcome explicitly excluded from this PRD]
3. User stories
- As a [user role], I want [capability] so that [outcome].
- As a [user role], I want [capability] so that [outcome].
4. Functional requirements
FR-1: The product shall [capability].
FR-2: The product shall [capability].
FR-3: When [condition], the product shall [response].
5. Non-functional requirements
NFR-1: Performance - [metric, threshold, conditions]
NFR-2: Security - [requirement, applicable standard]
NFR-3: Accessibility - [WCAG level, success criterion]
NFR-4: Reliability - [availability target, error rate]
6. Dependencies
- [Internal team or system this feature relies on]
- [External API, SDK, or contract]
- [Decisions still owed by another group]
7. Timeline
- [Milestone]: [Date]
- [Milestone]: [Date]
- [Release target]: [Date]
8. Success metrics
- [Metric]: [Baseline] → [Target] within [timeframe]
- [Leading indicator]: [Definition and threshold]
- [Counter-metric]: [What we must not break]
The template is intentionally plain. Visual formatting belongs in the rendered output, not the source. The metadata block at the top makes the document controllable across review cycles. The body makes the work executable.
Why each section earns its place
Generic PRD templates list these sections without explanation. The explanation is what tells you what belongs inside and what does not.
Problem statement
The Problem statement names the user problem and the business cost in one paragraph. It is the section a reader scans first to decide whether to read further. The frequent trap is writing a solution statement instead. "Users need a dashboard" is a solution. "Support managers cannot identify tickets at risk of breaching SLA until after the breach occurs" is a problem. The Problem statement also justifies the work. Name the user, the cost, and the trigger in one paragraph. If you cannot, the feature is not yet ready for a PRD.
Goals and non-goals
Goals state the outcomes the feature is intended to achieve. Non-goals state the outcomes explicitly excluded. Non-goals are the more useful list. The convention comes from Google's internal design-doc practice and from the Kubernetes Enhancement Proposal (KEP) format. Both require a Non-goals section. Without one, every reviewer assumes a different scope. The document then accumulates feature requests through review cycles. A well-written Non-goals list keeps that negotiation out of the document.
The right shape is 3 to 5 goals and 3 to 5 non-goals. Fewer than 3 of either means you have not thought hard enough about the edges of the work.
User stories
User stories capture the why behind each capability in the "as a [role], I want [capability], so that [outcome]" pattern Mike Cohn formalized in User Stories Applied (2004). The PRD is the right home for user-task stories, not implementation tasks. A PRD with 40 implementation-sized stories is a backlog dump. The PRD lists the 5 to 12 stories that describe how a user accomplishes the goals. Engineering breaks each one into implementation tasks during sprint planning.
Functional requirements
A functional requirement is a single, atomic "shall" statement of what the product does. One sentence, one identifier, one verifiable behavior. The Easy Approach to Requirements Syntax (EARS) gives five sentence patterns that cover the common cases. Our software requirements specification guide describes them in detail. PRDs do not need EARS-level rigor. The underlying principle still holds. Each requirement is one sentence with one outcome, and QA can decide pass or fail without consulting the author.
Granularity is the line between a functional requirement in a PRD and one in an SRS. A PRD captures the user-visible behavior. An SRS decomposes that behavior into the dozen system-level requirements engineering implements against. "The product shall let an administrator deactivate a user account" belongs in a PRD. "The system shall invalidate all active sessions for the deactivated account within 5 seconds" belongs in an SRS.
Non-functional requirements
Non-functional requirements (NFRs) cover quality attributes: performance, security, accessibility, reliability, internationalization. Each NFR needs a measurable threshold. "The product shall be fast" is not an NFR. "The product shall render the dashboard within 1.5 seconds at the 95th percentile for accounts with up to 10,000 records" is. ISO/IEC 25010:2011 lists the canonical NFR categories. You do not need the standard's vocabulary. Pick a fixed list and apply it to every PRD.
The frequent failure is silence on NFRs because "engineering will figure it out." Engineering figures out whatever the team thinks is normal. Normal is whatever the last similar feature did. That compounds problems silently across releases.
Dependencies
Dependencies lists every external team, system, and decision the feature relies on, with the responsible owner for each. The function of this section is to surface blockers early. An empty Dependencies list means one of two things. The feature is trivial and self-contained. Or the feature is complex and under-analyzed. Its author never asked who else has to deliver something for this to ship. The act of writing this section is what catches missed cross-team conversations.
Timeline
Timeline lists the milestones with target dates: design complete, engineering kickoff, code complete, QA complete, beta, GA. The timeline belongs in the PRD because it is part of the scope commitment. Without it, "scope" is unbounded by time. It is still not a project plan. Three to five milestones is enough. The detailed plan lives in the work tracker.
Success metrics
Success metrics define what "this worked" looks like. Each metric needs a baseline (the current value), a target (the value that means success), and a timeframe (when you will measure). At least one counter-metric — "we must not break X while improving Y" — is mandatory. Without it, teams optimize the headline number at the cost of something they never measured. The pattern is borrowed from Google's OKR practice and from the broader product-analytics literature.
PRD vs SRS vs design spec
The three documents serve different audiences, answer different questions, and require different rigor. Confusion among them is the single most common reason PRDs bloat into 60-page artifacts no one reads.
| Question | PRD | SRS | Design spec |
|---|---|---|---|
| What does it answer? | What shall the product do for the user? | What shall the system do, verifiably? | How shall we build it? |
| Audience | Engineering, design, QA, leadership | Engineering, QA, systems engineering, regulators | Engineering team building the feature |
| Owner | Product manager | Engineering lead or systems engineer | Engineering lead or tech lead |
| Detail level | User-visible behavior, scope, success metrics | Atomic, verifiable "shall" statements, traceable | Components, interfaces, data flow, sequence diagrams |
| Includes UI mockups? | High-fidelity flows, not pixel specs | No | Yes, if relevant to implementation |
| Includes architecture? | No | Constraints only | Yes |
| Required in regulated industries? | Recommended | Required (ISO/IEC/IEEE 29148:2018) | Required (varies by standard) |
| Update cadence | Per feature, frozen at engineering kickoff | Per release, version-controlled | Per implementation decision |
A PRD that includes data-model diagrams has crossed into design-spec territory. An SRS that justifies the feature with user research has crossed into PRD territory. Ask who would consume the section. If engineering needs it during build, it belongs in the design spec. If QA needs it to verify, it belongs in the SRS. If leadership needs it to approve scope, it belongs in the PRD.
A note on the BRD. A business requirements document sits one step upstream of the PRD. It answers "why is the company doing this work" at the level of revenue impact, market positioning, and strategic fit. The BRD audience is leadership and finance. Most modern product organizations fold BRD content into the PRD's Problem statement and Success metrics rather than maintaining a separate document. When the three documents blur, SRS vs PRD vs BRD walks through which one you actually need.
Common PRD mistakes
Five mistakes account for the bulk of failed PRD reviews. None of them are exotic.
Scope creep into design. A PRD that specifies button colors, micro-interactions, and copy down to the placeholder text is a design spec wearing a PRD's clothes. The fix is a link to the Figma file or design doc. Trust the design team to own those decisions. The PRD describes the user task. The design spec describes the interaction.
Missing non-goals. A PRD without an explicit Non-goals section invites every reviewer to imagine their own scope. By the end of review, the PRD has accumulated five new requirements no one will own. Writing 3 to 5 non-goals at draft time prevents the negotiation from happening inside the document.
Vague success metrics. "Improve user engagement" is not a metric. "Daily active users of the feature increase from baseline 18% to 30% within 60 days post-launch, measured by the dashboard-viewed event" is. The discipline is picking a baseline before launch. If you cannot measure the current state, your metric is hypothetical.
Untraceable user stories. A PRD lists 12 user stories and 18 functional requirements with no link between them. Engineering implements the requirements and ships. No one can verify which user story is satisfied. The fix is a traceability matrix. Each user story lists the functional requirements that fulfill it. Full bidirectional traceability is overkill for most PRDs. Unidirectional is not.
Frozen documents in changing contexts. A PRD approved in week 1 stays untouched while the team learns from prototype testing in weeks 2 through 4. By the time engineering reads the PRD in week 6, half the assumptions are stale. The fix is to treat the PRD as a living document until engineering kickoff. A version table tracks each material change. After kickoff, the document freezes and further changes go through change control.
When you need a PRD and when you do not
PRDs are not free. A well-written one takes a senior product manager 2 to 4 working days plus review cycles. The question is when that investment is worth it.
| Situation | PRD required? |
|---|---|
| New product, first version | Yes — defines the scope contract |
| Major release with cross-team dependencies | Yes — the alignment cost without one is higher |
| New feature touching 3 or more teams | Yes — coordinate or pay for chaos later |
| Feature in a regulated industry (medical, aviation, finance) | Yes — required for audit and certification |
| Contractual deliverable (custom software) | Yes — the contract references the PRD |
| Small iteration on an existing feature (copy change, layout tweak) | No — a ticket is enough |
| Bug fix or technical debt | No — engineering owns the change |
| Prototype or spike | No — write a one-paragraph brief |
| A/B test of a known design pattern | No — the test design doc is the right artifact |
The crossover is roughly the point where three or more groups need to act on the same plan. Below that, a PRD is overhead. Above it, the absence of a PRD costs more than writing one. A free Google Doc template will serve a team writing 3 PRDs a quarter on co-located product squads. The doc-of-docs approach starts to fail at scale.
The PRD as structured content
Most PRDs live as flat Google Docs. That works for one PRD. It breaks for an organization writing 40 PRDs a year across 6 product squads.
The failure modes are the same ones that break SOP libraries and SRS documents. The same Non-functional requirement ("the product shall be SOC 2 compliant, evidenced by quarterly access review") appears in 30 PRDs. When the SOC 2 standard updates, someone has to find those 30 documents and edit each one. Five get missed. At audit time, the team is on the hook for the inconsistency.
A second failure mode: the executive version. Leadership wants a 2-page PRD that omits implementation detail. Engineering wants the full 8-page version. Today that is two documents, and they drift. With conditional content, the same source publishes both. Sections tagged as "internal" disappear from the executive PDF. A single edit propagates to both outputs. The structure is the same one content reuse and the CCMS model were built for.
A third: connecting the PRD to its neighbors. Each PRD functional requirement should link to the SRS requirements it spawned. It should also link to the design components it shapes and the test cases that verify it. In Google Docs, those links rot the first time anyone renames a file. In a structured authoring system, they are typed references the tool can validate.
Where Topicary fits
Topicary is a cloud-native CCMS that works for requirements documents the same way it works for technical documentation. Reusable components hold the boilerplate: legal disclaimers, NFR templates, the standard success-metric format. Conditional content produces the executive and engineering versions from the same source. Variables carry product names and release versions. Cross-references link PRD requirements to SRS entries and test cases. PDF output serves executive review packs, and web output serves the engineering wiki. Token-based review lets cross-functional reviewers comment without login accounts, with comments tied to specific sections.
A team writing 3 PRDs a quarter does not need any of this. A Google Doc template will serve them well. Consider instead a team writing 30 PRDs a quarter across 5 squads, under regulated-industry constraints or contractual deliverables. That team has crossed the threshold the tool was built for. The structured authoring approach without XML complexity is the operational shift. The tool is the mechanism that makes it work.
Frequently asked questions
What sections should a PRD include?
A standard PRD template includes eight sections: Problem statement, Goals and non-goals, User stories, Functional requirements, Non-functional requirements, Dependencies, Timeline, and Success metrics. Smaller teams sometimes collapse Dependencies into Timeline, but the Non-goals subsection is mandatory in every case. The metadata block above the body (version, status, author, stakeholders) is what makes the document controllable across review cycles.
What is the difference between a PRD and an SRS?
A PRD describes what the product shall do for the user. An SRS describes what the system shall do, with each requirement atomic and verifiable. The PRD is owned by the product manager and answers "is this worth building." The SRS is owned by engineering or systems engineering and answers "did we build it correctly." In regulated industries the SRS follows ISO/IEC/IEEE 29148:2018; the PRD is recommended practice across product organizations but is not standardized.
Should a PRD include UI mockups?
It depends on detail level. A PRD should include high-fidelity user flows that show how the user accomplishes the goal, typically a screen sequence with annotations. It should not include pixel-level mockups, color specifications, micro-interaction timing, or copy down to placeholder text. Those belong in the design spec, which the PRD links to. If your PRD includes the design spec inline, you have two documents under one cover page.
Who owns the PRD?
The product manager owns the PRD. In product organizations without dedicated PM headcount, the function falls to whoever is accountable for scope and outcome — typically a tech lead with a product hat or a founder. The owner is the person who approves changes after kickoff, defends the scope contract during the release, and signs off the success-metric review post-launch. Co-ownership across PM and engineering tends to slow review without improving the document.
How long should a PRD be?
A small feature PRD runs 3 to 8 pages. A new-product PRD runs 15 to 30 pages. Anything past 40 pages usually means the document has absorbed responsibilities that belong in adjacent documents — system architecture in the PRD, design specs in the PRD, or implementation tasks dressed as user stories. The actionable test is whether an engineering lead can read the PRD in 30 minutes and start a kickoff conversation. If the answer is no, the PRD is too long, not too rigorous.
Is a PRD still needed in agile teams?
For most cross-team or new-product work, yes. Agile reduces the need for heavy upfront specification within a single team building incremental features. It does not eliminate the need for a shared scope contract when three or more teams depend on the same release, when a feature must satisfy a regulated requirement, or when leadership needs to approve scope before commit. The pattern that works is a lightweight PRD defining goals, non-goals, and success metrics, with user stories and requirements maintained in the work tracker against that contract.
Sources
- Cagan, M. "Inspired: How to Create Tech Products Customers Love." 2nd ed. Wiley, 2017. https://www.svpg.com/books/inspired-how-to-create-tech-products-customers-love-2nd-edition/
- Cohn, M. "User Stories Applied: For Agile Software Development." Addison-Wesley, 2004. https://www.mountaingoatsoftware.com/books/user-stories-applied
- Wiegers, K. and Beatty, J. "Software Requirements." 3rd ed. Microsoft Press, 2013. https://www.microsoftpressstore.com/store/software-requirements-9780735679665
- ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. International Organization for Standardization, 2018. https://www.iso.org/standard/72089.html
- ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. International Organization for Standardization, 2011. https://www.iso.org/standard/35733.html
- Kubernetes Enhancement Proposal (KEP) template. Kubernetes project, 2024. https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md
- Mavin, A., Wilkinson, P., Harwood, A., Novak, M. "Easy Approach to Requirements Syntax (EARS)." IEEE International Requirements Engineering Conference, 2009. https://ieeexplore.ieee.org/document/5328509