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.
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.