Toutes les équipes produit ont déjà eu cette conversation. Quelqu'un ouvre les analytics, désigne une fonctionnalité qui a demandé un trimestre de développement et demande pourquoi personne ne l'utilise. Le design a été validé. Les textes ont été soignés. Le déploiement est parti dans les temps. Et pourtant, l'adoption stagne.
La réaction habituelle consiste à en rajouter : un tooltip de plus, un email de plus, une ligne de plus dans le changelog. Mais le problème se situe souvent plus en amont. La fonctionnalité a été conçue pour un type d'utilisateur plutôt que pour un job que cet utilisateur cherchait réellement à accomplir.
Le Jobs to Be Done est le framework qui comble cet écart. Il remplace la question « qui est notre utilisateur ? » par une question plus précise : quel progrès cette personne cherche-t-elle à faire, et pour quoi nous a-t-elle engagés ? Ce guide couvre ce que signifie le JTBD, comment rédiger un job statement, comment mener les entretiens, six exemples détaillés et (la partie que la plupart des guides oublient) comment transformer un job en parcours d'onboarding qui le réalise vraiment.
À retenir
- Les gens engagent des produits pour progresser. Un job est le progrès qu'une personne veut faire dans une circonstance précise, pas une fonctionnalité, pas un persona, pas un profil démographique.
- Chaque job a trois dimensions. Fonctionnelle (la tâche), émotionnelle (ce que la personne veut ressentir) et sociale (comment elle veut être perçue). Les produits qui ne traitent que la dimension fonctionnelle perdent face à ceux qui traitent les trois.
- Le changement obéit à quatre forces. La poussée et l'attraction rapprochent les utilisateurs de vous ; l'anxiété et l'habitude les retiennent. L'onboarding consiste surtout à réduire l'anxiété, c'est pourquoi « plus de bénéfices » corrige rarement un taux d'activation faible.
- Un job statement ne contient aucune solution. « Quand [situation], je veux [motivation], pour pouvoir [résultat]. » Si un produit, une fonctionnalité ou une technologie apparaît dans la phrase, ce n'est pas un job statement.
- Interrogez ceux qui ont changé, pas tout le monde. Parlez à des personnes qui ont changé quelque chose au cours des 90 derniers jours et reconstituez leur chronologie à rebours. Les opinions sont peu fiables ; le comportement récent ne l'est pas.
- Le bénéfice se joue dans l'onboarding. Une fois le job connu, l'expérience de première utilisation cesse d'être une visite produit de votre barre de menus et devient le chemin le plus court vers une instance accomplie du job.
Qu'est-ce que le Jobs to Be Done ?
Définition du Jobs to Be Done (JTBD) : un framework de compréhension du comportement client qui décrit les personnes par le progrès qu'elles cherchent à faire dans une circonstance donnée, plutôt que par ce qu'elles sont. Selon le JTBD, les clients n'achètent pas des produits ; ils les engagent pour faire un job, et ils les licencient quand autre chose fait ce job mieux.
Ce recadrage semble anodin. En pratique, il change ce que vous construisez, ce que vous mesurez et qui vous considérez comme un concurrent.
Prenons une équipe qui conçoit une fonctionnalité de reporting. Formulé par persona, le brief dit : « Les responsables marketing des entreprises de taille intermédiaire ont besoin de meilleurs tableaux de bord. » Formulé par job, le même brief dit : « Quand mon CEO me demande comment s'est passé le mois dernier, je veux un chiffre défendable en moins de cinq minutes, pour ne pas avoir l'air mal préparé en comité de direction. »
La seconde formulation vous apprend quelque chose que la première ne pourrait jamais vous dire : le vrai concurrent n'est pas un autre outil d'analytics. C'est un tableur auquel le responsable marketing fait déjà confiance, et la pression d'une réunion qui commence dans dix minutes. Voilà pourquoi la rapidité de la réponse compte davantage que la variété des graphiques, et pourquoi un parcours d'onboarding qui commence par « connectez six sources de données » perdra à chaque fois.
D'où vient l'idée
Le framework est surtout associé à Clayton Christensen, dont l'étude sur le « milkshake » a montré que les acheteurs de milkshakes du matin d'une chaîne de fast-food ne formaient pas du tout une catégorie démographique : c'étaient des automobilistes qui engageaient une boisson épaisse pour rendre plus supportable un trajet ennuyeux conduit d'une main. La concurrence n'était pas les autres milkshakes. C'étaient les bananes, les bagels et l'ennui.
L'outcome-driven innovation de Tony Ulwick et les entretiens « switch » de Bob Moesta ont construit la mécanique pratique autour de l'idée : comment formuler un job, comment le trouver et comment détecter les forces qui finissent par faire changer quelqu'un. Les équipes SaaS modernes utilisent généralement un mélange des trois, et c'est ce que décrit ce guide.
Les trois dimensions d'un job
Un job n'est jamais purement pratique. Chaque décision d'engagement comporte trois couches, et celles qu'on ignore sont généralement celles qui décident si un produit s'installe durablement.
-
La dimension fonctionnelle : la tâche
La chose concrète qui doit se produire : consolider trois tableurs, obtenir une signature, publier une page. C'est la couche que les équipes produit documentent bien et, généralement, la seule qui arrive dans un cahier des charges.
-
La dimension émotionnelle : ce que la personne veut ressentir
Confiante plutôt qu'exposée. Aux commandes plutôt qu'en retard. Sereine un vendredi après-midi plutôt qu'anxieuse. Les jobs émotionnels expliquent pourquoi un produit techniquement inférieur à l'interface rassurante bat régulièrement un produit puissant qui donne aux gens l'impression d'être idiots.
-
La dimension sociale : comment la personne veut être perçue
Compétente aux yeux de son manager. Moderne aux yeux du conseil d'administration. Utile aux yeux de son équipe. C'est la dimension qui nourrit la promotion interne : les utilisateurs défendent les outils qui les font bien paraître auprès des personnes dont l'avis compte pour eux.
Un test pratique : prenez n'importe quelle fonctionnalité de votre roadmap actuelle et écrivez une phrase pour chaque dimension. Si les lignes émotionnelle et sociale restent vides, vous construisez une capacité, vous ne résolvez pas un job, et l'adoption dépendra entièrement de la capacité des utilisateurs à comprendre seuls pourquoi cela devrait les intéresser.
Jobs to Be Done vs personas vs user stories
Le JTBD est régulièrement présenté comme un remplaçant des personas. Ce n'est pas le cas. Les trois outils répondent à des questions différentes et échouent de manières différentes, et les équipes matures gardent les trois, simplement avec des frontières plus nettes.
| Outil | Question à laquelle il répond | Usage idéal | Comment il échoue |
|---|---|---|---|
| Persona | Qui est cette personne ? | Positionnement, ton de voix, choix des canaux, qualification commerciale | Dérive vers la fiction : photos de banque d'images, loisirs inventés et données démographiques qui ne changent jamais une décision produit |
| Job to Be Done | Quel progrès cherche-t-elle à faire, et quand ? | Priorisation de la roadmap, positionnement face aux vraies alternatives, conception de l'onboarding, définition de l'activation | Rédigé au mauvais niveau : soit si large qu'il est inutile (« gérer mon entreprise »), soit si étroit qu'il s'agit d'une demande de fonctionnalité déguisée |
| User story | Que devons-nous construire au prochain sprint ? | Cadrage et passage de relais à l'équipe technique | Devient un ticket de solution précédé de « en tant qu'utilisateur », déconnecté de tout job |
La répartition claire des rôles : le job décide de ce qui mérite d'exister, le persona décide de la façon d'en parler, et la user story décide de ce qui part en production ce sprint. Les problèmes commencent quand on demande à un persona de faire le travail du job : c'est ainsi que des équipes se retrouvent avec une roadmap pleine de fonctionnalités adaptées à l'audience mais qui ne servent rien de précis.
Comment rédiger un job statement (avec modèle)
C'est dans le job statement que l'essentiel de la valeur se crée ou se perd. Il tient en une phrase, et cette phrase doit résister à votre roadmap pendant des années.
Le modèle :
Quand [situation : la circonstance déclenchante],
je veux [motivation : ce que j'essaie de faire],
pour pouvoir [résultat attendu : en quoi ma vie s'améliore].
Les trois règles qui rendent un job statement utilisable
1. N'y mettez aucune solution
Pas de nom de produit, pas de nom de fonctionnalité, pas de technologie. « Quand je dois intégrer un nouveau client, je veux lui envoyer une séquence d'emails automatisée » n'est pas un job ; c'est une solution que quelqu'un a déjà choisie. Le job sous-jacent est : « Quand je prends un nouveau client, je veux qu'il soit productif dès la première semaine sans que je répète le même appel de configuration, pour pouvoir prendre plus de clients sans ajouter d'heures. »
Le test : un concurrent doté d'une architecture complètement différente pourrait-il répondre à cette phrase ? Si ce n'est pas le cas, vous avez rédigé une spécification.
2. Ancrez-le dans une circonstance, pas dans une fréquence
« Quand je fais le reporting hebdomadaire » est une entrée de calendrier. « Quand on me demande un chiffre que je n'ai pas sous la main » est une circonstance ; elle peut se produire chaque semaine ou trois fois un mardi, et elle vous dit exactement quand votre produit doit être présent. Les circonstances rendent les jobs exploitables pour l'onboarding et pour les déclencheurs in-app, parce qu'une circonstance peut être détectée dans le comportement produit.
3. Écrivez le résultat avec les mots de l'utilisateur, pas les vôtres
« Pour pouvoir améliorer l'efficacité de l'équipe » est une phrase tirée de votre site marketing. « Pour pouvoir arrêter d'être le goulot d'étranglement chaque fois que quelqu'un arrive » est ce qu'une personne dit vraiment. Une proposition de résultat rédigée dans le langage de l'éditeur est le signe le plus clair qu'un job statement a été inventé en réunion plutôt qu'entendu en entretien.
Surveillez le niveau. Un job placé trop haut (« développer mon entreprise ») ne permet pas de concevoir quoi que ce soit. Un job placé trop bas (« filtrer le tableau par date ») est une fonctionnalité. Le bon niveau est généralement celui d'une tâche qu'une personne pourrait accomplir en une seule fois et qu'elle décrirait comme « faite » ; c'est aussi, et ce n'est pas un hasard, la bonne taille pour l'objectif d'une première session d'onboarding.
Les quatre forces : pourquoi les utilisateurs changent (et pourquoi ils ne changent pas)
Un job explique ce que quelqu'un veut. Les quatre forces expliquent pourquoi cette personne finit par agir, ou pourquoi elle continue de ne rien faire pendant des années, pendant que votre équipe commerciale envoie des relances.
L'équation est sans détour : le changement ne se produit que lorsque la poussée et l'attraction l'emportent sur l'anxiété et l'habitude. Le marketing consacre presque toute son énergie à l'attraction. Les ventes ajoutent un peu de poussée. Presque personne ne s'occupe de l'autre plateau de la balance, et c'est de ce côté que se trouve l'essentiel de votre activation perdue.
| Force | Ce qu'on entend | Où la traiter |
|---|---|---|
| Poussée | « On ne peut pas continuer comme ça. » | Positionnement, découverte commerciale, contenu centré sur le problème |
| Attraction | « Ça réglerait le problème. » | Landing page, démo, essai gratuit |
| Anxiété | « Et si j'arrive à mi-chemin et que ça ne marche pas ? » | Onboarding : données d'exemple, annulation, une première victoire visible, première utilisation guidée |
| Habitude | « L'ancienne méthode, franchement, ça va. » | Onboarding + adoption : outils d'import, intégrations, et rendre la nouvelle méthode plus rapide que l'ancienne dès le premier jour |
C'est la chose la plus utile que le JTBD apporte à une équipe d'onboarding. Si votre taux de conversion de l'essai en abonnement payant est faible, le réflexe est de rendre le produit plus séduisant. Les quatre forces suggèrent plutôt de regarder ce que les utilisateurs redoutent pendant les dix premières minutes, un diagnostic sur lequel vous pouvez agir directement, et que nous abordons sous l'angle des métriques dans nos guides sur la friction utilisateur et sur la conversion des essais gratuits.
Comment mener un entretien Jobs to Be Done
La recherche JTBD n'est ni un sondage ni une collecte de demandes de fonctionnalités. C'est une tentative structurée de reconstituer une décision déjà prise, afin de trouver les forces qui l'ont produite.
Recrutez des personnes qui ont récemment changé : inscrites, passées à une offre supérieure ou parties au cours des 90 derniers jours
Reconstituez la chronologie à rebours à partir du moment de la décision
Identifiez la première pensée, la recherche passive, la recherche active et le déclencheur
Rapportez ce que vous avez entendu aux quatre forces
Rédigez le job statement, puis validez-le face au comportement produit
1. Recrutez des personnes qui ont récemment changé
La fraîcheur compte plus que la taille de l'échantillon. Quelqu'un qui s'est inscrit il y a onze mois vous racontera une histoire propre et rationalisée qui n'a pas grand-chose à voir avec ce qui s'est réellement passé. Quelqu'un qui s'est inscrit il y a trois semaines peut encore vous dire quel onglet était ouvert dans son navigateur et ce que son collègue a dit pendant la réunion juste avant.
Huit à douze entretiens suffisent généralement pour voir les jobs dominants se répéter. Incluez les utilisateurs partis : c'est la source de vérité la moins chère que vous obtiendrez jamais, et les seules personnes capables de vous dire à quoi ressemblait le job après que vous avez échoué à le réaliser.
2. Reconstituez la chronologie à rebours
Partez du moment de l'achat ou de l'inscription et remontez le temps. « Vous avez créé le compte un mardi après-midi. Que s'est-il passé ce matin-là ? » Puis continuez. La plupart des décisions de changement ont une longue préhistoire silencieuse : une première insatisfaction vague, des semaines ou des mois avant, un coup d'œil passif aux alternatives, puis un événement qui a soudain rendu le statu quo inacceptable.
3. Repérez les quatre moments
Chaque histoire de changement contient les mêmes temps forts. La première pensée (« ça commence à devenir pénible »). La recherche passive (lire, remarquer, chercher à moitié, sans intention d'agir). La recherche active (comparer, tester des démos, interroger ses pairs). Et le déclencheur, l'événement concret qui a transformé l'intention en action. Le déclencheur est l'élément le plus précieux de tout l'entretien, parce qu'il indique à votre marketing exactement quand se manifester et à votre onboarding exactement dans quel état l'utilisateur arrive.
4. Interrogez sur le comportement, jamais sur les préférences
« Qu'est-ce qui rendrait cela meilleur ? » produit une liste de souhaits. « Racontez-moi la dernière fois que vous avez essayé de le faire » produit des preuves. Les bonnes questions JTBD sont d'une concrétude presque ennuyeuse : qu'avez-vous essayé en premier ? Qui d'autre était présent ? Qu'est-ce qui a failli vous arrêter ? Qu'avez-vous dû arrêter de faire pour faire de la place à cela ?
La seule question à retenir par cœur : « Qu'est-ce qui a failli vous faire renoncer ? » Cette seule question fait remonter plus de matière sur la force d'anxiété qu'un sondage entier.
5. Validez le job face au comportement produit réel
Les entretiens vous disent quel est le job. Les données produit vous disent si votre produit le réalise. Dès que vous avez un job candidat, définissez à quoi ressemble « job accompli » sous forme d'événement, puis vérifiez quelle proportion de nouveaux utilisateurs l'atteint et en combien de temps. Si personne ne peut nommer cet événement, le job est encore trop abstrait. Nos guides sur les métriques d'onboarding utilisateur et le time to value expliquent comment l'instrumenter correctement.
6 exemples de Jobs to Be Done
Les job statements abstraits sont faciles à approuver et difficiles à rédiger. Ces six exemples sont volontairement écrits à un niveau exploitable, avec les dimensions fonctionnelle, émotionnelle et sociale séparées.
Job statement : Quand mon équipe travaille sur trois outils et que personne ne sait ce qui est bloqué, je veux un seul endroit qui montre le vrai statut sans que j'aie à le demander, pour pouvoir arrêter de passer mes matinées à collecter des mises à jour.
- Fonctionnelle : voir le statut actuel de chaque chantier sans collecte manuelle
- Émotionnelle : se sentir aux commandes plutôt qu'éternellement en retard
- Sociale : être perçu comme le manager qui sait toujours où en sont les choses
Job statement : Quand de l'argent entre et sort de mon entreprise chaque semaine, je veux savoir ce que je dois réellement avant l'échéance, pour pouvoir arrêter de garder un chiffre approximatif en tête en croisant les doigts.
- Fonctionnelle : un montant de dettes exact et à jour
- Émotionnelle : remplacer une angoisse financière diffuse par une certitude
- Sociale : paraître organisé aux yeux d'un expert-comptable, d'un associé ou d'un prêteur
Job statement : Quand j'ai besoin de la validation de quatre personnes sur des fuseaux horaires différents, je veux que leurs commentaires soient attachés à l'élément même qu'ils commentent, pour pouvoir arrêter de concilier des retours contradictoires issus d'un appel de groupe.
- Fonctionnelle : recueillir de façon asynchrone des retours contextualisés et attribuables
- Émotionnelle : sentir qu'on peut avancer sans attendre que les agendas s'alignent
- Sociale : être celui qui livre sans traîner tout le monde en réunion
Job statement : Quand les cinq mêmes questions arrivent chaque jour, je veux que les clients trouvent la réponse avant d'ouvrir un ticket, pour pouvoir consacrer mon temps aux problèmes qui ont vraiment besoin d'une personne.
- Fonctionnelle : rediriger les demandes répétitives vers le self-service
- Émotionnelle : sentir que le travail a du sens plutôt qu'il est mécanique
- Sociale : démontrer à la direction que l'équipe peut absorber la croissance sans recruter
Job statement : Quand une nouvelle recrue arrive lundi, je veux que tout ce dont elle a besoin soit prêt avant sa première connexion, pour pouvoir arrêter de m'excuser pour des comptes manquants le premier jour.
- Fonctionnelle : préparer comptes, documents et tâches avant une date d'arrivée
- Émotionnelle : éviter l'embarras bien précis d'un accueil visiblement désorganisé
- Sociale : représenter une entreprise bien organisée
Job statement : Quand un responsable me pose une question à laquelle je ne peux pas répondre de mémoire, je veux en quelques minutes un chiffre que je suis prêt à défendre, pour pouvoir contribuer à la décision au lieu de promettre de revenir vers lui.
- Fonctionnelle : obtenir rapidement une métrique fiable
- Émotionnelle : se sentir préparé plutôt qu'exposé
- Sociale : être crédible dans une salle où la crédibilité s'accumule
Comment appliquer le Jobs to Be Done à l'onboarding utilisateur
C'est ici que le JTBD cesse d'être un exercice de recherche et commence à rapporter. L'onboarding est le moment où votre produit soit réalise le job, soit demande d'abord à l'utilisateur d'apprendre une interface. Presque tous les mauvais onboardings relèvent du second cas.
1. Définissez l'activation comme l'accomplissement du job, pas des étapes
La plupart des définitions de l'activation mesurent indirectement l'effort : profil rempli, visite terminée, trois fonctionnalités cliquées. Aucune de ces actions n'est un progrès du point de vue de l'utilisateur. Remplacez-les par le plus petit événement qui signifie que le job a vraiment été accompli une fois : un rapport partagé, un client invité, une facture rapprochée.
Ce simple changement révèle souvent qu'un taux d'activation en apparence sain mesurait l'obéissance à votre visite plutôt que la valeur délivrée. Notre guide pour augmenter l'activation des utilisateurs approfondit le choix de cet événement, et le guide du moment aha explique comment le détecter dans vos données.
2. Supprimez chaque étape de la première session qui ne sert pas le job
Prenez votre parcours actuel d'inscription et de première utilisation et marquez chaque étape : rapproche-t-elle l'utilisateur d'une instance accomplie du job, ou sert-elle votre base de données ? Noms d'équipe, avatars, sélecteurs de rôle et écrans de préférences relèvent presque toujours du second cas. Ils peuvent attendre ; consultez notre guide des bonnes pratiques du parcours d'inscription pour voir jusqu'où on peut aller.
3. Déclenchez l'accompagnement sur la circonstance, pas sur le calendrier
Un job statement nomme une circonstance. Les circonstances sont détectables : un utilisateur ouvre la section reporting pour la première fois, importe un fichier, invite un collègue ou arrive sur une liste vide. L'accompagnement déclenché à ces moments-là porte ses fruits ; celui déclenché à « jour 1, jour 3, jour 7 » ne fonctionne généralement pas, parce qu'il ignore ce que l'utilisateur essaie de faire à cet instant.
Avec les visites produit Kompassify, vous pouvez attacher une visite ou un tooltip à l'élément et à la page exacts où le job commence réellement, et le cibler sur le segment pour qui ce job est réel, sans demander de mise en production à l'équipe technique.
4. Faites du job la checklist
Une checklist d'onboarding est l'endroit le plus clair pour rendre un job visible, parce qu'elle s'engage publiquement sur ce que « terminé » veut dire. Rédigez chaque élément comme une étape du job, formulée comme un résultat que l'utilisateur reconnaît : « Connectez le compte sur lequel vous faites réellement votre reporting », et non « Terminez la configuration de l'intégration ».
La checklist d'onboarding et la barre de progression de Kompassify existent exactement pour cela : montrer à l'utilisateur où il en est dans son job, plutôt que dans votre assistant de configuration.
5. Attaquez explicitement la force d'anxiété
Listez les trois choses que redoute le plus un nouvel utilisateur pendant les dix premières minutes : généralement « je vais importer les mauvaises données », « je vais casser quelque chose que mon équipe verra » et « je vais passer une heure sans arriver à rien ». Puis concevez de quoi neutraliser chacune : un bac à sable, une annulation visible, un jeu de données d'exemple ou un chemin de cinq minutes vers un premier résultat. L'anxiété est la force que l'onboarding est le seul à pouvoir faire bouger.
6. Segmentez par job, pas seulement par offre
Deux utilisateurs sur la même offre tarifaire peuvent arriver avec des jobs complètement différents. Une segmentation nourrie par le JTBD vous permet d'orienter chacun vers le parcours qui sert son job, la base de tout onboarding personnalisé digne de ce nom. Une courte question « qu'est-ce qui vous amène aujourd'hui ? » à l'inscription suffit souvent pour créer des embranchements, à condition que les options soient des jobs et non des intitulés de poste.
La version courte : trouvez le job, définissez l'activation comme le job accompli une fois, supprimez de la première session tout ce qui ne le sert pas, déclenchez l'aide sur la circonstance et consacrez le reste de vos efforts à l'anxiété. Cette séquence représente l'essentiel de ce que le JTBD peut apporter à une équipe d'onboarding.
Les erreurs courantes avec le Jobs to Be Done
✅ À faire
- Interroger des personnes qui ont changé au cours des 90 derniers jours
- Rédiger des job statements qui nomment une circonstance, pas un calendrier
- Inclure explicitement les dimensions émotionnelle et sociale
- Considérer les tableurs, les processus manuels et le fait de « ne rien faire » comme des concurrents
- Valider chaque job face à un événement produit mesurable
- Garder les personas, pour le positionnement et les canaux, pas pour la roadmap
- Refaire les entretiens quand votre marché ou vos prix évoluent
❌ À éviter
- Inventer des job statements en atelier sans aucun contact client
- Rédiger une demande de fonctionnalité et l'appeler un job (« je veux un export en masse »)
- Placer le job si haut qu'il ne permet de rien concevoir
- Demander aux utilisateurs ce qu'ils veulent au lieu de ce qu'ils ont fait
- Supposer qu'un produit a exactement un seul job
- Utiliser le JTBD pour justifier une décision déjà prise
- S'arrêter à la recherche ; une carte des jobs inutilisée ne change rien
L'erreur la plus coûteuse : mener les entretiens, produire une belle carte des jobs et ne jamais modifier le parcours d'onboarding. Un job qui ne change pas ce qu'un nouvel utilisateur voit lors de sa première session vous a coûté du temps de recherche et ne vous a rien rapporté. Choisissez un job, reconstruisez un parcours autour de lui et mesurez l'évolution de l'activation avant de cartographier quoi que ce soit d'autre.
Un plan sur 30 jours pour mettre le JTBD en pratique
Semaines 1–2 : trouver le job
- Extraire la liste des utilisateurs inscrits, passés à une offre supérieure ou partis au cours des 90 derniers jours
- Mener 8–12 entretiens « switch », en reconstituant chaque chronologie à rebours
- Étiqueter chaque citation : poussée, attraction, anxiété ou habitude
- Rédiger deux ou trois job statements candidats au format standard
Semaine 3 : le rendre mesurable
- Définir l'événement unique qui signifie « le job a été accompli une fois »
- L'instrumenter et mesurer la portée actuelle et le délai jusqu'au premier accomplissement
- Auditer la première session existante étape par étape au regard du job ; voir notre guide d'audit de l'onboarding
- Lister les trois principales anxiétés ressorties des entretiens
Semaine 4 : reconstruire un parcours
- Supprimer chaque étape de la première session qui ne sert pas le job
- Réécrire la checklist pour que chaque élément soit une étape du job
- Passer d'un accompagnement calé sur les jours à des déclencheurs basés sur la circonstance
- Livrer un réducteur d'anxiété : données d'exemple, annulation ou bac à sable
- Comparer le taux d'accomplissement du job avant et après
Construisez l'onboarding autour du job, pas du menu
Kompassify vous offre des visites produit, des checklists d'onboarding, des tooltips, des barres de progression et des analytics produit sans code : tout ce qu'il faut pour amener les nouveaux utilisateurs à un job accompli dès leur première session. Gratuit jusqu'à 100 utilisateurs actifs mensuels, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →Questions fréquentes
Qu'est-ce que le Jobs to Be Done (JTBD) ?
Le Jobs to Be Done est un framework qui explique le comportement des clients par le progrès qu'une personne cherche à faire dans une situation donnée, plutôt que par ce qu'elle est. Au lieu de décrire les utilisateurs par leur profil démographique ou leur poste, le JTBD décrit le job pour lequel ils engagent un produit : la tâche fonctionnelle, l'état émotionnel qu'ils veulent atteindre et la façon dont ils veulent être perçus par les autres. L'idée centrale : les gens n'achètent pas des produits, ils les engagent pour progresser dans une circonstance précise.
Quelle est la différence entre Jobs to Be Done et personas utilisateur ?
Les personas décrivent qui est l'utilisateur : poste, séniorité, taille d'entreprise, outils, objectifs. Le Jobs to Be Done décrit ce que l'utilisateur cherche à accomplir et dans quelle circonstance. Ils répondent à des questions différentes et fonctionnent mieux ensemble. Un persona vous dit comment parler à quelqu'un et par quel canal le toucher ; un job vous dit ce que votre produit doit réellement faire et où votre onboarding doit l'amener. Deux personas très différents peuvent partager le même job, et un même persona peut avoir plusieurs jobs distincts.
Comment rédiger un job statement ?
Le format standard est : Quand [situation], je veux [motivation], pour pouvoir [résultat attendu]. Un bon job statement ne contient aucune solution, reste stable dans le temps et précise la circonstance qui le déclenche. Par exemple : « Quand un nouveau collègue rejoint un projet en cours, je veux le rendre productif sans y consacrer des heures de mon temps, pour pouvoir tenir mes propres livrables. » Remarquez que rien dans cette phrase ne nomme un produit, une fonctionnalité ou une technologie : c'est le test.
Quelles sont les quatre forces du progrès en JTBD ?
Les quatre forces expliquent pourquoi un client change ou ne change pas. La poussée (push) est la frustration face à la situation actuelle. L'attraction (pull) est l'attrait de la nouvelle solution. L'anxiété est la peur de ce qui pourrait mal tourner avec la nouvelle solution. L'habitude est le confort de la façon de faire existante. Le changement ne se produit que lorsque la poussée et l'attraction l'emportent sur l'anxiété et l'habitude. L'essentiel du travail d'onboarding consiste en réalité à réduire l'anxiété et à déplacer les habitudes, pas à ajouter de l'attraction.
Comment mener un entretien Jobs to Be Done ?
Interrogez des personnes qui ont récemment adopté ou quitté votre produit, idéalement au cours des 90 derniers jours, tant que leurs souvenirs sont encore précis. Reconstituez la chronologie à rebours à partir du moment de l'achat : quand ont-elles réalisé pour la première fois que quelque chose devait changer, qu'ont-elles essayé, qu'est-ce qui a déclenché la recherche, qu'est-ce qui a failli les empêcher de s'inscrire. Interrogez-les sur des événements et des comportements, jamais sur des opinions ou des souhaits de fonctionnalités. Huit à douze entretiens avec des personnes ayant récemment changé suffisent généralement à faire émerger les jobs dominants.
Comment le Jobs to Be Done améliore-t-il l'onboarding utilisateur ?
La plupart des onboardings échouent parce qu'ils enseignent l'interface au lieu de réaliser le job. Une fois le job connu, vous pouvez définir une première session qui en accomplit une instance significative, supprimer chaque étape qui ne le sert pas et mesurer l'activation comme l'accomplissement du job plutôt que comme le nombre d'étapes terminées. Concrètement : une checklist dont les éléments correspondent au job, des visites produit qui apparaissent au moment du job plutôt qu'à la première connexion, et des états vides qui montrent à quoi ressemble le job accompli.
Le Jobs to Be Done est-il utile uniquement pour les nouveaux produits ?
Non. Le JTBD est sans doute encore plus utile sur les produits matures, où la liste des fonctionnalités a grandi plus vite que la clarté. Il donne à une équipe établie un moyen de décider quoi supprimer, quel segment est réellement servi et pourquoi une fonctionnalité bien conçue n'est pas adoptée. Mener des entretiens JTBD auprès d'utilisateurs partis est l'un des moyens les plus rapides de savoir si vous les avez perdus au profit d'un concurrent, d'un bricolage interne ou de la disparition pure et simple du job, une distinction que notre guide sur le churn utilisateur explore plus en détail.