Tech Debt & Strategic Roadmaps
"Shipping first time code is like going into debt” – Ward Cunningham, 1992
Every product has technical debt.? There is no perfect architecture or product.? But there are smart strategies you can follow to balance the need to pay down technical debt whilst maintaining a strategic roadmap.
A highly successful Product Manager understands the types of technical debt that exist, how it impacts their constituents, and has a plan to manage the debt and also deliver to market compelling new features that drive revenue and differentiation.
What is Tech Debt?
Technical debt is not one kind of problem.?
It could be a need to re-architect small or large platform components to address security or scaling needs.? It could be the use of aging libraries that need to be brought up to currency.? Or worst-case it could be a black swan event that derails plans and necessitates emergency patching like we saw with Log4j.
In my career I’ve seen all types of debt.? And just like in our real lives, not all debt is equally bad or needs to be addressed with the same level of urgency.
Sources of Tech Debt
We know that all products have some level of technical debt, and it’s a good idea to understand why it exists in your product.? These things don’t usually happen by mistake – it’s often the end state of someone making the best decision they could in the past.
Services-first companies that have transitioned to product-first often have the most challenging debt issues. When you start as a services business, making long term product decisions is secondary to providing the tooling needed to meet an engagement.? If you find yourself in this type of business, be aware the debt can take more resourcing than you expect.
Most debt can be classified as "organic."? Over the years as new product versions are released, choices are made about libraries, components and architectures. We position and deploy these products into production which then requires creative strategies for mitigation, especially when it comes to providing upgrades for existing customers.
Know Your Debt
Understanding the scope and types of technical debt that exists is critical to understanding your path forward. One starting point is to leverage a ranking system that looks at criteria such as:
With this map of where technical debt is impacting the business it's possible to plan a mitigation strategy. And the focus needs to start through the lens of the overall business strategy.
In a mature product organization, maintaining existing customers may be the most important focus. Therefore the highest priority might be mitigating debt related to customer upgrades or product stability in production.
In a rapid growth organization, debt related to sales barriers or innovation delivery could be the highest priority.
领英推荐
A highly successful Product Manager understands not just what the debt is. They understand how it impacts the business.?
Roadmapping Debt
Building a strategic roadmap that delivers strong innovation and tech debt mitigation is a balancing act. There is no perfect answer, which is why aligning to corporate strategic goals is critical.
As a starting point, plan for 80% resourcing to innovation, 20% to debt.? Black swan events like Log4j or unexpected customer demands can change this plan, but that’s why roadmaps are in PowerPoint and not stone.
Start by investing first in debt that reduces the ability to innovate new features.? Even in a mature product organization, your customers will be looking for new innovations they can leverage.? And the adage “innovate or die” exists for a reason.
Next, focus on debt that has a deadline to be paid.? For example, if you have an old Java version embedded, make a firm plan to upgrade to a current version well ahead of that components end-of-life.
Last is debt related to scalability or ease-of-deployment.? It may seem counter-intuitive, but most scalability problems can be managed by providing more compute resources, and ease-of-deployment can be addressed through improvements in documentation and services estimates.
Embrace & Extend Debt
Embracing and extending existing debt is also a reasonable approach to consider.?
A common scenario is a desire to create a new UX but there's limitations due to existing product architecture or technology stack.? Instead of starting a rearchitecting journey, it's reasonable to understand if there are new components that can be added to the platform to enable the innovation strategy.?
Yes, this is adding complexity, but that’s not always a bad thing and should be seriously considered.
Again though, there is no one-size-fits-all when dealing with technical debt.? A highly successful Product Manager understands what is most important to the business and will focus in those areas.
Thoughts on Rearchitecting
In almost all discussions around dealing with technical debt there will be someone who raises the idea of just starting over.? Investing in rebuilding or rearchitecting your product has many compelling benefits – a clean fresh platform is compelling on the surface.
Be wary of the real effort required.? It’s not uncommon to have discussions like “with 5 engineers we can rebuild on a new stack in 3 months” – remember that what sounds too good to be true often is.
For considerations about technical debt from the perspective of an architect, I strongly recommend reading “3 Essential Lessons from Re-architecting Systems (or how not to be a miserable wreck)” by Shannph Wong
VP Technology | Advisor | Growth Scaling Expert | ex-Meta, ex-Amazon, startup growth through IPO exit
1 年Nice points on Tech debt and finding the ways to budget and prioritize mitigating it. The biggest practical challenges that I find is how to prioritize fixing that debt and justifying the impact of it when you are 'under the gun'. When your marquee project is delayed due to some unexpected complexity, how do you not 'eat into the tech debt budget' to 'swarm' on your marquee project to get it back on track? (and how do you prevent this 'exception' form becoming the rule?)