For product teams, it's all too easily get caught up in building outputs instead of achieving outcomes.

‍

In this 30m webinar, filmed for Canvas Conference 2021, we’re looking at outcome thinking and how it can help product teams build the right thing.

This session covers:
- What outcome thinking is and how to define outcomes
- How to move from outcomes to action
- How to monitor progress and work out if you’ve achieved your outcomes

‍

This webinar will be especially relevant for strategy, design and product teams who:
- Struggle to manage and prioritise feature requests from senior stakeholders
- Feel there’s a lack of alignment between business objectives and user needs
- Need to maximise impact with limited resources or investment

‍

"You've got to be really clear on who your users are, what changes you seek to see in their world that will make their lives better, and how your product can play a part in that."

‍

‍

-

‍

Video transcript

‍

Hi there and welcome to this Canvas 2021 webinar. My name is Ross Harper. I'm a Digital Product Manager at 383 and today we're going to be talking about how to use outcome thinking to help your teams build build the right things.

Here's a sneak preview of what's coming up over the next 20 to 30 minutes. We'll start off with talking about outcome thinking, so, what it is and how it can help us define the right things to build. Second, we'll look at defining outcomes, so how to take a step back from what's going on and understand the outcomes that you're looking to achieve for your organisation and for your users. Then we'll move on to outcomes to action, so, once you know what it is you want to achieve, where do you start in trying to define the right things to build in order to get your organisation and your users where they want to go? Then tracking progress, so, once you've identified solutions, how do you make sure that your organisation knows whether or not it has achieved the outcomes that it looked to seek?

‍

Let's start off by talking about outcomes and what we mean by them and outcome thinking. Outcomes as defined by Josh Seiden in his book Outcomes Over Output - which is a really good book, it's a really quick read, would highly recommend it - he defined outcomes as the changes in the customer, user, or employee behaviour that lead to good things for your company, your organisation, or whomever is the focus of your work.

It's a really clear definition, there. Really, it is all about the change that you seek to see in, as he says, your customer, your user, employee behaviour, that lead to good things for your company. Really, it's that dual aspect that we're really interested in here.

‍

Just to be clear, we're really focusing on outcomes over what we call outputs. This screen here really helps to illustrate that. So if our aim in an afternoon was to keep our children entertained, we could look to build them the most fancy theme park in the world, with lots of expensive slides and things to do. That's what you see on the right here, and that's being output focused, where you're thinking so much about the thing that you want to build. Versus the outcome, which is what we see on the left, which is just taking children out into nature so they can explore things and have adventures that they create themselves.

The outcome that we're seeking is for the children to have fun and to explore. Really, if we think about the outcome over the output, we can find out the way to go and solve that problem, which uses resources efficiently. The more efficient that we can be at achieving those outcomes, the more that we can do, because we're not having to spend so much time and money building expensive things that aren't really necessary.

‍

As I said earlier, outcomes can relate to both users and organisations. Let's dive into a bit more about what we mean by that.

For user outcomes, really, this looks like the positive change that you want to enable for your users. This is imagining them in the future where they have been able to solve a problem that they really struggled with previously. Things became easier for your users, you managed to save them money, you managed to bring them joy, whatever that might be, whatever the change is. You've got to be really clear on who your users are, and what change you seek to see in their world that will make their lives better, and how your product can play a part in that.

The flip side of that is your organisational outcomes. We want to do all of these things for our users, but we also need to see a positive business benefit so that we can keep doing more of this. We really need to be focused on the organisational outcomes, the positive impact that the product has on your organisation. These can be both tangible, so, potentially generating revenue, or it could be intangible, so, things like your brand perception in the marketplace, if that's something that you're looking to move from one position to another.

Really, we want to look at how to achieve the user outcomes in a way that achieves our organisational outcomes, and finding out the right things to build that allow us to do those two things while making effective use of our resources, so that we're not doing things which are expensive, time consuming when they don't need to be.

‍

As I said, there is a clear link between user outcomes and organisational outcomes. If we were to go and solve users problems and make their lives better, that would be great. But we've also got to make sure that we keep paying the bills, we keep doing the things that we need to do for our organisation to keep being successful. We need to look through that lens of, if there's a customer problem to be solved, what's the opportunity for the organisation?

