The PRD Template: Writing Product Requirements That Work

Contributor
Apr 15
6 min read

A Product Requirements Document (PRD) is a contract between product and engineering: this is what we're building, why, for whom, and what done looks like. A working PRD is short, specific, and actually read. A typical PRD is long, vague, and skimmed once at kickoff. The difference isn't the template; it's the discipline behind it.

This guide is a template that works, with notes on what each section is for.

When to Write One

PRDs are worth writing for:

New features that cross multiple teams or systems
Significant changes to existing features
Anything where requirements have evolved during discovery and you need a stable artifact

Skip the PRD for:

Bug fixes
Small tweaks the team can handle in a ticket
Pure technical work (use an ADR or RFC instead)

The point is communication, not ceremony. If the team already knows what to build, the PRD adds nothing.

The Working Template

# [Feature Name]

## TL;DR
[2-3 sentences: what, who, why now]

## Problem
[The user problem we're solving, in their language]

## Users and Use Cases
[Who specifically, doing what, in what context]

## Success Criteria
[Specific, measurable outcomes that prove the feature worked]

## Scope
In scope: [bullet list of what's included]
Out of scope: [bullet list of explicit exclusions]

## Requirements
[Functional requirements, numbered]

## Open Questions
[Things we don't know yet, with owners]

## Constraints and Assumptions
[Technical, legal, business limits we're operating within]

## Rollout Plan
[How this gets to users; risks]

## Appendix
[Designs, research, related docs]

That's it. Most PRDs should be 2-4 pages. Longer ones get skimmed; shorter ones lose detail.

The TL;DR

Three sentences answering: what is this, who is it for, why now.

Bad TL;DR: "This PRD covers various improvements to the user dashboard to enhance the overall user experience."

Good TL;DR: "We're adding workspace switching to the dashboard. Power users with multiple workspaces currently have to log out and back in to switch — they've been the top complaint in support for two quarters. Targeting Q3 launch ahead of the enterprise upsell push."

The TL;DR is what gets read first and most often. Most readers won't go past it. Make it carry the weight.

The Problem Statement

What user problem are we solving. Not what feature are we building.

The discipline: write the problem so a stakeholder unfamiliar with the proposed solution can recognize it as a problem worth solving. If the only way to make the problem sound real is to assume the solution, the problem isn't articulated well.

Reference research, support tickets, sales feedback, or whatever evidence shows the problem is real. "Users are confused" is weak. "37% of new signups don't complete onboarding; exit surveys cite step 3 as the dropoff point" is strong.

Users and Use Cases

Who specifically. Not "users." Not even "power users." Specific personas, segments, or roles with specific behaviors.

For each user category, what they're doing when they encounter the problem and what they want to accomplish. The use cases anchor the requirements — they show why a requirement matters.

If you can't write a clear use case, the feature probably isn't sharp enough yet.

Success Criteria

This is where most PRDs go soft. "Users will have a better experience" isn't a success criterion; it's a wish.

Real success criteria are:

Measurable: tied to a metric you'll actually look at
Specific: a number or threshold, not a direction
Time-bounded: when you'll measure
Honest: includes thresholds for "this didn't work"

Example: "Within 30 days of launch, the feature is used by at least 25% of eligible users, and the related support ticket category drops by 50%. If usage is below 10% or tickets are unchanged at 60 days, we'll assess whether to remove the feature."

Including the "didn't work" threshold is critical. Without it, every feature is declared successful regardless of evidence.

Scope

What's in, what's out, explicitly.

The Out of Scope list is the most important section for preventing the requirement drift that kills releases. "Workspace switching is in scope; bulk workspace management is not in scope for this release" prevents three weeks of debate about whether bulk operations should be included.

Be specific. "Various improvements" is not scope. Named features and bounded scope are.

Requirements

The functional requirements, numbered for reference.

A requirement should be:

Testable: you can determine whether it's met
Atomic: one thing, not a paragraph
Necessary: removing it makes the feature meaningfully worse

Number them so reviewers can reference specifics ("R7 seems to conflict with R12").

A common mistake: writing requirements that are really implementation details. "The system shall use a Redis cache" is implementation; "Workspace switching should complete in under 500ms" is requirement.

Keep requirements at the behavior level. How the engineering team meets them is their job.

Open Questions

Things you don't know yet, with owners.

This section is honest. It says "we haven't figured this out yet, and we'll figure it out by Y." It signals to readers what's stable and what's not. Without this, the team finds out about open questions when they hit them mid-implementation.

Each open question needs an owner and ideally a target resolution date.

Constraints and Assumptions

Technical limits, legal requirements, business rules, dependencies.

Technical: "Must work on iOS 16+" or "Must integrate with existing auth flow"
Legal: "Must satisfy GDPR right-to-delete"
Business: "Pricing tier gates apply"
Dependencies: "Depends on the new permission system shipping in Q2"

Constraints often surface late in implementation when they should have been in the PRD. Front-load them.

Rollout Plan

How this gets to users. For something big, with risk to mitigate.

Internal first, then a beta cohort, then general availability?
Feature flag with gradual rollout?
Big-bang launch tied to marketing?
Phased by customer segment?

This section connects the PRD to the release plan. Without it, "how will this ship" becomes a separate conversation that may surface surprises.

Appendix

Designs, user research, related decisions. Material that's useful as reference but would clutter the main document.

The main PRD should be readable without the appendix. The appendix is for the reader who wants more.

What Makes a PRD Useful in Practice

A few practices that separate decorative PRDs from working ones.

Living document, not artifact. As the team learns during implementation, the PRD updates. Last-touched timestamps and change logs at the top show whether the document is current. Stale PRDs are worse than missing ones.

Owned, not committee-authored. One PRD owner makes decisions. Stakeholders provide input but don't co-edit. Documents authored by committee end up reflecting the lowest common denominator of disagreement.

Reviewed against, not just at kickoff. Engineering references the PRD during implementation. "This works as specified" or "this doesn't" — both useful. PRDs that are written, approved, and never opened again are dead documents.

Specific where it matters, not everywhere. A 50-page PRD claiming to specify everything actually specifies nothing well. Be specific on the points that matter — success criteria, scope boundaries, key requirements — and concise elsewhere.

Anti-Patterns

Marketing-speak: "delight users with cutting-edge experiences." Useless for engineering.
Solution-as-problem: "users need a workspace switcher." Workspace switcher is the solution; what's the problem?
Endless requirements: 200 numbered requirements, mostly trivial. Buries the important ones.
Mock-driven: a PRD that's mostly mockups with no written requirements. Designs change; the written intent persists.
Mystery decisions: "we decided to do X" with no reasoning. Future readers (and future you) won't remember why.

Sizing

A PRD's right length depends on the feature.

Small feature: 1-2 pages
Standard feature: 3-5 pages
Cross-team or strategic: 5-10 pages, but at this point consider whether you actually have one PRD or several

If the PRD is over 10 pages, it's probably trying to cover too much. Decompose into a high-level doc and child PRDs.

Key Takeaway

A working PRD is short, specific, and read. Lead with a TL;DR that carries the weight. State the problem in user terms before proposing the solution. Make success criteria measurable, including the threshold for "didn't work." Be explicit about scope, including out-of-scope. Keep requirements at the behavior level. List open questions with owners. Update the document as you learn. The template is the easy part — the discipline is keeping it useful.

ShiftQuality