Les Jobs To Be Done : quel intérêt pour un Product Manager ?

Il existe à ce jour peu d’articles en français au sujet des Jobs to be Done, que nous abrègerons en "JTBD" dans cet article. 👷‍♀️ Alors, nous avons décidé de nous retrousser les manches et de nous mettre aux travaux à faire ! 👷‍♂️

La théorie des JTBD n’est pas nouvelle, elle est le fruit de la réflexion de plusieurs générations d’économistes, chercheurs en sciences sociales ou stratégistes. Certains auteurs remontent même jusqu’à la destruction créatrice chère à Schumpeter, il y a plus de 75 ans, afin de comprendre pourquoi les utilisateurs choisissent une façon de faire les choses plutôt qu’une autre. Dans cet article, le premier d’une série consacrée aux JTBD, nous allons expliquer les concepts et une sélection des principales méthodologies en nous focalisant sur leur application à une démarche Produit.

Les Jobs to be Done ? 🙃 Mais qu'est-ce que c'est ?

Difficile de trouver une définition concise des Jobs to be Done étant donnée la multiplicité des travaux sur le sujet.

Toutefois, on retrouve dans toutes ces approches des principes communs qui visent à aider une organisation à découvrir et comprendre les motivations des clients à utiliser un produit ou un service.

Les utilisateurs achètent un produit ou un service pour réaliser un “Job” 🔧

Autrement dit, on n’achète pas une perceuse pour le plaisir de posséder une perceuse ; on “loue” une perceuse pour accomplir le “Job” consistant à percer un trou (Theodore Levitt, 1960).

Un Job est une description de ce que l’utilisateur ou le client cherche à accomplir dans une situation donnée, et repose sur une vision assez mécaniste :

• l’utilisateur s’appuie sur des inputs, dans le cas du trou à percer : la cheville, le crayon à papier qui sert à marquer l’emplacement du trou, le mètre ruban, la perceuse elle-même...
• l’utilisateur effectue un certain nombre d’activités, souvent schématisées par une “Job map” (voir plus bas)
• l’utilisateur obtient un output, ici : un trou dans le mur... ou un monceau de gravat, si l’utilisateur est vraiment maladroit !

Les “Jobs” ont une dimension fonctionnelle, mais aussi des composantes émotionnelles et sociales 💏

En plus de vouloir accomplir une tâche, les individus ont également d’autres aspirations comme le fait de ressentir une émotion particulière ou être perçu d’une façon spécifique par leurs proches. Ces aspirations constituent leurs “Jobs émotionnels” et leurs “Jobs sociaux”.

La compréhension de ces dimensions émotionnelles et sociales permet de construire des propositions de valeur répondant à la fois à l’exigence fonctionnelle et aux besoins émotionnels des clients : remplir parfaitement son Job fonctionnel est un prérequis pour qu’un produit rencontre le succès, mais les émotions qu’il peut provoquer constituent aussi un élément indispensable.

Il est courant que les individus possèdent de nombreux Jobs émotionnels et sociaux attachés à leur Job principal - oui, même lorsqu’ils percent un trou dans un mur ; peut-être cherchent-ils également à impressionner leur petit.e ami.e, ou seront fiers de le raconter à leurs amis ! Si vous effectuez des entretiens qualitatifs auprès d’un échantillon représentatif d’utilisateurs, il est probable que vous en identifierez des dizaines. Ne les laissez pas de côté, ces Jobs pourront servir à éclairer de futures décisions en matière de développement ou de marketing.

Un Job To Be Done est stable dans le temps et indépendant de la solution ➡️

Un Job To Be Done fonctionnel est la plupart du temps indépendant d’une époque ou d’une technologie donnée ; le Job est stable, ce sont les produits et services proposés pour accomplir ce Job qui changent, ainsi que les attentes des individus vis-à-vis du Job.

Par exemple, le Job consistant à trouver un moyen de transport pour rentrer chez soi existait bien avant les vélos en libre service ou Uber : les chaises à porteurs, les fiacres, les omnibus…

Le Job étant stable, il constitue donc un angle d’analyse intéressant d’un point de vue stratégique et fixation d’objectifs. L’objectif cœur d’une entreprise consiste à proposer une solution accomplissant un Job donné mieux et / ou moins cher que la concurrence.

