Jobs-to-be-done : au-delà des copier-coller

A l’heure où les Jobs-to-be-done suscitent un intérêt croissant et alors que certains bataillent sur le sens à donner à cette approche, il est essentiel de rappeler le contexte et de revenir sur quelques points clés, afin de mieux comprendre cette méthode où l’utilisateur est au centre de la réflexion produit.

En me basant sur les travaux d’experts ayant mis en perspective les Jobs-to-be-done (JTBD) et plus particulièrement sur les deux orientations qui reviennent couramment pour les définir, j’ai élaboré une synthèse des principaux aspects théoriques. J’aborderai ensuite les aspects pratiques, avec des astuces et des conseils pour vous aider à vous approprier cette méthode.

Voyons si cette citation de Tony Ulwick suffit à éclaircir le concept :
“Les Jobs-to-be-done (JTBD) sont avant tout une approche — une façon de voir qui permet d’observer les marchés, les utilisateurs, les besoins, les concurrents et les segments d’utilisateurs différemment, et ce faisant, rend l’innovation beaucoup plus prévisible et rentable.” Tony Ulwick

Cette définition ne vous avance pas plus ? Alors rappelons les notions importantes pour l’expliquer.

La théorie

Partons du postulat, attribué à Clayton Christensen, à l’origine des Jobs-to-be-done : “Chaque individu cherche à devenir une meilleure version de lui-même et à construire une meilleure version de sa vie. Dès lors, il identifie en permanence des sujets sur lesquels il souhaite progresser.”

Le « Job » est ainsi la métaphore qui représente chacun des objectifs qu’un individu cherche à atteindre quand il utilise un produit ou un service. On dit alors qu’il “recrute » un produit ou service pour réaliser un Job.

Quelques exemples de Jobs et de solutions :

Ces exemples mettent en exergue les principes fondamentaux des JTBD.

Les 3 règles du Job

1. Un Job est fonctionnel.
2. Un Job est stable dans le temps.
3. Un Job est dissocié de toute solution, il est indépendant.

Suivre ces trois règles permet de faire réellement évoluer un produit ou d’en créer de nouveaux en suivant les besoins utilisateurs. Plus question de se limiter au produit pour ajuster son offre. Dès lors, le Job est le repère qui permet de déterminer une solution adaptée. Vous l’aurez sans doute compris, un Job induit une multitude de réponses possibles, lesquelles évoluent en fonction de l’époque, des moyens technologiques et du contexte. La solution est une proposition faite aux utilisateurs, dont le taux de satisfaction est mesurable et comparable avec les solutions concurrentes. Le Job initial, quant à lui, reste le même et n’évolue pas (ou très ponctuellement, à l’occasion de grands changements).

1 Job = plusieurs solutions

Quand on cherche à “passer une soirée romantique à Paris”, l’idée du restaurant vient souvent à l’esprit. Sa fonction principale n’est pourtant pas de répondre spécifiquement à ce Job, mais il est un moyen d’y parvenir. A retenir : le nombre de Jobs auquel répond un produit ou un service est un caractère différenciant. Plus ce nombre est important plus la solution a de chances de conquérir ses utilisateurs et son marché.

Vous êtes sceptique ? Alors pensez au dernier produit que vous avez adopté car il vous permettait de faire plus de choses que sa version précédente. Ou encore, lorsque que vous êtes passé d’un Nokia 3310 à un Smartphone capable de combiner en un seul objet tous les avantages du premier avec ceux de votre appareil photo 2Mpx. Et enfin, n’appréciez-vous pas de pouvoir réserver simultanément votre avion et votre trajet de l’aéroport à l’hôtel ? Si certains exemples vous semblent plus parlants, tous appuient la même idée.

Attention cependant, le nombre de Jobs auquel une solution répond n’est pas le seul critère à prendre en compte. Pour être concurrentielle et différenciante, la solution doit se démarquer à différents niveaux tels que la rapidité, la qualité, la simplicité d’usage etc.

La pratique

Si vous êtes désormais plus à l’aise avec la notion de Job et, plus largement, de Jobs-to-be-done, vous pouvez passer à l’étape de mise en pratique. Afin d’apprendre à les identifier et à les formuler correctement, rappelons quelques règles essentielles :

Les Jobs détestent les persona. Dans son usage courant, le persona est l’outil qui représente ce que l’utilisateur veut et désire. A mon sens, la limite de cette méthode se trouve principalement dans le fait que l’on base l’ensemble des travaux d’innovation, de conception et de développement sur une personne artificielle. En effet, le persona est un artefact sur lequel on a projeté une apparence, des désirs, des sentiments, des projets et enfin un nom. Si mon produit ne plaît pas, il sera impossible de savoir si l’erreur vient du produit lui-même et de ses fonctionnalités ou de la segmentation et de la demande utilisateur basées sur un persona. Difficile dans ce cas de rectifier le tir !

