The Jobs to be done playbook – Fiche de lecture
Clemence Caron 27 juin 2023

“The Jobs to be Done playbook – Align your markets, organizations and strategy around customer needs” écrit par Jim Kalbach reprend la méthode développée par Clayton Christensen et Michel Raynor il y a plus de 30 ans. Ce livre se veut un recueil des techniques existantes pour appliquer la méthode de “Jobs to be done”. Ces techniques peuvent être utilisées seules ou combinées entre elles. Elles permettent d’atteindre différents objectifs et de s’appliquer à plusieurs cas d’usages.

La méthode “Jobs to be done”, souvent raccourcie en JTBD, a pour objectif de comprendre le problème auquel fait face un utilisateur pour accomplir une tâche et atteindre un objectif en utilisant un produit ou un service. Elle met en lumière les opportunités pour répondre au besoin de ce JTBD avant de penser à une solution.

Nous avons aussi eu l’occasion de prendre part à un atelier pratique lors des UXDays 2023 dont vous trouverez un résumé à la fin de cet article.

L’ensemble des techniques présentées fonctionnent dans une approche axée mono-produit. Cependant, il est assez rapide de se rendre compte qu’il y a un écart important entre la théorie et la pratique. Cela impose donc des limites dans la mise en pratique des écrits. Les techniques proposées ne peuvent pas toujours être applicables en l’état. Même si la réflexion est intéressante, ce sont des axes de la méthode JTBD plus délicats à intégrer dans un projet. 

Le résumé de notre lecture

Suite à notre lecture, nous avons pu identifier les techniques qui nous semblent intéressantes à inclure dans des projets futurs. Nous essaierons de les intégrer dans notre processus afin de pouvoir les tester et juger de leur efficacité. Toutefois, comme nous l’avons évoqué précédemment, d’autres techniques nous paraissent peu applicables par rapport à notre méthodologie actuelle. Nous reviendrons tout de même sur ces éléments afin d’expliquer les raisons qui ont motivé notre choix de les écarter dans l’immédiat.

De notre point de vue, ce livre doit être lu deux fois. Une première fois afin d’avoir une vision d’ensemble de la méthode JTBD et une seconde fois, à la manière d’un guide pratique, pour aller piocher les techniques nécessaires au moment opportun.

En bref

La méthode “Jobs to be done” se concentre sur l’objectif qu’un utilisateur souhaite atteindre plutôt que sur les produits ou les technologies. Pour définir les “Jobs to be done”, il est important de formuler précisément l’objectif principal que l’utilisateur veut atteindre ainsi que ses motivations. Plusieurs méthodes comme des interviews utilisateurs et des matrices de priorisation des motivations peuvent être utilisées dans ce sens. D’autres techniques présentées, comme la réorganisation interne autour du JTBD, sont plus difficilement applicable dans un fonctionnement en mode agence.

Le concept de “Jobs to be done”

a) Qu’est ce que la méthode Jobs to be done ?

La méthode JTBD suggère qu’un utilisateur utilise un produit/une solution pour accomplir un “Job to be done” qui ne varie pas dans le temps. Cette notion d’immuabilité est importante, car elle implique que la technologie n’est pas prise en compte dans la réflexion. Au fil du temps, un utilisateur cherche à réaliser ce JTBD plus efficacement, donc plus rapidement et plus facilement.

En plaçant l’utilisateur au centre de la réflexion, la méthode JTBD s’intéresse à ce que l’individu veut accomplir (son “main job”) et pourquoi c’est important pour lui (son “need”). Dans un premier temps, la solution n’est pas prise en compte.

b) Comment définir un “Job to be done” ?

1) Structure des Jobs to be done

