The Jobs to be done playbook - Reading notes

Author Clemence Caron
Date 27 June 2023
Reading time 14 minutes

Our reading summary

After reading the book, we were able to identify the techniques we think are worth including in future projects. We will try to bring them into our process so we can test them and judge how effective they are. That said, as we mentioned earlier, other techniques seem hard to apply compared with our current methodology. We will still come back to those points to explain why we chose to set them aside for now.

From our point of view, this book should be read twice. Once to get an overview of the JTBD method, then again as a practical guide, to pick out the techniques you need at the right moment.

In brief

The “Jobs to be done” method focuses on the goal a user wants to reach rather than on products or technologies. To define the “Jobs to be done”, you have to precisely formulate the main goal the user wants to reach as well as their motivations. Several methods, such as user interviews and motivation prioritisation matrices, can be used for this purpose. Other techniques presented, such as internal reorganisation around the JTBD, are harder to apply in an agency setup.

The “Jobs to be done” concept

a) What is the Jobs to be done method?

The JTBD method suggests that a user uses a product or solution to accomplish a “Job to be done” that doesn’t change over time. This idea of immutability matters, because it means technology isn’t part of the thinking. Over time, a user looks to perform this JTBD more efficiently, so more quickly and more easily.

By placing the user at the centre of the thinking, the JTBD method looks at what the person wants to accomplish (their “main job”) and why it matters to them (their “need”). At this stage, the solution isn’t taken into account.

b) How do you define a Job to be done?

1) The structure of Jobs to be done

There are 5 principles for defining a JTBD.

  • Job performer: the end user (e.g. a financial analyst).
  • Job: it splits into 3 categories. The Main job is what they want to accomplish. This “main job” has to be bounded, because you need to be able to reach an “end” (e.g. attending a conference). The Related jobs are the adjacent jobs, but different from the “main job” (e.g. taking a specialisation course). And finally the Emotional/Social jobs represent what the end user wants to feel while doing the job (e.g. feeling inspired by new knowledge).
  • Process: this is the chronological representation of the steps in the job. This process is most often represented as a “job map”, a kind of experience map without a link to a specific solution.
  • Needs: they represent what has to be done to accomplish the job (e.g. increasing my chances of getting permission from my manager to attend the conference).
  • Circumstances: the context for carrying out the job. Most often, the circumstances are related to time, place or a way of doing things (e.g. the conference is outside my city).
Diagram showing the 5 key elements of the Jobs to be done ecosystem.

The “main job” and the “needs” have to be defined carefully, since they are the keystones of the JTBD method. The JTBD methodology rests on these two main principles.

So they need to be defined properly. The method even provides a precise syntax to formulate them.

The structure of a job to be done is the following:

Verb + Objective + Detail

Example: Visit + my family + for Mother’s Day

2) The hierarchy of Jobs to be done

By formulating JTBDs in this way, it then becomes easier to rank them in order to identify which one is the “main job”.

Jim Kalbach explains that there are 4 levels of hierarchy within Jobs.

  • Aspiration: an ideal change (e.g. being a better family member)
  • Big job: a broader goal (e.g. visiting my family for Mother’s Day)
  • Little job: a smaller job, a step in the big job (e.g. arranging my transport at a specific time)
  • Micro-job: an activity, a task to accomplish the job (e.g. starting the car)

In this hierarchy, the big job is the equivalent of the “main job”. To pinpoint the right level of abstraction between the various jobs, you have to ask “why” you want to reach the level above and “how” you go down to the level below. So, with the example just mentioned, a job performer wants to visit their family for Mother’s Day in order to be a better family member. How can they visit their family for Mother’s Day? By arranging their transport at a specific time.

3) Formulating needs

When it comes to the “needs”, they also have a defined syntax:

Direction of change + Unit of measure + Object + Detail

Example: Improve + my chances + of getting permission from my manager + to attend the conference on cognitive psychology

Standardising the formulation of a job to be done and a need makes them easier to understand, since we only focus on the elements with strong differentiating value. The aim of this precise formulation is to limit the risk of ending up with several similar jobs to be done or needs. On top of that, this consistent way of phrasing things makes handovers smoother within a team or between departments.

What did we keep that we would apply tomorrow?

A wide range of techniques is presented in this book to put the JTBD method into practice on a project. While reading, some of the techniques proposed already more or less looked like what we do internally. For example, that’s the case for the mapping of personas against behavioural variables (Chapter 4, p.98). However, other techniques, that we don’t apply exactly the way the book describes, seem worth bringing into our projects to test in real-world conditions.

