How long should a PRD be?

As short as possible — usually 1–4 pages for a feature, 5–10 pages for a larger initiative. If your PRD is 30 pages, you're either writing a design spec (wrong document) or you haven't done the work of separating what matters from what doesn't. Engineers skim long PRDs and miss the important parts.

What's the difference between a PRD and a spec?

A PRD defines what to build and why (problem, users, success metrics, scope). A spec defines how to build it (technical design, API contracts, data models, edge cases). A PRD is written by product; a spec is written by engineering. They reference each other but don't overlap — a good PRD doesn't dictate implementation, and a good spec doesn't justify the business case.

Do I need a PRD for small features?

For anything a single engineer can ship in a day, a ticket with context is fine. For anything multi-person, multi-week, or cross-functional, write a PRD. The rule of thumb: if you'll forget the tradeoffs you're making in three months, write them down now.

Who signs off on a PRD?

At minimum: product, engineering lead, and design lead. For customer-facing changes, add the relevant GTM stakeholder (sales, support, or marketing). Explicit sign-off avoids the 'I thought we were building X' conversation two weeks in. Use a checkbox list at the top of the doc.

What goes in 'out of scope' and why does it matter?

Anything a reasonable reader might assume is included but isn't. 'Out of scope' protects the team from creep during development and sets expectations with stakeholders before the work starts. If you find yourself repeatedly saying 'that's not part of this project,' you should have listed it.

How to Write a Product Requirements Document (PRD)

A Product Requirements Document — PRD — is the contract between product, engineering, and design for what you're going to build. A good PRD gets everyone rowing in the same direction before anyone writes code. A bad PRD wastes a month of eng time and creates the post-launch argument about what the feature was "supposed to" do.

This guide covers how to write PRDs that get read, get built, and hold up over the life of a project. Markdown is the natural format because it's easy to edit, diff, and share — but the principles apply to any format.

What a PRD is for

A PRD answers five questions:

What problem are we solving?
Who has this problem?
What does the solution look like from the user's perspective?
What does "done" mean — how will we measure success?
What are we not doing, and why?

Notice what's not on the list: implementation details, technical architecture, database schemas, UI polish decisions. Those belong in separate documents (engineering design doc, design spec) that reference the PRD.

A PRD is about what and why, not how.

The PRD anti-patterns

Before we cover what to write, here's what to avoid:

The solution disguised as a problem. "Users need a bulk export button" is a solution. The problem is "Users spend 20 minutes per week copying data to reports and make mistakes."
The list of features. A PRD is not a bag of checkboxes. If every bullet point is a feature with no reasoning, you haven't written a PRD — you've written a roadmap line.
The novel. 40 pages of context, persona backstories, and historical decisions. Nobody reads page 40.
The vague ship criteria. "Launch when it feels good" is not a criterion. Neither is "improve engagement." Be specific.
The missing out-of-scope. Leaving out-of-scope implicit guarantees scope creep.

The structure

Here's a battle-tested PRD skeleton. The Product Requirement Document template is a filled-in version you can copy.

---
title: "[Feature name] PRD"
author: "Your Name"
status: "Draft | In Review | Approved | Shipped"
last_updated: 2026-03-11
reviewers:
  - [ ] Eng Lead
  - [ ] Design Lead
  - [ ] GTM Lead
---

# [Feature name]

## TL;DR

3–5 sentences. What we're building, who it's for, why now, expected impact.
This is the only section some readers will see. Make it count.

## Problem

Describe the problem in user or business terms. Include data.
Why is this a problem now and not six months ago?

## Users

Who specifically has this problem? What do they do today to work around it?

## Goals

What does success look like? Include quantitative goals (metrics) and
qualitative goals (what users should be able to do or say).

### Non-goals

What this project is explicitly NOT trying to achieve. Equally important.

## Solution

High-level description of what we'll build, from the user's perspective.
Include user stories, user flows, or mockup references — not implementation.

### User stories

- As a [user type], I can [action] so that [outcome].
- ...

### Scope

What's in this version. Bulleted, specific.

### Out of scope

What's NOT in this version. Bulleted, specific.

## Success metrics

How we'll measure impact. Specific numbers with timeframes.

- Primary: [metric] will [change] by [amount] within [timeframe].
- Secondary: [metric] will [change] by [amount].
- Guardrails: [metric] will not degrade by more than [amount].

## Open questions

Decisions that still need to be made. Who owns resolving each.

## Appendix

Links to research, data, competitor analysis, earlier explorations.

Let's walk through the sections in detail.

TL;DR

Write this last. It's the summary, and you can't summarize what you haven't written.

Example:

TL;DR: Free-tier users currently hit a hard wall at 5 projects, which is causing 12% of them to churn before completing their first real use case. We'll replace the hard limit with a soft limit that shows an inline upgrade prompt, plus a 30-day grace period after exceeding. Expected impact: 3–5% reduction in free-tier churn, 1–2% lift in free-to-paid conversion. Ships in Q2.

Five sentences, every one loaded.

Problem

The problem section is where PRDs live or die. A vague problem produces a vague feature.

Weak:

Users sometimes have trouble with the export flow.

Strong:

