The Product Equivalent Of Technical Debt

So if you work in software engineering, you're probably familiar with tech debt and you've probably spent a large portion of your career Tackling with tech debt trying to fight for space on the roadmap with tech debt Well, what if I told you that there's another type of debt that you now need to be aware of and that's called outcome debt Hi, my name is James Charlesworth and this is the product engineering podcast and today we're talking about a concept of outcome debt Outcome debt is the debt that accumulates inside your product when features that you shipped have not been measured Against the outcomes that they were trying to drive and it is a little bit similar to technical debt But it doesn't live line by line in the code. It's not the way that the functions are refactored It lives in your product and the product decisions that you've made are not verified at any point in the future afterwards So let's compare it to tech debt them. You probably already know what technical debt is But I'll give you a quick refresher Technical debt happens when you add more code into a code base and you don't stop to go back and refactor it So you add features in and instead of refactoring the stuff underneath you just add them on top So imagine you're building a house and you have a small foundation and you need to add more rooms onto that house Eventually if you stack rooms on top of each other so that you have a seven-story building with only like a few feet at the bottom You're gonna find that house is gonna feel very unstable So what you need to do is go back and dig some bigger foundations That's the kind of analogy for technical debt technical debt the code base underneath your platform your architecture The decisions you made when you were first writing it They are the foundations that hold up the rest of your product and sometimes it you do need to go back and change those foundations Some systems that were built for a certain amount of scale simply can't support a certain number of features without a massive amount of refactoring Technical debt can also come about when the industry shifts around you So technical debt can appear like accidentally just by the nature of new things coming out So if you built something with something like angular.js 13 or 14 years ago You've got technical debt just by nature of angular.js kind of being a bit obsoleted by now You have that technical debt through no fault of your own You might have had a perfectly well-designed angular.js app 15 years ago But now that angular.js app is legacy and it contains technical debt that just is there because Angular.js is no longer supported and there are better ways of doing things So technical debt doesn't necessarily mean this is a very important point and we're going to come on to this as well Technical debt doesn't mean that you've made the wrong decision Technical debt is just something that happens when you don't go back and refactor things in the future So one of the reasons that engineers find it very difficult to fight for technical debt on the roadmap Is because they see it as a kind of failure even intrinsically They see it as or it can sometimes come across as I didn't build this right the first time And it's really really important if you're an engineering manager or you're a product leader It's really important when you hear about technical debt Don't attribute blame to it because a lot of the time technical debt does not come about by somebody's fault They were the right decisions that were made at the time It's just so happened that new things have happened and we need to go back and change those decisions now Doesn't mean they were the wrong decisions. It doesn't mean we didn't build for scale So what does this all have to do with outcome debt? Well, all of what I've just said Translates to product outcome debt as well outcome debt accumulates when you're shipping features inside a product And you're not checking whether those products are actually achieving a certain outcome So you have a lot of uncertainty in your product because you've been focusing on getting stuff out the door And you've not been focusing on actually going back and refactoring parts of your products to make sure That those features are actually delivering the value that they were required to deliver It's very very unusual for a feature to get it right the first time at least 100 percent right And a lot of teams will settle for a feature that maybe achieves 60 of the solution to the problem and they'll just think okay That that problem solved and if you only achieve 60 of a solution and you leave 30 of a solution unaddressed Then you've accumulated outcome debt Because it is possible to build products that can achieve 100 of what you're trying to do You just need to constantly go back and readdress why you are building those things and what you can do to tweak things in the future And the way to diagnose outcome debt is in the previous episode We talked about measuring outcomes instead of outputs Well measuring outcomes is the way that you can diagnose outcome debt Because once you've worked out how you're going to measure the outcome of a feature Then you can use that measurement to apply it to previous features that you've shipped and you can work out which one to actually Achieving the outcomes in which ones are if you have features that are in your product and they work perfectly But they're not achieving the outcome. They were supposed to achieve then those features are Outcome debt and you probably do need to go back and redesign a few of those things maybe take some things out It's just something that happens over time and just like with technical debt I told you that technical debt can happen by accident because the industry shifts around you the exact same thing can happen with feature Outcome debt as well So if you build a feature that is the right solution today But maybe in the future the way that people use your product radically changes and that feature no longer serves their use case So for example Let's say you're working on a product that has a user interface where people can go in and they can check something And then in the future the trend is much move Well, like as it is at the minute the trend is moving towards people using external tools like slack or clawed or something like that And then really you think that that feature could probably be an mcp tool or something So people want to interact with that feature through an external external third-party integration And you didn't build that integration because people weren't doing that when you designed that feature So even if you built the right perfect feature at the time Because the user behavior has changed and the industry has changed that feature has naturally accumulated Outcome debt and the outcome of that feature has drifted away from the original successful outcome that you had And that's just the same as a technical architecture that can seem great at one point and in the future It can seem obsolete just because the world moves on around it So it's important just with technical debt not to think that we built the wrong things or we built substandard features That's often not the case It's often the case that you did build the right things But then the world just moved on user behavior changed market trends changed expectations changed And suddenly those things that used to be correct are now not correct anymore You've accumulated some outcome debt and you need to go back and fix it And the sunk cost fallacy plays into this as well because like with technical debt a lot of people when they're accumulating technical debt Will think well, we've already built this thing now We like we need to cling on to the architecture that we've already chosen And often the correct solution is to go out and rip out that old framework or redesign that architecture or change that database That often is the right solution and that will address some technical debt But sunk cost fallacy builds in where you double down on the things that you've already done That's particularly important with outcome debt because if you're building features and you've put a lot of effort into validating and Like constructing and shipping those features Then you will naturally cling on to those features in your product Even if it turns out that they weren't necessarily the right features to drive the product forward into the future So be conscious of that be conscious of are you clinging on to stuff in your products? Because five years ago, it was the right thing to build Measure those things against the outcomes that they're supposed to be driving today And if they're not then maybe you do need to go and make some of those hard decisions And if you listen to my last episode in this podcast where I talked about measuring outputs in the mac and mara fallacy That can play into outcome debt as well because if you just over index in shipping successful stuff That's successful at the time and you'll miss the ability to go back and review new evidence and reassess those things Based on new information, which is always really really important Just like with technical debt you with technical debt you address it by looking at the entire code base holistically through a modern lens And thinking if I was to redesign this today, what would I do differently? Well, you need to apply the same thinking to features that you've delivered inside your product in the past Look back at them and think if we were solving this same problem today, what would we do differently? It's likely that you would do things differently for whatever reason and that's no shame in the people that originally did it But you do need to do that process you need to go back and address that outcome debt And often addressing that outcome debt can be done at the same time as technical debt as well Because technical debt as we said at the start is very difficult to get onto a product roadmap But addressing outcome debt is much easier to sell because if you can say we're just going to go and tweak this feature We built two years ago because new information has arrived and we need to make it even better That's going to better drive a business outcome. You can often accumulate you can often address technical debt at the same time So we're going to go and replace a feature that uses this email service for one that uses a newer email service Well, guess what that old email service was technical debt in your code as well So you can go in and use modern frameworks and do some refactoring So you can have a sprint of addressing outcome debt and technical debt at the same time if you're smart about this And the important thing is that you do do it just like with technical debt. The important thing is that you do do it And the other point then is how you sell this So technical debt is often sold by engineers to product leaders Technical debt is often the case of engineers identifying that they've accumulated some technical debt and then having to pitch for it Having to say can you please give us a little bit of time so that we can Fix this problem. We were just telling you about now Well outcome debt is going to have the same problem, but it won't be with product managers outcome debt is often product managers go into their bosses to the executives to the stakeholders and saying We need to go and change this thing that we built a year ago And they're going to have the exact same problems that engineers have where again That idea of blame is going to creep in and you need to be very very conscious of an organization Not to blame people for flagging and asking for some time to fix both technical debt and outcome debt Because they're both things that do need to be fixed if you ignore them Then your product will end up just a big mess of features that no longer work Just like your code base will end up as a mess of code that no longer works together anymore and it's very very inefficient One of the reasons why startups can be so successful in a very narrow product vertical with a point solution Is because firstly yeah, they don't have very much technical debt. They can build a brand new code base But also they don't have very much outcome debt So startups, um also suffer from survivor bias The startups that have managed to solve a problem very elegantly are the ones that survive and they're the ones that you see You very rarely see all the startups that built the wrong set of features And so it can look like startups are amazing at building small point solution products, but that's not often the case Firstly, they have not accumulated any outcome debt yet Secondly, they haven't accumulated any technical debt yet and the word yet there is very important And thirdly you're only looking at the startups that did successfully do it So if you're working at a larger organization that doesn't have the luxury of a brand new code base and a very small product vertical If you're working in a bigger company or in a bigger product Then the only way to combat this is to constantly try and reassess what outcome debt you're accumulating inside your product What features have you got that are just getting in the way and maybe making things worse and what can you redesign? Re-factor and also, you know address technical debt for at the same time