Skip to main content

L’idée que les utilisateurs « embauchent » un produit peut sembler un peu étrange au premier abord. Cela a peut-être même pu vous faire croire que le cadre conceptuel appelé Jobs To Be Done est une sorte de plaisanterie entre chefs de produit.

En réalité, le jobs to be done (aussi connu sous le nom de jobs-to-be-done, JTBD ou Jobs Theory) n’est pas seulement quelque chose de réel, mais c’est aussi l’un des cadres d’analyse les plus efficaces et percutants que vous puissiez utiliser pour développer vos produits.

En tant que chef de produit senior ayant appliqué la théorie JTBD sur le terrain, croyez-moi : apprendre à utiliser cette méthodologie fascinante va complètement changer votre façon de voir votre produit.

Vous voulez plus de The CPO Club ?

Inscrivez-vous gratuitement pour terminer la lecture de cet article :

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Principes de la théorie Jobs To Be Done

Avant d’aborder la structure de ce cadre et de vous expliquer comment l’utiliser, laissez-moi vous présenter les idées centrales et les principes qui le sous-tendent, afin de vous aider à en saisir la véritable essence (au lieu de simplement mémoriser les étapes d’implémentation).

Des vétérans du management et du développement produit affirment que la première « façon de penser » derrière le JTBD remonte aux années 1960, lorsque le célèbre professeur de la Harvard Business School et spécialiste en marketing Theodore Levitt a introduit le concept de « résultats souhaités » et a prononcé cette phrase devenue célèbre :

"People don't want a 1/4 inch drill, they want a 1/4 inch hole."

Le génie de cette façon de voir les choses, c’est la manière dont on commence à aborder le développement produit.

Spotify voulait entrer sur le marché de la musique. Cependant, au lieu de créer une place de marché où l’on achèterait des chansons (comme le faisait iTunes à l’époque), ils ont compris que ce que les gens souhaitaient réellement, c’était de pouvoir écouter de la musique, pas simplement l’acheter.

Ils ont donc eu la liberté de bâtir quelque chose de fondamentalement différent (et mieux) qu’un magasin de musique : un service de streaming, qui conciliait un modèle commercial durable et la volonté des utilisateurs de simplement écouter de la musique.

Depuis ses origines dans les années 1960, l’approche axée sur la priorisation des résultats souhaités s’est fortement développée, de nombreux experts et penseurs renommés du management ayant élaboré leurs propres cadres conceptuels et « philosophies » à partir de celle-ci.

Voici quelques étapes marquantes :

L’idée de l’innovation de rupture selon Clayton Christensen, qu’il a formulée dans son ouvrage « The Innovator's Dilemma ». Clayton a remarqué que toute innovation révolutionnaire commence par la couverture des besoins d’un petit groupe de clients (les premiers utilisateurs), puis améliore la solution en vue de satisfaire les besoins additionnels d’un public plus large d’utilisateurs tardifs.

Le point central de cette structure « commencer par un créneau puis élargir » tient à la capacité des fondateurs et des chefs de produit à bien identifier les besoins et résultats recherchés par les utilisateurs de la niche, puis à faire de même pour un public plus large.

L’approche du « struggle-first » de Bob Moesta, qu’il décrit dans son livre « Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress ». Bob explique que les clients cherchent constamment à progresser dans leur vie (financièrement, dans leurs relations, ou dans tout autre domaine) et qu’ils rencontrent de nombreux obstacles sur ce chemin. Les meilleurs leaders produit repèrent ces difficultés et proposent des produits que les utilisateurs peuvent « embaucher » pour surmonter ces épreuves à leur place.

Le framework Outcome-driven Innovation (ODI) de Tony Ulwick (voici un bon article dans Harvard Business Review à ce propos). Selon Tony, le facteur ultime qui guide le processus de décision des clients est le résultat final qu’ils espèrent obtenir grâce à votre produit.

L’idée est donc que, face à plusieurs produits concurrents, les clients choisiront celui qui les aide le mieux à atteindre les résultats qu’ils désirent.

Comment fonctionne JTBD ?

Grâce à toutes ces idées et approches, nous arrivons enfin à JTBD. Il existe plusieurs interprétations de la théorie JTBD (et elles sont toutes assez pertinentes), mais je préfère personnellement la version de Tony, qu’il expose dans son ouvrage « Jobs to be Done: Theory to Practice ».

Selon lui, les clients ont besoin d’accomplir un « job » qui leur permettra d’atteindre leur résultat souhaité. Ils peuvent effectuer ce « job » par différents moyens et solutions, y compris en « embauchant » des produits qui prendront en charge cette tâche à leur place.

Si l’on cherche à visualiser ce concept, voici à quoi il ressemble :

the job to be done infographic

