No one likes it. No one wants it. Everyone would rather it didn't exist.
But it only gets larger 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.
The trouble with tech debt
Intuitively, we all know the consequences of not addressing tech debt:
Bottleneck: Can slow down future development and testing.
Maintenance: Can reduce the maintainability of systems.
Stability: Can slow down performance or create instability.
Exposure: Can create a security or compliance risk.
Unhappiness: Can make for a very grumbly engineering team.
Even executive decision makers intuitively understand this.
Yet, they deprioritize addressing it.
I admit, as an executive, even I often directed my teams to prioritize features over resolving tech debt.
Why?
Two reasons:
Visible impact.
The iceberg fake-out.
The hard truth is that tech debt will ALWAYS be at a disadvantage against features.
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...
Revenue-generating features NOW.
Address tech debt once we have a stabilized the ARR engine.
What if you're at an established company? Whether you're working on a growth product or a new one, you're still working with a finite budget (i.e., your funding) and features can have immediate impact - e.g., winning a sales deal, increasing conversion, reducing churn, boosting NPS, etc.
On the other hand, resolving tech debt has delayed impact that's measured in second-order effects, like efficiency, velocity, productivity, etc., or feel-good effects, like "engineer happiness".
That gets us to the Iceberg Fake-Out:
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 makes it hard to prioritize tech debt over features.
The iceberg under the water
It doesn't directly contribute to revenue.
It's not customer facing (until it's customer impacting).
Estimates to resolve always sound scary (and are always wrong).
Engineering likes to use words like "re-factoring". Executive hear, "rework", which translates to a perception of waste.
There's no guarantee of success (or, more specifically, product and engineering teams do a bad job of defining success criteria).
PMs and Engineers do a bad job of making the ROI case.
It never fully goes away (as soon as we solve this tech debt, there will be new tech debt).
The biggest struggle for product management and R&D folks around tech debt is usually 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.
Product managers try to fit it into formulaic scorecards or prioritization templates, 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, and 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.
So, what are we to do?
I'm going to share with you the playbook my teams and I have followed.
Tech debt prioritization playbook
There are 4 elements to it:
How we frame technical debt.
How we present the business case for it.
How we prioritize it.
How we establish credibility.
Note that "we" here means us product managers AND engineering.
1. Framing
We call it tech debt. Why? Most of us just accept the term "tech debt" without fully utilizing its power.
So, let's stretch that analogy of "debt".
If I get a loan for $10,000 at 5% interest, the principle is $10,000 and the interest I'll owe is 5%.
So, once I take the loan, I face a simple decision:
Do I continue to pay the interest or do I 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.
So, 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.
So, by fixing the problem, a task that took us 3 days to complete will continue to take us 3 days to complete, or - if we really do a good job - even <3 days.
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 business case
By quantifying what that principle and interest look like, we can present an ROI for tackling tech debt.
Start by quantifying the bad - for example:
Time spent regularly on maintenance, latency, etc.
Number of defects by severity - e.g., more Sev 1 defects recently?
Number of recurring bugs.
Number of system failures and time to resolve.
Product improvements slowed down by the tech debt.
An economic number can be put on these = time * dev cost per hour.
Then quantify the good - in other words, the outcomes we expect to get by resolving these issues:
Reduction in bugs, especially Sev 1s.
Improvement in system uptime.
Improvements in maintenance, latency, etc.
Again, put an economic number on these = time * dev cost per hour.
Supplement with any impacts to metrics like customer satisfaction or contractual SLAs.
For any security or compliance risk, work with those teams to quantify those risks in economic terms as much as possible. (E.g., violation of our SOC2 certification.)
Present a good ROI:
With the work above, you can make an argument that's tied to business results that matter instead of resorting to value judgment statements.
Bad way:
"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 way:
"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's $1M just to change a button! User satisfaction is at 10% and Eng 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 will get attention?
3. Sneaky Strategic Prioritization
Sometimes, a powerful argument like the one above will win the day.
Sometimes not.
So, how else can we think about approaching tech debt?
I share a strategic way and two sneaky (shh!) approaches my teams and I have used:
1. Strategic Allocation
Make "Quality" a strategic goal for your product.
We did this at one of my companies:
From my course, One Week Product Roadmap, in which I teach strategic prioritization and resource allocation, including tech debt.
By making Quality a top strategic priority, it gave us license to allocate a portion of our roadmap to quality initiatives, which included resolving tech debt.
The Quality goal was tied to certain success metrics, such as our SLA, uptime, speed to deployment, and customer satisfaction.
This way, we didn't have to justify every piece of tech debt to the brass. It empowered each product manager to prioritize tech debt in collaboration their own dev teams, as long as we hit the top-level goals.
2. Under the radar.
As a PM, 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 advertise it. Just agree to it and do it. (Yes, this is cheating.)
Pro tip: get your product and engineering leadership's support, so you have a poop umbrella.
For this to work, though, some very important considerations:
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, great, give it up for customer features.
I had one of my product managers do this for the mobile app he was managing. His team faced a mountain of bugs and tech debt. (100+ tickets.) They were running 4-week sprints with monthly release cycles. He made an agreement with his development 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 best PMs to this day.)
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.
You don't need to advertise this approach. (Yes, this is also cheating. But better to ask for forgiveness than permission!) Keep in mind, though, the same two caveats as above apply.
4. Credibility and Trust
Since it's not a level playing field between features and tech debt, trust plays a decisive role.
Trust, however, is earned in incremental successes over time.
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.
Establish the expected outcome - i.e., 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.
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, yeah, cheat a little too. 😉
Give this is a try and let me know how it goes.
That's it for today.
Have a joyful week, and, if you can, make it joyful for someone else too.
Whenever you're ready, there are 3 ways I can help you:
1. One Week Product Roadmap: Become a master of delivering value instead of a manager of backlog swamp. Own the room with your stakeholders. Based on over 25 years of battle-tested experience, this masterclass cuts through the fluff with practical, actionable strategies that work in the real world. Join product managers across the globe here.
2. Customer Discovery Toolkit: Use the customer discovery tactics I've used to grow my products to $100M+. Get a complete playbook of practical and immediately-implementable strategies to develop your own game plan to extract maximum customer insights. Download it here.
