Every PM eventually sits in this meeting. Engineering says the team needs a quarter to "pay down tech debt." Leadership hears "a quarter of nothing shipping." And you're in the middle, expected to referee a conversation where one side speaks in abstractions and the other in revenue.
Most PMs handle this badly in one of two directions. Either they wave it all through ("engineering knows best") and can't defend the roadmap gap, or they treat debt work as the flexible line item that always loses to features, and eighteen months later the team can't ship anything without breaking something else.
There's a better way, and it doesn't require you to read the code. It requires you to treat tech debt like any other product investment: understood, quantified where possible, and prioritized on its merits.
What Tech Debt Actually Is
The original metaphor (Ward Cunningham's) is precise: debt is what you take on when you ship something the fast way instead of the right way. Like financial debt, it's not automatically bad. Borrowing to hit a market window can be exactly correct. The problem is the interest: every future change in that area of the code costs more than it should, forever, until the principal is paid.
That framing gives you the two questions that matter for any piece of debt:
- •What's the interest rate? How much does this slow us down, how often, and is it getting worse?
- •Are we working in that area? Debt in code you never touch charges almost no interest. Debt in the code you change weekly compounds viciously.
Also worth knowing: not everything called tech debt is debt. The bucket usually contains real shortcuts, plus aging dependencies that became risky through no one's fault, plus architecture that was right for 10 customers and wrong for 10,000, plus code that's simply old and unloved. The responses differ, so ask which kind you're dealing with.
Translate Debt Into Product Language
Here's your highest-value move as PM: get debt out of moral language ("the code is bad, we feel guilty") and into consequence language. Debt matters to the business through exactly four channels:
- •Velocity: features in this area take 3x longer than they should. That's roadmap capacity being burned invisibly.
- •Reliability: this system causes incidents, and incidents cost customers, revenue, and on-call humans.
- •Risk: this unmaintained dependency or fragile system is a bad week waiting to happen (security, compliance, scaling cliffs).
- •People: nobody wants to work in this part of the codebase, and the engineers who understand it are the ones most likely to burn out or leave.
When engineering brings you a debt item, work with them to name its channel and rough size. "The billing code is a mess" becomes "every billing change takes three weeks instead of three days, and billing changes are on the roadmap all year." One of those sentences survives a leadership meeting. The other doesn't.
This translation is a partnership skill, and it runs both ways: you learn enough context to represent the problem, engineering learns to frame problems by consequence. Our guide on working with engineers covers building the trust that makes these conversations honest.
How to Prioritize It
Once debt is framed by consequence, it competes in the same prioritization conversation as everything else. Some structure that works in practice:
Keep a standing allocation
Most healthy teams reserve a fixed slice of capacity (commonly around 20%) for engineering health: debt, tooling, upgrades. The allocation approach beats the "big cleanup quarter" approach for the same reason regular maintenance beats engine replacement. It also removes the per-item political fight; the team owns the slice, and you own trusting them with it.
Piggyback aggressively
The cheapest time to pay down debt is when you're already working in that code. If Q3 roadmap includes billing features, Q3 is when billing debt gets attention, scoped into the project rather than competing with it. This is the practical payoff of the "are we working in that area?" question, and it's a scheduling decision that's literally yours: sequence the roadmap so feature work and debt work in the same area land together.
Save big-bang efforts for big-bang problems
Occasionally something genuinely needs a dedicated project: a migration, a rewrite of a core system, a scaling wall. Treat these like any major initiative: a written case (what it costs us now, what it unlocks, what happens if we wait a year), success criteria, and staged delivery if at all possible. Multi-quarter rewrites with no intermediate value delivered are where roadmaps go to die; push hard for increments.
Refuse the guilt-based queue
The worst prioritization signal is "this has been in the backlog forever and engineering keeps asking." Age is not impact. An old item with no articulable consequence loses to a new item with a clear one, debt or feature alike.
Defending the Work Upward
When leadership pushes back on debt investment ("can't we just ship features?"), your job is to make the invisible cost visible:
- •Show the trend, not the incident. "Deploy frequency has halved in a year" or "escaped bugs are up 40%" tells a story executives can act on. If engineering doesn't track these, even rough numbers help.
- •Use the capacity frame. "We're paying roughly a 30% tax on everything we build in this area. This project retires the tax" makes debt work sound like what it is: buying back roadmap.
- •Anchor to a business moment. "Before we sign enterprise customers on this system, it needs to survive their load" beats abstract quality appeals.
- •Report the wins. When last quarter's debt work makes this quarter's feature land in half the time, say so, loudly. Debt work has terrible PR by default because success looks like nothing happening. Fix the PR.
And a warning in the other direction: don't let debt become unquestionable. "It's tech debt" can be a place where pet projects hide. The consequence test applies to everyone. An engineering lead who can't say what a cleanup buys, in one of the four channels, hasn't finished the argument, and it's respectful, not hostile, to ask.
The Signals Worth Watching
You don't need engineering metrics mastery, but a few numbers tell you whether debt is winning:
- •Cycle time trend: are similar-sized things taking longer than they did a year ago?
- •Incident frequency and repeat offenders: is the same system on fire every month?
- •Estimate inflation: when everything in one area gets padded 2x "because that code is scary," the fear is data.
- •Team sentiment: ask directly in 1:1s: "where does it hurt to work?" Engineers know exactly where the debt is. They're rarely asked by someone who can act on it.
The Bottom Line
Tech debt is a portfolio of loans your product has taken out. Some were smart. Your job isn't to eliminate it (impossible, and not even desirable); it's to know the interest rates, pay down the expensive loans first, keep a standing budget for maintenance, and make the costs visible to the people who control investment.
PMs who can do this are conspicuously rare, and engineering teams remember them. It also comes up in interviews more than you'd think: "how do you balance tech debt against features" is a standard question, and "a fixed allocation, consequence-based prioritization, and piggybacking on roadmap work" is a standout answer.
Ready for a team that will appreciate it? Browse open product roles at productmanagerjobboard.com.