The Product Equivalent Of Technical Debt

Software teams are used to talking about technical debt, but products can accumulate another kind of debt too.

Outcome debt builds up when features are shipped without confirming whether they achieved the result they were intended to produce. Over time, products become filled with decisions, assumptions and features that may once have made sense, but are no longer delivering enough value.

In this episode, James explains how outcome debt compares with technical debt, why it does not necessarily mean that anyone made a bad decision, and how changes in customer behaviour, technology and the wider market can cause previously successful features to lose their effectiveness.

The episode also explores how outcome measurement helps teams identify outcome debt, why sunk costs make weak features difficult to remove, and how teams can address technical debt and outcome debt together.

In this episode

• What outcome debt is and how it accumulates
• The similarities between outcome debt and technical debt
• Why good product decisions can become outdated
• How changing customer behaviour creates outcome debt
• Why measuring outcomes reveals problems that delivery metrics miss
• The role of sunk-cost thinking in product decisions
• How to reassess older features using current evidence
• Combining product improvements with technical refactoring
• How leaders can create space to address outcome debt without assigning blame
• Why established products must continually revisit earlier decisions

Outcome debt is not evidence that a team failed. It is a natural consequence of building products in a changing environment. The important question is whether teams regularly return to previous decisions, measure their continued impact and improve or remove the features that no longer serve the product.

The Product Engineering Podcast explores how software teams can move beyond shipping features and take greater responsibility for measurable product outcomes.

What is The Product Engineering Podcast?

The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.

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