a) Switch Interviews - 4 forces

This way of running user interviews is based on the purchasing decisions and the underlying motivations that led a user to use a specific solution. This kind of interview can only take place once the purchasing or use timeline is complete. This kind of interview is only useful with users who have purchased or used a solution. The interviews revolve around 4 forces that push a user to switch from one solution to another offer. They are identified as follows:

  • Problem: what pushes them away from the current situation
  • Attraction: what draws them towards a new solution
  • Uncertainty: what creates anxiety when faced with a new choice
  • Habit: what keeps them stuck with the current situation

Usually, the end result of these interviews is to surface weaknesses across several of the 4 forces. By addressing the weaknesses that come out of the switch interviews, it then becomes possible to surface solutions that align with the JTBD.

b) Defining unmet needs

Prioritising needs is the key to the JTBD method. The solutions that target unmet needs have the highest chance of being adopted. A job can have several unmet needs. First, you have to formulate the users’ needs as shown earlier in this article. “Unmet needs” are also called “desired outcomes” in the ODI method (“Outcome Driven Innovation”).

There are two ways of dealing with “desired outcomes”, depending on whether or not material from user research is available.

When it isn’t possible to gather enough material from users, you can position the “desired outcomes” on an “Importance vs Satisfaction” matrix. The needs to address first are those with high importance and low satisfaction.

Otherwise, you can survey users on each “desired outcome” by tying them to two scales: importance and satisfaction (numbered from 0 to 10). By collecting the scores given to each “desired outcome”, you can calculate the “Satisfaction Gap” out of 10. This is the importance score minus the satisfaction score. Then you add this “satisfaction gap” to the importance score to get an “Opportunity Score” out of 20. The higher the result, the bigger the opportunity.

Importance vs Satisfaction matrix used to surface the unmet needs of jobs to be done. Diagram explaining how to compute the Opportunity Score to assess the unmet needs against the Satisfaction Gap of jobs to be done.

c) Job stories

​​Job Stories are different from User Stories. User Stories are not tied to the user’s need. There is no indication of why the user acts in a particular way to accomplish their task.

The formulation of a User Story is the following: As a (role), I can (capability) so that (benefit).

Job Stories, on the other hand, start with a re-contextualisation, a way of setting the scene. Several options exist:

Option 1: When (situation), I want (motivation) so that I can (expected outcome).

The situation has to be detailed as much as possible.

Example: When I’m hungry, I want to be able to eat properly so that I can keep my energy up throughout my conference day / When I’m hungry, while running late to go somewhere, not knowing when I’ll be able to eat again and fearing I’ll be tired and irritable from the hunger, I want to be able to eat properly so that I can keep my energy up throughout my conference day.

Option 2: When I (circumstances + step in the job), I want (micro-job) so that I can (need).

Example: When I’m short of materials to finish my art project, I want to find alternative materials so that I can make the most of my current supplies.

Option 3: When I (circumstance), I want (capability of the solution) so that I can (need).

Example: When I’m getting ready to go to work, I want to get a notification with the weather forecast on my phone so that I can plan an appropriate outfit and avoid arriving at work soaked from the rain.

Option 4: When I (circumstance), I want (job) so that (benefit a solution offers).

Example: When I’m planning my departure on holiday, I want to get the fastest route possible so that I spend the least time in traffic jams.

Job stories all have to be written in the same format. Redundancies should be avoided as much as possible, and their number kept between 3 and 8 per project or sprint. It is critical to share the job stories with all the project stakeholders. They serve as a common base to check whether a proposed solution is appropriate or to run tests with end users.

What we won’t use in the short to medium term

As with any method, some techniques may not fit the internal process already in place. The Jobs to be done method is no exception. Several elements presented in this book feel incompatible with the way we currently work. Some techniques are also not applicable to an agency setup.

a) Internal organisation around the JTBD

The first step to reorganise a company around the JTBD is to use the big jobs as an organising principle to create local groups.

You then organise around the jobs by deciding how much weight these jobs should carry. Obviously, there are business functions that don’t directly serve the JTBD but still have to fit into the organisation. That is why organising around the JTBD usually happens at a second or third hierarchical level. The aim is to get cross-functional groups that combine a classic hierarchy with a user-centred hierarchy. The example used in Jim Kalbach’s book is the internal organisation at Spotify. The idea behind this organisation is to add extra dimensions on top of a more traditional structure to gain flexibility. “Guilds” bringing together profiles from several teams are created around the JTBD.

Spotify's internal org chart around jobs to be done, with inter-tribe guilds.

b) Extending market opportunities

