@fahadhasan
A practical approach to keeping product decisions understandable after a project has shipped.
Writing down the trade-offs
A decision is easier to understand when its context travels with it. The useful part of a technical note is often the reason a particular approach was chosen.
Start with the problem
Describe the behaviour that needs to change. Record the constraints that matter: the people using the product, the data involved and the systems already in place.
Compare the real alternatives
Write down the options that were seriously considered. Explain their practical costs and the evidence that favoured one of them. A short note with concrete examples is more useful than an exhaustive list of abstract possibilities.
Leave room for change
State what would cause the decision to be revisited. Future maintainers can then judge whether the original assumptions still hold.