What the hell is jobs to be done?

Jobs-to-be-done (or Jobs-theory) is a framework for understanding why people do what they do.

Leading proponent of Jobs-theory, Harvard professor Clayton Christensen, describes Jobs to be done (JTBD) as:

"A tool for evaluating the circumstances that arise in customers’ lives. Customers rarely make buying decisions around what the “average” customer in their category may do — but they often buy things because they find themselves with a problem they would like to solve.

With an understanding of the “job” for which customers find themselves “hiring” a product or service, companies can more accurately develop and market products well-tailored to what customers are already trying to do".

JTBD theory can be useful in:

• Strategy — Aligning your vision and mission with customers or finding gaps and opportunities in markets

• Product — Know what to build, plus the experiential and functional qualities it should have

• Marketing — Getting people to switch to your product, and retaining the ones you have

If you have come into contact with JTBD, you have probably come across one of two approaches.

One approach, advocated by the likes of Clayton Christensen, Rewired Group and Alan Klement is focused on the idea of progress and desires - often at a high-level.

The second approach, made popular by Tony Ulwick of Strategyn consultancy, forms part of Ulwick’s Outcome Driven Innovation framework and combines some of the high-level thinking with more task-orientated processes.

Ulwick’s approach offers some interesting insight, especially through some of the lenses and tools he uses, but for me at least, it’s the exploration of higher-level customer motivations and contexts that feels like the richest area for exploration.

But let's start at the beginning.

What is a job-to-be-done?

My favourite definition is based on Ash Maurya's description:

A job-to-be-done is the manifestation of an unmet need or want, in response to a trigger.

A job is the need or want.

The 'to-be-done' means it’s unresolved at this point in time.

A trigger is something that is happening, either within you or external to you, that informs the job to be done. i.e. It's raining, I need something to keep me dry or I'm feeling stressed and I need some way to feel better.

The more context we have, the more we can understand the trigger (or triggers) that give rise to an unmet need or want.

Most of the time, when a job is triggered, we have go-to solutions. These solutions will do the job well, poorly or somewhere in-between. We tend to adopt these solutions until there is a potentially better candidate.

This switch in solutions is often triggered when something changes within the context (e.g. It's raining and I need something to keep me dry whilst I'm running), or something comes along that can do the same job better (in some meaningful dimension e.g. price, quality etc).

Again, to quote Ash:

Needs are functional. Wants are emotional.

Needs have utility. Wants have energy.

To add to this:

Needs tend to be immediate. Wants tend to be longer-term.

Needs arise in the moment. Wants transcend months, years and even lifetimes.

Whilst processes like task analysis can help you understand needs, they often lack an understanding of wants.

These wants, or desires are almost always driven by one or more emotional component: control, care, belonging, self-expression, competence and recognition.

According to current research: "...the answer [to what is satisfying about satisfying events] is autonomy, competence, relatedness, and self-esteem.

Security may also be a need, which becomes salient in times of privation. Pleasure-stimulation, self-actualisation - meaning, popularity-influence, and physical thriving are less important, and we would tend to deny them ‘need’ status. Least deserving of need status is money-luxury.” 

For example, I need something to keep me dry vs I want to look stylish so that my social status is improved amongst my friends and peers.

Products tend to sit within an ecosystem of interconnected, sometimes opposing jobs-to-be-done.

For example, we may need and want to be healthy but the need to exercise is de-prioritised in favour of other competing jobs; for example, spending time with your family or just doing nothing.

Jobs-to-be-done is a theory

Jobs-to-be-done is a set of assumptions or propositions that attempts to provide a plausible or rational explanation of the cause-and-effect relationships within the world around us.

In this case, it’s a model for how and why we think people behave the way they do, in relation to choosing (or not) different solutions. The theory suggests that if we understand what people want and need in the context within which these needs arise, we can design better solutions.

