Editor’s note: This piece originally appeared on the Logi Analytics blog.
Technical debt is the bane of every product manager—but what is it? Very simply, technical debt is when you haven’t built capabilities into your underlying software platform that are necessary to deliver the next set of features for your customers. Often as a product manager, you may be eager to deliver new features to a customer, but when you describe those needs to your technical team, you find out that those exciting new features actually take a long time to build.
You can improve your projects—and save your team time—by learning about what causes technical debt and how to manage it.
Five common causes of technical debt
In order to avoid amassing technical debt, you first need to understand how it accrues. Technical debt can come from several common sources:
1. You’re addressing a new capability.
Maybe you’ve run across something you haven’t dealt with before but now need to address. If you fail to identify key enablers for this new feature set, you might end up creating technical debt as your team needs to build the architecture to support your new capability.
2. You rushed your work.
Another possible cause of technical debt is lack of time. Your team built something too quickly—and maybe took some shortcuts to get there—and now you’re going to pay for those shortcuts.
3. You prepared too much.
This may be surprising, but overbuilding early in a project can also cause technical debt. Requirements often change as projects go on, especially longer projects. If you build too much at the beginning, you risk having to redo work later on when the technologies have changed. As much as your engineering teams may want to get ahead of the curve and build underlying architecture early, doing that may leave you paying for it down the road.
4. You’re building to the next feature.
While overbuilding is one source of technical debt, underbuilding by only thinking of the next checkpoint can also create technical debt for you. If you’re not anticipating what will come beyond the next feature, then you’re basically starting cold every time you start up a new feature. Not anticipating potential new capabilities when starting a new feature can cost your team as much time as building too much too early.
5. You’re building when you should buy.
While your engineering teams will often want to build everything themselves, that’s not always in your best interest. If the thing you’re considering building is available through third-party tools, has use cases or capabilities that are well-established, or is complicated and not core to your own IP, then you should probably buy. Otherwise, you could find yourself with a bunch of sophisticated requirements and a community building out a solution that you ultimately could have gotten for less time and money – and put your team to better use elsewhere. For instance, if you are looking to add analytic capabilities to your product, investing in a comprehensive embedded analytics platform can help stop the accrual of, and even reduce, technical debt.
What it boils down to is that technical debt can slow you down in terms of being able to respond to the market as quickly as you want to or delivering those features you’re trying to deliver.
Can technical debt be beneficial?
While technical debt can cost time and money, sometimes you’ll actually want to create technical debt on purpose.
For example, if you’re testing a feature or need to get to a feature or fix on a tight timeline, you might build less than the platform you eventually need so that you can get to market and get feedback faster. You’re making a choice—create technical debt now in order to satisfy another need. If you’re doing a good job, you’ll also make the choice soon after creating that technical debt to take steps to pay it down.
There is no “zero ideal” for technical debt. You have to understand when you’re choosing to generate it, avoid making decisions that will generate too much, and then manage that technical debt by paying it down over time. If you invest ahead and pay down your technical debt, it won’t slow down your velocity for feature delivery into the field.
How do you manage technical debt?
Since there is no zero ideal for technical debt, monitoring and managing it becomes that much more critical to your team’s success. There are two primary things you’ll want to balance, and they tie into two of those common sources of technical debt:
- Overpreparing. If you build too much architectural ramp, you’ll spend too much time building the ability to deliver features and not actually delivering those features. Features, frankly, are where the value lies, so you don’t want to divert your energies too far away from the actual value delivery.
- Underpreparing. If you spend no time preparing, you might have a release where you deliver a lot of great features, but then have several releases where you deliver nothing. By underpreparing, you don’t have a runway to be able to deliver the next set of features. Since features are where the value lies, underpreparing can be catastrophic for your product, especially if you’re in an early product launch. If you don’t have the appropriate architectural runway, and you end up paying down a lot of technical debt, your ability to deliver value into the market can be frozen.
With managing technical debt, the thing to really keep in mind is that balance is key. You’ll have to balance the desire of your engineering team to build out everything they think they’ll ever need against the desire of the business to only focus on features that will deliver immediate value. You will always have some form of technical debt—and that’s okay. If you can perfect the high-wire act between the amount of technical debt that exists at any point and your ability to deliver features that have value into the market, you’ll be in good shape.
Key takeaways
- Don’t build capabilities that won’t be needed for months down the road, as more than likely requirements will change before that time arrives.
- Technical debt isn’t necessarily bad, and can often be used to benefit a project that is rushed or needs immediate feedback.
- Balance the desire to build outright with the ability to deliver features that have value into the market.
- Think about balancing the innate desire of your technical team to overbuild in preparation for the future with your ability to deliver features that have value into the market.
