La méthode Job-To-Be-Done (littéralement : le travail à faire), souvent abrégée en JTBD est une approche de l’innovation centrée sur le client (Customer-centric innovation) et les résultats.
Laissons le professeur à Harvard Business School Clayton M. Christensen, l’inventeur de la théorie de l’innovation disruptive, « disruptive innovation », présenter la méthode Job-To-Be-Done.
On peut simplifier en définissant « Job to be done » de la manière suivante : remplacer le produit par le service
Le concept de « job to be done » a été développé par Clayton Christensen et Michael Raynor. Il suggère que les gens sont moins intéressés par les produits qu’ils achètent que par les services que ces produits leur rendent. Ce concept n’est pas nouveau. Dans les années 1960, Theodore Levitt, un professeur de marketing de la Harvard Business School, avait déjà remarqué que « les gens n’ont pas besoin de perceuses. Ils ont besoin de trous dans leurs murs. »
Jérôme Barthélemy, Le « job to be done » : remplacer le produit par le service
Origine du Jobs-To-Be-Done
Il semble que le premier à avoir mis en exergue cette notion soit Theodore Levitt, un professeur de marketing de la Harvard Business School dans les années 1960, qui répétait fréquemment à ses élèves : « People don’t want to buy a quarter-inch drill. They want a quarter-inch hole ».
Images PhHere
En réalité, les clients se comportent avec un produit ou un service comme le ferait un recruteur avec un candidat. Ils recherchent le produit capable de « faire le job » (en l’occurrence, le trou dans le mur) et l’« embauchent » (l’outil) pour cette raison-là. Ces utilisateurs décident d’en changer (de le « virer ») quand un autre produit fait mieux le travail.
D’un point de vue marketing, comprendre quel est ce travail, en adoptant la perspective du client, aide à créer des produits ou services innovants et adoptés par les utilisateurs finaux. En termes de design, se concentrer sur le job-to-be-done, le résultat attendu, permet aussi de créer une meilleure expérience utilisateur.
Les principes du Jobs-To-Be-Done
Dans la perspective JTBD, les segments d’utilisateurs, ou de clients, ne dépendent pas de données démographiques ou psychologiques. En fait, chacun essaie d’obtenir le même résultat, à partir de ses propres critères. L’aspect chronologique n’entre pas en ligne de compte car si les produits ou services évoluent, le Job-To-Be-Done est stable.
Le « job » est le résultat que l’utilisateur souhaite réellement accomplir, son but. C’est pour cela qu’une personne achète ou utilise les produits ou services d’une entreprise. Ses raisons d’opter pour tel produit ou service sont conscientes et inconscientes. Il s’agit des bénéfices espérés, ou des critères de réussite, appelés Functional Jobs et Personal Jobs.
Les functional jobs correspondent aux tâches essentielles pour atteindre l’objectif, aux consignes qui permettent d’accomplir le travail. C’est la dimension fonctionnelle. En quelque sorte, ce sont des bénéfices, ou des critères de réussites, objectifs.
Les Personal Jobs, les critères plus personnels, sont répartis en deux catégories : Emotional Jobs et Social Jobs.
- Les Emotional Jobs sont toutes les émotions que l’utilisateur a envie, ou peur, de ressentir durant la réalisation des tâches.
- Les Social Jobs désignent la manière dont l’utilisateur veut être perçu par les autres. Ces critères conduisent au Job-To-Be-Done, donc au choix de la solution qui permettra de réussir le job.
Concrètement, il faut donc trouver des solutions adéquates par rapport aux objectifs des utilisateurs, tout en tenant compte de leurs considérations sentimentales et sociales.
Avantages et limites
Appliquée aux méthodes de recherches UX, le Job-to-Be-Done divise. D’après ses défenseurs, adopter cette perspective aide les équipes à se concentrer sur les problèmes réels des utilisateurs afin de trouver des solutions. Comme nous le verrons ci-dessous, la façon de conduire les entretiens utilisateurs, dans une optique JTBD, semble moins contraignante qu’avec les personas. Enfin, les Jobs-To-Be-Done pourraient permettre de créer des personas plus significatifs.
Voir la comparaison avec la méthode des personas dans cette vidéo du NNGroup : Jobs-to-Be-Done vs. Personas
D’autres considèrent que les JTBD ne prennent pas suffisamment en compte, par rapport aux personas, le contexte d’utilisation des produits ou services. De plus, gommer les aspects démographiques et sociologiques (nom, âge, sexe, métier, etc.) empêcherait de ressentir de l’empathie pour les utilisateurs. Enfin, cette façon de déterminer les besoins des utilisateurs serait inadaptée à certains produits ou services complexes. Beaucoup s’accordent néanmoins à y voir, au minimum, un outil complémentaire des personas.
Pour schématiser, le persona aide à comprendre des archétypes d’utilisateurs de l’application. La méthode des personas nous montre en quoi leurs motivations peuvent être différentes et quels sont les comportements similaires. En revanche, la théorie des Jobs-to-Be-Done se focalise sur les résultats concrets attendus par les utilisateurs.
Application pratique Job-To-Be-Done
Le concept marketing du JTBD a d’abord été conçu par Clayton Christensen, professeur à la Harvard Business School, en 2007, sans exemple de mise en pratique.
Quelques applications :
D’autres professionnels du marketing de l’innovation, comme Antony Ulwick, ont approfondi le sujet. Néanmoins, il n’y a aucun modèle spécifique à suivre, ni livrable recommandé.
Voir ce “Retour d’expérience et atelier sur la méthode Jobs To Be Done (JTBD).”
Les Jobs-To-Be-Done invitent avant tout à considérer différemment le produit et les clients afin de proposer des services ou produits innovants.
C’est une structure pour développer des solutions centrées sur les objectifs des clients. Toutefois, des modèles et des cadres ont été proposés ces dernières années pour mieux appliquer la démarche JTBD. Voici donc quelques exemples de techniques issus de la boîte à outils JTBD :
- JTBD Interviews
- Job Stories
- Jobs Atlas
JTBD Interviews
Les étapes sont similaires à celles utilisées pour construire des personas : interviews d’un panel d’utilisateurs, utilisation des données quantitatives existantes, analyse et synthèse. En revanche, la manière de conduire les entretiens, d’organiser puis d’utiliser les données est différente. Il existe de nombreux guides et kits à télécharger en ligne pour mener les interviews.
Exemple de JTBD interview
Les switch interviews, par exemple, que nous pourrions traduire en français par « interview du changement » ou « de la transition », servent à comprendre pourquoi le client choisit ou rejette un produit. Quel processus le conduit à prendre cette décision ? Qu’est-ce que l’utilisateur attend du produit ? Quelle est sa valeur pour lui ?
De préférence, l’équipe choisit d’interroger quelqu’un qui a soit récemment acheté le produit ou service (dans les 30 jours précédents), soit choisi un produit ou service similaire à celui de l’entreprise, soit rejeté un produit ou service pour préférer celui d’un concurrent. Chronologiquement, on suppose que l’utilisateur l’a acheté ou rejeté en suivant ce parcours :
- La première pensée : le problème à déterminer. L’utilisateur commence à rechercher une solution de manière passive.
- Premier évènement inconnu : l’envie de trouver une solution se renforce et l’utilisateur débute une recherche active.
- Deuxième événement inconnu : Il compare les produits ou services pour résoudre son problème, se renseigne, etc. Le processus de décision se met en place.
- Achat du produit ou service et consommation.
Les premières questions à lui poser pourront être : quand est-ce que vous avez pensé à acheter ce produit pour la première fois ? Qu’est-ce qu’il s’était passé ce jour-là ? Est-ce que quelqu’un était avez-vous pendant la phase de recherche ? L’une des limites étant qu’il faut compter sur la mémoire et la sincérité de l’utilisateur.
Ensuite, d’après les JTBD, quatre « forces » sont à l’œuvre lorsque l’utilisateur passe d’un comportement à un autre :
- L’évolution de la situation (push of the situation) : ça ne fonctionne pas comme je le voudrais, j’aimerais que ce soit mieux. Pourquoi ?
- Attrait pour une nouvelle solution (pull of the new solution) : cette nouvelle solution pourrait être meilleure. Quels sont les arguments ? La réponse sera peut-être le prix, les fonctionnalités proposées, etc.
- Habitudes de la situation présente (habits of the present) : les habitudes qui provoquent une résistance au changement. Par exemple, si je persévère, ça va fonctionner mieux ou encore, l’application actuelle a aussi des avantages. Quelles sont ces habitudes ?
- Anxiété vis-à-vis de la nouvelle solution (anxiety of the new solution) : Que redoute l’utilisateur avec ce produit ? Pourquoi est-il anxieux ?
Là, aussi, l’objectif est d’obtenir ses réponses pour identifier les obstacles (pain point), bénéfices et besoins. Il sera alors possible de tirer parti de ces entretiens pour concevoir ou améliorer un produit ou service. Cependant, rien n’empêche de créer une fiche persona à laquelle on ajoute des éléments issus de ces interviews axées JTBD.
Job Stories
L’entreprise Intercom, spécialisée dans les applications de messagerie client, a conçu les Job Stories. Théoriquement, ces histoires sont racontées par des clients réels durant des entretiens et non par des personas. L’idée (discutable) étant que les User Stories des personas proviennent de personnages imaginaires, sans prise en compte des réelles causes et conséquences de leurs actes. Les deux manières de raconter l’histoire sont différentes.
Les histoires des utilisateurs, scénarios d’usage, fonctionnent sur ce modèle :
En tant que… [persona], je veux… [action] pour que… [résultat espéré].
La Job Story suit ce procédé :
Quand… [situation] Je veux… [motivation] alors je peux… [résultat espéré].
| (When) Quand…. | (I want to…) Je veux… | (So I can) Alors je peux… |
| Contexte et situation : qu’est-ce qui motive l’utilisateur à agir ? | Functional goals (objectifs fonctionnel) | Emotional goals (objectifs émotionnels)
|
| Social goals (objectifs émotionnels) |
Cependant, il est possible de combiner l’histoire du persona et la job story afin d’avoir une vision plus réaliste de l’utilisateur, sans perdre la dimension empathique du persona. Il suffit d’ajouter ces informations sur la fiche persona déjà créée qui correspond à ce segment d’utilisateurs.
Lire à ce sujet :
Incontournable, cette vidéo Flupa
Jobs-to-be-done, comprendre les motivations des utilisateurs
Les jobs-to-be-done, c’est une méthodologie qui se focalise sur l’objectif de ton usager, son désir réel, celui qui vient avant tout désir de produit. Au delà de la dimension fonctionnelle, on s’intéresse aux motivations profondes et notamment émotionnelles pour comprendre non pas comment les usagers utilisent des produits, mais pourquoi ? Solène Lagrée, Product mentor chez Openclassrooms. Animé par Sébastien L’HOSTE
Jobs Atlas
La méthodologie du Jobs Atlas a été détaillée dans l’ouvrage Job To Be Done: A Rodmap for Customer-Centered Innovation (McGraw-Hill Education, 2016) de Stephen Wunker, Jessica Watman et David Farber. Cet atlas peut aider les équipes en charge du design, du développement et autres parties prenantes lors de la conception d’un produit ou service. C’est un artefact composé de quatre sections pour comprendre les utilisateurs, leurs besoins et les expériences qu’ils recherchent dans les produits ou services proposés.
1) Le Job Drivers (moteurs, conducteurs ou vecteurs du Job)
Cette section comprend les attitudes, les circonstances et le contexte passé, tout ce qui permet de comprendre ce que pensent les utilisateurs. L’idée est de déterminer ce qui a rendu le Job-To-Be-Done désirable afin de définir un segment d’utilisateurs du produit ou service. Les modèles mentaux, motivations, sources d’anxiété, etc. rentrent dans cette catégorie.
2) Current Behaviors (comportements actuels)
Ces comportements sont en fait les actions « physiques » actuelles des utilisateurs pour accomplir le job : cliquer sur tel bouton, lire unesection du site web plutôt qu’une autre, hésiter à mettre un produit dans leur panier, etc. Il faut les rattacher au Job Driver. C’est ce que l’utilisateur fait en raison des pensées et modèles mentaux définis dans la première section.
3) Painpoints, obstacles, opportunities (points douloureux, obstacles, opportunités)
Les actions de l’utilisateur ne correspondent pas à ce qu’il pense et veut faire. D’une certaine manière, on retrouve ici les éléments qui le poussent à abandonner sa navigation ou à ne pas acheter le contenu de son panier sur un site e-commerce. Le manque d’affordance d’une application et la confusion qui en découle figurent dans cette catégorie. Cependant, tout ce qui rend l’expérience utilisateur désagréable permet aussi à l’équipe de trouver des opportunités d’amélioration.
4) Success criteria (les critères de réussite)
Les « comportements actuels » (Current Behaviors), inspirés par les pensées et les modèles mentaux de l’utilisateur (Job Drivers) sont censés l’amener vers la réussite (Success Criteria). Ce parcours est entravé par des frictions (Painpoints, obstacles). À ce stade, les designers disposent de pistes pour trouver les défis à relever et optimiser l’expérience utilisateur. C’est aussi à eux d’en faire un poster sous une forme attrayante visuellement pour susciter la créativité.
Conclusion
Ce ne sont que quelques exemples de méthodes. La théorie des Jobs-To-Be-Done invite surtout à changer de perspective, de regard, sur le client et sa relation avec le produit ou service. C’est un cadre pour trouver des solutions innovantes en partant du principe que l’utilisateur souhaite avant tout que le job soit fait le mieux possible. Néanmoins, existe de nombreux points communs entre les JTBD et les personas. Rien n’empêche de mêler les deux approches pour mieux guider la phase de conception.
Lire aussi :
Lire aussi :
- What is Jobs to be Done (JTBD)?
- Connaître les « jobs to be done » de vos clients Par CLAYTON M. CHRISTENSEN, TADDY HALL, KAREN DILLON ET DAVID S. DUNCAN
- L’innovation relève-t-elle par nature du quitte ou double ? Pas si vous comprenez les motivations des clients.
JOBS TO BE DONE: Theory to Practice
de Anthony W. Ulwick
Pourquoi tant de projets d’innovation échouent-ils ? Quelles sont les causes profondes de l’échec ? Comment peuvent-ils être évités ? Depuis 1990, Tony Ulwick a lancé un processus d’innovation qui répond à ces questions. En 1999, Tony a présenté à Clayton Christensen l’idée que « les gens ont des besoins ou des processus sous-jacents dans leur vie, auxquels ils répondent d’une manière ou d’une autre en ce moment » – un aperçu qui allait devenir la théorie des Jobs-To-Be-Done .