Le point de départ pour vos clients est l'état actuel non idéal qui ne les satisfait pas. Par exemple, pour une agente de support client en télétravail, cet état actuel est son salon où elle effectue habituellement son travail parce que son appartement ne dispose pas d’un espace de bureau dédié.

Pourquoi est-ce un état actuel non idéal ? Eh bien, à cause du bruit de fond provenant de son chien, de ses enfants et de ses voisins, elle craint de paraître non professionnelle durant ses appels de support avec ses clients.

Elle souhaite donc obtenir le résultat désiré d’avoir des appels de support sans bruit.

Pour y parvenir, elle doit changer sa situation actuelle et faire des progrès vers son résultat souhaité en diminuant le bruit de fond. C’est une tâche qu’elle doit accomplir.

Une des solutions serait d’interdire l’accès du salon à tout le monde — mais cela s’avère difficile à tenir toute une journée de travail dans un petit appartement. Une autre possibilité serait de déménager dans un logement doté d’un bureau insonorisé — mais c'est très contraignant, stressant et cela engendre de nombreux coûts à long terme. Enfin, il existe l’option de recourir à un logiciel de suppression de bruit pour supprimer tous les bruits en temps réel.

Compte tenu du coût des solutions alternatives, elle serait plus que ravie de payer une dizaine de dollars par mois pour ce type de service !

Ainsi, le logiciel de suppression du bruit a accompli sa tâche avec succès en supprimant les bruits de fond de ses appels et lui a permis d’atteindre le résultat souhaité : passer des appels sans distractions.

Nous avons rassemblé l’essentiel — prompts IA, offres exclusives, et une bibliothèque de ressources pour les responsables produit. Déverrouillez votre compte pour y accéder.

Nous avons rassemblé l’essentiel — prompts IA, offres exclusives, et une bibliothèque de ressources pour les responsables produit. Déverrouillez votre compte pour y accéder.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Les lois du JTBD

Dans sa définition du cadre JTBD sur le site de son cabinet de conseil Strategyn, Tony évoque quelques « faits » intéressants concernant ces tâches qui peuvent nous aider à mieux saisir l’essence du JTBD.

  1. Une tâche restera la même avec le temps. Autrefois, les gens engageaient des preneurs de notes pour rédiger des comptes rendus pendant les réunions. Aujourd’hui, ils utilisent des outils d’IA pour résumer à leur place. Différentes solutions, même tâche.
  2. Les tâches sont « indifférentes aux solutions ». Cela signifie que les clients peuvent recourir à différents types de solutions pour accomplir une même tâche. Cela signifie également que votre produit n’a pas besoin de ressembler à ce que proposent vos concurrents pour bien accomplir la tâche.
  3. La meilleure solution obtient toujours la tâche à remplir. En cas de concurrence, le gagnant est le produit qui traite la tâche de façon plus efficace, rapide ou économique (ou selon une combinaison de ces trois aspects).
  4. Les gens préfèrent une solution unique pour chaque tâche. Les clients préfèrent les produits qui couvrent l’ensemble de la tâche de bout en bout et évitent les situations où accomplir la tâche nécessite de faire appel à plusieurs produits.

Pour résumer, le cadre Jobs To Be Done repose sur l’idée que ce que les gens veulent réellement, ce sont les résultats finaux et non les outils utilisés pour y parvenir.

Cependant, ils attachent de l’importance au processus. Pour les aider à atteindre leurs objectifs, ils doivent accomplir certaines tâches (ou "jobs") et sont prêts à engager quelqu’un ou quelque chose (un service ou un logiciel) pour les accomplir à leur place.

En identifiant ces tâches et en adaptant vos produits pour les traiter de manière fluide, vous augmentez les chances que les gens paient pour votre produit et l’utilisent de façon continue.

Comment utiliser le cadre JTBD au quotidien dans le développement produit

Vous comprenez désormais l’importance de bien saisir l’essence du JTBD avant d’apprendre à l’utiliser, car les étapes suivantes prennent tout leur sens dans ce contexte.

Ce que je vais partager ici n’est pas la version « classique » du JTBD (que vous pouvez retrouver dans les nombreux ouvrages cités plus haut).

Je souhaite plutôt vous présenter la déclinaison du JTBD que j’ai utilisée avec succès dans la vie réelle pour certains de mes produits.

Voici un exemple Jobs to Be Done tiré de ma propre expérience professionnelle.

Comprendre les besoins du client et les résultats attendus

Le cœur de tout produit réussi est une recherche utilisateur bien menée. Sachant à quel point le JTBD repose sur l’idée que « les gens veulent des résultats, pas des outils », vous devriez toujours commencer par identifier vos utilisateurs et apprendre à connaître leurs attentes.

Je n’ai pas de méthode « spécialement adaptée au JTBD » pour cette recherche. Mon équipe produit et moi-même avons utilisé nos méthodes traditionnelles et des outils pour en savoir plus sur les utilisateurs. La seule différence, c’est que nous avons axé nos questions sur la découverte du résultat final recherché par nos utilisateurs.

