If you've worked with software engineers, you would have come across the term 'tech debt'. This is essentially poor system architecture that were taken before at an earlier stage of development that needs to be addressed now to make progress in a way that doesn't lead to issues.

For example, when designing an e-commerce website that accepts orders (like Amazon), one might design it to handle up to a hundred thousand users at a time. But, if the product does very well and gets a lot more users than that, it needs to be re-architected to handle the larger scale.

Then, as a Product Manager, it is constantly a trade-off decision to be made as to what kind of a tech debt to take on to make short-term progress before investing in reducing the tech debt. After all, designing the most scalable and reliable architecture that never fails might be impractically expensive and unnecessary until that scale is reached.

Similarly, we constantly make decisions in our lives that follow this phenomenon.

We make decisions with a certain time horizon in mind, and once that time horizon is passed, we might realize that we need to invest in reversing the consequences of the decisions we made in the past. I call this decision debt.

Just like tech debt, it might be impractically expensive and unnecessary to make decisions with a hundred-year horizon. But, knowing what horizon we are making the decisions in will remove the surprise when things start to break at that horizon.

Knowing the horizon helps us be prepared for this breakage, and hopefully take preventive action.