There’s a dirty word in the software business, one that is spoken only in hushed tones, whispered in ears during lulls in activity, the thing-that-shall-not-be named: “Technical Debt”. Every Product Manager deals with this, whether they are aware of it or not, whether they plan for it or not. It is a natural side-effect of the software development process, of the choices we make on a daily, weekly, and monthly basis. It’s unavoidable, but still remains largely undiscussed in most companies. It’s time to take Technical Debt out of the shadowy, secret world in which it exists and bring it into the light — because the more we try to pretend that it doesn’t exist, the more it will continue to remain the boogeyman hiding in our product closet, waiting to pounce upon us when we least expect it. Before we can do that, we need to clarify what we mean by Technical Debt, and clarify why it exists, when we should look out for it, and how we can manage it.
What is “Technical Debt”?
At the most fundamental level, technical debt is the cost of future rework taken on when we make a decision in the present moment. These decisions can be made knowing that we’re taking on future work to refactor, improve, or rebuild what we’re currently working on, or they could be made without a full understanding. Obviously the first case is more manageable, as it falls into the realm of the “known unknowns”, while the latter is dangerous, because we can’t really plan to mitigate for “unknown unknowns”.
The primary source of technical debt is deciding to take a technical shortcut now, with the intent to return to it in the future. This happens probably most often in the realm of User Experience, where we shortcut some troublesome UX work now in favor of shipping sometime, with the expectation that we can make it better in the future. But it’s not entirely relegated to UX; performance decisions, architectural decisions, implementation decisions can all lead to technical debt. And that’s not necessarily a “bad” thing — after all, most Product Managers subscribe to some form of the age-old axiom, “Perfection is the enemy of the good”. But we do need to be aware of when we’re making these decisions and weigh the future impact against the present need.
One thing to consider when making such decisions is the “weight” of the technical debt that you’re taking on. It’s one thing to choose not to account for some “sad path” User Experience element, and another to choose to implement a fundamental system upon which the entire product relies. I like to lay out such things into a spectrum of technical debt from “light” to “heavy”. “Light” technical debt are things that can easily be changed in the future, with minimal impact to the user or to the system itself — color schemes, error messages, certain API responses or dependencies all fall into this category. “Heavy” technical debt are the things that have systemic impact or upon which multiple components depend — database architecture, application frameworks, partner dependencies all fall into this category. Understanding as much as we can about the future impact of our choices is just as important as knowing that we’re making such a decision.
Assuming that we are aware that we’re making a decision likely to result in technical debt, and that we understand the nature of that future rework, how do we decide whether it’s “right” to take on that technical debt? Unfortunately, there’s no single formula or golden rule that one can use to make that determination. It’s going to be something that takes the form of the lawyer-favorite “multi-factor analysis”, looking at multiple factors and making the decision based on some or all of these considerations:
- What is the pressure to release the product as-is? Revenue, Customer Sat, etc.
- Can you plan to take on the technical debt quickly following the shortcut?
- How certain is it that the technical debt will result in negative consequences in the future?
- What’s the worst thing that can happen if the technical debt is never paid? When could this happen?
- Do your stakeholders understand the tradeoffs as well as you and your dev teams do?
Thinking through those considerations will often make it very clear whether or not this particular bit of technical debt is something that you should take on, or whether you need to suck it up and push through to solve for the problem you’re facing the “right” way rather than the “fast” way.
Planning to Reduce Technical Debt
While it’s true that most technical debt discussions wind up coming out of left field and almost always arise when there’s an urgent need to ship, that doesn’t mean that we can’t try to plan and account for it, either before it comes up or after it has already been incurred. As Product Managers, it’s part and parcel of our job to budget time for ourselves and for our development teams to both anticipate and to accommodate technical debt as we go about our daily work. Neglecting technical debt in planning or response only serves to hamstring us and our teams from the success that we all want to achieve.
Keep in mind, planning for technical debt doesn’t require in-depth analysis of every single decision that we make, every single tweak that the developers do. Rather, it’s just one of the many things that we should consider in our planning efforts. We should take a look at the things that we’re planning to work on and just take a few moments to think about what’s likely to cause trouble based on prior experience — and to call those out early rather than later. Similarly, when we decide to take on some technical debt, we need to make sure that we do the proper administrivia to ensure that the future work gets captured and not lost in the shuffle. Ideally, we want to take on technical debt as close to the time we take it on, but there are always other pressures that mean it gets pushed down the priority stack — but if we ensure that it’s been captured and properly labeled, we won’t lose track of it. If all we do as Product Managers is make sure that technical debt is on our checklist of planning considerations, that alone will put us in a better position than many companies find themselves in right now.
Part of planning is understanding what the implications of our decisions are, and technical debt is something that occasionally does need more than just a spot on the checklist. We should spend the necessary amount of time to determine whether we need to spend more time understanding the impacts of technical debt that we’re taking on — an iterative approach, as in most things related to software, is the best here. This is because there are occasionally those technical debt decisions that have serious repercussions — retrofitting an ETL process on a database for customer-facing reporting solutions isn’t a one-sprint fix, for example. When we do run into these high-impact, high-risk situations, we need to make sure that we understand both the short-term and long-term impacts. Maybe we can run that ETL process for a year before it falls down, and if we know that it’s a 3-month project, then we have to ensure that we’re working on it no more than 9 months out (but hopefully not cutting it that close!). The more risky the future impact, the more essential it is for us to advocate and fight against the pressures to build something “new” with our stakeholders, and do the right thing for the product.
It’s interesting to note that as Product Managers we tend to shield our stakeholders from discussions about technical debt. For whatever reason we choose to do this, it needs to stop — it’s a disservice to both our development teams and our stakeholders. While we don’t necessarily need to go into the nitty-gritty, gory technical details of the debt that we’re taking on, as Product Managers we owe it to our stakeholders to help them to understand the tradeoffs that occur during the product development process and how it affects future plans. The earlier and more clearly we can articulate these costs to our stakeholders, the more they will respect the plans that need to be made to account for the technical debt that we take on. We may even succeed at times in being proactive enough to permit us to avoid taking on the technical debt at all, if the future situation could be dire enough to concern the stakeholders. Product development isn’t all green lights and thumbs-up, and we as Product Managers have a duty to clearly articulate some of the yellow-light situations that come up, and to discuss these with our stakeholders as the intelligent human beings that they are. The sooner we make them aware of the costs of technical debt, the better we can frame discussions both now and later about when to take it on and when to resolve it.
Striking the Balance Between Old and New
No matter how well we understand the technical debt that we’re taking on, or how much we want to plan for it and educate our stakeholders, we still have to balance out those technical debt plans against the pressure to delivery new capabilities. It’s a constant challenge for Product Managers in software development, since technical debt doesn’t generally generate revenue, close new deals, or move the technology forward to the extent that our company wants. At the same time, ignoring technical debt can have serious impacts on customer retention, customer satisfaction, and future flexibility to adopt new technologies. Achieving the right balance between solving technical debt and delivering on new features is something that every Product Manager needs to strive for.
As noted before, whenever we take on technical debt, we need to make sure that we’re capturing that anticipated future work somewhere. On agile teams, this should go into your product or team backlog; for less-agile teams, you might need to capture technical debt as open bugs or in some form of BRD/PRD depending on your company’s systems. We need to have this backlog so that we can slip work in where there is an opportunity, and so that we can have prioritization discussions with stakeholders and development teams. The more we hide or sweep technical debt under the rug, the bigger the risk we take on that something will become an urgent issue, and the fingers wind up (rightly) pointed at us for not making people aware of the situation sooner. Having a clear, prioritized backlog of technical debt helps us to understand what needs to be done, position small fixes throughout our new product development, and manage expectations of our stakeholders — it’s a win/win/win proposition for everyone involved.
Work on technical debt, once in the plan, can be particularly susceptible to changing priorities. As Product Managers, we likely understand the importance of paying off technical debt better than any of our stakeholders do — and it’s incumbent upon us to reinforce plans that are made to pay off technical debt, especially when there’s some market or customer pressure to put it off just a little bit longer. The longer we put off technical debt, the more we build up; the more we build up, the less likely we are to resolve any of it; and the less technical debt we resolve, the riskier our future work becomes. It’s inevitable that some technical debt will fall to the wayside under pressure from stakeholders, but as Product Managers we need to defend our plans to pay off technical debt to the same extent that we defend our plans to improve the product for our customers and market — after all, when something blows up we’ll have no choice but to drop everything and fix the product. Nobody wants to be in that position, and the better we manage our plans to pay down technical debt, the less likely that all-hands firefighting is to happen.
Assuming that you have a clear backlog of technical debt items to work on, one of the easiest ways to ensure that they get resolved is by following a principle I’ve referred to in the past as the “While the patient is open…” rule. Simply put, this means that whenever you’re working on a feature or improvement in your product, you need to review the currently-open technical debt items in that area, and address them if at all possible. For example, if you’re working on an item details page for an e-commerce solution, and there’s some technical debt around the SQL queries or stored procedures that power that page, you should try to fit in those performance improvements while you’re working on the page. This serves two purposes — most importantly, it gives you an opportunity to pay off some bits of technical debt; but it also often makes the final delivery of that feature more impressive to the stakeholders, particularly for performance-related improvements. When they see that not only has the item details page layout improved, but so has the performance, they’ll start to understand and internalize the importance of technical debt. Working your technical debt into already-open work is also usually a much easier sale to your stakeholders than trying to slot in completely unrelated work alongside feature work.
Technical Debt is Part of Our Job
Every product in the world will have some amount of technical debt to solve. And the impacts of this debt will range from imperceptible to platform-jeopardizing. As Product Managers, part of our job is negotiating the twisting path from ideation to delivery and beyond, which includes understanding when and why we decide to take on technical debt, and relaying those risks to our stakeholders when needed. We must also apply the same systemic approaches to managing technical debt that we do to our feature and functionality backlogs. The worst thing that we can do is to ignore these decisions that affect core components of our product and of our customer experience — in regard to technical debt, ignorance is anything but bliss.