Outcome Driven Engineering Explained

What changes when you stop giving an engineering team features to deliver and instead give them an outcome to achieve?

In this episode of The Product Engineering Podcast, James explores Outcome-Driven Engineering: an operating model where product managers and engineers share accountability for creating measurable product impact.

Rather than starting with a predetermined solution, an outcome-driven team starts with the change it wants to see in customer behaviour or the product. The team then works together to understand the problem, decide how success will be measured, experiment with possible interventions and learn from the results.

In this episode

• What an outcome actually means in Product Engineering
• The difference between delivering a feature and delivering an outcome
• Examples including basket abandonment, product engagement and feature adoption
• Why Product Engineering is a cross-functional team model, not simply a job title
• How product managers and engineers retain different skills while sharing the same measure of success
• Why individual engineering metrics shouldn't replace team-level outcome accountability
• How an outcome-driven team moves from an outcome to measurement, experimentation and delivery
• Why you should decide how you'll measure success before you build
• Using prototypes and small interventions to test ideas quickly
• How learning can cause a team to refine, change or even abandon its original outcome
• Why shipping software is only part of the job — the real question is whether anything changed

The central idea is simple: instead of asking a Product Engineering team “What did you ship?”, ask them “Did you drive the outcome?”

Next episode: Accountability — how to create an accountability structure that matches the kind of work a Product Engineering team is doing.

Find out more at doproductengineering.com.

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.

Welcome to the podcast.

This week we're talking

about outcome driven engineering.

How can you take a product engineering

team and give them an outcome and have

that entire team, product managers and

engineers all have shared accountability

for delivering that

outcome until it's completed.

Hi, my name is James Charlesworth and

this is the product engineering podcast.

And in this episode, I'm going to talk to

you about outcome driven engineering.

And outcome driven engineering is one of

the core fundamentals of having a

well-functioning product engineering team

because product engineering is different

from traditional roadmap driven

engineering in that it doesn't

necessarily work towards delivery targets

and shipping features

and things like that.

It generally works towards business

outcomes and product outcomes that the

entire team can rally

around delivering together.

And that's a really, really crucial

difference because for a long time,

software engineering and product

management were seen as two relatively

different functions where discovery and

validation and all that kind of stuff was

done by product managers and then

execution and delivery and testing and

things were done by engineering.

Product engineering combines

those two functions together.

It doesn't combine the

individual jobs together.

You still have product managers and you

still have engineers.

But what it does is it puts everybody

together in the same combined

cross-functional team and it gives them

the same measure of success.

It gives them the same accountability.

And often that

accountability is driving an outcome.

So what do we mean by outcome?

Well, that word outcome in the context of

product engineering generally describes a

change that you're going to put into a

product or a change in user behavior that

you want that will drive some kind of

positive result or positive experience

with a product, but you don't necessarily

know what that change is when you decide

you're going to work on that outcome.

So that's why it's very different to a

feature or something like that.

Adding a feature in a product usually

starts from knowing what the feature is

and knowing why we're building it.

An outcome can often start

from a place of uncertainty.

So when you have an outcome you're going

to drive, you often don't know

how you're going to get there.

And then product engineering is the

process of working out what kinds of

things you should change in your product

in order to achieve that outcome.

So I'll give you a few examples of

outcomes just to make

this a little bit real.

Let's say you've got an e-shopping

website or something like that and people

are adding items into their basket, but

they're not checking out, they're

abandoning the basket.

Well, the outcome there might be we want

to reduce the number of

users who abandon their basket.

So in order to do that, you'd have to

change how the basket works, you'd have

to change how the product works.

And what that would do is it would change

the behavior of the users and then cause

them to actually

abandon their basket less.

You could add a number to that, a target.

You could say currently 10% of our users

abandon their baskets.

That's actually really good.

We want that to get that down to 5%.

And again, crucially, when you decide

that that's the outcome that you're going

to drive, you don't

necessarily know how to do that.

We don't know what feature to build into

the platform at that point.

We've just decided that we are going to

reduce the number of users who are

abandoning their basket

inside our application.

Another common outcome in particular that

SaaS products want is user engagement.

So let's say you have a subscription to a

SaaS product, how often you go back into

that SaaS product and how often you

revisit it is a really, really good

indicator of how much

value you're getting from it.

It's not always a one-to-one mapping, but

in general, the more often you return to

a piece of software or product, the more

value you're getting out of it.

So you can measure what percentage of

your users are returning, what types of

users return differently to others, and

you can design product

outcomes around those numbers.

So let's say you've got a specific

segment of users that you think should be

logging into your product every single

day, and you look at the data and you

find out that the median user is only

logging in three times a week or twice a

week, then you can say we want to

increase how often they go back into the

products to once a day, and that has a

bunch of positive business

outcomes associated with it.

Generally, people that use products more,

it becomes stickier for them, it becomes

much harder for them to switch away from

it, which will ultimately reduce customer

churn and things like that.