Likewise, the organisation could find lots of ways to potentially make money, improve their brand reputation, but if those aren't offering real utility for users and helping to achieve their outcomes, then these are likely to be things that won't even be touched by the user and therefore ultimately not achieve organisational outcomes.

The two are very clearly linked. There's a clear value exchange happening that we need to be clear on when we assess any potential thing to build.

‍

Now we've talked about what outcomes are, how do we go about defining outcomes within an organisation? First, we have to start by listening and asking a lot of questions, both to stakeholders in the organisation and to users, so we can really find out who they are, what they're trying to do, and how our products and services can potentially help them. Asking questions is key to build up a picture of where we want to go and where our users want to go.

We also need to start diving into data to help refine that position. If we're looking at organisational growth, are we looking at user growth from where we are today to where we want to be? Is it growth in revenue? What step up are we looking to achieve?

From a user's problem, if, say, users are struggling to do a job, what's the fallout rate that we're seeing through that process? What's the target that we'd look to achieve if we were to go and solve that problem? You want to see that, if users are raising complaints about a particular issue, are you seeing that in your data?

Same for the organisation; if stakeholders are saying, we need to go and improve this aspect of our organisation, that needs to be backed up by data as well, so that you've got a clearer picture of where you are today and where you want to be in the future.

‍

In terms of user outcomes, when we look to define exactly what those are, what outcomes might we seek to deliver? We've raised a couple of examples here, just to get you thinking about your own organisation and what these user outcomes might potentially be.

For any product or service that we put into our user's hands, the change that we seek to make in their lives could be that we help them solve a problem. It could be to reduce friction in their lives. It could be to save them money, say, for a comparison site, as an example. It could be to save them time or increase convenience, if something is particularly difficult to do, has many steps. It could be to help them gain social kudos, so, by using our product, your friends will see you in a whole new light, something like that. It could be any number of things and it's important to figure out who your users are, what they're struggling with, and how you can potentially help them.

From an organisational perspective, we could maybe seek to seek one or more of the outcomes below, potentially. For example, to generate more revenue, acquire more customers, or better retain existing customers, if you're managing to attract them but not keep them. It could be to change the brand's reputation, either from being viewed as a poor brand to do business with to one that's easy to do business with, or one who seen is quite traditional and would rather be seen as more forward thinking. It could be to gain a competitive advantage, having the ability to do something that your competitors cannot. Or it could be something like societal changes, that's the organisational change that you seek.

Whatever it is, it's really clear to be in contact with your stakeholders to understand where they want the business to go and how your product team can help them get there.

‍

The organisational outcomes that we discussed just there were more external facing, the things that the organisation, how it wants to be perceived and how it generates money externally. If you're building a product for internal use, potentially internal software, there are internal outcomes that you may seek out. These could potentially be to gain efficiencies. It could be to reduce costs. It could be to gain internal capabilities, so, being able to do things internally that couldn't be done before. It could be to generate a cultural change within the organisation, say, if people initially thought that doing things in the company was very difficult, there was a high turnover in staff that could enact a cultural change, if you can fix those problems. It could be legal compliance; GDPR has seen many companies have to build software in order to solve those problems. It could be to gain wider buy-in. So, if there is a transformation that the organisation seeks to enact, they might need to, say, build a pilot in order to rally people around internally and continue that change forward.

‍

That's an overview of what these outcomes could look like and you need to go and do that research with your stakeholders, with your users, in order to build what we call an outcome map.

This is what the process of outcome mapping looks like. At the top of your outcome map, you have your organisational outcomes. That could be, as we said, potentially generate more revenue, better improve customer retention. This is the benefit to the organisation and helping the organisation get where it needs to go.

In order to achieve these organisational outcomes, you then need to think about what it is you can do for your users. These are what we call user outcomes, and there could be many different things that you can do for your user in order to satisfy your organisational outcome.

If we were to focus in on a particular user problem and the outcome that we seek to enact for them, for that particular problem, there could be multiple solutions. This way of thinking really helps to broaden our horizons into all the different ways that we can solve these problems. If we just went for the first one that we thought of, that could be, as we talked about earlier, an output which is time-consuming, resource-heavy, expensive to build, potentially difficult to use. What we want to do is think of all the different ways that we can solve these problems so that we're picking the one that makes best use of our resources and has the greatest likelihood of achieving the user outcome, which will then achieve our organisational outcome.

