# Product Requirement Document

A **Product Requirement Document (PRD)** is a document that describes what a product or feature should do, who it is for, and why it is being built. It is usually written by a product manager and serves as the shared reference point for design, engineering, QA, marketing, and stakeholders.

A PRD defines the **what** and the **why**, and leaves the **how** (technical implementation) to the engineering and design teams.

## Purpose

- Align everyone on the problem being solved and the intended outcome
- Set a clear scope, including what is explicitly *not* being built
- Give design and engineering enough context to make good decisions
- Provide a baseline for testing and for judging whether the launch succeeded

## Typical contents

| Section | What it answers |
| --- | --- |
| Overview / background | What is this, and why now? |
| Problem statement | What user or business problem are we solving? |
| Goals and success metrics | How will we know it worked? |
| Target users / personas | Who is this for? |
| Use cases / user stories | What do users need to accomplish? |
| Functional requirements | What must the product do? |
| Non-functional requirements | Performance, security, accessibility, reliability |
| Scope and non-goals | What is in, and what is deliberately out? |
| Assumptions, constraints, dependencies | What are we relying on or limited by? |
| Design / UX references | Wireframes, mockups, flows |
| Timeline and milestones | When are the key phases due? |
| Open questions | What is still undecided? |

## Characteristics of a good PRD

- **Problem-first**: starts from the user need, not from a solution
- **Specific and testable**: requirements can be verified as met or not met
- **Prioritised**: distinguishes must-haves from nice-to-haves (e.g. MoSCoW: Must, Should, Could, Won't)
- **Concise**: short enough that people actually read it
- **Living**: updated as decisions are made and things are learned

## PRD vs. related documents

- **MRD (Market Requirements Document)**: the market opportunity and customer needs; comes before the PRD
- **BRD (Business Requirements Document)**: the business objectives and justification
- **Technical / design spec**: *how* the requirements will be implemented, written by engineering
- **User stories / backlog**: the PRD broken down into deliverable units of work

## In agile teams

Traditional PRDs were long, fixed specifications written up front. Agile teams tend to use a lightweight version, often one page, that captures the problem, goals, and key requirements, and evolves alongside the backlog rather than being signed off once.

---
Hub:: [[📇 Product Requirements Documents]]