PRDs, PR/FAQs and specs

Misalignment is expensive. A team that "kind of agrees" on a feature discovers the disagreement in code review, QA, or after launch. A PRD and its cousins exist to force clarity before that happens: what problem we are solving, for whom, what success looks like, and what we are explicitly not doing.

The right size depends on the bet: a one-pager for a small experiment; a PR/FAQ for a new product line; a living PRD for a multi-squad feature. Product owns the problem and the observable behavior. Engineering owns the implementation design. Mixing those too early locks the wrong decisions.

A PRD earns its keep when someone new can read it and answer: what problem, for whom, what does done look like, what must not break, and what are we deliberately skipping?

Write non-goals and metrics first. If you cannot, you are not ready to spec. Prefer observable behavior over adjectives: "Issues list p95 < 300 ms" beats "the page should feel snappy." Put edge cases in the doc — empty states, permissions, retries, a down dependency, migration — so every engineer does not invent a different policy.

The cost of under-documenting is rework and political thrash. The cost of over-documenting is theater. A bugfix needs no PRD; a new product line needs a press release before a field list. After review, publish a one-line changelog of decisions so old comments do not sneak back in as requirements.

Concepts in this section

Step	Concept	What it answers
1	Writing a PRD	Which sections, and when you need a doc at all
2	Requirements vs specs	Who owns behavior vs implementation
3	PR/FAQ	When to write the press release first
4	Acceptance criteria	How P0s become testable, including edge cases
5	Living PRDs	Status, changelog, one home, pairing with design docs

In interviews, narrate problem → users → goals → non-goals → requirements → risks. That is a verbal PRD. Mention acceptance criteria for one tricky edge case. Interviewers rarely want a novel; they want structured clarity under time pressure.

Common mistakes

Solution in the problem statement. Rewrite until the first paragraph names who hurts.
Empty non-goals and metrics that are ship dates.
PRD as API spec, or a ticket as a new product line.
Stale "approved" docs with no changelog of decisions.

Key takeaways

PRDs align teams on problem, users, metrics, non-goals and requirements before code.
Non-goals and open questions are as important as the feature list.
Amazon PR/FAQ writes the customer press release first to kill weak ideas early.
Acceptance criteria and edge cases make requirements testable. Right-size the doc; keep it living; pair with eng design docs for the how.