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. 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). It is excellent for understanding the impact of not addressing technical debt promptly.

Second, I could have mentioned Martin Fowler's Technical Debt Quadrant. It is an effective way to engage with engineering teams, mainly when used alongside a 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