⛴️ As a PM, leverage tech debt as a business advantage
Work together with your engineering team to manage tech debt
As a product manager, invariably you come across the concept of “tech debt”. Often it’s an engineer telling you they want to carve out some time to fix something bothering them in the codebase. PMs often relent, and think that tech debt is just another technical cost of developing products. But as a PM, you should take a more active role in managing tech debt, even leveraging it as a business tool.
What is tech debt?
When an engineering team implements a product change sub-optimally, often even intentionally, they incur tech debt. There’s no immediate user-facing impact. Tech debt is not a bug. Rather, tech debt is typically characterized by poor code quality, resulting in an unstable or less flexible product going forward, unless the debt is paid off.
Why incur tech debt?
In finance, incurring debt is borrowing from the future. It gives you capital to do something now, that you wouldn’t have otherwise been able to do. It serves as an investment, so that with the assumed positive ROI, you are able to repay that debt in the future. In the same way, incurring tech debt allows you to advance your product at a compressed timescale. You can create user-facing product changes faster, trading off code quality. If the investment results in a successful product, you can repay the tech debt in the future by re-architecting and re-factoring the code then. The unit of financial debt is money. You borrow money from the future. The unit of tech debt is engineering resources, which is typically time. You are effectively borrowing time from the future.
Just like you have to pay interest on unpaid financial debt, you have to pay ongoing product and engineering costs for tech debt. Poor code quality means that the product is error-prone to subsequent changes. It’s more likely for an engineer to ship a bug if the existing code is complicated and hard to understand, a common manifestation of poor code quality. Furthermore, it may take longer for an engineer to create a new product change, because they have to work around the poor code. The interest on financial debt is linear. It’s usually a fixed rate based on the remaining principal of the loan. And the remaining principal doesn’t change by itself. For tech debt, the costs grow faster. As code quality worsens, the problems increase exponentially. If you are working in a tech debt ridden codebase, it’s not motivating to maintain what little code quality remains with each subsequent change. So tech debt itself tends to grow worse over time, if it’s not actively managed.
In practice, the major cost of tech debt from a product perspective is engineer satisfaction. Humans want to do good, quality work, even non-perfectionists. If your environment constrains you from doing that, it’s discouraging. An unmotivated engineering team ships poor quality product, slower. Happy and satisfied engineers create amazing products, faster.
Managing tech debt as a PM
Tech debt is a technical concern. But it also has a direct business impact. So as a PM, you should be very much involved in managing it. Typically, your first concern as a PM new to a team, should be mitigating existing tech debt. It’s unlikely that you would be working on a totally new product. So work with the engineers on your team to identify and measure existing tech debt. Make a plan to repay that debt over time. Scope out the work in future sprints and reserve space in your roadmap. But most importantly, ask engineers what is the business impact of fixing this tech debt. It’s unrealistic to try and evaluate each tech debt fix ticket in your issue tracker with an ROI quantified with dollars and cents. But you also shouldn’t be satisfied if an engineer says, “it will make the codebase cleaner”. That’s not actionable information from a product management perspective. Ask questions like, “Will fixing this part of the codebase speed up development? Will we be able to get rid of those annoying edge cases that may become a problem when we launch the new adjacent product? Will it make it easier to create the new API we’ve been planning?”. You don’t need to get into the nitty gritty technical details. But just enough to inform product decisions going forward.
Consider when to incur new tech debt. As a general rule of thumb, if your product is newer, you should be incurring more tech debt. As a new product, you are still exploring and experimenting. You are doing customer research. You can even think of your product as a more stable version of throwaway prototypes. The primary goal of product development in these early stages is learning about the customer, and reacting quickly as needed. So you should be cobbling your product together as quickly as possible, in order to validate assumptions. And so along the way you incur tech debt. Once the assumptions are validated and you have more confidence a given product feature makes sense, you can repay the tech debt, stabilizing the product, and even scaling it to many more users. If the feature is not successful, you’ve still furthered your customer development process. You understand more about the users and market. And at the same time, you’ve invested minimally from an engineering perspective to get to this point. This is a net positive.
Incurring tech debt is not only a matter of developing products quickly and efficiently, it can also be the only way for your business to survive in the first place. Early stage startups or even teams in small and medium-sized companies have limited time and money to build a product. If you spend most of your time building a tech debt-free product, and it fails to acquire enough users, you’ve ultimately failed. You now have a great piece of engineering, but a useless product. There’s no time left to pivot. Since you no longer have resources, your investors (whether inside the company or outside) are not interested in supporting you anymore. You’ve exhausted your runway. You may even need to shut down the company. Alternatively, you can iterate your product quickly, building many experimental features along the way, validating them with users. And so you incur a lot of tech debt. In the extreme case, you may even need to throw out the entire codebase after the experiments. But you’ve gained tremendous value because you’ve validated the product concept and business model. This value in turn can be cashed in by getting more funding from investors, where you then build the more stable version of the product. In this way, tech debt is a tremendous business tool for PMs. It’s no longer a risk to be mitigated, but turns into a strategic advantage.
In finance, there are different seasons. Sometimes you incur debt. Sometimes you repay it. Sometimes you do both in parallel. It really depends on the different scenarios. And as long as you are being strategic and intentional, debt opens up a lot of opportunities. In the same way, consider how to use tech debt to your advantage. Be disciplined to repay existing tech debt. But don’t be afraid to take calculated risks in incurring new tech debt. In general, if the amount of debt doesn’t radically go up over time, and fluctuates along a safe level, you should be in good shape.
Working with engineers
Engineers often frown upon tech debt. Their expertise is in creating and maintaining stable systems. So engineers are predisposed to minimize tech debt. They want to approach that ideal as much as possible. They do understand that at a business level, there needs to be compromises from time to time, and are willing to relent and incur tech debt. But as a PM, you should strive to reach beyond this understanding. Engineers are motivated to do good engineering from a day to day perspective. But they are also motivated to do good product from a week to week, and month to month perspective. If you help them understand the business impact of tech debt, and involve them in those business decisions, they will grow a greater appreciation of the strategic business advantage of tech debt. In this way, you’re effectively further reducing the negative impact of tech debt by at least helping the engineering team to stay motivated, even while they work in a messy part of the codebase for a period of time.
📬 Mentorship in your inbox: Subscribe to Product Management 101
Product Management 101 covers practical tips and basic skills for aspiring and new product managers.
I’m Victor Wu, Head of Product at Tilt Dev. I’ve been creating digital products for over 15 years, and mentoring folks for much of that time. Subscribe, and reply to email updates with questions you’d ask in a real-life mentoring session. I’ll answer them in future issues.