Engineers usually know where the technical debt is. They live with it every day. What they often struggle with is getting time to fix it, because it competes with features that leadership can see and customers have asked for.
Product managers sit right in the middle of that tension. For a long time I treated technical debt as engineering's problem that occasionally needed a sprint. That was a mistake. Debt affects how fast the team ships, how often things break, and how much new work costs. Those are product problems.
Understand what the debt is costing
"We need to refactor the payment module" is hard to prioritise. "Every change to payments takes twice as long as it should and we've had three incidents from it this quarter" is easier.
When engineers raise debt, I ask:
- What does it slow down, and by how much roughly?
- How often does it cause bugs or incidents?
- Is it getting worse over time?
- What would we be able to do after fixing it that we can't do now?
Martin Fowler's technical debt quadrant is a useful way to think about where debt came from, whether it was a deliberate shortcut or something the team only understood later. 1 It helps take the blame out of the conversation.
Make it visible
| Debt item | What it slows down | Risk if ignored | Rough effort |
|---|---|---|---|
| Old playback library on TV apps | Every TV feature | Harder platform updates, more failures | Large |
| Duplicate checkout logic across platforms | Payment changes | Inconsistent behaviour, bugs | Medium |
| Missing automated tests on booking flow | Every release | Late-found regressions | Medium |
| Hard-coded config for regions | Launching in new markets | Slow expansion | Small |
These examples are illustrative. The point is that once debt is written down in terms of what it affects, it can sit on the same list as features and be compared honestly.
Reserve capacity, then adjust
A common approach is reserving a regular share of each sprint for debt and maintenance. I like this because it stops debt work from always losing to features. The exact share depends on the state of the codebase and the pressure on the team. It should be agreed with engineering and adjusted over time.
For bigger items, I'd plan them like any other roadmap item, with a clear reason and an expected outcome. "Replace the playback library so we can support the new TV platforms and reduce play failures" is a roadmap item, not a hidden chore.
Tie debt to features where you can
Some of the best opportunities come when a feature touches an area with heavy debt. If you're going to work in that code anyway, it's often cheaper to clean it up at the same time.
When estimating a feature, I'd ask engineering what it would cost with and without the related cleanup. Sometimes the cleanup adds a bit now and saves a lot later.
Don't let it become a dumping ground
"Tech debt" can also become a label for anything engineers would like to rebuild. Not all of it is equally important. Apply the same questions you'd apply to features: what's the impact, what's the evidence, what's the cost of waiting?
This is where something like RICE or a simpler version can help. It puts debt and features on the same scale, even if the scores are rough. My prioritization frameworks comparison covers other options.
Show the result
When the team pays down a piece of debt, share what changed. Faster releases, fewer incidents, a feature that's now possible. That makes the next debt conversation much easier, because leadership has seen it pay off.
A team that never has time for debt eventually has very little time for anything, because every change gets slower. Treating it as part of the product is how you avoid getting there.