Debt Relief for Product Teams
One of the strange realities of my life that I’ve come to terms with is that Pandora serves me up non-stop debt relief commercials in between songs. My best guess as to why this is happening is that I’ve broken their ad targeting algorithm through a combination of (a) 80s music playlists and (b) credit card signups. But after years of listening to such offers, I’ve become very familiar with the formula for getting debt under control:
stop adding more
start consolidation
prioritize the list
find leverage points
make an actual dent
repeat until relief
And this approach is something that can be utilized by software teams to wrangle product / technology debt as well. Let me elaborate:
[1] Stop Adding More
The first rule is to simply stop chasing a moving target; prevent new debt from accruing. This means changing any behaviors (e.g. short-sighted architectures, one-off features, etc) that are continuing to increase the debt balance. If you can’t completely put a stop to the buildup then at least slow it down. All of this implies you have a mechanism to both measure debt overall and its accumulation. In addition to instrumentation, process is key to ensuring that any attempts to add more debt are discussed, with the additional benefit of just plain making it harder to do so by having to go through more hoops (i.e. the default path is to layer decisions to compound value vs aggravate debt).
[2] Start Consolidation
Once you have a (mostly) static pile of debt to clean up, you have to organize it into a consolidated list. Whatever your tool of choice, it’s critical that it simplify access and collaboration; managing debt on a product team involves the entire cross-functional group. You make it easy to add and drop things from the list because it needs to remain up-to-date and accurate; when there is the inevitable org change or talent transition, you don’t want to be reliant on triable knowledge to keep track of debt. Lastly, having the list in a tool ensures visibility (for sprint planning, for quarterly reviews, etc), which is key to alignment on how to tackle it.
[3] Prioritize the List
When it comes to prioritizing the list of debts, keep in mind that the goal is not only reduction in debt, but also what you can achieve once you’re free from it; you need a north star metric. Some of the more meaningful outcomes I’ve seen teams achieve by shrinking debt are increasing feature velocity, reducing support costs, creating innovation bandwidth, accelerating delivery pace, and improving product quality. Once you know the end result you’re aiming for, stack ranking what debt you want to tackle first is a much simpler exercise - you may even realize your goal is not to get to 0, but rather just to a point where it’s no longer a hurdle to your larger business objectives.
[4] Find Leverage Points
As you start actually eliminating debt, it helps to model a dependency graph - you should be able to distinguish superficial debt from systemic debt. You can think of systemic debt as the root cause of multiple superficial debts - for example a legacy monolithic architecture results in service hotspots and dependency deadlock. With this framework, product teams can actually have a reasonable debate on whether to (a) start with low-hanging fruit (i.e. superficial debt) in the interest of building up the muscle or (b) go after higher ROI legacy issues (i.e. systemic debt) that take longer to address but builds a foundation. Getting more sophisticated on understanding debt also leads to conversations around creating multi-purpose services, building vs buying core infra, and end-of-life-ing rarely-used features.
[5] Make an Actual Dent
One of the biggest mental hurdles to overcome with debt is the feeling that it’s insurmountable - getting a “win” and starting to show progress is paramount. The visceral feeling of seeing a list of issues getting shorter helps keep people motivated to go after this type of work. There is actually an argument to be made that starting with low-complexity / low-value debt removal in the interest of getting a quick win is a sensible strategy, as it bootstraps the flywheel to a degree.
[6] Repeat Until Relief
Finally, debt management, like any other best practice, needs to be operationalized vs one-and-done. Reducing debt is an ongoing product team responsibility on the same level as feature delivery, and part of a balanced diet approach. Whatever an organization’s product development playbook is, it should weave in the 5 steps above throughout the lifecycle.
I’d love to hear from readers on the approaches they’ve taken to get a handle on product debt - please chime in via comments👇. And if you enjoyed this post, please consider subscribing.
further reading / references
layering product choices allows you to compound value vs exacerbate debt
there are plenty of hacks around creating and curating prioritized lists
managing software debt hinges on understanding the product lifecycle
all workstreams in a company boil down to a sequencing of loops
a product team that has a healthy diet actually has 4 food groups
ReForge sees tech debt as a strategic success lever (vs a burden)
childish drawing / interpretation