So outcomes like that are often tied into

like if you're a SaaS company, they'll be

tied to your core SaaS

metrics like customer churn.

So an outcome in a SaaS product might be

user rate or activation

rate on a new feature.

We've built something in the past and

people aren't really using it, so the

outcome there could be we want more

people to use this feature.

And again, we don't know how we're going

to get more people to use that feature,

but we're going to explore it, we're

going to try things out, we're going to

experiment, and ultimately we're going to

try and drive that outcome.

And that's the key difference between

delivering features and delivering

outcomes is that the accountability on

the entire product engineering team

becomes the outcome and not the feature.

And this means you need to kind of create

a more cross-functional

engineering team as well.

The term product engineering does get

used as a job title, but it doesn't have

to be people with the

title of product engineer.

You could have software engineers, you

could have front-end software engineers,

have DevOps people, and you

can have product managers.

If you put all those people into one

team, then they bring all of their skill

sets and all of their individual roles,

and that is one product engineering team.

So you create a cross-functional team

that still has all of

those individual skills.

Your product manager will of course still

be your product manager, and they'll be

bringing all of their product manager

skills and experience the team, and your

DevOps person will bring all of their

DevOps experience to the team.

But the entire team is the

cross-functional

product engineering team.

And that distinction is really important

because when you say to a team you're now

a whole as a group responsible for

driving this outcome, then you remove all

of the individual pieces of

responsibility that

people might think they have.

So let's say you are a DevOps person.

Often DevOps people hold themselves

accountable to uptime metrics and SLAs

and things like that.

And so if you're on a product engineering

team, but you've got one level of

accountability, front-end engineers might

hold themselves accountable to like the

bundle size on the front-end, or whatever

it is, the important distinction is that

you need to remove some of those

individual pieces of accountability and

make the entire team

accountable for everything.

You're not going to drive that outcome if

your stack falls down every five minutes.

So the work that the DevOps person is

doing is important for the outcome, but

they're not individually

accountable for doing it.

You're not going to drive that outcome if

your product manager isn't doing

discovery and talking to users.

So again, the work that your product

manager does fits in that overall

outcome, but you're not judging that

individual product manager on how much

discovery they've done.

Just like you're not judging that

front-end engineer on how many UI bug

tweaks or anything like that they've

made, you're judging the entire team on

how effectively

they're driving an outcome.

So the actual process of outcome driven

engineering follows a bunch of stages.

And it usually assumes that at the start,

you don't know how you're

going to drive that outcome.

Now you might have an idea, you might

have drawn up on a whiteboard a bunch of

possible solutions, but the ultimate goal

is to get to the learning of what's going

to drive that outcome.

So outcome driven engineering teams will

go through this iterative process that's

a little bit different to the iterative

process that a delivery

team on a roadmap might do.

Software engineers working to a product

roadmap, they still use iterations.

They'll do development and testing and

then shipping it and then iterating it,

but they'll generally do that within the

confines of a chosen solution.

So if you ask a roadmap driven team to

build a feature, then they

will iterate on that feature.

Maybe they'll build the API first and

then they'll do an iteration, they'll add

some front-end and

all that kind of stuff.

But ultimately you've already told them

what feature you want them to build.

If you've got a product engineering team

that's outcome driven, you haven't told

them what they're going to build.

You've told them what

outcome you want them to drive.

And then they go through the iteration

process where learning and discovery and

delivery are all part of one large

outcome iteration process.

So the process typically goes like this.

They will start with their outcome and

they will try and define what their

outcome is and how

they're going to measure it.

So let's say for example you are trying

to increase the rate in which customers

come back into a product, then you can

define that outcome as we want to

increase the rate from two times a week

to every single day.

We want this particular segment of users

to be logging into our product.

Then what you do is you work out how

you're going to actually measure that.

So we're going to measure

it with product analytics.

We're going to measure

it with general analytics.

We're also going to measure it by talking

to users as well so we can get their

feedback from whether they hate it,

whether they're logging in because they

have to or whether they're logging in

because they need to.

And then what you do is you take that

measurement system, you decide, you know,

make sure it's reliable, and then you

apply it to where you are today.

So you've got a measurement system that

says how often people are

coming back into your product.

You look at your product at the minute

okay people are coming in three days a

week, the P50 for that median is three

days a week, so we want to

drive it to every single day.

So once you've got that measurement

system in place and you're happy with

your ability to collect those kinds of

measurements and collect that evidence,

you can then go and

start thinking of solutions.

So there's a bunch of different ways you

could try and get people to

come back into your product.

You could maybe send

them out emails and things.

You could maybe do some things

autonomously so that when they do log in

they can actually see

something's happened.

You know there's a bunch of different

ways you could

redesign the user interface.

You could make it mobile optimized.

You can make maybe some people you've

only got it working on Google Chrome and

they're using Safari.

Like there's a bunch of different reasons

why people might not be coming into your

product and so you can start

experimenting with those things.

