In partnership with
Thank you to our sponsors who help support this newsletter:
Turn customer feedback into evidence that moves your product roadmap faster
For PMs who need buy-in fast: Enterpret turns raw feedback into crisp, evidence-backed stories.
Explore any topic across Zendesk, reviews, NPS, and social; quantify how many users are affected and why; and package insights with verbatim quotes stakeholders remember.
Product teams at companies like Canva, Notion and Perplexity use Enterpret to manage spikes, stack-rank work, and track sentiment after launches—so you can show impact, not just ship lists.
Replace hunches with data that drives planning, sprint priorities, and incident triage.
Thank you to our sponsors who help support this newsletter:
Sponsored
Innovate, Disrupt, or Die
Discover how innovation will accelerate your business.
Paid Subscribers get access to the full post. Inner Circle Members also get access the 15-min audio podcast and 8-min video explainer that come with this post.
Ugh. Tech debt.
The ugly elephant in the room.
No one wants it. Everyone would rather it didn’t exist. But it only grows over time.
We all wish we could just take the blue pill and live in ignorant bliss.
But it's time to swallow that red pill with a tall glass of water and dive in.
Today, I’m going to teach you how to prioritize tech debt.
What You’ll Learn Today:
Why tech debt never gets prioritized
The hidden consequences of ignoring tech debt
How to advocate for tech debt resolution in clear, compelling business terms
How to create a compelling ROI case that gets attention
Tactics to prioritize tech debt — some strategic, some stealth
How to build credibility and trust with small wins
The Trouble With Tech Debt
Intuitively, we know the consequences of ignoring tech debt:
Bottleneck: Slows down future development.
Maintenance: Reduces system maintainability.
Stability: Degraded performance or create instability.
Exposure: Creates security or compliance risks.
Unhappiness: Makes engineers grumbly.
Executives understand this too. Yet, they deprioritize addressing it all the time. Why?
Three reasons:
1. Visible Impact Wins
Features directly drive revenue and are often customer-facing. Whereas resolving tech debt has delayed impact.
Let’s say you work in a $5M company that’s trying to get to $10-25M. The company has 12 months of funding runway.
The CEO’s calculus is simple:
If we don’t deliver revenue-generating features... we won’t sign new customers... we won’t make it to $10M... we’ll run out of funding... which means we can’t pay the bills or make payroll… the company shuts down.
So, the decision becomes:
Revenue-generating features NOW.
Address tech debt once we have a stabilized the ARR engine.
Even in a larger company, features can have immediate impact growth or at least immediate customer satisfaction. Whereas resolving tech debt is measured in second-order effects, like efficiency, velocity, productivity, etc., or feel-good effects, like “engineer happiness.”
The hard truth is that tech debt will ALWAYS be at a disadvantage against features.
2. The Iceberg Under The Water
There are 2 challenges here:
Customers can’t see the impact until there’s a problem.
We don’t feel the pinch until development estimates start getting unreasonably inflated or something truly goes wrong with the system.
This means the worst of tech debt is hidden until it explodes. This makes it hard to prioritize tech debt over features.
3. Poor advocacy
For starters, Engineering likes to use words like “re-factoring,” which are scary to executives. They hear “rework,” which translates to a perception of waste.
Furthermore, estimates to resolve tech debt always sound scary (and are always wrong). And there’s no guarantee of success. Product and engineering teams often do a bad job of defining success criteria.
Finally, it never fully goes away — as soon as we solve this tech debt, there will be new tech debt.
Poor Advocacy
The biggest struggle around tech debt is not the absolute time you have to spend on it, but rather how to advocate for it with stakeholders. It’s in the advocacy that product and engineering teams fail.
PMs try to fit it into formulaic prioritization scorecards, which never work, because tech debt will never get scored anywhere near as high as features.
Engineers advocate for it using intangible value statements like, “It will cause problems downstream,” “It will be easier to develop new code,” or (my personal favorite) “If this company really cared about its customers, it would invest in quality.” While all these may be true statements, none are quantified, so will never compete with customer features and strategic goals.
The irony is that, in life, we typically associate high quality with being expensive, but, in software, high quality is actually cheaper in the long-run.
What resolving tech debt really gets to is the issue of Quality. Which can be hard to measure.
Tech debt isn’t going away, of course. To manage it effectively, we need a structured approach.
So, today, I'm going to share with you the exact playbook my teams and I have used to get buy-in for resolving tech debt.
Table of Contents
Tech Debt Prioritization Playbook
There are 4 elements to it:
How you frame technical debt.
How you present the business case for it.
How you prioritize it.
How you establish credibility.
Note that this is a joint effort between you, the Product Manager, and engineering.
1. Framing
We call it “tech debt”. But few fully leverage the metaphor. So let’s stretch it.
Think of a $10,000 loan at 5% interest. You now face a simple decision:
Do you continue to pay the interest or do you look to pay down the principle?
We can use this analogy for tech debt.
Pay the interest = how much harder will it get to do the work because of imperfections in the code base? Quantify this. For example, a task that may take us 3 days to complete will now take 6 days.
Pay down the principle = tackle the thing that’s causing the problem, which will reduce our interest payments in the future. Quantify this. For example, a task that took us 3 days to complete will continue to take the same time, or — if we really do a good job — less time.
This trade-off is where the debt metaphor is most valuable. The key is to quantify what that principle and interest look like.
2. Making The ROI Business Case
Once you quantify “interest” and “principal,” you can present a business case.
Start by quantifying the bad. For example:
Time spent on maintenance, latency, or recurring bugs
Number and severity of defects or system failures
Delays to product improvements caused by tech debt
Put an economic number on these = Time * Dev Cost per Hour.
Then quantify the good — the outcomes we expect to get by resolving these issues:
Reduction in bugs, especially Severity 1s
Improved uptime and performance
Faster maintenance and deployments
Again, put an economic number on these = Time * Dev cost per Hour. Supplement with any impacts to metrics like customer satisfaction, contractual SLAs, or compliance (e.g., SOC2).
With the help of Engineering, do a quick quadrant assessment of impact vs cost:
This way, you can focus on the most impactful and cost-effective fixes first.
Now, you can present our ROI case. With the work above, you can make an argument that’s tied to business results instead of resorting to value judgment statements.
Bad business case:
“Poor documentation and the different sub-systems make it hard to develop new features. The web servicing environment is well beyond its useful lifespan and has a high cost of ownership. Users are saying they’re unhappy with the performance. So we need to build a new, more resilient infrastructure with a new tech stack that enables new features to be delivered more efficiently and effectively, and deliver a more integrated and modern user experience. It will take 12 months, but — scout’s honor — it will be worth it.”
Better business case:
"The system has suffered 10 outages in the previous 6 months, 2 of which caused business to be down for an entire day. The total economic cost in terms of human power and lost business is $10M. And because the system runs on multiple sub-systems, even changing a button takes 6 weeks to complete. That'‘ $1M just to change a button! User satisfaction is at 10% and Engineering is spending $60M a year just to keep our system afloat.
Re-platforming is going to be a 12-month $30M investment, which, I know sounds like a scary number, but with an anticipated $120M in savings over the next 3 years, I think it's worth it."
Which business case do you think is more likely to get attention?
3. Prioritization
Even with a strong ROI argument, tech debt often loses to features. So, how else can we think about approaching tech debt?
Here are 3 tactics my teams have used — one strategic and two sneaky. (Shh!)
Tactic 1: Strategic Allocation
Make Quality a strategic goal for your product. We did this at one of my companies:
The Quality goal was tied to certain success metrics, such as our SLA, uptime, speed to deployment, and customer satisfaction.
By making Quality a top strategic priority, it gave us license to allocate a portion of our roadmap to quality initiatives, including resolving tech debt.
This way, we didn’t have to justify every piece of tech debt to the brass. It empowered each product team to prioritize tech debt in their own streams, as long as we hit the top-level goals.
Tactic 2: Secret Sprint Time
Agree with your engineering lead to allocate a small portion of each sprint or release to tackling tech debt. 1%, 5%, 10%, 15%, whatever. Don’t broadly advertise it. Just agree to it and do it. If this feels sneaky, then, yes. Yes, it is.
For this to work, though, some very important caveats:
You CANNOT be late on revenue or customer commitments. If it comes out those were delayed because of “unauthorized” refactoring work, you’ll have some uncomfortable explaining to do.
Don’t be slavish to that %. If there’s no tech debt to resolve in a particular sprint or release, give it up for customer features.
Pro tip: Get your product and engineering leadership’s support, so you have a poop umbrella.
I had one of my Product Managers do this for our mobile app. His team faced over a 100 tickets of bugs and tech debt. They were running 4-week sprints with monthly release cycles. He made an agreement with his dev team to target 10-15% of each release to eradicating the defects. In 3 months, they crushed the list down 84%, while also releasing some critical customer updates. (One of my favorite PMs to this day.)
Tactic 3: Sneak it in
If all else fails, work with the engineering team to reasonably bake it into estimates for customer features.
In other words, if a customer feature would normally take 3 days, agree to 4 days. That 1 extra day is for resolving related (if even loosely) tech debt.
If this feels a bit like cheating, then, yes. Yes, it is. You don’t need to advertise this approach. Keep in mind, though, the same two caveats as above apply.
4. Credibility and Trust
Since tech debt isn’t on a level playing field with features, trust plays a decisive role.
Trust is earned in incremental successes over time. Success breeds credibility. Credibility breeds trust. Trust builds momentum.
What does this mean in practice?
It may be tempting to do a big rework. (And engineers love to do this.) But unless it’s being explicitly championed by the CTO (i.e., the CTO is willing to lie down on the line for it), it’s unlikely to get prioritized.
In addition, doing a big rework is always daunting, no matter how good the story is or what promises of gold are made.
So, the better approach is to create a visibly solid track record of proven outcomes with resolving small-scale debt first.
Identify some small rework.
Set clear criteria for success.
Deliver it on-time with quality.
Measure the outcome.
Make it visible.
In almost all cases, the #1 thing that enables repaying tech debt is strong trust between Product Management, Engineering, and leadership.
This trust, however, is earned. We earn it over time by creating a strong track record. This, in turn, gives us room to go after bigger things.
Your Takeaways
So, that’s the playbook for dealing with tech debt:
Use a framing device.
Present a good ROI.
Prioritize it strategically.
Build trust through small wins.
And, yes, cheat a little too. 😉
Give this a try and let me know how it goes.
That’s all for today.
Have a joyful week, and, if you can, make it joyful for someone else too.
cheers,
shardul
Here are 4 ways I can help you today:
Strategy Design Workshop: Transform scattered priorities into clear, actionable direction. I’ll facilitate your team through a customized workshop to align stakeholders and create strategies that actually get executed instead of forgotten. Book a call.
Product Management Audit: Get a clear picture of what’s working and what’s holding your team back. Through a systematic analysis, I’ll evaluate your strategy, processes, roles, metrics, and culture. You’ll walk away a practical set of findings and actionable recommendations to strengthen your product organization. Book a call.
Corporate Training: Elevate your entire product organization. I’ll teach your team how to think and act strategically, craft outcome-driven roadmaps, and dramatically improve how they deliver measurable results that matter to your business. Book a call.
Improv Based Team Building Workshop: Boost creativity, trust, and collaboration through improv. Your team will problem-solve faster and work better together. Book a call.
Shardul Mehta
I ❤️ product managers.