Tech debt has a public relations problem. It is usually introduced to non-engineers as housekeeping — the software equivalent of tidying a garage. Framed that way, it will always lose to a feature, because tidying is never as urgent as shipping.
That framing is wrong, and product managers are the ones who can fix it.
What debt actually is
Debt is a decision, made at a specific moment, to accept a slower future in exchange for a faster present. Stated like that, it is obviously a product decision. Somebody chose the date. Somebody chose the scope. The engineer who took the shortcut was usually executing that choice, not making it.
Some debt is worth taking. Shipping in six weeks instead of six months can be the right call, and the shortcut that makes it possible is a legitimate trade. The failure is not in taking the debt — it is in taking it silently, so that nobody records what was borrowed or what the repayment costs.
The interest is paid in delivery speed
The clearest signal I know: watch how long a small change takes over time. A team that took three days to ship a minor change last year and takes two weeks now is paying interest. Nobody filed a ticket for it. It shows up as everything being a bit harder than it should be, and it compounds quietly.
By the time it is visible on a roadmap — as a large, unavoidable “platform work” epic — the cost of dealing with it has multiplied several times over.
What to do about it early
The phase where this is cheapest to handle is the one where it feels least necessary: the beginning.
- Write the debt down when you take it. Not in a code comment. In whatever list the product manager actually reads, with a note on what it will cost to unwind.
- Attach it to a trigger, not a date. “Refactor this when we add the second payment method” survives reprioritisation better than “refactor in Q3”.
- Budget a standing share of capacity. A fixed slice each cycle, spent without needing to be justified, avoids the negotiation that debt work always loses.
- Track delivery time as a metric you report. It converts an engineering complaint into a business number, which is the only form in which it will get attention.
Why the PM has to own it
Engineering can identify debt, estimate it and fix it. What engineering cannot do alone is decide it is worth more than the next feature — that is a prioritisation call, and prioritisation belongs to product.
Every time a product manager treats debt as somebody else’s concern, they are choosing to slow their own roadmap down. It just happens far enough in the future that the connection is easy to miss.
I talked through this in more detail in a video for product managers, aimed squarely at people who work with engineers without being one.