The outcome-driven approach to innovation

This is quite natural. As human beings, we have a deep rooted tendency to focus on solutions (i.e. feature ideas) and lose sight of the outcomes we want to achieve. Our habit is to express our needs (and fight for them) in terms of specific solutions, rather than desired outcomes.

Look at how product development teams work day-to-day and in particular, for example, how they use product backlogs.

In most organisations, product backlogs focus on feature ideas. In theory, these are meant to clearly describe a user’s desired outcomes as well. But in practice they rarely do, and almost never do it well.

This is because feature backlogs and user stories are, first and foremost, tools to describe solutions to be elaborated and engineered, rather than desired outcomes.

Then, look at the daily rituals of a typical product team

At the end of a daily scrum meeting, everyone on an agile team is generally quite clear about what tasks they’re going to work on today, and what feature they're building.

But at some point in the day-to-day trenches of product development, it's difficult for all team members to keep a clear understanding of:

• the situations that customers will be in, when they’ll be using these features
• and what they'll be trying to achieve in these situations.

Focusing on feature ideas without being clearly aligned on the desired outcomes makes it difficult for teams to focus their efforts in the right way, or solve the right design problems.

When organisations focus too much on feature ideas and lose sight of desired outcomes, they waste their resources building impressivelooking features that customers don’t use.

These fancy features don’t get used because they don’t actually make it quicker and easier for customers to achieve the outcomes that they want, in the situations that they’re in.

Outcome-Driven Innovation (which some people also call ‘Jobs-to-beDone’) is a simple, powerful way of thinking that puts desired outcomes at the centre of every conversation – so no one loses sight of them.

It’s based on two simple ideas:

Idea #1: People don’t want features, products or services; they want outcomes.

For example, when a B&Q customer says “I want a lawnmower”, what they really want is a nice lawn – not a lawnmower.

Or if a friend tells you that they want a connected thermostat, what they’re after is probably not a connected thermostat: maybe what they really want is a comfortable home or to save money.

And, yes, if Henry Ford had asked people what they wanted, they might have asked for a faster horse. But what these people were trying to achieve was to get to distant places quicker and easier.

Idea #2: Focusing on the outcomes customers want to achieve, illuminates the path to successful innovation.

Focusing on feature ideas won’t give you the direction that you need to discover successful products and services. It’s like walking in a random direction and hoping you’ll arrive somewhere scenic

Starting from desired outcomes is deciding where you want to go first and then figuring out how to get there.

Your understanding of your customers’ outcomes is your North Star. Without it, you're lost.

This first tip is about understanding needs.

Traditionally, product or service development teams have captured customers' and stakeholders' requirements as feature ideas. This leads to endless debates about which features should be prioritised, while key assumptions about customers' needs remain implicit, unclear or untested.

Instead of asking "What features should the product or service have?", outcome-driven teams ask two simple questions in every conversation:

• Customer outcomes: What outcomes are customers trying to achieve?
• Business outcomes: What outcomes are we (the business) trying to achieve?

This second tip is about discovering and prioritising opportunities. As they strive to come up with feature ideas that ‘differentiate’ their product or service, it’s easy for teams to lose sight of what would actually be valuable to customers.

Rather than trying to be different, it’s much better to focus on making it easier for customers to achieve the outcomes they want, in the context that they’re in.

You can identify opportunities for innovation by answering these simple questions:

• Context: What situations are customers in, when they use your service?
• Desired outcomes: What are customers trying to achieve, in these situations?
• Problems with the current solution: What problems, frictions and pain points do they encounter, when they’re trying to achieve these outcomes, in these situations?

This third tip is about designing solutions.

Too often designers get given the description of a feature (in the form of a feature idea or a user story), and are asked to design it. With such a brief, it’s natural for designers to jump to execution ideas without being clear on what that solution needs to achieve.

A much better way to brief designers is to ask them: “How might we make it easier for customers to achieve this outcome in this situation?”

Designing towards desired outcomes, rather than from feature ideas, empowers designers to use their strategic and problem solving skills.

Doing this also forces teams to get aligned right at the start about what a design solution would need to achieve.

All too often, design work gets presented as static wireframes or mockups, on big TV screens, for a wide range of stakeholders to approve.

That’s not at all how customers experience a design solution.

When you work in an outcome-driven way, you don’t think of what you’re designing as a User Interface screens: ultimately what you’re designing is a series of interactions to take customers from their starting situation to their desired outcome.

This means assessing a design solution as a series of interactions, and testing how quickly and easily they help customers achieve their desired outcomes in real situations.

For example, you can measure ‘time on task’, i.e. how much time it takes for test customers to get to their desired outcome using a prototype.

You can also use a front-facing video capture software such as lookback.io to watch their facial expressions and ask them to think out loud.

These tests are affordable and easy, and will teach you a lot of things that wouldn’t have come up in a stakeholder meeting.

One of the most impactful things that you can do day-to-day is to help your teammates to zoom out and go back to the desired outcomes, every time that they get bogged into solution ideas.

Next time this happens, grab a Sharpie, a few post it notes and ask:

• “What are we trying to achieve here?”
• “What situation are customers in, when they’re interacting with what we’re designing?”
• “What are they trying to achieve, in these situations?”
• “Can we make that easier?"