Product Requirements Document (PRD) is a product-management artifact that defines what a product or feature must do and why — the 📝problem, the intended users, the requirements, and the 📝success criteria — before a team builds it.

A PRD typically covers a problem statement, target users, goals and explicit non-goals, functional requirements, constraints, and measurable success metrics. It deliberately describes the what and the why while leaving the how — architecture and implementation — to engineering design documents. The document serves as the shared contract between product, design, and engineering: disagreements surface in review of the PRD, where changing course costs a conversation, rather than mid-build, where it costs a rewrite.

Practice varies widely. Heavyweight PRDs descend from waterfall-era requirements engineering; agile teams often shrink the form to one-pagers or replace it with user stories and continuous discovery, and 📝Amazon's "working backwards" PR/FAQ is a well-known alternative that opens with the imagined press release instead of the requirements list. The form has recently found a second audience: AI coding agents consume PRD-shaped specs directly, and a precise statement of requirements up front is one of the more reliable ways to keep an autonomous build on target.