Once we've identified a solution that we like the look of, that seems to fit the bill, we then need to go and test. We need to devise some experiments to assess all the different risk factors around the idea, de-risk those so that, again, we're just making sure that we're building the right thing. We're building something that's not going to trip us up, either in its feasibility, it's usability; we want to go and assess these factors before we actually commit to building anything.

‍

This is what an outcome map looks like and we'll be revisiting this with an example later in the webinar. Now we've defined what outcomes are, how to define outcomes themselves, how do we then move from outcomes to action?

Well, really, let's just talk about the importance of now that we've defined our outcomes, how is that going to help the product team? Really, well-defined outcomes help product teams stay on track when faced with inevitable feature requests.

We know that feature requests come in, either from users or from stakeholders high up in the organisation. Outcomes, and those that we seek to enact, help us to filter out ones that aren't going to get us where we need to go, that are not going to help our users get where they need to go. If we are really clear on the outcomes that we're seeking, we've agreed them throughout the organisation, if somebody comes to us with an idea, we can either assess it to say, oh, actually, that could help us get where we need to go, or it's really clear, thanks, but it's not quite fitting with our user problems and our organisational goals. Having clear outcomes helps to kick back some of these feature requests that we know bombard product teams at times.

‍

Let's look at an example for how outcome thinking could help a completely hypothetical organisation. Let's say that they make physical products. They sell them via their website, and somebody high up in the organisation says, we need a chatbot.

At the moment, the product team has no real background on that. They've just received this feature request, essentially from someone high up who holds a lot of sway. We see this a lot in legacy product organisations that don't quite have the empowerment that they need.

Let's look at how outcome thinking can help align everyone around what it is that we really should build and what it is that we're looking to achieve.

When the team receives a feature request like this, they should really be thinking, what's really driving this request and what outcomes are we looking to achieve? They shouldn't be looking to just jump on the request to keep somebody happy. They should start to do a bit of probing, to start to realise, actually, what is it that we're looking to achieve, both for our users and as an organisation?

We go back to asking questions. This is the starting point for outcome thinking, as I said, and the reason for that is, by asking the right questions, you can uncover the outcomes that are truly sought.

We're starting at the solution level here, but we can then tease out what are the organisational outcomes that that person is thinking of, and is the rest of the business aligned to that?

‍

What questions should we be asking? First of all, about the problem. Somebody has come to us with a solution, but, actually, what problem is this thing trying to solve? Who's it for? How do we know that there is a problem in the first place? Do we have any insights, particularly data or customer feedback, that says that this is a problem worth solving? Really, let's start to define the problem.

On the flip side, the opportunity. What is the opportunity for the organisation if we were to solve it? How is solving the problem going to help our users? If it's going to have a minimal impact on users, then, really, is it something worth solving? If we were to solve it, how would it help our organisation? If we know where the organisation wants to get to, is solving this problem is going to help us get there? Does it align with where we want to go? It might just be that this idea, this just doesn't fit in with who we are as a business, so we need to think about business viability as well.

We should then think about the proposed solution. If someone's come to us with a solution, do we believe it's the right thing? Have they considered anything else? Can we think of anything else? How else could we solve the problem? Have we seen anyone solve the problem similarly, either in our industry or potentially outside? If it's a similar problem that hasn't been looked at in this industry before, there could be some lateral thinking that might be able to help us out here.

The purpose is to surface all of these ideas so that we're not just bound to the first thing that somebody comes to us with. We can look at all the potential solutions in order to achieve this outcome.

Lastly, we need to think about our constraints. How much can we invest into creating a solution? Because, again, if we think too much about the output, we could end up busting our constraints and spending too much money, too much time and really doing the wrong thing for our organisation and for our users. We need to understand what resources can we commit to this? Is there a time frame that we need to deliver to? If something is urgent, let's make it urgent.

Really importantly, has anything been promised to anyone? If this stakeholder has said to the CEO that it's going to happen in two months time, it's good to know that now. You don't want to be finding out in two months when he's screaming and shouting, where's my chat bot, especially if that's the wrong thing.

