Returning from holidays and thinking about technical debt
I'm back and in one piece
Showing typical lack of foresight I started a newsletter then went on holiday. I went snowboarding for the first time in 9 years and just about survive. Here's a picture of my taping my foot together to avoid having to spend hundreds of pounds replacing a boot. We'll come back to this shortly - I promise it's relevant!
New podcast episodes
I've released 3 podcast episodes since the last update. I won't spam you with all the cover art but you should definitely go listen to them
I talked to Derek Osgood, founder of GTM platform Ignition, about the importance of having a coherent go-to-market plan for your product releases. This is certainly something that, working in B2B product management, is a constant pain point and it was interesting to hear Derek's thoughts about how to make it better.
I also talked to the wonderful Holly Hester-Reilly, founder of H2R Product Science, about her 5 step product science programme and how she believes that it can be applied to any type of company and help them make great products. Holly also runs her own podcast and I'll be appearing on that some time soon.
And finally, I spoke to Katerina Suchkova, product leadership coach and founder of Ahead of Product about a subject that is dear to my heart; the tricky transition from individual contributor to product leader, what it means & whether you even really want to get there.
Better listen to these quick, because this weekend I'm releasing an episode with the one, the only, the incredible Melissa Perri, author of the amazing Escaping the Build Trap. Stay tuned!
But Jason, what about that boot?
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.
Allen Holub 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!