Outcome Driven Engineering Explained

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.