Jobs-to-Be-Done (JTBD) est une théorie de l'innovation produit qui reformule les besoins des clients comme des "tâches" qu'ils essaient d'accomplir — avec des dimensions fonctionnelles, émotionnelles et sociales. Plutôt que d'étudier qui sont les clients (données démographiques), le JTBD étudie ce que les clients essaient d'atteindre et les circonstances qui les amènent à "embaucher" un produit pour effectuer une tâche spécifique.
?
Quel est le concept central de la théorie Jobs-to-Be-Done?
Le cadre JTBD, développé par Clayton Christensen et popularisé dans le SaaS par Bob Moesta, propose que les clients n'achètent pas de produits — ils les "embauchent" pour progresser dans une situation spécifique. L'illustration classique: un magasin de bricolage ne vend pas de forets; il vend des trous de 1/4 de pouce. Et les gens ne veulent pas des trous de 1/4 de pouce — ils veulent accrocher un tableau. Et ils ne veulent pas seulement accrocher un tableau — ils veulent être fiers de leur maison. Cette superposition des dimensions fonctionnelles, émotionnelles et sociales de chaque tâche révèle que les décisions produit axées uniquement sur la fonction des fonctionnalités manquent les moteurs émotionnels et sociaux qui influencent le plus puissamment le comportement et la fidélité des clients. Appliqué au SaaS: les clients n'"utilisent pas un CRM" — ils l'"embauchent" pour "se sentir en contrôle de mon pipeline de ventes et confiant avant une réunion de prévision."
?
Comment le Product Ops utilise-t-il le JTBD dans la découverte et la spécification de produits?
Le Product Ops intègre le JTBD en formant les PMs à utiliser les techniques d'entretien JTBD dans la recherche utilisateur. Un entretien JTBD se concentre sur l'histoire de changement du client — les moments qui l'ont amené à chercher une nouvelle solution, l'événement spécifique qui a déclenché la recherche ("le push"), ce qu'il imaginait que la nouvelle solution lui apporterait ("le pull"), et ce qui a failli l'empêcher de changer ("anxieties"). Cette chronologie des événements révèle: le contexte spécifique dans lequel les clients vivent la tâche, les concurrents qu'ils ont considérés (y compris la non-consommation — ne rien faire), les facteurs qui ont motivé leur décision, et les attentes qu'ils avaient vis-à-vis du nouveau produit. Le Product Ops compile les insights JTBD dans un modèle "Forces of Progress" que l'équipe PM utilise lors de la priorisation — garantissant que les fonctionnalités sont conçues autour du contexte complet de la tâche, et non pas seulement de la tâche fonctionnelle.
?
Comment le JTBD se connecte-t-il à l'Outcome-Driven Innovation et à la priorisation de la feuille de route?
L'Outcome-Driven Innovation (ODI), l'implémentation du JTBD par Tony Ulwick, traduit la théorie en un outil de priorisation quantitatif. L'ODI définit les "résultats souhaités" comme les métriques spécifiques que les clients utilisent pour évaluer le succès de leur tâche — exprimées sous la forme "minimiser le temps nécessaire pour [tâche]" ou "minimiser la probabilité que [situation indésirable] se produise." Les clients évaluent chaque résultat sur deux dimensions: l'importance (à quel point est-il important que le produit excelle dans ce domaine?) et la satisfaction (à quel point sont-ils satisfaits de la performance actuelle du produit?). Le score d'opportunité = Importance + max(Importance - Satisfaction, 0). Importance élevée + faible satisfaction = opportunité élevée. Cela donne au Product Ops une liste priorisée de "besoins non satisfaits" qui est statistiquement fondée sur les retours des clients, résistante à l'influence individuelle des clients, et directement exploitable pour la construction de la feuille de route.
Défi de Connaissance
Vous maîtrisez Cadre Jobs-to-Be-Done (JTBD) ? Essayez maintenant de deviner le mot associé de 5 lettres !
Écrivez ou utilisez le clavier