Term

Product Decision Record

Info

Originally written in French. Translated by AI — the meaning has been preserved, not the prose.

Short definition

A short document recording a cross-cutting product decision rule, with its context, the alternatives set aside, the consequences accepted and the conditions that could make it evolve. Abbreviated PDR.

Full definition

The phrase is modelled on software engineering's Architecture Decision Record, and it belongs to no established body of product methodology: it circulates by imitation of technical vocabulary rather than through a shared definition.

In the articles on this blog, the term designates an object delimited by three restrictions rather than by a template. Its altitude: it states what applies in a type of situation, never what should be built. Its rarity: a few entries a year, from five to twenty depending on the size of the organization. Its immutability: a validated PDR isn't rewritten; changing position produces a new PDR that replaces the old one, which stays in place.

Its usual form is a series of short sections — status, date, decision, context, alternatives considered, reasons for the choice, consequences, conditions for re-evaluation, decision-makers and people consulted. The exact template varies; what doesn't vary is the presence of the why and the absence of execution.

Usage in the field

The term comes into play in discussions about a product company's decision memory, about the distribution of artifacts between decision, specification, roadmap and backlog, and about the causes of repeated re-discussions with sales and support.

Synonyms and variants

"Product decision register", "decision log", "documented decision". In organizations that don't use the acronym, the thing sometimes exists under the names "doctrine note", "product principle" or "arbitration rule".

Not to be confused with

  • Architecture Decision RecordArchitecture Decision Record — the same gesture applied to a technical architecture choice; the PDR takes up its structure while moving the object towards the product rule.
  • PRDProduct Requirements Document, which describes what you want to build and with what expected behaviour; it can be constrained by a PDR, it doesn't replace one.
  • Roadmap — a view of intent over a given horizon, saying what the company is doing, preparing or refusing; it communicates a direction, where the PDR gives a rule applicable to unforeseen cases.
  • BacklogBacklog — the collective space of subjects ready to be worked on; it carries the action, the PDR carries the reason that authorizes or forbids the action.
  • Meeting minutes — a trace of what was said in a session; they record a sequence of events, the PDR records a rule detached from the session that produced it.

Examples

"In case of conflict, we favour the customer." — the minimal form of a PDR decision on a marketplace: no feature, but dozens of decisions influenced.

"The product is supported by default in French and English. Any other language requires a minimum threshold of signed annual revenue." — the usage on a recurring commercial question in a SaaS.

Ambiguities / debates

The word "record" carries the main ambiguity: it suggests a recording, therefore exhaustiveness. The usage retained here takes the reverse — the apparatus's value decreases with the number of entries.

Unsettled: the threshold of rarity. "A few a year" transposes badly from a ten-person structure to a multi-product group, and no criterion says at what volume the register stops being consultable.