So once you've got a way to measure the

outcome the team can start having ideas

and it's important that it's the team

here because often you know in a

non-product engineering sense it will be

the product with all those ideas.

In a product engineering model it's the

entire team, the cross-functional team of

product managers and engineers.

They all get together and they put their

heads together and they try and think of

some things that they can do, some

interventions that they can make in the

product that will try

and drive that outcome.

And then they go ahead

and they prototype those.

AI is really useful here.

You can grab Claude code and you can

build a small prototype of something and

then you try and use that measurement

that you'd set up in the first step to

make sure that prototype is actually

going to drive the outcome and if it is

then you can iterate on it and you can

make it production ready and you can try

it with some more users and then you can

continue iterating and ultimately you

know you can drive that outcome.

It could be that there's two or three

different things or different things you

can change inside the product.

So again you could do three or four

pieces of work to try

and drive that outcome.

But ultimately you're never going to get

it right first time, you're never going

to know because

there's too many unknowns.

So the most important thing is to be able

to prototype and then test out those

prototypes based on the way that you said

you were going to measure your outcome.

So this is a really really important

point but when it comes to measuring the

success of a prototype it's absolutely

vital that you've decided how you're

going to measure it before you put the

effort into building that prototype or

coming out of that idea because what you

don't want to be doing is retroactively

adding measurements or something on

something afterwards.

What you don't want to be doing is just

purely relying on feedback because you

know anybody that's worked with in a

discovery process or done validation if

you put a prototype in front of a user

and say do you like this they will often

just say yes that's not useful data.

You need to actually observe them using

it over time and you need to collect much

more intelligent product analytics data

to work out if that prototype is the

right direction to be going on.

So that is an iterative process and what

happens as you go around that you'll

build up more knowledge about what could

possibly drive that outcome.

So let's say you are trying to get users

to come back into your

software more often than they do.

As you try out different prototypes you

target different sets of users you will

start to build up much clearer picture of

what's stopping people from using your

product and then that will help you steer

the actual interventions that

you make inside the product.

It could be that you haven't actually

classified your users properly so it

could be that one type of user is going

in more than they necessarily need to and

another type of user isn't going into

your product as much as

they need to be doing it.

So if you can make that distinction then

you've learned something there you've

learned that maybe your outcome shouldn't

be increasing the number of users that

come back into the product maybe your

outcome should be increasing it for this

one particular segment of users and maybe

even decreasing it for those maybe you

could automate some of

why they're logging in.

Your outcome can as you

learn more about how it works.

So again it's important to be able to

revisit the actual outcome it's important

to be able to do an iteration try

something out experiment gather some

evidence measure it and then refine where

you're going to go with the outcome.

It's also possible that you could

completely abandon that outcome if you

discover something more important.

So it could be that it doesn't matter if

people come into your platform once a day

maybe you've got an MCP server and people

can do everything that they need to do

just by using your MCP server in their

Claude instance or something like that so

maybe you just double down on that and

you make it so that it doesn't matter if

they log into your platform every day.

So that outcome can shift and it can

change based on the learnings.

So you start with an outcome which is get

people to log into our platform every day

and then you learn you experiment you

discover more information and by I mean

product managers and engineers they all

get together they all try out ideas and

then they all look at the measurements

and decide where to go next and it has to

be a collaborative process.

People do like I say have different

skills and they contribute different

things but ultimately the entire team has

to make the decisions and they have to be

happy with decisions and the reason they

have to be happy is because you're then

going to hold that product engineering

team accountable to being

able to drive that outcome.

So if you say to a team we want to drive

adoption inside the product you then need

to be able to turn around to them in a

month or two months or whenever the

review period is and ask them did you

drive adoption in the

product that's the main question.

I don't you know we don't necessarily

care what you shipped we don't care what

your cycle time was or what your review

process was we care did you drive

adoption inside the product and you

should be able to ask that question of

any member of a product engineering team

you should be able to ask the back-end

engineer did you drive adoption in that

product what are you using to measure it

just as effectively as you could ask the

product manager that because the entire

team should feel aligned around that

outcome and they should be holding

themselves accountable for

driving that outcome as well.

Next week we're going to talk about

accountability and a bit more and how you

can set up an accountability structure

and how you can line the accountability

structure to the work itself but I hate

this has given you a little bit of an

insight into what an outcome actually is

and how you can try and develop outcomes

that will drive your product engineering

teams towards positive business value and

not necessarily measure them by what they

ship but measure them by what

actually outcome they drive.

So join me next week when we're going to

talk about accountability that's it from

this week I hope you're enjoying the

podcast please do like and subscribe and

give me any feedback it's do

productengineering.com you can find my

email address on there I really

appreciate feedback this podcast is still

super super new so anything that you want

me to talk about in the future please do

tell me or if you just want to steer it

in a certain direction then please do I

will have guests in the future if you

want to come and guest on this podcast

then send me an email as

well and we'll sort that out.