Les Jobs détestent les suppositions. C’est en partie pour cette raison que les Jobs, selon moi, détestent les persona. Étant la plupart du temps un assemblage de données et d’interprétations, ils apparaissent comme un montage de suppositions. Est-ce que les utilisateurs de mon produit sont tous des trentenaires CSP+ qui aiment le bon vin ? Sans doute pas. Est-ce que cela aura un réel impact sur la solution que je vais proposer ? Je vous laisse en juger, mais mon expérience me dit que non. A ce titre, les Jobs sont plus fiables que les persona, car construits sur de l’observation et des retours utilisateurs structurés, tel que vous le verrez sur la Job Map présentée un peu plus bas.

Les Jobs détestent les solutions. Il s’agit ici d’un prérequis qui concerne uniquement la formulation du Job. Comme expliqué, élaborer une solution est la réponse à un Job. Or, elle ne doit pas apparaître dans son libellé. Je ne veux pas acheter une machine Nespresso, je veux me préparer un espresso chez moi le matin. Quelle que soit la machine que je choisis, elle devra répondre à ce Job.

Pour construire des Jobs de qualité, n’oubliez pas de combiner ces 3 principes. Votre Job doit répondre à l’ensemble de ces critères.

L’utilisateur

Une question reste toutefois en suspens : comment aller à la rencontre des utilisateurs pour construire mon produit, selon l’approche des Jobs-to-be-done ? Plusieurs moyens s’offrent à vous : interviews, questionnaires… quelle que soit votre méthode, l’essentiel est d’orienter votre recherche de sorte à comprendre ce qu’ils cherchent à réaliser quand ils utilisent votre produit ou celui de votre concurrent.

Astuce : Pour optimiser votre travail d’identification de Job lorsque vous interrogez des utilisateurs, ciblez ceux qui ne sont pas allés jusqu’au bout du parcours d’achat (abandonnistes). Demandez-leur pourquoi ils sont partis. Sonder le client insatisfait est une méthode qui s’avère puissante lorsqu’il s’agit de comprendre ce que vos utilisateurs souhaitent réellement faire.

Conclusion : Vos concurrents ne sont pas les sociétés qui créent le même produit que vous, mais l’ensemble des solutions utilisées pour réaliser le Job (Tony Ulwick). Lorsque l’on aborde les choses sous cet angle, les possibilités d’améliorer votre produit et d’optimiser la satisfaction de vos utilisateurs augmentent. J’entends déjà certains d’entre vous dire : « Attention, les utilisateurs ne savent pas ce qu’ils veulent ». Vous avez entièrement raison. Ils ne le savent pas, ou du moins pas précisément ou pas complètement. C’est pourquoi, les Jobs-to-be-done ne vont pas sans une panoplie d’outils permettant de structurer le travail avec les utilisateurs, pour en tirer le meilleur parti.

La Job Map

Comprendre le parcours d’un utilisateur sur tout le cycle de son Job et non pas simplement sur celui du produit (erreur très répandue), s’avère primordial.  Pour vous aider dans cette tâche, la Job Map est votre meilleure alliée. Elle est composée de plusieurs étapes, 8 au maximum, qui représentent la totalité du cycle d’un Job.

Les 8 étapes de la Job Map

“La Job Map n’est pas une Customer Journey car elle ne décrit pas les étapes que l’utilisateur suit pour commander, recevoir, installer […] son produit. Ces étapes sont listées ailleurs. La Job Map vous permet d’identifier ce que l’utilisateur essaie de réaliser à chaque étape du Job, indépendamment de la solution.” Tony Ulwick

Si cet outil pourrait faire l’objet d’un article à part entière, tant il est complexe et qu’il créer de dissensions entre les experts, l’essentiel est de retenir qu’il sert de structure aux retours utilisateurs. Une Job Map, a pour avantage de réduire au maximum le nombre de suppositions sur leurs attentes.

La bonne formulation d’un Job

Il n’y a pas qu’une seule façon d’aborder l’énoncé d’un Job, tout comme il n’y a pas qu’un seul moyen de découvrir les besoins utilisateurs. Il y a cependant une structure commune à tous les Jobs, qu’il faut respecter.

Remarque : Parmi les différentes visions des Jobs-to-be-done, certaines s’axent sur une formulation incluant les aspects émotionnels et sociaux. Je fais volontairement abstraction de ces notions ici, car elles font particulièrement débat et ne sont pas indispensables dans une introduction générale au concept. Il aurait été pertinent de les aborder, par exemple, pour des problématiques marketing.

