Customer Validation

Jobs to be Done and the Job Map

How to find your key innovation opportunities based on the Jobs to be Done

Erik van der Pluijm
Erik van der Pluijm
2019-11-03 | 3 min read

Job to be Done (JTBD)

As you probably read a hundred times, innovation starts by understanding your customer. What do they try to achieve? What is the ‘Job’ they try to get done? And how can you help them achieve it?

In Lean Startup terms, that job your customer is trying to get done is called ‘Job to be Done’, or, in short, JTBD. Finding the JTBD for your customer is a large part of the early stages of the startup journey.

Two questions

Looking at the JTBD, it makes sense to ask two practical questions:

1. How do you find the JTBD?

2. How exactly will it inform your innovation process?

The ‘Jobs to be Done Framework’ from ‘Outcome Driven Innovation’ has a way of linking Jobs to innovation opportunities. (Please find a link to this framework at the end of the post).

Based on that framework, in this post I’d like to summarise some of the steps that will take you from observing customers to finding innovation opportunities.

One way to find the JTBD for a customer is to start observing and interviewing (potential) customers. Ask them to tell you what they want to achieve. Use the customer journey canvas to map out the steps your customer follows to get his or her job done.

If you have one or a number of these customer journey maps, you can start to translate them into JTBD and Job Maps. To do that, first you need to convert their goal to a ‘Job Statement’. This makes it more structured and helps keep focus.

Job Statement

A good job statement is structured as follows:Job statement = verb + object of verb + contextual clarifier.

Example “listen to music while on the go”.

Example “predict stock prices in real time”.

Note: You can turn these into ‘user stories’ by adding ‘As a (type of user), I want to…’ at the beginning of the job statements.

Go over your customer journeys and find the jobs people are trying to get done. Sometimes, the jobs they say they want to get done are not the actual jobs. They might be a ‘subgoal’, a step on the way to the actual goal. These goals (or jobs) string together, and form a way for the customer to get to where they want to go, using the means currently at their disposal. Users mentally plan backwards from the job they try to get done to find steps that will lead to that goal.

Note: keep this ‘mental planning’ in mind when coming up with alternative solutions: if people don’t understand how to get the job done they won’t adopt the product.

In the first example, “listen to music while on the go,” the customer journey might contain the following steps:

- Get your phone and headphones

- Open a music app

- Select a song

- Play the song

- Listen to the song on the go

The last step is the goal, the other steps are things the user must do to get to that goal. Each of these steps can be further subdivided, by analysing what the exact actions are a user needs to take. How will they ‘select a song’, for instance? Are there alternatives?

Job Map

By analysing the customer journey in these terms, and using the ‘job statement’, you can turn the customer journey into a ‘job map’.

The Job Map looks a lot like an idealised part of the customer journey that a customer needs to go through in order to get their job done. A good Job Map is ‘solution agnostic’, so it does not depend on the actual solution that is used.

E.g. Job: “play relaxing music”

- Access music source → Select music → Play music

This is solution agnostic, since it could refer to using a gramophone, hiring a mariachi band, or simply pulling out your phone and opening Spotify.

There can be multiple customer journeys associated with a specific JTBD and job statement.

E.g. Job: “find new music to play”

1. Open music app → Select ‘my discovery playlist’ → Play music → Wait for a great song → Star song.

2. Open music app → Open favourite song list → Click ‘similar music’ → Wait for a great song → Star song.

3. Ask music loving friend for great new songs → Open music app → Search for song → If it is good, star song.

As you can see there are different strategies different people may follow. A good product allows people to use multiple strategies, but keeps an eye on the objective: get the song in your library, in this case. Allowing this flexibility will make it easier to fit the product into their existing routines, and will be able to cater to different use cases.

The Job Map you define will need to allow for these different use cases and strategies. For instance:

Access music source → Find a recommendation for music → Listen to the music → If it is good, remember it for later

Universal Job Map

In fact, there is even a ‘universal Job Map’:

1. Define / plan

2. Locate / gather

3. Prepare / organize

4. Confirm / verify

5. Execute

6. Monitor

7. Modify

8. Conclude

Not all of the steps are always used, but this universal map pretty much works for all cases. Just try it with the example above.

Next, now that we have a job map, it is important to find out the customer’s actual needs while getting the job done. Where in the job map are customers unhappy about their options? Where do they need more, better, or different alternatives in order to get the job done?

Desired Outcomes

To do that, more detail on the job steps is needed. Every step of the job map has one or more desired outcomes associated with it.The desired outcomes define the ‘need’ the customer has at that step in the job map.The format for the desired outcome:Desired Outcome = Direction of improvement + Performance metric + Object of control + Contextual clarifier

Example “Maximize the chance that the user immediately gets a music recommendation they like.”

Note: Try to keep the desired outcomes solution agnostic as well.

One job can have multiple steps, and each step can have multiple desired outcomes. That means you should find many desired outcomes.

The next step is to find out which steps of the Job Map are important to the customer, but currently underserved. Where are they unhappy with their current solution?

- If there are multiple ways to achieve a desired outcome, this outcome is ‘overserved’. Would it be possible to find a cheaper solution?

- If there are no or few ways to achieve a desired outcome, it is ‘underserved’. Perhaps a new solution can get the job done in a better way in this step.

- To what degree do current solutions achieve the desired outcome? This is the ‘satisfaction’ of the outcome.

- How happy are customers with their current solution in case of an overserved outcome? Or, how unhappy are they that a solution is missing, in case of an underserved outcome? This is the ‘importance’ of this outcome.

Rank desired outcomes

When you have a list of desired outcomes, have (potential) customers rank them in terms of satisfaction and importance.

Important and Unsatisfied

You are looking for the important, and unsatisfied outcomes. Those are the opportunities. Now, use this to find better solutions to remove or improve the way in which users go through the job steps.

Visualize it

The great thing about this Jobs to be Done Framework is that you can actually visualise the opportunities in an opportunity map based on the data your customers provided when ranking the jobs. Now that’s what I call data driven innovation.


Image: Opportunity Map from Outcome Driven Innovation

Jobs To Be Done Framework and Outcome Driven Innovation

This post was based on the ‘Jobs to be Done Framework’ and ‘Outcome Driven Innovation’ by Tony Ulwick. If you want more details, please read his excellent post

-- Keep experimenting 🚀