Le Job est également indépendant de la solution. Si l’on reprend l’exemple des transports, l’innovation dans ce secteur n’a pas consisté à proposer un cheval plus rapide. Le Job "aller d’un point A à un point B" doit être défini indépendamment de la solution - cheval - pour pouvoir conceptualiser de nouvelles solutions - par exemple, l’automobile. La conception de ladite solution vient très rarement des clients, qui ne sont pas des experts. En revanche, ils peuvent exprimer un certain nombre de besoins, par exemple “se déplacer plus vite” ou “ne pas prendre froid en hiver” qui permettront de qualifier leurs attentes vis à vis du Job et de guider la recherche d’une nouvelle solution.

De ce point de vue, les Jobs To Be Done correspondent tout à fait aux approches que nous préconisons chez Thiga : s'attarder sur les problèmes avec une vraie recherche utilisateurs avant de réfléchir aux solutions.

Quelques premiers outils pour pratiquer les Jobs to be Done

La Job Map 🗺️

A l’instar de presque tous les processus d’innovation, la méthodologie Jobs to be Done propose un framework découpé en étapes clés. Cette Job Map comprend 8 étapes qui permettent a priori de décrire de manière structurée n’importe quel Job :

Schématiquement, elle s’organise en 3 étapes macro : la phase de pré-exécution, la phase d’exécution du Job et la phase de post-exécution. Les phases de pré et post-exécution sont indispensables à la sensation d’accomplissement du Job et font partie intégrante de l’expérience globale.

Pour plus de détails, nous vous invitons à consulter cet article sur la création d’une Job Map.

La Job Map est un support qui permet de se poser des questions intéressantes d’un point de vue Produit :

• Le Job peut-il être exécuté de manière plus efficace, en simplifiant certaines étapes, en les automatisant ou en les supprimant ?
• Certains clients ont-ils plus de mal à effectuer le Job que d’autres ?
• Pouvons-nous supprimer le besoin d’un ou plusieurs inputs afin de faciliter la phase de pré-exécution ?
• Pour chaque étape, qu’est-ce qui peut causer un résultat médiocre ou mauvais ? À quoi ressemble le résultat idéal pour cette étape du point de vue du client ?

Reprenons l’exemple de la perceuse et du trou. La phase “Locate” peut présenter plusieurs problèmes à l’utilisateur : choisir la bonne cheville et la bonne vis par exemple, déterminer la taille du trou nécessaire pour accrocher son étagère, ou bien encore commencer par retrouver la perceuse qui est souvent rangée à la cave. La méthode JTBD incite à creuser l’importance accordée par les utilisateurs à chacune de ces activités, les points de douleurs associés, et aussi à imaginer ce qui caractériserait selon eux une étape “efficace” ou “réussie”. Par la suite, si on souhaite simplifier cette phase pour l’utilisateur, ou carrément la supprimer, on peut imaginer de multiples leviers d’action (plus ou moins fantaisistes):

• proposer des perceuses avec un design compact et élégant, qui permettent de les garder à portée de main et de les ranger facilement plutôt que de les stocker à la cave
• offrir des ressources de formations à l’utilisateur pour clarifier le matériel dont il aura besoin pour percer son trou
• proposer une application ou une perceuse connectée qui calcule automatiquement la taille de la cheville (et donc du trou) nécessaire pour soutenir une étagère, en fonction du type de mur et du poids cible de la déco qui sera posée sur l’étagère.

Le Desired Outcome Statement 🧞

Tony Ulwick, fondateur du cabinet Strategyn, a développé toute une méthodologie fondée sur les principes des Jobs To Be done, appelée “Outcome-driven-innovation” et dédiée à l’identification d’opportunités d’innovation pour un produit et une entreprise.

Le constat est simple : créer un produit à succès ou construire une démarche d’innovation repose au niveau fondamental sur la capacité à adresser de manière pertinente un besoin fort des utilisateurs. En listant l’ensemble des besoins, en identifiant ceux qui sont les plus mal adressés par le marché et en construisant une solution appropriée, on maximise théoriquement les chances de réussir. L’un des outils clés de cette méthodologie est donc le “Desired Outcome Statement”, qui consiste à formaliser les besoins utilisateurs liés à un Job donné de manière très spécifique : une direction, une métrique, un objectif et un élément de contexte.

Par exemple :

