> ## Content Index
> Fetch the complete content index at: https://madewithlove.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# A framework to deal with technical debt
- URL: https://madewithlove.com/blog/a-framework-to-deal-with-technical-debt/
- Published: 2024-01-12T09:29:04.000Z
- Updated: 2024-07-16T08:36:59.000Z
- Description: Are there any specific product management framseworks to deal with technical debt?
- Author: Andreas Creten
- Tags: Engineering, Code quality, Documentation, Processes, Technical debt

Last November, I gave my talk, *Transforming Legacy into Success,* at a product management conference. In my talk, I cover many (practical) techniques one can apply to dealing with [technical debt](https://madewithlove.com/blog/on-technical-debt-what-is-it-how-is-it-created-how-to-avoid-it-and-how-to-fix-it/). At the end of my talk, someone asked if I knew of **specific product management frameworks to deal with technical debt**.

I realise I was not happy with the answer I gave them. As far as I recall, I mentioned integrating technical debt into your product roadmap by allocating specific capacity (aka the ratio). Besides that, I stressed the importance of talking with your engineering team regularly.

It still boggles me that this was the only thing I could come up with. It does make sense, but there are a couple of other frameworks one can use.

The first one I want to highlight is the [Cost of Delay divided by Duration (CD3)](https://www.prodpad.com/glossary/cost-of-delay/). It is excellent for understanding the impact of not addressing technical debt promptly.

Second, I could have mentioned [Martin Fowler's Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html). It is an effective way to engage with engineering teams, mainly when used alongside a [technical debt register](https://blog.logrocket.com/product-management/how-to-use-technical-debt-register).

Ultimately, it still comes down to what I mentioned in my answer. Theories and frameworks are invaluable, but the crux of managing technical debt lies in listening to your developers and approaching each situation pragmatically. A complete rewrite or starting from scratch is rarely the answer. Instead, it's about finding a balance in the day-to-day reality of managing technical debt.

---

**Also read**: [A founders guide to technical debt](https://madewithlove.com/blog/understanding-and-managing-technical-debt-and-legacy-code-a-guide-for-founders/)