Product Definition · master area

Product Decision Records (PDR)

Scope or priority decisions with rejected options. The product analogue of an ADR. Records the why of trade-offs that future cycles must see — and the artefact that survives the PO leaving.

Owners: PO Phase it lives in: What We Build (Volume III) The corpus principle this enacts: Every artifact in the chain is a hedge against the departure of the person who created it.

Where it lives in the chain

• What We Build · Design Shaping · the Product Decision Record — the canon

How to do this

A PDR has six sections, parallel to the ADR shape:

1. Title — the decision named in one line. "PDR-014: Defer multi-section support to release 2."
2. Context — what made this decision necessary. "Multi-section adds 40% to release-1 scope; the prediction still tests with single-section only."
3. Decision — what we're doing. "Single-section only in release 1. Multi-section in release 2."
4. Rejected options — what we considered and rejected, with reasons. "Option B: ship both with a flag. Rejected because the flag's complexity outweighs the value of a single test cycle."
5. Consequences — what this commits us to. "Schools with multi-section will hold off until release 2 (ETA Q3). CS handoff explicitly notes this exclusion."
6. Date and signatories — when, and who agreed.

What good practice looks like

PDRs are written for decisions that the team anticipates being asked about three months later — "why didn't we ship multi-section in release 1?" When that question comes, the PDR is the answer. Three lines from a Slack thread is not.

A PDR is not written for every decision. Tiny scope nudges happen at standups; broad strategy decisions live in the Initiative Brief. PDRs sit at the middle altitude — scope-level decisions that will outlast the cycle's memory.

The discipline mirrors ADRs:

• Never write a PDR with only one option considered. "We decided X" without alternatives is not a decision record; it's a notification.
• Never write "Decision: TBD". If undecided, mark Proposed and state what information would resolve it.

Three years later, when a new PO inherits the product, the PDRs explain the why of the current shape. Without them, the new PO inherits a product whose constraints are invisible — and the next cycle relitigates decisions that were already settled, in the absence of the evidence that settled them.

Related crafts

• ADR — the technical-side counterpart
• Slicing & Prioritization — what PDRs often record
• Epic Naming & Kickoff — where PDRs often surface