Write the PRD as a Decision, Not a Specification

There are two ways to write a product requirements document. The first reads like a recipe: here are the screens, here are the fields, here are the states. The second reads like a court ruling: here was the question, here are the options we considered, here is the option we chose, here is what we are not doing and why.

Most teams write the first kind. Most teams should write the second kind. The recipe version is faster to produce and feels more 'complete' on a Monday morning. The decision version is harder to produce but compounds across the life of the product. Three years later, the recipe is a museum piece. The decision is still the document everyone references when the same argument resurfaces.

A specification-style PRD optimizes for execution. It tells engineering what to build, designers what to draw, and QA what to test. This sounds good. But it has a hidden cost: it never records the reasoning that produced the spec.

Six months later, someone joins the team and asks 'why do we do it this way?' The answer is in a Slack thread that has since been archived, or in the memory of a person who has left, or it never existed in the first place — the decision was made in a meeting and the PRD just captured the output. The team is now executing a decision nobody alive can defend.

A spec without reasoning is a museum exhibit. A decision with reasoning is a tool.

Structure the document around the choice, not the build.

- **The question.** What were we deciding? One sentence. 'Should X be a configurable setting or a system default?' or 'Should we batch process at write time or at read time?' - **The options.** Three at most. Each one a one-paragraph description. - **The trade-offs.** A table or list mapping each option to its costs and benefits. Be honest. The losing option should have real merits. - **The decision.** One sentence. Not three paragraphs. Not a 'recommended approach.' A decision. - **The reasoning.** Two to four bullet points. Why this option and not the others. - **The reversibility.** How hard would it be to reverse this in six months? A line saying 'cheap to reverse' or 'multi-quarter migration' changes how seriously stakeholders treat the choice. - **Non-goals.** What this decision deliberately excludes. We covered this in another essay. It's the most important section.

The spec — what to actually build — appears AFTER all of this, not before. The spec is a consequence of the decision. The spec is the easy part.

Three years from now, you will face the same argument again. A new stakeholder will propose Option B. The team will look around and not remember why Option B was rejected the first time. With a recipe-PRD, the conversation starts from zero. With a decision-PRD, you open the original document, read three paragraphs, and the question is resolved in under five minutes — or, more usefully, you discover that the original reasoning no longer applies because the world changed, and you have a clean way to re-evaluate.

Decision-PRDs are the closest thing a product team has to institutional memory.

Two practical moves. First, change your template. The current template likely has 'Problem,' 'Solution,' 'Requirements,' and 'Success Metrics.' Replace 'Solution' with 'Decision' and add 'Options considered.' This single change forces the author to enumerate alternatives before declaring an answer.

Second, make decision-PRDs reviewable. Have the reviewer's job be 'find the option I would have picked instead, and explain why I didn't.' If the reviewer can't reconstruct the trade-off, the PRD failed. Send it back.

Doing this for a few cycles changes how the team writes. The bar moves from 'can I describe what to build' to 'can I describe the choice I'm making.' That second skill is the real product skill. The first is just typing.

The reviewer's job is to find the option you didn't pick. If they can't, your PRD failed.