You Pitched a New Feature. You Should Have Pitched Paying Down Tech Debt.

The roadmap meeting was going well. You presented the mockups for the new AI-powered reporting dashboard. It was slick. Stakeholders were nodding. Then your engineering lead unmuted. "This is great," she said, "but it builds on the old analytics service. We're already seeing performance issues there. This will make it worse."

You acknowledged the concern, added a "technical risks" bullet to your slide, and moved on. The feature was approved. But the warning echoed. You just sold a beautiful new top floor for a house with a creaky foundation.

This is the product manager's trap. We are incentivized to deliver new, shiny, marketable value. We pitch features. We build roadmaps full of them. But our most important job isn't just adding more; it's ensuring the product can sustain value over time. And that often means tackling the invisible enemy: technical debt.

Tech Debt Isn't Just 'Bad Code'

When engineers talk about tech debt, stakeholders often hear a vague, self-serving request to "refactor" or "clean things up." They hear a delay with no customer benefit.

It’s your job to translate.

Technical debt isn’t just messy code. It's the accumulated friction that slows everything down.

• It’s why a "simple text change" requires a full week of testing.
• It’s why the same bug keeps reappearing after you've "fixed" it three times.
• It's why your team can’t give you a confident estimate for a new project.
• It’s the ceiling on your team’s velocity and your product’s potential.

Ignoring it is like ignoring rust on a bridge. For a while, traffic flows just fine. But one day, it doesn't.

Stop Asking. Start Making a Business Case.

Walking into a room and saying, "Engineering wants to spend a sprint paying down tech debt," is a losing strategy. You've framed it as a cost center. You've pitted engineering’s needs against the business's desires.

You need to reframe the conversation entirely. Don't pitch a cost. Pitch an investment with a clear return.

1. Quantify the Pain in Dollars and Cents

Your stakeholders think in terms of resources, revenue, and risk. Use their language. Partner with your engineering manager to gather the data.

• Time spent on bugs: "Our team spent 35 hours last sprint fixing bugs directly related to our outdated payment processor. That’s nearly a full week of one engineer's salary. Over a quarter, we're burning $30,000 just to keep this one system limping along."
• Slowed velocity: "Three sprints ago, our story point average was 25. Now it's 18. This isn't because the team is working less; it's because every new story requires navigating this complex legacy code. We're moving 28% slower than we were last quarter."
• Direct customer impact: "Our number one complaint to customer support is page load speed. We've traced 60% of these complaints to the same three services. Our data shows customers who experience a load time over four seconds are twice as likely to churn in their first month."
• Opportunity cost: "The 'social login' feature on the roadmap is estimated at six weeks. If we first spend two weeks overhauling our authentication service, we can build it in two weeks instead of six. We get to market a month faster and unblock future personalization work."

Suddenly, you’re not talking about code. You’re talking about money, speed, and customer retention.

2. Propose a Plan, Not a Vague Problem

Don't just present the problem. Present the solution as a clear, scoped, and time-boxed project. Treat it like any other feature on your roadmap.

Bad: "We need to address tech debt in Q3."

Good: "We propose a project called 'Checkout V2.' It will take one sprint with four engineers. The goal is to replace our payment processor integration. We will measure success by a 50% reduction in payment-related support tickets and a 1-second improvement in checkout page load time."

This gives stakeholders something concrete to evaluate. It has a name, a timeline, a team, and success metrics. It feels like a strategic investment, not a black hole of engineering time.

3. Make It a Fixed Part of Your Process

One-off projects are great for tackling major debt, but the best long-term strategy is prevention. Work with your engineering lead to allocate a fixed percentage of every sprint—usually 15-20%—to "health and maintenance."

This isn't for new features. It's for small refactors, upgrading libraries, improving monitoring, and fixing nagging bugs.

Frame it as preventative maintenance. You change the oil in your car not because it’s broken, but so it doesn't break. This is the same principle. This small, consistent investment ensures your team's velocity doesn't slowly degrade over time. It protects your ability to ship those shiny features in the future.

Your job is to manage the product as a whole system. That includes the parts customers don't see. The most impactful work you can do this quarter might not be a flashy new feature. It might be fixing the foundation so you can keep building for years to come.