Stripe’s 2018 Developer Coefficient study surveyed developers across 300+ companies and found that engineers spend 33% of their working hours dealing with technical debt. Not building features. Not shipping value. Maintaining, patching, and working around code that somebody decided was good enough at the time.
That number should bother every product manager. But most PMs treat technical debt as an engineering problem, something the tech lead brings up in sprint planning that competes with “real” work on the roadmap. This framing is wrong, and it quietly destroys execution velocity.
The Tax You’re Already Paying
Technical debt compounds the same way financial debt does. Deloitte’s 2026 Global Technology Leadership Study, drawing on insights from more than 660 CIOs, CTOs, and CISOs, found that technical debt consumes between 21% and 40% of total IT spending across organizations. For every dollar a company invests in technology, somewhere between 21 and 40 cents goes toward maintaining decisions somebody made years ago.
For a product manager, this shows up in two measurable ways.
Slower cycle times. Features that should take two sprints take four. The engineers aren’t slower; they’re navigating a codebase where every change requires touching three other systems that nobody planned to touch. Velocity charts flatten, and the instinct is to push harder on the team instead of examining what’s dragging them down.
Unpredictable delivery. When engineers can’t estimate reliably, the root cause is often hidden complexity in the codebase. A senior developer on a team I coached through a fractional COO engagement told me they spent 40% of a quarter rebuilding an integration layer that had been “temporary” for three years. Every estimate they gave during those months was wrong, and the PM kept blaming estimation discipline instead of asking what was making estimates unreliable.
Why Product Managers Avoid This Conversation
I’ve watched this pattern repeat across every product team I’ve worked with: the engineering lead raises technical debt in planning. The PM listens politely, then steers the conversation back to features. The debt item lands on the backlog where it sinks below the fold and never surfaces again.
PMs dodge this conversation for three reasons.
First, technical debt is hard to translate into customer value. Stakeholders want to hear about features, not refactoring. A PM who walks into a quarterly business review saying “we need to spend six weeks on database migration” without connecting it to business outcomes will lose credibility.
Second, the payoff is invisible when it works. Nobody celebrates the outage that didn’t happen, the deploy that went smoothly, or the estimate that was finally accurate. Debt reduction doesn’t generate launch announcements.
Third, most PMs lack the technical depth to evaluate which debt items matter. When an engineer says “we need to refactor the auth module,” the PM has no framework for deciding whether that’s a week of work or a quarter, whether it’s urgent or aspirational.
A Framework That Cuts Through the Ambiguity
Martin Fowler’s Technical Debt Quadrant classifies debt along two axes: deliberate versus inadvertent, and reckless versus prudent. The quadrant that matters most for product managers is prudent and deliberate, the debt you chose to take on intentionally, usually to validate an idea or hit a market window.
This is the debt you own. You made the tradeoff. You should also own the repayment plan.
Three questions every PM should ask in sprint planning:
1. What debt did we take on last quarter, and what’s the carrying cost?
“Carrying cost” means the ongoing penalty: slower deploys, more incidents, longer onboarding for new engineers. If your team can’t quantify this, that’s a signal, not an excuse to skip the question.
2. Which debt items are blocking the next quarter’s roadmap?
This reframes debt from “engineering wants to clean up code” to “this codebase constraint prevents us from shipping what we planned.” When a feature requires touching a system that’s fragile, the debt isn’t optional. It’s a prerequisite.
3. What’s our allocation ratio this sprint?
Shopify’s engineering team uses what they call the 25% rule: roughly 25% of engineering capacity goes to technical debt. They split it between daily refactoring (about 10% of individual time spent improving code they’re already working in), monthly cleanup projects, and larger quarterly efforts. The specific number matters less than having one at all. A team that treats debt allocation as zero every sprint will eventually hit a wall where feature development slows to a crawl.
Making Debt Visible to Stakeholders
The hardest part isn’t deciding to pay down debt. It’s getting organizational support for it.
In a fractional COO engagement I ran for a SaaS company, the engineering team had been requesting “tech debt sprints” for over a year. Leadership kept saying no. The turning point came when we reframed the request. Instead of “we need to refactor,” we presented a specific metric: deployments had slowed from eight per week to two per week over 18 months. Each failed deployment cost the team half a day of debugging. We projected the trajectory and showed that within six months, the team would spend more time deploying than developing.
That got approval. Not because leadership suddenly cared about code quality, but because they understood the business cost.
The same approach works for PMs presenting to stakeholders. Stop saying “technical debt.” Start saying:
- “Our deployment frequency has dropped by X% this quarter.”
- “Feature Y requires Z weeks of prerequisite infrastructure work before we can start.”
- “Engineering estimates are averaging 40% over their original projections because of codebase complexity.”
These are product metrics, not engineering jargon. They belong in your stakeholder updates just as much as feature progress does.
The Execution Payoff
Teams that treat technical debt as a product decision, not an engineering complaint, ship more reliably. Their estimates get tighter. Their incident counts drop. Their engineers stay longer because they aren’t grinding through the same brittle code month after month.
The PM’s job in execution isn’t just to push features through a pipeline. It’s to maintain the health of that pipeline. Technical debt is where pipeline health lives.
If you’re running a delivery confidence check each sprint and technical debt never comes up, you’re asking the wrong questions. If your backlog has zero debt items prioritized in the top 20, your team’s velocity problems aren’t going away.
Own the tradeoff. Own the repayment. That’s what execution leadership looks like.