Laissez-moi vous donner un exemple basé sur le service de notifications push web sur lequel nous avons travaillé.

À noter : Cet outil permet aux sites web d’envoyer des notifications push à leurs visiteurs. Il s’agit d’un nouveau canal marketing lucratif que les sites peuvent utiliser pour promouvoir leurs produits.

Pour élaborer les personas de ce service, nous interrogions les personnes ayant utilisé les produits de nos concurrents directs et indirects. Lors d’un entretien avec l’utilisateur d’un concurrent, la pratique traditionnelle consiste à poser des questions du type :

Quelles sont les trois choses que vous détestez chez {competitor} ? Quelles sont les trois choses que vous adorez ? Quels facteurs ou quelles améliorations pourraient vous pousser à passer de {competitor} à une autre solution ?

Bien que nous ayons également posé ces questions lors de nos entretiens, notre objectif principal était d'obtenir des réponses à celles-ci :

Pourquoi utilisez-vous {competitor} ? Quel est le résultat final et l'avantage que vous en tirez ? À quelle fréquence avez-vous besoin d'obtenir ce résultat ? Comment mesurez-vous le succès ou déterminez-vous si {competitor} répond à vos besoins ?

Et il y avait une bonne raison pour laquelle nous interrogions à la fois des concurrents directs (par ex. OneSignal et iZooto) et indirects (par ex. Mailchimp et Twilio). Nous avons mentionné plus tôt que les « jobs » et les résultats souhaités sont indépendants de la solution. Cela signifiait que les réponses que nous obtiendrions concernant le résultat seraient les mêmes (ou du moins similaires) quel que soit l'outil utilisé par nos répondants.

C'est exactement ce que nous avons constaté. Apparemment, le résultat souhaité le plus courant pour notre marché cible (qui était, à ce moment-là, les boutiques e-commerce) était de diminuer le nombre de soi-disant « paniers abandonnés » — lorsque des personnes ajoutent des produits à leur panier d'achat et les y laissent pendant des jours ou des semaines.

Le "job" que faisaient pour eux à la fois les services d’e-mails et de notifications push web était de rappeler aux utilisateurs qu'ils avaient un panier abandonné et d'offrir une remise s'ils revenaient finaliser l'achat.

C’est sur cette problématique que nous avons finalement décidé de nous concentrer, et nous avons développé un produit capable de le faire mieux que quiconque.

Infographie Apprendre à connaître les besoins et résultats souhaités des clients

L’exemple que j’ai mentionné ci-dessus portait sur des entretiens utilisateurs, mais ce n’est pas le seul moyen de découvrir ce que veulent vos clients. Vous pouvez également envisager de :

  • Faire des études de marché tout en identifiant différents segments de clientèle et profils démographiques.
  • Des enquêtes utilisateurs que vous pouvez mener en utilisant notre liste sélectionnée de questions d’enquête.
  • Des entretiens en groupe de discussion, au cours desquels vous invitez un groupe de personnes sélectionnées pour discuter de leurs besoins et expériences avec vous.

Mais peu importe le type de découverte client que vous entreprenez, souvenez-vous toujours de donner la priorité aux questions qui révèlent les résultats finaux que vos clients souhaitent obtenir.

Formuler l’énoncé du job

En résultat de tout ce que vous avez appris lors de vos entretiens et enquêtes, vous devriez avoir une compréhension assez solide à la fois des résultats recherchés par vos utilisateurs et des tâches qu'ils effectuent généralement pour y parvenir.

Il est maintenant temps de matérialiser ces enseignements en formulant le livrable principal de la méthodologie JTBD : un énoncé de job. Voici à quoi cela ressemble :

Infographie Formuler l’énoncé du job

Présenter les résultats et les jobs de cette façon est particulièrement utile car cela inclut des informations essentielles telles que :

  • La situation et l’environnement dans lesquels le client rencontre un problème. Dans notre cas, il s’agissait de personnes abandonnant leur panier d’achat.
  • Le job que notre client doit réaliser pour atteindre le résultat souhaité. Pour les propriétaires de boutiques en ligne, il s’agissait d’envoyer des messages de rappel à ceux qui avaient abandonné leur panier.
  • La raison émotionnelle et rationnelle qui motive le désir du client d’atteindre ce résultat. Si des personnes ajoutent des produits à leur panier et les oublient, cela représente un potentiel de chiffre d’affaires perdu pour nos clients ; ils ont donc une raison rationnelle de réduire ces cas.
  • Enfin, il y a le résultat souhaité. Dans cet exemple, les commerçants voulaient éliminer ces paniers abandonnés.

