Technical debt has an interest rate. Measure it.

"This module is a mess" is true, and also useless in a planning meeting. Every codebase has messy modules. The question a product manager is really asking is: what does it cost us to leave it alone?

Principal vs. interest

The principal is the effort to fix the thing. The interest is what you pay every week for not fixing it: slower changes, extra review rounds, incidents, onboarding time. Teams love to argue about principal. Interest is the number that actually matters.

A cheap way to estimate interest

For one month, every time someone touches a known debt area, they add a line to a shared sheet:

date, area, task, extra_hours, reason
2026-09-03, billing/export, add CSV column, 3, no tests, manual QA
2026-09-11, billing/export, fix rounding bug, 5, duplicated logic in 2 places

No one estimates perfectly, and that's fine. After four weeks you have a rough monthly interest per area, and the conversation changes from opinions to arithmetic:

Fixing billing/export costs about two weeks. We are currently paying roughly a week per month to keep it alive. It pays back in two months.

What not to do

• Don't build tooling for this before the spreadsheet proves useful.
• Don't track every file — pick the five areas people already complain about.
• Don't turn the sheet into a performance metric, or the numbers will stop being honest.

The goal isn't precision. The goal is to make the cheapest debt to fix also the most visible one.