We've asked our questions and we also need to go and get our data. How big is this problem? Again, who is facing it? And what is the opportunity at stake here? We need to use data to inform our understanding of the problem and help tie down that definition.

‍

Then, we can start to build up our outcome map. This time we're kind of starting at the solution level and you can see how we can then build this up to build up a bigger picture of what's going on in the organisation.

The stakeholder's come to us and said, we need a chatbot. What user problem is this solving? What is the outcome that we would seek for this? If we were to map it up, when we talk about the user's problem and how we could improve their experience, what that would mean is that we would look to improve user's ability to find relevant products. Say we've done some work, we've spoken to users, we've spoken to the stakeholder and it all revolves around this issue where customers come to this hypothetical site looking for a product and they can't find what they are looking for. This person has proposed a chat bot, for some reason.

That doesn't really matter. What really matters is this problem. We need to help users find these relevant products. Why is that a problem worth solving? What is solving that problem going to do for the organisation? Well, if we're able to help customers find relevant products, then that should improve the customer purchase journey, and therefore we should see an increase in revenue generated from the website. Immediately, this is a problem worth solving if we can.

Again, we need to think about how big is this problem? Are there any other problems that we could seek to solve in order to achieve this organisational outcome? We'll come to that in a second.

‍

We've mapped this up. We can see how potentially delivering this solution could help the user, and by helping the user, how that might help our organisation. But if we were to take the user's problem of being able to find relevant products, there are many different ways that we can do that.

We can look at better product categorisation, so just helping users to narrow down into the product that they're looking for. We could improve some search functionality, so the user can put in whatever term they're interested in and find the product that they're after. We could build some kind of fancy product matchmaker which would run as a questionnaire, and then from the user and who they are, it could find products related to them. Feels a bit heavy handed and a bit long winded, so maybe not the greatest idea, but this just shows all the different ways from really simple stuff to really complex things, how we could potentially solve this problem, achieve the user outcome, and then achieve the organisational outcome.

Let's say that better product categorisation feels like something that would solve the problem, would be quick to deliver. We could then go and devise some experiments to potentially see if this is likely to solve the problem. We'd maybe look at building a paper prototype just so that we list up the categories and show them to customers just to see if they make sense. We could then do a clickthrough prototype, allowing users to drill down themselves to find the product that they want and see if we've solved the problem versus where we are today.

That's how to potentially solve the problem in a different way and navigate the team away from a potentially expensive chatbot solution to something much more simple that's ultimately going to get the user where they want to go, which is to their product, and where the organisation needs to go, which is with increasing revenues.

However, if increasing revenue was the name of the game, that was the most important thing for the organisation at the moment, they could potentially look at other user problems to solve in order to have the biggest benefits in terms of increased revenue.

Those other problems could be, and this is, again, hypothetically speaking, they go and look at the data and they find out that there's a huge bounce rate on the home page because the page load time is too long. The team could instead move away from the original problem and look to solve that, if they thought it was a bigger problem that was more likely to increase revenue. They could look to upsell customers before the checkout. Again, this would increase revenue from the website, but just a very different way of achieving this organisational outcome.

It's important to note that if somebody comes to you with a solution, find out how else you could potentially solve that problem, and also if it's the problem that you should be solving in the first place.

‍

Hopefully, you can see, only when everyone is clear on the organisation's priorities and the needs of the user can we even begin to determine the right thing to build. You need to build up this picture of, where is this organisation trying to get to? What are all the different ways that we could help our users? What are the biggest problems to go and solve? And by solving those big problems, ultimately, what's the best way of doing that? How can we test these ideas to make sure that our ideas are in fact ones worth building?

Before you build up this map, you could end up just being at the mercy of stakeholders, at the mercy of users, whoever screams the loudest, essentially. You wouldn't have this big picture on exactly what is the right thing to build. Hopefully, you can see the power of outcome thinking there.

‍

You've built your outcome map. You've come up with solutions to your biggest problems. How do you then track progress?

The big questions here are, how do we know if we've found an effective solution? We've thought of all the different ways that we could deliver this user outcome. Actually, how do we know if something is going to be effective before we commit to building it? And then once we have built it, how do we know if an outcome has been achieved?