Vous aurez peut-être remarqué que nous avons utilisé le terme « messages de rappel » au lieu de « e-mails de rappel » pour les notifications push. La raison est que nos clients ne se souciaient pas vraiment du canal physique pour envoyer ce message, tant que cela permettait effectivement de diminuer le taux d’abandon.

Créer une carte du job

La documentation de nombreux jobs-to-be-done de vos clients ainsi que de leurs déclarations d’attendus et de résultats est déjà une véritable réussite. Mais ce n’est que la moitié du chemin, car il vous faudra transformer ces jobs en une proposition de valeur solide, en exigences pour un nouveau produit (y compris une feuille de route), et en expérience utilisateur.

Pour cela, nous pouvons tirer parti d’un autre livrable JTBD : la job map (carte des tâches à accomplir).

La job map est la représentation visuelle de l’ensemble du parcours que doivent suivre vos clients pour accomplir avec succès leur mission. Elle sert d’étape intermédiaire entre vos définitions de jobs et la cartographie du parcours client ou les exigences produit que vous remettrez à votre équipe d’ingénierie.

Voici un modèle de carte des tâches conçu par GitLab.

Job Map Developed By GitLab Screenshot
Source : GitLab

La structure ci-dessus est le fruit du travail de Tony Ulwich, qui a proposé de l’utiliser pour cartographier les jobs dans son cadre d’innovation pilotée par les résultats (Outcome-driven Innovation).

À présent, laissez-moi l’illustrer pour vous avec l’exemple de Spotify et du job « Créer une playlist personnalisée pour refléter un état d’esprit particulier ».

  • Définir : Les utilisateurs comprennent qu'ils ont besoin d’une playlist personnalisée selon leur humeur.
  • Localiser : Ils trouvent la fonctionnalité de création de playlist et s’y rendent.
  • Préparer : Les utilisateurs recherchent et sélectionnent les chansons qu’ils souhaitent ajouter à la playlist.
  • Confirmer : Ils revoient la playlist pour s’assurer d’avoir toutes les chansons désirées pour leur humeur.
  • Exécuter : Les utilisateurs enregistrent la playlist et lui donnent un nom.
  • Surveiller : Ils consultent des indicateurs comme le nombre d’écoutes ou de mentions "j’aime" pour évaluer la popularité de leur playlist.
  • Modifier : Les utilisateurs intègrent les retours des autres dans leurs playlists en ajoutant ou supprimant des chansons.
  • Conclure : Lorsqu’ils ressentent l’humeur pour laquelle cette playlist a été créée, les utilisateurs la lancent et profitent de la musique.

Selon le job que vous souhaitez cartographier, il peut être pertinent de supprimer certaines étapes si vous estimez qu’aucune action n’est nécessaire pour cette phase.

Créer une solution que les gens voudront recruter pour ce job

Enfin, nous arrivons à l’étape où vous pouvez créer vos livrables habituels de gestion de produit, comme des PRD, des maquettes, des user stories, et bien plus, en utilisant vos logiciels de gestion de produit quotidiens.

Vous connaissez déjà la liste des étapes que vos utilisateurs suivent pour couvrir leurs besoins non satisfaits, il ne vous reste plus qu’à créer des fonctionnalités pour couvrir les actions nécessaires à chaque étape.

Pour l’étape « préparer » du job cité ci-dessus, par exemple, il vous faudra développer une fonctionnalité permettant à vos utilisateurs de rechercher des chansons, de filtrer les playlists d’autres utilisateurs, ainsi que d’ajouter ces chansons à leur propre playlist.

Au-delà du développement de fonctionnalités correspondant aux jobs, n’oubliez pas les aspects plus « administratifs » comme votre tarification et la gestion des paiements, l’expérience client pour la gestion de leurs données et de leur compte, ainsi que leur accès au support.

Tout Est Dans La Capacité À Rendre Votre Produit “Recrutable”

Jobs To Be Done est un cadre d’analyse et une manière de penser exceptionnels qui vous aide à concentrer vos efforts sur les fonctionnalités qui rendront votre produit plus attractif pour les utilisateurs désireux de vous « recruter » afin de gérer leurs tâches à leur place.

Que vous soyez dans une start-up ou un géant de la tech (comme Intercom ou Microsoft), je vous assure que JTBD vous aidera à maximiser l’impact de votre travail de gestion de produit. Si vous avez apprécié ma réflexion sur JTBD, pensez à vous abonner à notre newsletter pour recevoir d’autres contenus similaires dans votre boîte mail.

Suren Karapetyan

Suren Karapetyan, MBA, est chef de produit principal spécialisé dans les solutions SaaS pilotées par l'IA. Il s'épanouit dans le monde dynamique des start-ups en phase initiale et trouve l'adéquation produit-marché pour celles-ci. Son portefeuille est varié, allant d'outils de suppression du bruit pour le télétravail à des logiciels de dédouanement pour des agences gouvernementales.