Confession from the product side: I didn’t understand tech debt until my engineering team showed me the velocity charts.
I thought “tech debt” was engineers being perfectionists about code quality. Like, “sure, it works, but it’s not elegant enough.”
I was so, so wrong.
The Wake-Up Call: Features Taking 3x Longer Than Planned
We planned a “simple” integration with Stripe. Engineering estimated 2 weeks. I thought, “Great, we’ll ship it mid-quarter.”
Six weeks later, it was still in development.
My initial reaction (I’m embarrassed to admit): “Why is engineering so slow?”
Then my engineering lead sat me down and showed me the data:
- The Stripe integration itself: 4 days of actual work
- Fixing our brittle payment service to support webhooks: 8 days
- Debugging race conditions in our order processing: 5 days
- Refactoring our database transactions (because they were locking up): 7 days
- Testing everything because our test coverage was 30%: 6 days
Total: 30 days. And only 4 were “new feature work.” The other 26? Tech debt.
That’s when I realized: tech debt isn’t a quality preference, it’s a velocity tax.
The Metric That Changed Everything: Time-to-First-Deploy
Michelle and Luis mentioned this, and I want to emphasize it from the product side because this metric convinced our leadership to invest in tech health.
We tracked how long it took new engineers to deploy their first feature:
- New services (clean architecture): 3-5 days
- Legacy monolith: 12-18 days
Think about what that means: We’re paying the same salary for someone who’s productive in 3 days vs 18 days. That’s a 6x difference in time-to-value.
When I showed this to our CFO, her response was: “Why are we hiring into the monolith at all?”
That question led to a 6-month migration project that I now co-own with engineering.
Now I Co-Own the Tech Debt Backlog
Here’s the shift that’s made the biggest difference: tech debt is no longer “engineering’s problem.”
I attend tech health sprint planning. I help prioritize which debt to tackle based on roadmap impact. I advocate for tech health sprints when execs push for more features.
Why? Because I learned the hard way: deferred tech debt becomes delayed features.
The ROI Framework in Practice
Michelle’s framework—“tech debt competes on ROI, not guilt”—is exactly how we work now.
Every quarter, we have a “debt vs features” roadmap conversation. Engineering brings 5-7 tech health initiatives. Each one answers:
- What does this unblock? (specific features or integrations)
- What does this accelerate? (velocity improvements, onboarding time, etc.)
- What does this prevent? (incidents, outages, customer escalations)
Then we stack rank everything—features and debt—based on business impact.
Some quarters, debt wins. Like Q4 last year, our #1 priority was migrating off a legacy auth service because it was blocking enterprise deals worth $3M ARR.
Some quarters, debt is lighter. Like this quarter, where we’re in growth mode and our tech foundation is solid.
The key: it’s a conversation, not a negotiation. We’re not debating whether to pay down debt—we’re deciding which debt has the highest ROI.
The IEEE 15% Guideline: Our Reality Is 10-20%
You asked if 15% is realistic. Our experience: it depends on phase.
- Post-MVP phase (validating product-market fit): 5-10% debt work, mostly critical bugs. We’re optimizing for learning speed.
- Growth phase (scaling the product): 15-20% debt work. We’re paying down shortcuts and building for scale.
- Mature phase (optimizing and expanding): 10-15% debt work. We’re in maintenance mode with occasional architectural shifts.
The mistake I used to make: treating every phase the same. Early on, I pushed for features at 100% capacity even when we were scaling. That’s how you end up with Maya’s velocity death spiral.
Now I ask engineering: “What phase are we in, and what’s the right debt allocation for this phase?”
A Question I Now Ask During Planning: “What’s the Debt Cost of This Feature?”
This has become my favorite question in sprint planning.
Before we commit to a feature, I ask: “What tech debt does this create, and when will we pay it down?”
Sometimes the answer is: “None, we’re building on clean architecture.”
Sometimes it’s: “This is a shortcut for validation, we’ll refactor in Q2.”
Sometimes it’s: “This feature requires architectural changes first, or we’ll create massive debt.”
That last one used to frustrate me. Now I understand: if we skip the architecture work, the feature will take 3x longer anyway. Better to do it right upfront.
Example: Last quarter we wanted to add real-time notifications. Engineering said, “We need to add a message queue first, or this will be brittle and slow.”
Old me: “Can we ship the feature now and add the queue later?”
New me: “What’s the timeline difference between doing it right vs doing it fast?”
Engineering: “Right way: 4 weeks. Fast way: 2 weeks now, then 6 weeks of firefighting and migration later.”
We did the 4-week version. It shipped cleanly, scaled beautifully, and unblocked three other features that needed the message queue.
Investing in architecture isn’t slower. It’s faster in aggregate.
Challenge to Other Product Managers
If your engineering team is saying they’re too slow, look at the tech debt percentage.
If they’re spending 40%+ of time on debt work, you don’t have a productivity problem. You have a debt accumulation problem.
And the solution isn’t “work harder.” It’s “invest in paying down debt so future work goes faster.”
Our velocity doubled after we did a 6-week tech health sprint to refactor our core services. Doubled. That’s not an exaggeration.
Now when engineering asks for tech health time, I don’t push back. I ask: “What velocity improvement will this unlock?”
Because sustainable 85% with good architecture is way faster than unsustainable 100% with brittle code.
Maya’s Question: Prevention vs Management
Maya asked if structured management prevents debt accumulation or just manages it.
From the product side, I think the answer is: both, but you need to be intentional.
Luis’s tech health sprints manage existing debt—they carve out time to pay down what’s already there.
But what prevents new debt? That’s the upfront architectural work. The “let’s add the message queue before we build 5 features that need it” decision.
We track both:
- Reactive debt work (fixing what’s broken): This should decrease over time if you’re doing it right
- Proactive architecture work (building foundations): This should be consistent, 5-10% every quarter
If all your tech health time is reactive firefighting, you’re managing debt but not preventing it.
If you’re investing in architecture upfront, you’re preventing the 42% tax from ever happening.
Final Thought: How We Align Product + Engineering
The best change we made: shared metrics.
We both track:
- Feature delivery velocity (product cares)
- Tech debt percentage (engineering cares)
- Time-to-first-deploy (both care)
- Incident rate (both care)
When both sides own both metrics, the conversation changes from “engineering needs to go faster” to “we need to invest in foundations so we can go faster together.”
Tech debt isn’t an engineering problem. It’s a business problem that requires product + engineering alignment to solve.
And once you have that alignment, the ROI is incredible.