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
Innovate, Disrupt, or Die is your weekly newsletter focused on all things corporate innovation, startup disruption, and venture-building.
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
Become a Subscriber to Unlock the Rest
Become a Paying Subscriber or Inner Circle Member of Street Smart Product Manager to get access to this post and premium community events.
Click Here to Unlock Cool BenefitsA Paid Subscription also gets you:
- Subscriber-only comment section
- Monthly live group chat Q&As with me
- Discounts to monthly events and AMAs
- First/early access to new online courses before the general public
- Access to exclusive resources to accelerate your learning and impact
- An Inner Circle Membership gets you all the above PLUS free access to all events, full replay archive, 1 strategic resume review per year, and exclusive access to the PM Exchange