Il y a 5 principes permettant de définir un JTBD.

  • Job performer : c’est l’utilisateur final (ex : Un analyste financier).
  • Job : il se divise en 3 catégories. Le Main job est ce qu’il veut accomplir. Ce “main job” doit être limité, car il faut pouvoir atteindre une “fin” (ex : Assister à une conférence). Les Related jobs sont les jobs adjacents, mais différents du “main job” (ex : Prendre un cours de spécialisation). Et enfin les Emotional/Social jobs représentent ce que veut ressentir l’utilisateur final en faisant le job (ex : Se sentir inspiré par de nouvelles connaissances).
  • Process : il s’agit de la représentation chronologique des étapes du job. Ce process est le plus souvent représenté sous la forme d’une “job map”, sorte d’expérience map sans mise en relation avec une solution précise.
  • Needs : ils représentent ce qu’il faut faire pour accomplir le job (ex : Augmenter mes chances d’obtenir une permission de mon supérieur pour assister à la conférence)
  • Circumstances : c’est-à-dire le contexte pour réaliser le job. Le plus souvent les circonstances sont liées au temps, au lieu ou à une manière de faire (ex : La conférence est en dehors de ma ville)
Schéma représentant les 5 éléments clés constituant l'écosystème des Jobs to be done.
Les cinq éléments clés constituant l’écosystème des Jobs to be done (p.18)

Le “main job” et les “needs” doivent être définis avec attention puisqu’ils sont les clés de voûte de la méthode JTBD. C’est de ces deux principaux principes que la méthodologie JTBD s’appuie.

Ainsi, il est important de les définir correctement. D’ailleurs, la méthode prévoit une syntaxe précise pour les formuler.

La structure d’un job to be done est la suivante : 

Verbe + Objectif + Précision

Exemple : Rendre visite + à ma famille + pour la fête des Mères

2) La hiérarchisation des Jobs to be done

En formulant de cette manière les JTBD, il est ensuite plus facile de les hiérarchiser entre eux afin de savoir lequel est le “main job”. 

John Kalbach nous explique qu’il y a 4 niveaux de hiérarchie au sein des Jobs.

  • Aspiration : un changement idéal (ex : Être un meilleur membre de la famille)
  • Big job : un objectif plus large (ex : Rendre visite à ma famille pour la fête des Mères)
  • Little job : un job plus petit, une étape du big job (ex : Organiser mon transport à un moment précis)
  • Micro-job : activité, tâche pour accomplir le job (ex : Démarrer le véhicule)

Vis-à-vis de cette hiérarchisation, le big job est équivalent au “main job”. Pour cerner le bon niveau d’abstraction entre les différents jobs, il faut se demander “pourquoi” on veut atteindre le niveau supérieur et “comment” descendre au niveau inférieur. Ainsi, par rapport à l’exemple cité précédemment, un job performer veut rendre visite à sa famille pour la fête des Mères dans le but d’être un meilleur membre de sa famille. Comment peut-il rendre visite à sa famille pour la fête des Mères ? En organisant son transport à un moment précis.

3) La formulation des needs

En ce qui concerne les “needs”, ils possèdent également une syntaxe définie : 

Sens du changement + Unité de mesure + Objet + Précision

Exemple : Améliorer + mes chances + d’obtenir la permission de mon supérieur + pour assister à la conférence sur la psychologie cognitive

Standardiser la formulation d’un job to be done et d’un need facilite leur compréhension puisque l’on ne s’attarde que sur les éléments à forte valeur différenciante. L’objectif de cette formulation précise est de limiter le risque d’obtenir plusieurs jobs to be done ou needs similaires. De plus, cette uniformité de formulation permet une passation plus fluide au sein d’une équipe ou entre les services.

Qu’avons-nous retenu que nous appliquerions demain ?

Une multitude de techniques sont présentées dans ce livre pour mettre en œuvre la méthode des JTBD lors d’un projet. Au cours de cette lecture, certaines techniques proposées ressemblaient déjà plus ou moins à ce que nous appliquons d’ores et déjà en interne. Par exemple, c’est le cas pour la cartographie des personas par rapport à des variables comportementales (Chapitre 4, p.98). Toutefois, d’autres techniques, que nous n’appliquons pas tout à fait de la manière que dans le livre, nous semblent potentiellement intéressantes à intégrer dans nos projets pour les tester en conditions réelles.

a) Switch Interviews – 4 forces

