Framing a trade-off and recording it in an ADR
A year later, nobody remembers why the team picked that architecture unless the decision was written down. The lesson helps a PM state a trade-off explicitly, scale the analysis to how reversible a choice is, and write an Architecture Decision Record the whole team can use.
Lesson objective
By the end of this lesson, you will be able to frame an architecture trade-off ("we favor X at the expense of Y"), judge whether a decision is reversible and therefore deserves more or less analysis, and write an ADR with context, options, decision, consequences and a review condition.
Topics covered
- ADR
- architecture decision record
- architecture trade-off
- reversible decision
In the glossary
Where it fits
Deciding and recording
How do you choose between two options, keep a record of the decision and deal with technical debt?
Lessons in this module
- Framing a trade-off and recording it in an ADR (this lesson)
- Technical debt, a product decision
What you will learn in this module
This lesson is part of the course Read and challenge a technical architecture
- Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
Related courses
- Product ManagementAdvancedRegular practice: you already use the tools or work on this topic.
Git for PMs: ship as a team without putting production at risk
3 hr 30 min
- Tech for PMsAll levelsNo prerequisites: accessible to everyone.
Explain how a web product works, from browser to server
2 hr 30 min
- Tech for PMsJuniorSome basics are useful: introductory knowledge of the topic.
Design and test an API integration as a PM
3 hr