How to Write a PRD: Template, Example & Checklist

A product requirements document is a living alignment artifact: it records the problem, users, intended outcomes, scope, tradeoffs, and unresolved decisions. It should change when evidence or implementation constraints change.

Start with the PRD template, fill only the sections your team needs, and record decisions instead of treating approval as an immutable contract.

All company names, dates, metrics, incidents, and targets in the examples below are fictional and illustrative.

What a PRD is for

A PRD answers five questions:

1. What problem are we solving?
2. Who has this problem?
3. What does the solution look like from the user's perspective?
4. What does "done" mean — how will we measure success?
5. 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 is an adaptable PRD skeleton. The Product Requirements 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.

Fictional, illustrative 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.

Stronger fictional example:

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 a small, prioritized set of goals. If the list becomes hard to reason about, split the initiative or identify a primary outcome.

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 the edge cases most likely to affect correctness, safety, or user trust:

• 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: measures you monitor for unacceptable regressions. Set thresholds from evidence and system requirements.

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.

Fictional, illustrative 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)

Teams that use checkbox sign-off can record it in Git history, but a checkbox does not by itself establish formal approval or compliance. Follow the organization's review process.

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 helps a future reader understand why the scope or decision changed.

Length calibration

Let complexity and decision risk determine length. Keep the problem, goals, scope, tradeoffs, and open questions easy to scan; move research, technical design, and raw evidence into linked appendices or separate documents.

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.