Cette manière de procéder pour les entretiens utilisateurs se base sur les décisions d’achat et les motivations sous-jacentes ayant amené un utilisateur à se servir d’une solution précise. Ce type d’interview ne peut avoir lieu qu’une fois la timeline d’achat ou d’utilisation complétée. Ce type d’interview n’a d’intérêt qu’auprès d’utilisateurs ayant acheté ou consommé une solution. Les entretiens sont axés autour de 4 forces qui poussent un utilisateur à changer de solution pour une autre offre. Elles sont identifiées comme telles :

  • Problème : qui éloigne de la situation actuelle
  • Attraction : qui attire vers une nouvelle solution
  • Incertitude : qui rend anxieux face à un nouveau choix
  • Habitude : qui pousse à rester avec une situation actuelle

Généralement, la finalité de ces entretiens permet de faire remonter des faiblesses dans plusieurs des 4 forces. En adressant les faiblesses qui ressortent des switch interviews, il est alors possible de faire émerger des solutions qui respectent le JTBD.

b) Définir les besoins non répondus (=unmet needs)

Prioriser les besoins est la clé de la méthode JTBD. Les solutions visant les besoins non répondus ont les plus grandes chances d’être adoptées. Un job peut avoir plusieurs besoins non répondus. Tout d’abord, il faut formuler les besoins (= les needs) des utilisateurs comme présenté plus haut dans cet article. Les “unmet needs” se retrouvent également sous l’appellation de “desired outcomes” (les résultats souhaités) dans la méthode ODI “Outcome Driven Innovation” (l’innovation axée sur les résultats).

Deux manières de traiter les “desired outcomes” existent en fonction de la présence ou non de matière issue d’une recherche utilisateur.

Dans le cas où il n’est pas possible d’obtenir une matière suffisante auprès des utilisateurs, il faut positionner les “desired outcomes” sur une matrice “Importance vs Satisfaction”. Les besoins à satisfaire en priorité sont ceux avec une forte importance et une faible satisfaction. 

Sinon, il est possible de sonder les utilisateurs sur chaque “desired outcomes” en les associant à deux échelles : importance et satisfaction (numérotée de 0 à 10). En récoltant les notes attribuées à chaque “desired outcomes”, on peut calculer le “Satisfaction Gap” sur 10. Il s’agit de la note d’importance minorée de la note de satisfaction. Ensuite, on additionne ce “satisfaction gap” à la note d’importance pour obtenir un “Opportunity Score” sur 20. Plus le résultat obtenu est élevé, plus l’opportunité est importante.

Représentation de la matrice Importance vs Satisfaction permettant de faire ressortir les besoins non répondus des jobs to be done
Matrice Importance vs Satisfaction (p.85)

Schéma explicatif du calcul du Opportunity Score pour évaluer les besoins non répondus par rapport au Satisfaction Gap des Jobs to be done
Calcul du Opportunity Score pour évaluer les besoins non répondus (p.88)

c) Les job stories

​​Les Job Stories sont différentes des User Stories. Les User Stories ne sont pas rattachées au besoin utilisateur. Il n’y a pas d’indication de pourquoi l’utilisateur agit de telle manière pour accomplir sa tâche.

La formulation d’une User Story est la suivante : En tant que (rôle), je peux (capacité) pour que (bénéfice).

Les Job Stories, quant à elles, débutent par une remise en contexte/une remise en situation. Plusieurs options existent :

Option 1 : Quand (situation), je veux que (motivation) afin que je puisse (résultat attendu).

Il faut détailler le plus possible la situation.

Ex : Quand j’ai faim, je veux pouvoir me restaurer convenablement afin que je puisse rester en forme durant toute ma journée de conférence / Quand j’ai faim, en étant en retard pour aller quelque part, sans savoir quand je pourrai manger de nouveau et ayant peur d’être fatigué et irrité à cause de la faim, je veux pouvoir me restaurer convenablement afin que je puisse rester en forme durant toute ma journée de conférence.

Option 2 : Quand je (circonstances + Étape dans le job), je veux que (micro-job) pour que je puisse (besoin).

Ex : Quand je manque de matériel pour finaliser mon projet artistique, je veux trouver des matériaux alternatifs pour que je puisse maximiser le nombre d’utilisations de mes fournitures actuelles.

Option 3 : Quand je (circonstance), je veux que (capacité de la solution) pour que je puisse (besoin).

Ex : Quand je me prépare pour aller travailler, je veux obtenir une notification du relevé météo sur mon téléphone pour que je puisse prévoir une tenue adaptée et limiter le risque d’arriver mouillé au travail à cause de la pluie.

