Clayton Christensen aimait raconter l'histoire d'une chaîne de fast-food qui voulait vendre plus de milkshakes. Elle interrogea des clients sur leurs préférences de saveurs, leur goût pour le sucré et la taille du gobelet. Aucune des modifications apportées ne fit bouger les ventes. Un chercheur tenta alors une autre approche : il s'installa sur un parking et observa les gens acheter des milkshakes. Il ne posait qu'une seule question : « Qu'est-ce que vous cherchiez à faire quand vous avez décidé de prendre un milkshake ce matin ? »
La réponse : la plupart des acheteurs du matin avaient un long trajet ennuyeux devant eux. Ils voulaient quelque chose qui les occupe et ne leur laisse pas l'estomac vide avant le déjeuner. Le milkshake remplissait ce rôle mieux qu'une banane (trop vite consommée), un bagel (trop salissant) ou un café (trop petit). Le produit avec lequel ils étaient en concurrence n'était pas les autres milkshakes — c'était l'ennui et la faim.
Cette histoire résume l'essence du Jobs-to-be-Done. Les gens n'achètent pas des produits. Ils les engagent pour accomplir un travail dans leur vie.
Dans la terminologie JTBD, un « travail » est le progrès qu'une personne cherche à accomplir dans une situation donnée. Ce n'est pas une tâche (« Je dois envoyer un fichier »). Ce n'est pas un objectif (« Je veux être plus productif »). C'est le progrès spécifique qu'une personne spécifique cherche à réaliser dans une situation spécifique — avec tout le contexte, les contraintes et les émotions qui entourent ce moment.
Le travail comporte trois composantes : une situation (le déclencheur qui crée le besoin), une motivation (ce que la personne cherche à accomplir) et un résultat (la définition du succès de son point de vue). Les trois comptent. Un produit qui maîtrise la motivation mais ignore la situation sera utilisé au mauvais moment. Un produit qui maîtrise la situation mais ignore le résultat sera engagé puis rapidement renvoyé.
Rédiger des énoncés JTBD formels force la clarté sur le travail que votre produit est réellement engagé à faire — et révèle les écarts entre ce que vous croyez être le travail et ce que les utilisateurs vivent réellement.
Remarquez comment chaque énoncé révèle quelque chose qu'une liste de fonctionnalités ne révélerait jamais : les enjeux émotionnels, le contexte des forces concurrentes et la définition du succès du point de vue de l'utilisateur. Rien de tout cela ne remonterait dans un sondage demandant « quelles fonctionnalités voulez-vous ? »
Chaque travail a trois dimensions, et les produits qui ne répondent qu'à la dimension fonctionnelle laissent de la valeur réelle sur la table.
Slack n'a pas grandi parce qu'il était meilleur que l'e-mail pour envoyer des messages (fonctionnel). Il a grandi parce qu'il faisait sentir aux équipes qu'elles étaient plus connectées et vivantes (émotionnel) et donnait aux individus l'impression de faire partie d'une conversation en temps réel plutôt que d'une file d'attente de boîte de réception (social). Les fonctionnalités qui répondent uniquement au travail fonctionnel sont facilement banalisées. Les produits qui répondent aux trois dimensions sont beaucoup plus difficiles à remplacer.
La meilleure recherche JTBD se concentre sur le moment de l'embauche — la décision de commencer à utiliser un produit — et le moment du licenciement — la décision d'arrêter. Les deux moments sont riches en signaux.
Pour l'entretien d'embauche, demandez : « Repensez à la dernière fois que vous avez décidé d'utiliser [produit]. Que se passait-il ? Qu'est-ce que vous cherchiez à accomplir ? Qu'avez-vous essayé d'abord ? » Pour l'entretien de licenciement : « Quand avez-vous arrêté d'utiliser [produit] ? Que faisiez-vous juste avant de décider de changer ? Qu'est-ce que l'alternative faisait différemment ? »
Les réponses vous surprendront presque toujours. Les utilisateurs décriront des situations, des frustrations et des motivations que votre équipe n'avait jamais anticipées. C'est tout l'intérêt. La recherche JTBD n'est pas une recherche de validation — c'est une recherche de découverte. Vous ne testez pas vos hypothèses ; vous les remplacez par des preuves.
Une fois que vous avez identifié les travaux principaux pour lesquels votre produit est engagé, utilisez-les comme filtre pour chaque décision produit significative. Pour toute fonctionnalité proposée, demandez : sur quel travail spécifique cela aide-t-il les utilisateurs à progresser ? Si la réponse est « aucun de nos travaux principaux », c'est un signal fort de déprioritiser — même si la fonctionnalité semble attrayante.
Le JTBD révèle également où vous servez trop bien. Si les utilisateurs ont un travail qui est déjà suffisamment bien accompli, ajouter plus de fonctionnalités dans cette zone génère des rendements décroissants — et ajoute potentiellement de la complexité qui rend le produit plus difficile à utiliser pour les utilisateurs ayant des travaux différents. La lentille des travaux vous montre où investir et où vous arrêter.