I have a frequent recurring nightmare that involves my engineering partner coming to me and saying something to the effect of: “Pranav, our technical debt is unsustainable, we need to spend the next three months refactoring the code base — no new product development till then.”

Technical debt—“tech debt” for short—are arguably some of the most panic inducing words in product management, and it is a frequent topic of discussion (and source of tension) between engineering and product.

Before developing a product perspective on tech debt, let’s first understand what it is and what causes it.

What is tech debt?

Technical debt is incurred when developers make the trade-off to do something quick and dirty vs. slower and cleaner. Like the metaphor implies, this trade-off involves “interest payments” in the future i.e. future development becomes more clunky and at some point teams may need to “pay down the principal” by refactoring code.

Tech debt may manifest itself through content that is hard coded in the front-end instead of in a content management system. Moreover, tech debt may lead to a lack of proper instrumentation and alerting, reliance on manual testing instead of automated testing, and ultimately a system that is not ultimately scalable to a large number of users.

What causes tech debt?

Like many things, tech debt arises from a lack of time and adequate information.

Sometimes, developers sometimes cut corners to meet deadlines. There might not be enough time for up-front design. Developers may do things that are application or job specific instead of something that is reusable. The team might have developers that are not as skilled or committed as they should be.

Sometimes, technical debt is unavoidable, because issues and optimal design only become clearer once the team has already spent some time in developing the solution. And finally, sometimes, technology gets outdated and needs to be replaced.

“Debt” sounds bad — but is tech debt always a bad thing?

Perhaps unsurprisingly for someone who works in financial services , I don’t think all “debt” is inherently bad.

Tech debt that is taken on to allow a team to test and validate ideas quickly is acceptable. In fact, this is the bedrock of lean product development: testing small iterations and validating need and demand before investing in making the solution scalable from a product and technology perspective.

There is no point building a perfect technical solution if that product is rejected by customers, or will change significantly in response to feedback. We have to leave room to “do things that don’t scale” in order to find product-market fit. So, this kind of technical debt is acceptable as long as there is an understanding and commitment that time will be spent on paying down tech debt before the product or feature is scaled.

So, how should a product manager approach technical debt?

Here are a few approaches that I’ve seen being adopted with varying degrees of success

• Case by case decisions: Involve negotiation between product and engineering leadership on how much of the upcoming effort will be devoted to new feature development vs. paying down technical debt or shoring up the architecture or increasing the resilience of the technology stack. This is not always the most comfortable of conversations: product feels that the engineering team hasn’t done their job properly and is putting product goals in jeopardy to “clean up their mess”. Meanwhile, tech feels that product is not prioritizing technical resilience. Not surprisingly, this conversation often devolves into negative territory. The negativity can be mitigated through a strong and trusting relationship between the product and engineering leaders.
• A fixed “budget”: From my experience, this is a more prudent and sustainable approach. The product and engineering teams agree to a fixed amount of capacity devoted to paying down technical debt. This could take a few forms — a fixed allocation of story points every sprint spent on tech debt, or one out of every four sprints spend on technical effort. Given that teams may prudently take on tech debt to validate a product idea , the budget for paying down tech debt may need to increase before the product is scaled.

Two best practices that comes to mind on this topic: documentation and explicitly tracking tech debt in the backlog. Documentation across the product and tech teams will help to retain the context and rationale for taking on debt, which will be important in case of team-member transitions. Tracking tech debt as part of the backlog will ensure that room is created for the team to work on it, and that there is visibility to the work that is happening.

All views, opinions and statements are my own.