Skip to content

Product Decision Records (PDRs)

PDRs answer “what do we choose to build / NOT build, and why?” (product / business). They are the product-side complement to ADRs (../decisions/), which answer “how do we build it?” (technical / architecture).

ADRPDR
QuestionHow do we build it?What do we build / not build?
AuthorityTech leadProduct owner
Lives indocs/decisions/docs/product-decisions/
Example”Ship Native AOT to protect IP""No SAML for the SMB tier”

Without a PDR, a decision like “we don’t do SAML for SMB” gets re-litigated every time a customer asks or a new dev suggests it. With a PDR, the answer is a link. This matters most once a team forms: it stops the same debate from happening 20 times.

  1. Copy ../templates/T10-pdr.md.
  2. Number sequentially: PDR-0001, PDR-0002, …
  3. Status: proposedaccepted → (deprecated | superseded).
  4. Append-only: never delete a PDR; supersede it with a newer one and link both ways.
PDRTitleStatus
PDR-0001Open-core split — public MIT SDK, private commercial Proaccepted

Candidate decisions to capture (need product-owner confirmation)

Section titled “Candidate decisions to capture (need product-owner confirmation)”

These came up during the 2026-06-21 workflow audit as likely product decisions, but they have not been explicitly ratified. Confirm with the product owner before writing each as an accepted PDR — do not assume:

  • Cloud/SaaS timing (self-host first vs hosted offering, and when).
  • Target segment scope (SMB vs mid-market vs enterprise) and what that excludes (e.g. SAML, on-prem HA).
  • Channel/feature prioritization that is deliberately out of the near-term roadmap.