Ah yes - well, of course I have to turn every one of my life experiences into a tiresome product management metaphor these days. The story behind the boot is that it’s a bit old, and towards the end of the week the sole started to come away. I had to decide whether to get an entire new pair of boots for the rest of the week (expensive, nuclear option) or just kind of tape it up with my handy duct tape and hope it survived long enough (the cheaper option). I chose the cheaper option but got to thinking that this sort of thing happens when we build products, and it happens all the time.
At the heart of product management, we’re trying to make sure that we make the best, most impactful decisions for our users and our business. This means that sometimes we are presented with a choice; spend a very long time perfecting something or try to get something out quicker so we can deliver value sooner and (crucially) understand if it’s actually even valuable. We may end up compromising on functionality or taking a shorter term view on what we build. Maybe it won’t be scalable, or we’ll accept the risk that certain things have to be rewritten down the way as our understanding develops. This is where tech debt comes in.
has written a great article
on this, where he explains that tech debt is not
badly written, buggy code that is a disaster waiting to happen. Tech debt is simply a series of compromises that we make on purpose, based on what we know today, and we need a plan to pay it back later. It’s basically analogous to a credit card - you’re able to get things you want now at the expense of having to do something about that later. I’d also extend the metaphor slightly and say that some tech debt is like a mortgage, the most acceptable kind of debt, and something that can be paid down over a much longer time period.
A common question that occupies product managers & developers is “when can we pay this tech debt off?” It’s a good question, and the best product managers will be very conscious of tech debt, its implications, and the importance of paying it off. The best developers will be aware that tech debt doesn’t mean anything tangible to non-tech people and that they work for a business that has goals that need to be met. These people should work together to:
• Work out what debt actually needs to be paid off and when
• Find a way to frame that debt in a way that resonates with non-tech stakeholders
• Work out a pragmatic way to pay off the debt in stages
It’s important to be conscious of the fact that, in many cases, paying this debt off will result in a system that looks and feels identical to the system before. Making sure that the benefits are spelled out in as non-technical terms as possible (we can support 10x users! we can get that ISO certification our clients keep asking for! our help centre won’t keep crashing!) is critical rather than trying to persuade the CMO of the benefits of that React upgrade. But also, we need to challenge our developer counterparts to make sure that that any rework is necessary, iterative, small, and ideally runs in parallel to other efforts.
It’s a balance, but you’ve got to get it right otherwise you’ll end up in trouble when all the wheels fall off!