37% of users who start the CSV export flow abandon before completing. Of those, 68% cite "too many steps" in the post-abandonment survey. The flow currently has 6 clicks; competitor analysis shows 2–3 is standard. This is costing us an estimated 400 completed exports per week, the activity most correlated with paid conversion (r=0.72).

Include:

Quantitative framing (how big is the problem?)
Qualitative framing (how does it feel to the user?)
Why now (what changed, or what changes if we don't act)

Users

Name the specific user segment. "Our users" is not a user segment.

"Free-tier users in the first 7 days after signup" — yes
"Enterprise admins managing 50+ team members" — yes
"Mobile users on iOS, US only" — yes
"Our users" — no

If multiple segments have the problem in different ways, list them separately. If the problem mainly affects one segment, say so explicitly — this helps design and engineering scope correctly.

Goals and non-goals

A goal is a specific outcome you want to achieve. It's not a feature.

Feature (wrong): "Add a bulk edit button." Goal (right): "Users editing 10+ items at once complete the task in under 30 seconds."

List 2–5 goals, ordered by priority. More than 5 goals means the project is actually multiple projects.

Non-goals are the goals you could pursue but are explicitly deprioritizing. This is where you cut scope before stakeholders add it in for you. Examples:

"We are not redesigning the broader settings page, only the billing section."
"We are not adding new payment methods — this release improves what exists."
"We are not changing the free/paid split — both tiers get this feature."

Solution

Describe the user experience, not the implementation.

User stories are classic and still useful for simple features.
User flows (step-by-step walkthroughs) are better for multi-step interactions.
Mockups or Figma links are best when design has made progress.

Avoid:

"We'll use Postgres triggers to..." (implementation)
"The frontend will call POST /v1/export..." (implementation)
"Built in React with..." (implementation)

Do:

"When a user clicks Export, they see a dialog asking which columns to include..."
"If the export is larger than 10,000 rows, show a warning with an estimated time..."
"On completion, email the file link to the user's registered email address..."

Edge cases

List 5–10 specific edge cases and how the feature should behave:

What happens on network failure mid-export?
What happens if the user navigates away during the export?
What does a user with zero data see?
What's the experience for a user over their plan limit?

Engineers will ask all of these during implementation. Answering them in the PRD shortens that loop.

Success metrics

The hardest section. Vague metrics kill projects silently — nobody can tell if the thing worked.

Structure:

Primary metric: the one number that tells you the project worked. Usually the one from the Problem section.
Secondary metrics: nice-to-haves that indicate the feature is healthy.
Guardrails: metrics that can't get worse. "Page load time won't increase by more than 100ms." "Support ticket volume won't increase by more than 10%."

Criteria for a good metric:

Specific. "Export completion rate" not "engagement."
Measurable. You can pull it from your analytics tool today.
Time-bound. "Within 30 days of launch."
Attributable. You can tell whether the feature caused the change, not just coincided with it.

Example:

Primary: Export completion rate increases from 63% to 80% within 30 days of launch, measured on users who reach the export flow. Secondary: Free-to-paid conversion within 14 days of first export increases from 4.2% to 5.5%. Guardrails: P95 export latency does not exceed 8 seconds. Support tickets tagged "export" do not increase by more than 15%.

Open questions

A running list of things that aren't decided yet. Each gets an owner and a resolution deadline.

## Open questions

- **Should we rate-limit exports?** Owner: @sara. Decision by March 15.
- **What columns are exportable by default?** Owner: @marcus. Decision by March 18.
- **Do we need audit logs for exports?** Owner: @priya. Decision by March 20.

This section shrinks over the life of the PRD. When it's empty, you're ready to ship.

Review and sign-off

Put a checklist at the top of the PRD:

## Reviewers

- [ ] @engleader — Engineering
- [ ] @designlead — Design
- [ ] @gtmlead — Go-to-market
- [ ] @legal — Privacy review (if user data)

Each reviewer checks the box when they've read and agreed. For Markdown stored in Git, this becomes part of the PR history — an auditable record that the right people aligned before work started.

Living document

A PRD isn't frozen at approval. As implementation reveals realities (tech is harder than expected, users behave differently in testing, scope shifts), update the PRD and note the changes in a changelog at the bottom:

## Changelog

- **2026-03-20:** Removed "custom column ordering" from scope — eng estimated 3x original size.
- **2026-03-15:** Added 30-day grace period after discussing with support team.
- **2026-03-11:** First draft.

The changelog answers "why did we change this?" six months later, which is a question that always gets asked.

Length calibration

A rough guide:

Small feature (single engineer, 1–2 weeks): 1 page. TL;DR, problem, scope, metrics. Done.
Medium feature (small team, 1 month): 2–4 pages. Full template, lightly filled.
Major initiative (multiple teams, a quarter): 5–10 pages. Full template, thoroughly filled, with appendices.
Company-changing bet: 10–20 pages, with preceding strategy docs. Rare.

If you're writing more than 10 pages, question whether you're writing a PRD or a book. Move detail to appendices or separate docs.

Closing

A PRD is a tool for alignment, not a record of your thinking. If it doesn't change minds, prevent mistakes, or shorten conversations, rewrite it until it does.

Start with the template. Fill only the sections that matter. Share early, before the doc feels polished — the real value of a PRD is the conversations it forces, not the document it produces.