Jobs define the market, so you have to focus on the progress this market is trying to make as it looks for a solution to meet its needs.

To start, you have to look at the progress users want to make. To do that, the “related jobs” have to be taken into account by looking at customer aspirations.

Next, the company has to question its activity. It has to come to a single answer that reflects the progress users expect. Sometimes there may be several possible answers.

Finally, thanks to these insights, the offer can be reframed. The point is to align the offer with customers’ main aspiration (product, service, marketing message, etc.). The Airbnb example is quite telling. For them, the product is travel, not accommodation booking. Starting from this observation, they created “Airbnb experiences”, which offers experiences around travel (visits, activities, etc.).

As a design and user experience agency, we don’t have control over the business and strategic choices of companies. We can only advise them as well as we can by taking into account the results of the user research we carry out.

c) The JTBD strategic development matrix

The JTBD matrix lets you predict development by studying the solutions that make the JTBD faster and cheaper.

Starting from the “unmet needs”, you can segment users by JTBD. The strategic development matrix can be applied to each product or product group in order to decide on a strategy. You should apply one strategy per product, but a company with several products can apply different strategies to each of these products.

Once the strategy is decided, you have to assign a product or service to each user segment created from the “unmet needs”. There are then 4 different ways to develop your market based on the JTBDs:

  • Do more steps: starting from the job map, do as many steps as possible with the solution
  • Do the steps better: compare how the steps are done with the competition to find a better alternative
  • Do complementary steps: how to do other steps, bringing them into the job
  • Run ideation and test the solutions that respond to the job in a strategic way

Finally, a value proposition is built by finding the message that resonates with the target audience for doing the JTBD. The “need” has to come through in the marketing message.

The social and emotional aspect as well as the circumstances should not be left out.

A product’s strategy can evolve over time as existing offers and market demand change. For example, Uber used several different strategies as it launched its products: a differentiating strategy for Uber Black, a disruptive strategy for Uber Pool, and a dominant strategy with Uber X.

Diagram of the strategic development matrix based on Jobs to be done.

Putting it into practice at UXDays 2023

At UXDays 2023 (the article with the recap of all the workshops is here), we attended the workshop “Les secrets pour bien formuler vos Jobs-to-be-done et créer des produits innovants” presented by two employees from Peaksys, the technology subsidiary of CDiscount.

The topic was the search for business opportunities in the area of organising surprise birthday parties.

We started with a 5-minute job interview, with the aim of gathering as much information as possible on the expected outcomes and what mattered to the interviewee. From the answers we got, we had to fill in a Job-to-be-done canvas to synthesise the elements collected:

  • The “job performer”: the organiser
  • Their “main job”: organising a surprise birthday party.
  • The emotional and social aspects, of the “feeling” and “being perceived” type.
  • The “main needs”, such as “minimising the risk that the secret gets out”.
  • The “main circumstances”, with the phrasing “if (comparison 1) vs (comparison 2)”, which gives “if the guests are on time vs if the guests are late”.

Once these first elements from the job interview were in place, we broke down the big steps of the job. Several scenarios exist, but the big steps are similar: “Define the guest list”, “Plan the meal”, and so on. The important thing is to always focus on a task to accomplish and not on a solution. So you make a point of writing “Plan the sleeping arrangements” rather than “Book the hotel”.

For lack of time, we couldn’t finish filling in the JTBD canvas, but a worked example was given to us at the end of the workshop.

Thanks to this hands-on session, some concepts felt clearer to us, like the emotional and social aspect of a job or the wording of the job’s steps. That said, we still think the Jobs-to-be-done method cannot apply to every type of project, because of how specific the canvas is.

UXDays 2023 Jobs-to-be-done workshop in action

Conclusion

After reading about the techniques presented in this book and putting them into practice at UXDays, there is a sense of déjà vu. Indeed, if you replace the phrasing “job-centred” with “user-centred”, the mechanics on offer are roughly the same. You find a lot of techniques that already exist in other methods. That’s the case, for example, with experience maps, called customer journey maps in the JTBD method. In the end, JTBDs can easily fit into other methods such as Design Thinking or Lean Design. This method offers fairly similar techniques.

Our reading leads us to think that the Jobs to be done method is one viewpoint for running a project. It is one part, one level of detail, of user-centred thinking. From there, what are the most opportune moments in the lifecycle of a project to switch to a JTBD approach?

Vous souhaitez discuter de votre projet ?

Tout le monde parle expérience utilisateur, design de service, ergonomie… C’est pas très clair, mais vous aimeriez bien découvrir tout ça ou progresser.

Contactez-nous