It falls short of being a methodology or a method. It isn't a research strategy or the means or modes of data collection. This has been a source of frustration for many who have been sold on the principles of JTBD but left directionless.

So how might we actually go about understanding a customer’s JTBD?

Researching jobs-to-be-done

Many of the methods you would use in other forms of formative research hold up. 1-2-1 depth interviews, ethnography, focus groups, call centre listening and even well-crafted quantitative surveys give you a sense of a customer’s JTBD.

There are some specific JTBD methodologies, such as the ‘switch interview’, but I can see no advantage in these over tailoring your own discussion guides for a 1-2-1 depth interview.

There are three main areas that your research will be probing:

• The context: who, what, where, when

• Observations: past decisions, solutions and behaviours

• Situational analysis: the ‘why’ - the pushes, pulls and anxieties

A well-used technique for thinking about the situation is the four forces model used by Rewired Group. It describes the tension between things pulling you towards a solution and the things holding you back.

Synthesising jobs-to-be-done

After undertaking research, you will need to convert this into a usable form.

I like to borrow from Agile methodologies which means I look for Epic JTBD. Big goals that tend to be emotionally driven and relate to the progress people want to make in their lives i.e. be a good parent, respected by colleagues, or useful to society etc.

I then look for interconnected job stories. These are slightly lower level and are a mix of wants and needs. I tend to borrow from Intercom's format of codifying these. A JTBD encompasses situations, motivations and outcomes. So we use:

[ When _____ ] [ I want to _____ ] [So I can _____ ]

‘When ____’ focuses on the situation, ‘I want to ____’ focuses on the motivation, and ‘So I can ____’ focuses on the outcome.

I also like to map out how these jobs interact with one another and what the solution landscape looks like.

You may also consider grouping things together based on contextual information. In other words, if a lot of jobs occur in a particular context - you split them up by grouping.

For example, if you're researching the way people consume music - it might be useful to group jobs that occur in different contexts: in the car, with the kids, at a party, in the park etc.

Once you have collected jobs you can go through a process of prioritisation. This is done through surveying, qualitatively through interview or approximately with your team.

You might use MoSCoW, Kano or other models for understanding the importance vs current levels of satisfaction around a particular JTBD. A technique I've not used yet, but I think might be effective, is pairwise comparison at scale - perhaps using a tool like allourideas.

Finally, you might want to measure against your own business objectives and ask, is this a problem we want to solve and is the market big enough to justify our involvement?

Using jobs-to-be-done

We now have a set of prioritised jobs-to-be-done. These become design briefs.

For example, let's take a job story:

When it’s raining, and I'm doing exercise outside I want to find a way to keep dry so that I can continue to exercise and be comfortable in a way that looks good to others and doesn't affect my performance so I feel confident in what I'm wearing and continue my training programme in preparation for my first marathon.

This job story encodes a lot of information about the context, the wants, needs and desired objectives. It's testable too - we can ask people if they feel confident, we can measure their training data to see if rain affected their commitment and performance.

You also know whether a solution fits the brief pretty quickly. For example, the answer is very unlikely to be an umbrella unless we radically redesign it.

This kind of job story also makes an excellent starting point for rapid innovation processes like Design Sprints.

The good thing about jobs-to-be-done - especially higher-level ones - is that they tend to stay stable over time.

People have similar sets of needs and wants despite changes in technology meaning our solutions change but the needs don't.

For example, people always want to know what's happening in their world, regardless of whether the solution at hand is a town crier, radio, newspaper, TV news, blogs, Twitter or any new future technology.

This means that investing in JTBD research can create value, not just for one particular project or product but for years to come.

What next?

Yes, it has a weird name.

Yes, it feels like a fad or a cult at times.

Yes, it’s another way of framing customer understanding.

But it’s still a genuinely useful way of thinking about customer behaviour. My recommendation is to start introducing these practices without the need to explain it as part of a theory. By the time you’ve explained what a job-to-be-done is, you could be talking to real customers and gathering the necessary insights.