Introduction
Tout responsable technologique est confronté au même défi : comment savoir si nous construisons la bonne chose ? La pensée produit traditionnelle se concentre souvent sur les fonctionnalités, les données démographiques des utilisateurs ou les hypothèses internes. Jobs to be Done (JTBD) offre une perspective différente. Ce cadre déplace l'attention de ce que sont les clients vers ce que les clients essaient d'accomplir. Cet article explique JTBD en termes pratiques pour les gestionnaires technologiques. Vous apprendrez ce qu'est le cadre, quand il s'applique, comment l'utiliser dans un exemple réaliste d'organisation technologique et comment gouverner les décisions qui en découlent. À la fin, vous disposerez d'une méthode claire pour identifier les besoins des clients, prioriser le travail et mesurer le succès de manière à aligner les équipes et les parties prenantes.
Contexte de gestion
JTBD est un outil de gestion pour comprendre la demande. Il aide les dirigeants à prioriser les investissements, à aligner les équipes interfonctionnelles et à éviter de construire des fonctionnalités dont personne ne veut. L'idée centrale est que les clients « embauchent » un produit ou un service pour progresser dans une situation spécifique. Le travail (job) est le progrès recherché, pas le produit. Par exemple, une personne n'achète pas une perceuse parce qu'elle veut une perceuse ; elle embauche la perceuse pour faire des trous. Dans un contexte technologique, une entreprise pourrait embaucher un outil de gestion de projet pour coordonner le travail distribué, pas parce qu'elle veut l'outil lui-même. Ce changement subtil a de grandes implications sur la manière de définir la valeur, de cadrer les feuilles de route et de mesurer le succès.
JTBD ne remplace pas les autres cadres de gestion ; il est complémentaire. Il fonctionne bien avec les OKR (Objectives and Key Results) : objectifs et résultats clés pour fixer des buts axés sur les résultats, avec SWOT (Strengths, Weaknesses, Opportunities, Threats) : analyse des forces, faiblesses, opportunités et menaces pour l'analyse situationnelle, et avec Lean Startup (démarrage lean) : méthode de développement par hypothèses et itérations pour tester des hypothèses. Cependant, JTBD a un objectif distinct : il révèle la motivation sous-jacente au comportement du client. Alors que les OKR définissent ce que vous voulez accomplir, JTBD vous aide à comprendre pourquoi le client s'en soucie. Cette distinction est importante car de nombreuses initiatives technologiques échouent non pas à cause d'une mauvaise exécution mais à cause d'une compréhension erronée du problème.
Quand les gestionnaires devraient-ils utiliser JTBD ? Il est particulièrement utile lorsque :
- Vous entrez sur un nouveau marché ou segment.
- Les produits existants ne parviennent pas à gagner du terrain malgré une utilisation élevée.
- Les équipes sont en désaccord sur ce qu'il faut construire ensuite.
- Vous devez prioriser un backlog avec de nombreuses idées concurrentes.
- Vous concevez un nouveau produit ou une nouvelle capacité de plateforme.
Dans ces situations, JTBD fournit une manière structurée de recueillir des preuves sur les besoins des clients et de les traduire en décisions exploitables. Il est moins utile pour des améliorations progressives d'un produit mature où le comportement des utilisateurs est bien compris. Dans ces cas, des méthodes d'amélioration des processus comme PDCA (Plan, Do, Check, Act) : planifier, faire, vérifier, agir ou DMAIC (Define, Measure, Analyze, Improve, Control) : définir, mesurer, analyser, améliorer, contrôler peuvent être plus appropriées. JTBD est un outil de découverte, pas un cycle d'amélioration continue.
Une remarque importante : JTBD n'est pas une formule qui donne une réponse unique. C'est une lentille d'investigation. La qualité de vos analyses JTBD dépend de la qualité de vos entretiens clients, observations et analyses. Plus tard, nous discuterons de la manière d'éviter les pièges courants tels que le biais de confirmation et l'écoute superficielle.
Exemple d'organisation technologique
Pour rendre JTBD concret, considérons une entreprise technologique fictive appelée CloudCore, qui fournit une plateforme de gestion d'infrastructure cloud. La direction de CloudCore souhaite améliorer la rétention des clients. Ils soupçonnent que les clients se désabonnent parce que la plateforme est trop complexe. Au lieu de sauter directement aux solutions, ils décident d'appliquer JTBD.
Étape 1 : Définir le client et le contexte
CloudCore se concentre sur les petites et moyennes entreprises (PME) qui migrent vers le cloud mais manquent de personnel DevOps dédié. Le contexte est la difficulté à gérer l'infrastructure avec des ressources limitées.
Étape 2 : Mener des entretiens clients
L'équipe interroge 15 clients actuels et anciens. Ils posent des questions telles que : « Qu'essayiez-vous d'accomplir lorsque vous vous êtes inscrit à CloudCore ? » et « Que s'est-il passé la dernière fois que vous avez utilisé la plateforme ? » Ils évitent de poser des questions sur les fonctionnalités ou la satisfaction.
Étape 3 : Identifier les travaux (jobs)
À partir des entretiens, ils découvrent plusieurs travaux distincts :
- « Lorsque ma facture cloud augmente de manière inattendue, j'ai besoin de comprendre pourquoi avant que mon patron ne le demande. »
- « Lorsque je déploie une nouvelle application, j'ai besoin de m'assurer qu'elle ne casse pas les services existants. »
- « Lorsqu'un serveur tombe en panne, j'ai besoin de rétablir le service rapidement sans réveiller mon équipe à 3 heures du matin. »
Ce sont des travaux fonctionnels. Ils découvrent également des travaux émotionnels : « J'ai besoin de me sentir confiant que je ne commets pas une erreur coûteuse. »
Étape 4 : Prioriser les travaux
L'équipe note chaque travail sur l'importance, la fréquence et la satisfaction actuelle. Le travail concernant les pics de facturation inattendus arrive en tête car il est fréquent, important et mal servi.
Étape 5 : Traduire les travaux en exigences
Pour le travail principal, l'équipe définit le succès comme : « Les clients peuvent identifier la source d'une anomalie de coût en 10 minutes et prendre des mesures pour éviter qu'elle ne se reproduise. » Cela devient la base d'une nouvelle fonctionnalité : un tableau de bord de détection d'anomalies de coûts avec alertes et recommandations.
Étape 6 : Tester et apprendre
CloudCore construit une version minimale du tableau de bord et la teste avec un petit groupe de clients. Ils mesurent le temps pour identifier l'anomalie, la réduction des tickets de support liés à la facturation et la satisfaction client. En fonction des résultats, ils itèrent.
Cet exemple illustre comment JTBD fait passer une équipe d'hypothèses vagues à des résultats mesurables. Il montre également que la méthode exige une écoute active, une analyse structurée et des tests itératifs.
Travaux vs fonctionnalités dans l'exemple CloudCore
| Travail du client (ce qu'il veut accomplir) | Fonctionnalité ou solution (ce que le produit fournit) | Mesure de succès |
|---|---|---|
| Comprendre les pics de coûts cloud inattendus | Tableau de bord de détection d'anomalies de coûts | Temps pour identifier l'anomalie < 10 minutes |
| Déployer des applications sans casser les services | Outils de déploiement progressif et de test canari | Taux d'échec de déploiement < 1 % |
| Rétablir le service rapidement après une panne | Retour arrière en un clic et alertes d'incident | Temps de récupération < 5 minutes |
Remarquez que les fonctionnalités ne sont pas les travaux ; ce sont des solutions possibles. Le travail reste stable dans le temps, mais la solution peut changer.
Liste de contrôle pour la décision et la gouvernance
L'adoption de JTBD nécessite des droits de décision clairs et une gouvernance. La liste de contrôle suivante aide les gestionnaires à évaluer si une initiative JTBD est bien formée et qui doit posséder les décisions.
Liste de contrôle de revue d'initiative JTBD
| Question | Oui/Non | Responsable |
|---|---|---|
| Le segment de clientèle est-il clairement défini ? | Oui | Priya Shah, cheffe de produit |
| Avons-nous interrogé au moins 10 clients de ce segment ? | Oui (15 entretiens) | Marcus Lee, responsable de recherche |
| Les travaux sont-ils décrits dans le langage du client, pas dans le jargon interne ? | Oui | Priya Shah, cheffe de produit |
| Avons-nous priorisé les travaux en fonction de l'importance, de la fréquence et de la satisfaction ? | Oui | Priya Shah, cheffe de produit |
| Avons-nous un résultat mesurable pour le travail principal ? | Oui (temps pour identifier l'anomalie < 10 minutes) | Priya Shah, cheffe de produit |
| Avons-nous validé le travail avec des clients supplémentaires au-delà des entretiens initiaux ? | Oui (5 entretiens supplémentaires) | Marcus Lee, responsable de recherche |
| Existe-t-il un plan pour tester des solutions potentielles avec un pilote restreint ? | Oui (bêta avec 20 clients) | Elena Rodriguez, responsable d'ingénierie |
| Avons-nous défini des métriques de garde-fou pour éviter les effets secondaires négatifs ? | Oui (disponibilité du système > 99,9 %) | Elena Rodriguez, responsable d'ingénierie |
| Y a-t-il un point de décision pour continuer, modifier ou arrêter le pilote ? | Oui (après 30 jours) | Tom Baker, vice-président produit (sponsor exécutif) |
| Avons-nous documenté les hypothèses et les questions ouvertes ? | Oui (journal des hypothèses dans Confluence) | Priya Shah, cheffe de produit |
Cette liste de contrôle garantit que JTBD n'est pas seulement un exercice de remue-méninges mais conduit à des décisions concrètes fondées sur des preuves.
Considérations de gouvernance
- Droits de décision : Le cheffe de produit possède généralement la définition du problème et la priorisation. L'ingénierie possède la faisabilité de la solution et la mise en œuvre. Le sponsor exécutif possède le feu vert final pour l'investissement.
- Cadence : Le travail JTBD n'est pas un événement ponctuel. Il doit être revisité lorsque les conditions du marché changent, que de nouveaux segments sont envisagés ou que la stratégie produit évolue. La cadence dépend de l'horizon de planification et de la disponibilité des preuves.
- Modes d'échec : Méfiez-vous de ces pièges courants :
- Biais de confirmation : entendre ce que vous voulez entendre dans les entretiens. Atténuez en ayant plusieurs intervieweurs et une analyse indépendante.
- Saut vers la solution : proposer des fonctionnalités avant de comprendre pleinement le travail. Atténuez en séparant la définition du problème de l'idéation de la solution.
- Surgénéralisation : traiter un travail d'un segment comme universel. Atténuez par une validation spécifique au segment.
Conclusion
Jobs to be Done est un cadre puissant pour comprendre les besoins des clients et aligner les investissements technologiques. Cet article a expliqué ce qu'est JTBD, quand l'utiliser et comment l'appliquer avec un exemple réaliste d'organisation technologique. Nous avons fourni une liste de contrôle de décision et de gouvernance pour aider les gestionnaires à évaluer les initiatives JTBD et à attribuer les responsabilités.
Prochaines étapes pour les gestionnaires :
- Identifiez un produit ou une initiative actuelle où les besoins des clients ne sont pas clairs.
- Menez un petit ensemble d'entretiens clients en utilisant les principes JTBD.
- Définissez les principaux travaux et testez votre compréhension avec un pilote restreint et mesurable.
- Utilisez la liste de contrôle de gouvernance pour examiner les progrès et prendre des décisions éclairées.
Rappelez-vous, JTBD n'est pas une solution miracle ; c'est une manière disciplinée de poser de meilleures questions. En vous concentrant sur le progrès que recherchent les clients, vous pouvez réduire les retouches, éviter de construire des fonctionnalités inutilisées et offrir une valeur réelle. Commencez petit, mesurez les résultats et laissez les preuves guider vos choix.