A ce stade, j’ai abordé les Jobs comme des formules très génériques, qui ont l’avantage de décrire des objectifs “globaux” et d’être partagées par un grand nombre d’utilisateurs. Néanmoins, elles demeurent trop vagues pour permettre de cibler une problématique spécifique. Afin d’optimiser cette approche, je vous conseille d’y associer la notion de résultat souhaité (desired outcome). Au même titre qu’un atome d’oxygène et deux atomes d’hydrogène forment une molécule d’eau, les résultats souhaités représentent les briques qui constituent chaque besoin. C’est pourquoi, certains experts les considèrent comme l’atome du besoin. Les Jobs et les étapes de la Job Map sont composés d’une multitude de résultats souhaités, soit d’une multitudes d’attentes.

L’intégration des résultats souhaités

C’est en identifiant et répondant à toutes ces attentes utilisateurs que vous maximiserez vos chances de trouver LA solution qui remportera leur faveur. Alors, comment formuler correctement un résultat souhaité ? D’après mon expérience, deux angles différents sont envisageables :

1. Ce qui m’empêche d’atteindre le résultat > problème.
2. Et ce que je souhaite réaliser > objectif.

Ces deux orientations permettent d’adapter plus facilement l’approche des JTBD aux besoins utilisateurs.

Un bon résultat souhaité, quelle que soit sa formulation, est composé au minimum d’une direction, d’une metric (élément de mesure) et d’un objet. Ces éléments permettent d’avoir une formule claire, mais ils permettent également de réduire à sa plus simple expression la mesure de l’attente ciblée : a-t-elle été comblée ? Oui ou Non.  Une manière simple et efficace de mesurer la satisfaction de vos utilisateurs !

Le résultat souhaité centré sur le problème

“Quand j’essaie d’accrocher un tableau… dans le salon… j’ai du mal à le placer horizontalement”

Ce libellé introduit mon Job principal : “je veux accrocher un tableau”, un élément de contexte : “dans mon salon” et mon résultat souhaité : “je ne veux pas que mon tableau soit bancal”. Bien qu’ici, le résultat souhaité soit écrit sous forme négative, ce qui peut arriver avec les utilisateurs, il est facile de comprendre l’attente qui s’y cache.

En effet, cette vision synthétique de l’approche, permet de formuler les besoins utilisateurs, en s’attachant à l’essentiel : “je veux accrocher un tableau dans le salon sans qu’il penche”. Le succès de la solution sera donc simple à mesurer : “mon tableau est-il bien droit ?”

Comme mentionné précédemment, d’autres critères de succès entrent en compte pour éprouver le caractère différenciant d’une solution : est-elle facile à utiliser ? Rapide ? Fiable ?… Autant d’éléments qui peuvent être transposés par la suite.

Le résultat souhaité centré sur l’objectif

“Je veux passer le moins de temps possible à trier mes chansons, dans l’ordre que je souhaite”

Dans ce cas de figure, la formulation est bien centrée sur ce que je cherche à obtenir en utilisant la solution. J’ai identifié une action que je souhaite pouvoir réaliser (trier ma musique), en précisant une direction (réduire) et ma façon d’en mesurer le succès (temps passé). Si nécessaire, je peux ajouter un élément de contexte. Par exemple : « en voiture ». Cet élément me donne de nouveaux critères à respecter : l’utilisateur n’aura a priori qu’une seule main disponible et un temps limité (pendant un feu rouge par exemple) pour s’exécuter. Ainsi, libre à vous d’identifier des éléments de contexte pertinents pour répondre au mieux aux besoins de votre cible.

Remarque : Encore une fois, la formulation des JTBD ne se limite pas à une seule approche. Certaines se concentrent sur la superposition d’éléments de contexte, d’autres se basent davantage sur l’action ou les obstacles rencontrés. A vous de choisir celle qui vous convient le mieux et qui vous paraît la plus intuitive. Parallèlement, la Job Map permet de faciliter l’identification des résultats souhaités sur toutes les étapes du Job. Il va sans dire que l’intervention des utilisateurs finaux dans le processus est primordial, afin d’éviter au maximum les suppositions.

Une fois que vous estimez, avec vos utilisateurs, avoir identifié et listé suffisamment d’attentes, il est nécessaire de les trier par ordre de priorité. Riche de cet apport, vous pourrez construire votre produit petit à petit, en étant toujours aligné sur les besoins de vos utilisateurs. Lorsque ce pré-requis est respecté, toutes les approches et les techniques vous donneront des résultats satisfaisants, dès lors qu’ils répondent à des attentes réelles.

Pour privilégier une approche centrée utilisateur, confrontez toujours votre vision à la réalité du terrain, grâce à des cycles courts de production. En effet, le travail sur les Jobs et les résultats souhaités n’est jamais terminé. Vos utilisateurs évoluent, tout comme votre produit.

Le mot de la fin

De cette introduction aux Jobs-to-be-done, on comprend toute l’importance de la formulation d’un besoin dans la définition d’une solution.

Le champ d’application des JTBD est bien vaste et nous n’en avons pas fait le tour, tant sur le travail des besoins que sur les aspects de ciblage et de marketing. Ces points pourront faire l’objet de prochains articles.

Alors n’hésitez pas à réagir !