PRD (Product Requirements Document)
A PRD is the document that describes what a product or feature should do and why: the requirements, scope, and constraints a team agrees on before building.
Updated
A Product Requirements Document (PRD) defines what a team is about to build and why. A good one covers the problem and evidence for it, goals and success metrics, the requirements themselves, explicit non-goals, and known constraints. The non-goals are usually the most valuable part: scope creep starts where the PRD went quiet.
PRD vs spec
The PRD is the what and why, owned by product. The spec is the how, owned by engineering. One PRD often spawns several specs. Both documents share the same failure mode, though; see spec drift.
Where PRDs fail: after shipping starts
A PRD is a snapshot of what the team believed on the day it was approved. Then building starts, and the real decisions begin: scope cut in a Slack thread, a requirement reversed in design review, an edge case settled in a PR comment. Each one quietly amends the PRD, and almost none of them are written back into it. Six weeks later the document describes a product that doesn't exist, and "is this in the PRD?" stops having a useful answer.
That was survivable when only humans read PRDs, because people ask around. It's worse now that AI agents read them as ground truth: an agent handed a stale PRD will build the cut feature back, confidently. That's decision drift with a document lending it authority.
Keeping the record live
The fix isn't writing better PRDs. It's capturing the decisions made after the PRD, in the places they actually happen. Lockstep captures those decisions from Slack, Notion, and Jira, puts a human approval on each, and checks pull requests against the approved record, so "does what shipped match what we decided?" has an answer. See how it works.
- What does PRD stand for?
- Product Requirements Document: the document that defines what a product or feature should do and why, agreed on before building starts.
- What's the difference between a PRD and a spec?
- The PRD says what to build and why: the problem, goals, and requirements. A spec says how: the technical design that satisfies them. The PRD is owned by product; the spec by engineering.
- Why do PRDs go out of date?
- Because deciding doesn't stop when the PRD ships. Scope gets cut in Slack, requirements change in design review, edge cases get settled in PR comments, and almost none of it flows back into the document.
- How do I know if what shipped matches the PRD?
- Usually you don't, until a demo or a customer surfaces the gap. Nothing structurally compares shipped behavior to the PRD. The practical fix is keeping a live record of post-PRD decisions and checking changes against it before they merge.
Related