# 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 1. Start with the problem statement and don't move to the solution until you can describe the problem clearly in 3 sentences. 2. Fill in goals and non-goals together — the non-goals are often more clarifying than the goals. 3. Write user stories before requirements. Requirements that don't map to a user story should be questioned. 4. 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. 5. 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.*