How should Product and Engineering record important decisions?
Record a consequential Product or Engineering decision in a short note that names the problem, options considered, evidence and assumptions, decision owner, rationale, consequences and review trigger. Keep the record close to the work and link a later change to the earlier decision. Routine reversible choices need less ceremony than costly or hard-to-reverse ones.
Key takeaways
- Record rationale when a decision will be hard to reconstruct.
- Make the accountable decision owner visible.
- Capture uncertainty and the condition that would change the decision.
- Supersede an old record when evidence changes.
Six months after a feature launches, another team asks why it uses a costly integration. The people who made the choice have moved on. A short decision record can preserve the trade-off and the conditions under which it should be revisited.
Choose decisions worth retaining
A useful decision record is a compact account of a choice likely to affect future work. Examples include a significant architecture constraint, a product scope trade-off or a decision to accept operational risk. A routine naming choice rarely needs one. Product owns value and priority decisions; Engineering owns technical approach and risk. Joint discussion should leave the accountable owner clear.
Use existing records where they fit
Teams often rely on meeting notes, tickets or architecture decision records. These can work if they are findable and explain why the decision was made. AWS guidance on ADRs describes recording architectural context, decision and consequences, and superseding accepted records when a later choice changes direction. Extending that pattern to Product decisions is a practical recommendation, not a formal ADR standard.
Write the smallest useful record
State the decision date, owner, problem, relevant evidence, options, reason for the choice and expected consequence. Mark assumptions plainly, especially when user evidence or technical tests are incomplete. Link to the feature or service where people will encounter the result. Invite relevant Product, Engineering, design or operations colleagues to challenge the record before it is accepted when their responsibilities are affected.
Review without rewriting history
Set a trigger such as a changed user need, a reliability threshold or an expiring contract. When that trigger occurs, write a new decision and point back to the old one. This preserves what was reasonable at the time and makes the change legible. Keep sensitive details in an approved location and avoid turning the record into a substitute for delivery work or a long approval chain.
Example
Hypothetically, a payments team chooses to reuse an existing identity service for a new merchant flow. Product records the intended onboarding outcome and why a custom flow was deferred. Engineering records the interface constraint, fallback and security review. They set a review trigger if onboarding failures rise or the shared service changes. A later team can see the original reasoning and make a new decision with fresh evidence.
FAQs
-
Should every backlog item have a decision record?
No. Use one when a choice has lasting consequences or would be difficult to explain later.
-
Can Product and Engineering share one record?
Yes, provided the record identifies who owns each substantive decision and who was consulted.
-
What if the decision proves wrong?
Write a new record with the new evidence and link it to the earlier choice; avoid erasing the original rationale.
Is the way you deliver fit for a world of continuous change?
Find out where change flows — and where it slows.
