In software development, how to manage technical debt refers to the accumulation of work that builds up when developers implement quicker, short-term solutions instead of more optimal (but more labor-intensive) solutions.
Technical debt uses a financial metaphor to illustrate how short-term decisions today, like borrowing money with interest, can have magnified effects in the future, like owing a lot of interest, being denied additional credit, hurting your credit score, etc. It may seem like a great idea to get that loan and drive that new car off the lot today, but only if you can consistently make the payments. Otherwise, it’s going to cause a lot of trouble for you down the road.
Technical debt works the same way. It’s not always a bad thing and it’s certainly not the result of “lazy” developers “taking shortcuts.” Often, technical debt can be a great way to get an MVP out the door and beat competitors to market. Maybe you don’t implement the most elegant solution today, but you start generating revenue sooner and can carve out time to address and rework those issues in the future.
Technical debt also often arises from placing unrealistic time or resource constraints on a development team. If you give developers a one- or two-week sprint to do a month’s worth of work, you’re setting yourself up for technical debt (and possibly a mob of angry developers). We’ve described the definition of technical debt more in the video below.
In product management, how can you best avoid taking on unnecessary debt and negotiate existing debt without slowing things down or stalling innovation? Here are some tips to help.
1. Make how to manage technical debt part of every conversation with your developers.
Odds are that your development team is intimately familiar with existing technical debt. They’re also likely well-positioned to provide debt-related insights that can help you weigh the pros and cons of planning decisions currently on the table.
Tweet This:
“Make technical debt part of every conversation with your developers.”
Making technical debt a recurring topic of conversation in planning meetings helps keep the focus on long-term improvement, flexibility, and scalability. Asking engineering leads these types of questions will help you make decisions about when to take on additional debt or when to devote more resources to trimming down existing debt alongside other development activities:
- What will this shortcut save us now?
- What are we gaining by opting for a less-than-ideal fix today?
- What kinds of challenges or limitations does this set us up for later?
- Do we fully understand why we can’t address this today or do we need to further investigate before committing to future reworking or refactoring?
- Do we fully understand the dependencies involved in this solution? Is it going to impact more than just the feature currently on the table?
- If we do take on this debt, what are the future implications?
- Does that timeline conflict with other release plans, feature updates, etc?
- How long can we possibly put this off?
- Are we putting this off for a strategic reason, i.e. do we suspect there will be a better way to fix this later if we wait?
Once you implement a tool, build a framework, etc., it immediately starts becoming outdated. Some debt is expected, and that’s fine—what you need to understand is what you’re compromising in any decision, and for how long that is reasonable, i.e. the code is a bit ugly, but we’re going to need a new component library down the road, and that may be a better time to address that issue.
2. Be an organizational advocate for maintenance.
Dedicating some concrete percentage of development time to business-as-usual activities, including bug fixes, system maintenance, and technical debt is a somewhat obvious solution, but it takes some organizational advocacy to make this a standard part of the culture.
At best, technical debt is an ever-present reminder that says “Hi, I’m here, remember when you opted for that quick fix? Me too. Fix me at some point when you have time.” At its worst, technical debt is a nightmare that haunts your development team’s dreams and constantly eats away at the stability of your application. But that doesn’t mean stakeholders want to listen to an explanation of why you’re prioritizing some underlying architecture update over a new feature they’re personally more excited about.
One strategy for building enthusiasm around debt-related activities is to dedicate time to illustrate what happens if you don’t address your technical debt. In our experience, when everyone agrees that debt needs to be addressed, 90% of the time it’s either because you can’t add new features with the current status quo, or because development efforts will be exponentially faster if you fix things now.
As a product manager, you can advocate for the importance of carving out development time for debt-related projects. Building out a swimlane on your product and engineering roadmaps dedicated to bug fixes, routine maintenance, and gradually eliminating technical debt, will ensure that you’re advancing your product while chipping away at its vulnerabilities and weaknesses. This ongoing approach helps you avoid hitting a wall at some point where you can’t launch a new feature because your architecture isn’t stable enough to support it.
3. Develop a KPI tied to basic product expectations.
One way to help prioritize the work to address technical debt is to have KPIs around your product performance or development velocity. At ProductPlan, we segment our NPS feedback to understand where users are satisfied—or dissatisfied—with the product web experience. We have initiatives to improve that element of our NPS score and can use this as an objective way to evaluate the priority of framework changes.
For a website, you may have specific objectives around load times or other metrics that can only be improved by addressing technical debt. For example, we recently underwent an upgrade related to how our application functions in a web browser. The previous framework was working fine but we realized new features we had in the pipeline we’re going to encounter some turbulence if things weren’t updated. So we updated them.
If you’re going upstream against a culture that doesn’t particularly value the importance of managing technical debt, as a product manager you can also prioritize feature-related work that is dependent upon the elimination of some technical debt. For example, you can include a requirement that a specific part of your app displays more quickly, knowing that a particular speed issue is tied to the underlying debt.
4. Encourage your development team to track technical debt in the same place they track other development items.
One list to rule them all. With technical debt, you’re essentially gaining some immediate benefit today and time-shifting a bigger project to the future. The idea here is that those tasks actually end up on the backlog where they can be tracked and prioritized along with other activities. If they’re being logged somewhere else they’re less likely to get done and less likely to be factored in during planning.
Keeping technical debt on your backlog also has the added benefit of emphasizing that addressing these issues is as important as addressing new development tasks. In other words, there’s not an “important backlog of new features” and an “unimportant backlog of technical debt.” Having everything in one place aids the prioritization process. You want to avoid a situation where a particular item falls through the cracks and remains undiscovered until something breaks.
Tweet This:
“Encourage your development team to track technical debt in the same place they track other development items.”
Another way to keep debt from falling off everyone’s radar is to track it as part of an epic and work with developers to groom that regularly. This ties into one of the questions we mentioned under the first tip, in that sometimes technical debt itself become outdated. It was noted as part of project A, but due to work on Project B it is no longer an issue. Or it was important to update part of product A, but, for example, you’ve moved a lot of that underlying infrastructure to AWS so now it’s not actually a problem. The important thing is to make a note of the debt and track it; put it somewhere to make sure the conversation is active, but keep it clean.
5. Empower developers to do some situation planning around technical debt.
As a product manager, you regularly get to do situation planning, prioritize work, and play with “what if” scenarios. Technical debt is a great vehicle to help engage your development team in similar activities. Make it part of your planning activities to let your development team make requests, build a wish list, etc.—you do this kind of exercise with your customers and their feature requests all the time. If developers were given X number of sprints or months just to address debt, what would they do? How would that change the product’s performance immediately and overtime? How would these changes impact the product roadmap?
You might realize there’s a huge benefit to addressing infrastructure-level projects before you embark on a set of new features and make changes to your product roadmap on the spot. You might not. But sharing your roadmap with developers while they share their thinking about debt-related priorities is a great way to relate these underlying issues directly to your roadmap (and to strategic goals like revenue, customer growth, etc.) It’s also a great opportunity to see how developers think about prioritization, problem-solving, and more. Activities like these can help product managers develop more empathy and strengthen that product-engineering relationship.
6. Plan reasonable workloads for sprints.
As we mentioned in the introduction, the easiest way to accumulate technical debt is to ask too much of your developers in too short a timeframe. Consult with engineers as you develop your product roadmap to ensure your expectations for timelines align reasonably well with their bandwidth.
At times, it’s going to be unavoidable to take on technical debt (and it’s definitely not always a bad thing to take on), but as a product manager, part of your job is to ensure the ongoing health of your product.
If technical debt starts to get out of control, you’re the one that’s eventually going to feel that pain, along with your customers and development team. If you can make addressing technical debt an organizational value across your product and development teams, you should be able to better ensure the long-term agility and health of your product. This has the added benefit of fostering better communication, empathy, and transparency between product and engineering.
Have more thoughts on how to manage technical debt as a product manager? Share them in the comments below.
