design shaping · the product decision record
The Product Decision Record
Not every decision is architectural. Some are product decisions — questions about behaviour, scope, or priority that need a written answer so the next person who encounters the question finds it resolved rather than open. The PDR is lighter than an ADR: the question, the answer, what was rejected and why, the date. It lives in Confluence, linked from the relevant Epic or story.
PDR · Exam Grading
Rubric-based marking is deferred to release 2
Question Should release 1 support rubric-based marking for open-answer questions, or only free-score marking?
Decision Release 1 supports free-score only. Gal enters a number; no rubric template is available.
Rejected Include rubric in R1: adds 3 wireframe states and a schema extension. The walking skeleton doesn't need it — Gal can grade without rubrics, just not as consistently.
Date Decided 18 April 2026 · Trio aligned
Without this record, the rubric question will resurface in amigos, in code review, and in the client conversation — each time consuming 20 minutes of re-reasoning. With it, the answer is found in 30 seconds.
The PDR is the product-side sibling of the ADR. ADRs constrain the code — schema changes, API contracts, retry strategies. PDRs constrain the scope — what is in this release, what is deferred, what is rejected. Both are written before the work is built. Both prevent the rejected option from returning as a "new idea" two sprints later. And both survive the conversation: the decision is found in Confluence, not reconstructed from memory.