Product Requirements Document (PRD) Template

A PRD's job is to get everyone (eng, design, PM, stakeholders) aligned on what's being built and why, before anyone writes code. Keep it as short as the problem allows.

A PRD that's too long to read is a PRD nobody reads.

How to use this document

Fill in Problem and Goals first, and get alignment on those before writing solution details, most PRD churn comes from skipping this step.
Keep Out of scope honest, the fastest way to blow a deadline is scope that was never written down as excluded.
This is a living document during design/build, then it freezes as a record once shipped, don't keep editing it after launch, write a new one for v2.

Overview

Field	Value
Author	[name]
Status	[Draft / In review / Approved / Shipped]
Target release	[date or milestone]
Stakeholders	[PM, eng lead, design, others who need to sign off]
Related docs	[design doc, tickets, prior PRDs]

Problem

What's broken or missing today, for whom, and how do you know? Cite real evidence: support tickets, usage data, direct user quotes.

Not "users probably want this."

[2-4 sentences. Be specific about the user and the pain, not the feature.]

Goals

What does success look like, in terms you can actually measure after launch?

[Goal 1: tie to a metric where possible, e.g. "reduce time-to-first-value from X to Y"]
[Goal 2]
[Goal 3]

Non-goals

Equally important: what this project explicitly will not solve, so reviewers don't scope-creep it later.

[Non-goal 1]
[Non-goal 2]

Users & use cases

Who is this for, and what are they trying to do? A short user story or two beats a persona slide.

As a [user type], I want to [action], so that [outcome].

[Add 1-3 of these covering the primary flows.]

Requirements

Split must-have from nice-to-have. Reviewers should be able to look at this table and know exactly what "done" means.

#	Requirement	Priority	Notes
1	[Functional requirement]	P0	[Any constraint or edge case]
2	[Functional requirement]	P0
3	[Functional requirement]	P1
4	[Nice-to-have]	P2	Cut if timeline is tight

Out of scope

An explicit list of things adjacent to this feature that are not included. This keeps scope from creeping and sets expectations with stakeholders up front.

[e.g. Mobile app support, web only for v1]
[e.g. Bulk import, single-item creation only for v1]

Design / UX

[Link to Figma/mockups, or embed key flows. If there's no design work needed, say so explicitly rather than leaving this blank.]

Technical considerations

This isn't a full design doc, just what a PM or stakeholder needs to know about feasibility, risk, and dependencies. Link the actual design doc or ADR for depth.

Dependencies: [other teams, third-party services, infra prerequisites]
Data/privacy considerations: [PII involved? retention? compliance?]
Performance/scale considerations: [expected load, any known limits]
Rollout plan: [feature flag? staged rollout? all at once?]

Success metrics

How will you know this worked, two to four weeks after launch? Define the metric and the target before launch, not after.

Metric	Baseline	Target	How measured
[e.g. Activation rate]	[current %]	[target %]	[analytics event/dashboard]
[e.g. Support tickets on this flow]	[current count/week]	[target]	[ticket tag]

Open questions

Track unresolved decisions here so they don't get lost in Slack threads. Resolve them before moving this to "Approved."

Question	Owner	Resolved?
[e.g. Do we need rate limiting on this endpoint at launch?]	[name]	[ ]

Example: filled Problem + Goal

Problem: support tickets show that 22% of new team signups never invite a second teammate within the first 7 days. Cohort analysis shows those teams are 3x more likely to churn within 30 days.
Exit interviews suggest the invite flow is buried in settings instead of surfaced during onboarding.
Goal: increase the 7-day team-invite rate from 78% to 90% by surfacing an invite prompt directly in the onboarding checklist, measured via the existing team_invited analytics event.

이 템플릿을 팀 워크스페이스로 복제하려면 → rootr.io