Option 4 : Quand je (circonstance), je veux que (job) pour que (bénéfice que propose une solution).

Ex : Quand je prépare mon départ en vacances, je veux obtenir le trajet le plus rapide possible pour que je passe le moins de temps dans les embouteillages.


Les job stories doivent toutes être rédigées selon le même format de formulation. Il faut éviter un maximum les redondances et restreindre leur nombre entre 3 et 8 par projet ou sprint. Il est primordial de partager les job stories avec toutes les parties prenantes du projet. Elles servent de base commune pour vérifier si une solution proposée est appropriée ou pour réaliser des tests auprès des utilisateurs finaux.

Les éléments que nous n’utiliserons pas à court-moyen terme

Comme pour chaque méthode, des techniques peuvent ne pas s’intégrer au processus interne déjà en place. La méthode des Jobs to be done ne fait pas exception. Plusieurs éléments présentés dans ce livre nous semblent incompatibles avec notre manière de fonctionner actuellement. Certaines techniques ne sont également pas applicables à un fonctionnement en mode agence.

a) L’organisation interne autour du JTBD

La première étape pour réorganiser une entreprise autour du JTBD est d’utiliser les big jobs comme principe d’organisation pour créer des groupes locaux.

Ensuite, on organise autour des jobs en déterminant le niveau de prise en compte de ces jobs. Évidemment, il y a des fonctions business qui ne servent pas directement le JTBD qu’il faut pourtant intégrer à l’organisation. C’est pour cette raison que l’organisation autour du JTB se fait plutôt à un second voir troisième plan hiérarchique. L’objectif est d’obtenir des groupes interfonctionnels qui combinent une hiérarchie classique avec une hiérarchie centrée utilisateur. L’exemple utilisé dans le livre de Jim Kalbach est l’organisation interne chez Spotify. L’idée de cette organisation est d’ajouter des dimensions supplémentaires en complément d’une organisation plus traditionnelle afin de gagner en flexibilité. Des “Guild” regroupant des profils appartenant à plusieurs équipes sont créés autour du JTBD.

Organigramme interne autour des Jobs to be done chez Spotify avec des guildes inter-tribe.
Hiérarchie interne chez Spotify (p.211)

b) Étendre les opportunités de marché

Les jobs définissent le marché, il faut donc se concentrer sur le progrès que ce marché essaie d’atteindre en cherchant une solution pour répondre à leurs besoins.

Pour commencer, il faut regarder les progrès que veulent faire les utilisateurs. Pour ce faire, les “related jobs” doivent être pris en compte en s’intéressant aux aspirations des clients.

Ensuite, l’entreprise doit se questionner sur son activité. Elle doit obtenir une réponse unique qui reflète le progrès attendu par les utilisateurs. Il peut parfois arriver qu’il y ait plusieurs réponses possibles.

Finalement, grâce à ces enseignements, l’offre peut être recadrée. L’intérêt est de faire coïncider l’offre avec l’aspiration principale des clients (produit, service, message marketing, …) L’exemple de AirBnb est assez parlant. Chez eux, le produit c’est le « voyage » et non pas « la réservation d’un logement ». En partant de ce constat, ils ont créé «Airbnb experiences» qui propose des expériences autour du voyage (visites, activités…).

En tant qu’agence de design et d’expériences utilisateurs, nous n’avons pas la main sur les choix business et stratégiques des sociétés. Nous pouvons seulement les conseiller au mieux en prenant en compte les résultats de la recherche utilisateurs que nous effectuons.

c) La matrice de développement stratégique du JTBD

La matrice JTBD permet de prédire le développement en étudiant les solutions qui font le JTBD plus vite et moins cher.

En repartant des “unmet needs”, on peut segmenter les utilisateurs par JTBD. La matrice de développement stratégique peut être appliquée pour chaque produit ou groupe de produit afin de décider d’une stratégie. Il faut appliquer une stratégie par produit, mais une entreprise avec plusieurs produits peut appliquer des stratégies différentes pour chacun de ces produits. 