How do we test solutions? As I mentioned, we need to start by devising experiments. Think about the potential risks around the idea, the assumptions that need to be true in order for the idea to work, and then figure out how to test these assumptions quickly and cheaply.

We need to consider the four risks around any digital product, which are: value - would the users use it; usability - would they be able to use it even if they wanted to; feasibility - can we deliver it with the engineering resource, the skills, the money that we have, and business viability - does this idea work with the other areas of the business?

We then need to set targets before we do any experimentation. It's really important to set quantifiable targets so that we know, when we do an experiment, did we reach the threshold of certainty that we were looking for? It's easy once you've run an experiment to then look at results and ask within the team, is this good? You need to define what good looks like ahead of the experiment.

Then it's time to test and analyse. Go and run the experiments and collect both quantitative and qualitative data. For example, if 80% of customers felt that a new experience which was being tested was better than their current experience, why was that? It's good to know that 80% felt it was an improvement, but was it specifically the ideas that you were testing that enabled that? And more importantly, for the 20% that felt that it didn't improve, what might improve the experience? That helps you to refine the idea further and not miss out on any opportunities.

Lastly, we need to talk about implementation and the metrics around implementation. As we mentioned, with some of the organisational outcomes, some of these can be really far in the future outcomes that we're looking to achieve, such as brand reputation. These are things that take a long time, to change people's minds. Same with things around customer retention. If you're looking to retain customers better after, say, three month mark, you're not going to be able to know whether your idea has solved that problem and has enabled that organisational outcome three months in advance. But when you release the feature, people are going to start asking about that, so you need to be able to give them a warm feeling that you're on the right track before you've got the data in three months.

It's therefore important to find metrics that help us determine whether or not we're on the right path at the outset. We call these metrics leading indicators and they're really focused around user outcomes rather than organisational outcomes. These are the metrics that give us immediate feedback as to whether or not we've improved the user's experience.

‍

A good example of that is Net Promoter Score. If we were to go back to a hypothetical organisation who were selling products on their website, if we see a big change in Net Promoter Score, purely based off better product categorisation, then we know that we're likely to achieve our user outcomes, our organisational outcomes, which was to generate revenue - and actually, generating revenue, we should see an impact fairly quickly. For something which is further off, we might need to look at leading indicators and trust that they're going to get us there before we see the target metrics which we want to talk about now.

Leading indicators are all things that we can pick up from the user as they're using the product and help to give us a steer as to whether we're heading in the right direction before we get data around our organisational metrics.

We call these target metrics. These are the things that really matter to your stakeholders and they tell the story of the benefits of the organisation. You've solved the user's problem, that's nice, but ultimately, what is the organisational benefit? As I mentioned, some of these can take a long time to come through. Things like percentage of customers retained after three months; your Net Promoter Score, if you see a big change in that when you release the feature, if people are saying, yes, I'd happily recommend this, then great. If they're happy to recommend it, then you should see an impact when it comes to your retention after three months.

It allows you to report back quicker without having to just wait and see and wonder whether or not your idea has achieved the organisational outcome that you look to seek. Hopefully that helps you to understand that leading indicators can be used to get early indication from your users as to whether you've solved their outcome and whether or not you're in the path to delivering your organisational outcome.

‍

As a summing up, what are our key takeaways? How do we use outcome thinking in order to build the right thing?

Number one, as I said, it's important to understand the needs of your users and your organisation. Go out and interview your stakeholders, interview your users, and go and delve into the data to tell the story of where you are now and where you want to get to.

Second, it's time to map your intended outcomes. From where the company wants to get to, what are all the different user problems that you could potentially solve? And for your biggest problems, what are all the different ways that you can solve those problems? It's really important to build up that picture and that will help the team stay on track.

Third, it's time to test your ideas. Your most promising ideas, how can you go and test them quickly and cheaply around the biggest risks so that you understand their effectiveness and identify whether or not these are the right things to build?

For those that pass the threshold, you can then use leading indicators and target metrics in order to track success. These will tell you whether you've achieved your outcomes for your user and for your organisation.

Thank you very much. Hopefully this session has been useful for you. Hope you have a great Canvas 2021 and if you have any any questions, feel free to get in touch with 383 or myself. Thank you very much.