Autre exemple, pour reprendre le Job consistant à percer un trou : “minimiser la quantité de poussière générée lors du forage sur les murs en plâtre.”

Ce formalisme présente plusieurs qualités :

• il est stable : pour un Job donné, un desired outcome statement a des chances de rester valable sur une longue période (même si l’importance qu’on lui attribue peut varier dans le temps)
• il est focalisé sur la valeur perçue par l’utilisateur : on identifie et on met en avant la ou les métriques utilisées par l’utilisateur lui-même lorsqu’il évalue la qualité du Job
• il permet la comparaison avec des solutions concurrentes, en terme d’efficacité sur chacun des “outcome statements” et se prête bien à la rédaction de questionnaires quantitatifs
• il permet de segmenter les clients en différents profils, en fonction de l’importance relative accordée à chacun de ces critères de valeur

Une fois qu’on a identifié le Job et ses différentes étapes, formaliser les “Desired Outcome Statement” (via des études qualitatives ou quantitatives) permet d’identifier des besoins peu ou mal adressés qui peuvent guider l’innovation produit.

Quel intérêt pour un Product Manager ? 🥤🚘

L’approche des Jobs to be Done répond assez bien aux préoccupations fondamentales d’un bon Product Manager : acquérir une connaissance profonde des besoins des clients afin de construire un produit qui réponde aux mieux à leurs attentes.

Elle pousse également à prendre du recul et à considérer le problème dans une approche plus large que le périmètre du produit proprement dit. Un exemple d’utilisation des JTBD est celui de McDonald’s, qui s’était fixé comme objectif d’augmenter ses ventes de milkshake. La première intuition consisterait à travailler sur le produit lui même (changer la recette, introduire de nouveaux parfums…) ; mais l’équipe chargée du projet a commencé par étudier le Job des acheteurs de milkshake, via une phase d’immersion dans un McDonald’s situé à proximité d’une station-service. Leur constat : la moitié des milkshakes étaient vendus avant 8h30, et ce, quasi exclusivement au même profil de client - seul, pressé, partant au travail, en voiture et n’achetant qu’un seul milkshake. Le Job du milkshake était en effet assez spécifique : les clients voulaient quelque chose qui les maintienne éveillés et qui leur permette de ne pas avoir faim pendant toute la durée de leur voyage, parfois long et fastidieux. Pourquoi un client choisit-il un milkshake plutôt qu’une banane, qu’un donuts ou un autre snack ? Pour une raison simple, le milkshake se consomme lentement, il se sirote et occupe l’esprit ; il est également pratique à consommer tout en conduisant.

Du coup, les recommandations de l’équipe n’ont pas visé seulement le produit lui-même, mais l’ensemble de l’expérience, afin de faciliter l’exécution du Job : déplacer la position des milkshakes sur les comptoirs, proposer des cartes prépayées en partenariat avec les stations essences, repenser le packaging pour mieux isoler et maintenir le produit frais plus longtemps, épaissir la consistance pour le rendre plus long à siroter…

En bref, cette approche pour un Product Manager permet d’obtenir des informations différentes de celles issues d’un simple recensement des points de douleur et au travail séparé sur chaque point d’amélioration.

Pour un Product Manager, la méthodologie permet également de découvrir les motivations sous-jacentes qui poussent les utilisateurs à acheter un produit, et de repenser la façon dont on communique la proposition de valeur. Dans de nombreux cas, la qualité du produit n’est pas en cause, mais la façon dont il est expliqué ou vendu à l’utilisateur ne correspond pas à la façon dont ceux-ci perçoivent la valeur autour du Job. Dans ce cas, le travail sur les Desired Outcome Statements permet parfois de réajuster le discours pour mieux coller aux qualités perçues par les utilisateurs.

Si vous deviez retenir 3 points :

• Comprenez la vraie raison qui poussent vos utilisateurs à choisir votre produit : une raison mécanique, mais aussi des besoins émotionnels ou sociaux
• Réfléchissez aux contours de l’expérience globale des utilisateurs avant, pendant et après l’utilisation
• Pensez à communiquer autour de la valeur perçue par l’utilisateur au sein de vos équipes comme dans le marketing de votre produit

Voici donc pour une première approche des JTBD. Dans un prochain article, nous déroulerons un cas concret de A à Z. Stay tuned !