The Outcome-Driven Approach to Innovation

Jean-Francois Hector
By Jean-Francois Hector under Insights 10 February 2017

Creating products and services that people love takes more than just building an app. It takes a deep understanding of unmet customer needs, a clear focus on the right opportunities, and a lean, rigorous, iterative design process.

Most innovations fail because, at some point in the development process, teams lose sight of what customers really want to achieve.

I believe that by and large, innovation and product development teams focus too much on feature ideas, and lose sight of desired outcomes.

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:

An Agile team at Scrum

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 impressive-looking 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.

An expensive product that customers don't use

___

Outcome-Driven Innovation (which some people also call ‘Jobs-to-be-Done’) 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.

People don’t actually want products, services or features. People want outcomes, and they hire products or services to achieve these 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.

___

Here’s how to use Outcome-Driven Innovation in four simple tips.

Tip #1. Don’t capture requirements as feature ideas. Capture requirements as desired outcomes

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:

___

Tip #2. Don’t focus on how to be different. Focus on making it easier for customers to achieve the outcomes they want, in the context they’re in

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:

1. Context: What situations are customers in, when they use your service?

2. Desired outcomes: What are customers trying to achieve, in these situations?

3. 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?

___

Tip #3. Don’t design from feature ideas. Design towards desired outcomes

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.

___

Tip #4. Don’t review ideas out of context. Instead, test how quickly and easily your design solution takes customers from starting situation to desired outcome

All too often, design work gets presented as static wireframes or mock-ups, 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.

___

Strategic leadership is helping your team to zoom out

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:

___

If you would like to discover more about how we work at TAB, and our outcome-driven approach to product design, contact us.