Une fois la stratégie décidée, il faut attribuer un produit ou un service à chaque segment d’utilisateur créé grâce aux “unmet needs”. Il y a ensuite 4 manières différentes de développer son marché basé sur les JTBD : 

  • Réaliser plus d’étapes : à partir de la job map, faire le plus d’étapes possible avec la solution
  • Faire mieux les étapes : comparer la manière de faire les étapes avec la concurrence pour trouver une meilleure alternative
  • Effectuer des étapes complémentaires : comment faire d’autres étapes, les intégrer au job
  • Faire de l’idéation et tester les solutions qui répondent au job d’une manière stratégique

Enfin, une proposition de valeur est construite en trouvant le message qui résonne auprès de la cible pour faire le JTBD. Le “need” doit ressortir du message marketing.

Il ne faut pas omettre l’aspect social et émotionnel ainsi que les circonstances. 

La stratégie d’un produit peut évoluer au cours du temps en fonction du changement des offres existantes et de la demande du marché. Par exemple, la société Uber a utilisé plusieurs stratégies différentes en lançant ses produits, stratégie différenciante pour Uber Black ou encore stratégie disruptive pour Uber Pool en passant par une stratégie dominante avec Uber X. 

Schéma de la matrice de développement stratégique basé sur les Jobs to be done
Matrice de développement stratégique basé sur le JTBD (p.205)

La mise en pratique aux UXDays 2023

Lors des UXDays 2023 (l’article avec le résumé de tous les ateliers se trouve ici), nous avons pu assister à l’atelier “Les secrets pour bien formuler vos Jobs-to-be-done et créer des produits innovants” présenté par deux employées de chez Peaksys, la filiale technologique de CDiscount.

Le sujet était la recherche d’opportunités de business dans le domaine de l’organisation d’anniversaires surprise.

Nous avons démarré en menant une job interview de 5 minutes dans le but de récolter un maximum d’informations sur les résultats attendus et ce qui comptait pour l’interviewé. À partir des réponses obtenues, nous devions remplir un Job-to-be-done canva pour synthétiser les éléments récoltés :

  • Le “job performer” : l’organisateur
  • Son “main job” : l’organisation d’un anniversaire surprise.
  • Les aspects émotionnels et sociaux du type “Se sentir” et “Être perçu”.
  • Les “main needs” comme “Minimiser le risque que le secret soit dévoilé”.
  • Les “main circumstances” avec la formulation “Si (comparatif 1) vs (comparatif 2)” ce qui donne “Si les invités sont à l’heure vs les invités sont en retard”

Une fois les premiers éléments issus de la job interview mis en place, nous avons décliné les grandes étapes du job. Plusieurs scénarios existent, mais les grandes étapes sont similaires : “Définir la liste des invités”, “Prévoir le repas”, etc. L’important est de toujours se focaliser sur une tâche à accomplir et non pas à une solution. Ainsi, on s’efforce d’écrire “Prévoir les couchages” à la place de “Réserver l’hôtel”.

Par manque de temps, nous n’avons pas pu aller au bout du remplissage du JTBD canva mais une “correction” nous a été fourni en fin d’atelier.

Grâce à cette mise en pratique, certaines notions nous ont paru plus claires comme l’aspect émotionnel et social d’un job ou encore la formulation des étapes du job. En revanche, nous pensons toujours que la méthode des Jobs-to-be-done ne peut pas s’appliquer à tous types de projets du fait de la spécificité du canva.

Conclusion

À la lecture des techniques présentées dans ce livre et suite à la mise en pratique aux UXDays, on a une sensation de déjà-vu. En effet, si l’on remplace la formulation “centrer sur le job” par “centrer utilisateur”, les mécaniques présentées sont sensiblement les mêmes. On retrouve beaucoup de techniques existantes dans d’autres méthodes. C’est par exemple le cas des expériences map, appelé customer journey map dans la méthode JTBD par exemple. Finalement, les JTBD peuvent facilement s’intégrer à d’autres méthodes comme le Design Thinking ou le Lean Design. En effet, cette méthode propose des techniques assez semblables.

Notre lecture nous amène à penser que la méthode Jobs to be done est un point de vue pour réaliser un projet. C’est une partie, un niveau de détail, de la réflexion centrée utilisateur. Suite à ce constat, quels sont les moments les plus opportuns dans le cycle de vie d’un projet pour passer à une approche JTBD ?

Clemence Caron