A PRD (Product Requirements Document) describes what a new product or major feature must achieve before design and development begin; Marty Cagan and Roman Pichler are its key proponents. It covers the problem statement, goals and success metrics, personas and use cases, functional and non-functional requirements, scope and out-of-scope, constraints and assumptions, and open questions. Cross-functional teams thus share one reference.

PRD

Details
Full Name

Product Requirements Document

Also known as

Product Spec, Feature Spec, Requirements Specification

Core Concepts:

Problem statement

Clear articulation of the problem to be solved and the target users

Goals and success metrics

Measurable outcomes that define what "done" looks like (KPIs, OKRs)

User personas and use cases

Who will use the product and what they are trying to accomplish

Functional requirements

What the system must do — features, behaviors, and capabilities

Non-functional requirements

Quality attributes — performance, security, scalability, accessibility

Scope and out-of-scope

Explicit boundaries to prevent scope creep and align stakeholders

Constraints and assumptions

Technical, business, regulatory, or timeline constraints

Open questions

Unresolved decisions or dependencies that must be tracked

Key Proponents

Marty Cagan ("Inspired"), Roman Pichler ("Strategize")

When to Use:

  • Before starting design or development of a new product or major feature

  • When aligning cross-functional teams (engineering, design, marketing, legal)

  • To provide a shared reference for scope negotiations and tradeoff decisions

  • When stakeholder sign-off or compliance documentation is required

  • As a living document updated throughout the product discovery process