Product Requirements Document (PRD)

Framework: Standard PRD
Use for: Defining the requirements for a new feature or product
Time required: 2–4 hours (writing); ongoing review

How to use this template

Start with the problem statement and don't move to the solution until you can describe the problem clearly in 3 sentences.
Fill in goals and non-goals together — the non-goals are often more clarifying than the goals.
Write user stories before requirements. Requirements that don't map to a user story should be questioned.
Get reviewers to sign off on the problem statement and goals before you write the detailed requirements — changing direction early is cheap; changing it after engineering starts is not.
Keep the open questions table live throughout the project. Close questions with the resolution, not just the answer.

Header

Field	Details
Feature / Product Name	[Name]
Author	[Name]
Date	[Date created]
Status	[Draft / In Review / Approved / In Development / Shipped]
Version	[v1.0]
Reviewers	[Names and roles of required approvers]

TL;DR

One paragraph. What is this, why does it matter, and when does it ship? A new engineer joining the team should be able to read this and know whether to read further.

[Describe what is being built and why. Connect it to a user problem or business outcome. State the target launch window. Keep it to 3–5 sentences.]

Problem Statement

Fill in each clause. If you can't complete the third clause ("We know this because..."), you need more research before writing requirements.

Users currently [describe what users are doing today — the workaround, the frustration, the gap].

This causes [describe the impact — lost time, errors, churn, missed revenue, user frustration].

We know this because [cite the evidence — user research, support tickets, data, interviews, NPS feedback].

Proposed Solution

2–3 paragraphs. Describe what you're building at a conceptual level — not the technical implementation, but what the user will experience. What changes about their workflow?

[Describe the solution from the user's perspective. What will they be able to do that they couldn't before? What disappears from their workflow?]

[If relevant: describe what this solution explicitly does NOT do — context for the non-goals table below.]

Goals and Non-Goals

Goals (In Scope)	Non-Goals (Explicitly Out of Scope)
[What success looks like for this feature]	[What we are not solving with this feature]
[Business or user outcome this enables]	[Adjacent problem we are intentionally deferring]
[Specific capability being delivered]	[Feature that might seem related but is not included]
[Quality or reliability bar to hit]	[Platform or integration not being supported in v1]

User Stories

As a...	I want to...	So that...
[User type, e.g., "logged-in subscriber"]	[Action they want to take]	[Outcome or benefit they get]
[User type]	[Action]	[Outcome]
[User type]	[Action]	[Outcome]
[User type]	[Action]	[Outcome]
[User type]	[Action]	[Outcome]

Requirements

P0 = must-have for launch | P1 = important but not blocking | P2 = nice-to-have / future consideration

Requirement	Priority	Notes
[Functional requirement — what the system must do]	P0	[Any clarification or constraint]
[Functional requirement]	P0
[Functional requirement]	P1
[Functional requirement]	P1
[Non-functional requirement — performance, security, accessibility]	P0
[Non-functional requirement]	P1
[Edge case or error state to handle]	P1
[Edge case or error state to handle]	P2

Success Metrics

How will we know this feature is working? Define these before building so there's no moving the goalposts.

Metric	Baseline (Current)	Target	Measurement Method
[Primary success metric]	[Current value or "N/A — not measured yet"]	[Target value]	[How and where measured]
[Secondary metric]	[Baseline]	[Target]	[Method]
[Guardrail metric — something that must NOT get worse]	[Baseline]	[Must stay above / below X]	[Method]

Technical Considerations

Notes for engineering — known constraints, dependencies, or design decisions that should inform implementation. This section is owned jointly by PM and engineering.

[List known technical constraints, relevant existing systems, API limitations, scalability concerns, security requirements, or anything else engineering should know before writing the technical spec.]

Open Questions

Question	Owner	Due Date	Resolution
[Unresolved question that affects design or requirements]	[Name]	[Date]	[Fill in when resolved]
[Unresolved question]	[Name]	[Date]
[Unresolved question]	[Name]	[Date]
[Unresolved question]	[Name]	[Date]

Dependencies

Dependency	Team / System	Status
[What this feature depends on]	[Team or system name]	[Not started / In progress / Resolved]
[API, data pipeline, or infrastructure change needed]	[Team]	[Status]
[Cross-functional deliverable — design, legal, data]	[Team]	[Status]

Timeline

Phase	Description	Target Date
Discovery complete	Problem validated, solution scoped	[Date]
PRD approved	All reviewers sign off	[Date]
Design complete	Mocks reviewed and approved	[Date]
Engineering kickoff	Tech spec written, sprint planned	[Date]
Development complete	Feature code-complete	[Date]
QA and testing	All test cases pass	[Date]
Launch	Feature live for users	[Date]

PRDs align teams around what's being built and why. Covered in depth at biztechprimer.com.

Browse all templates →Download the Markdown