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.

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.

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.

What a PRD looks like

A one-page skeleton most teams can start from:

# Bulk export for admins
Problem: Admins export users one page at a time and file support tickets to get the rest.
Goals: Admins can export all users as CSV in one action.
Success metric: Fewer export-related support tickets (target set from current volume).
Requirements: CSV only; includes role and last-login; runs in the background.
Non-goals: Scheduled exports. Custom columns.
Constraints: Must respect existing row-level permissions.

Every line under Non-goals is a decision, and it will be tested.

PRD vs decision log

A PRD is written once, up front. A decision log is appended to as the work goes, one entry per decision, with an owner and a date. The PRD says what you planned; the log says what you changed and why. A ready-made format is in the decision log template.

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, Jira, Confluence, Google Docs, and GitHub PRs, asks the decision's owner to approve each in one click, and checks pull requests against the approved record, flagging conflicts (it warns by default; blocking is opt-in). That way "does what shipped match what we decided?" has an answer. See how it works, the longer answer on knowing whether engineering built what the PRD said, and Lockstep for product teams.