- Dans les discussions sur la roadmap produit, les responsables commerciaux, marketing, R&D et business parlent tous du client, mais si l’on passe à côté du job pour lequel le client recrute le produit, les critères de décision deviennent flous
- Intuit s’est lancée dans une course aux fonctionnalités en suivant 150 demandes de fonctionnalités issues de sondages, sans disposer d’une boussole pour distinguer celles qui comptaient vraiment
- Dans l’exemple du milk-shake, les questions sur le goût, le prix ou la texture n’ont pas augmenté les ventes, mais l’observation des situations d’achat a révélé que le job essentiel des navetteurs du matin était leur long trajet vers le travail et la faim
- Un même milk-shake concurrence le matin des bagels, barres protéinées et jus, tandis que l’après-midi il concurrence les options de goûter pour un enfant : les critères d’évaluation et les produits concurrents changent
- Pour trouver le Job to be done, il faut observer les problèmes proches, le choix de ne rien faire, les comportements de contournement, les tâches que les gens veulent éviter et les usages anormaux
Pourquoi les demandes des clients ne peuvent pas servir de boussole à la roadmap
- Dans les réunions de roadmap, chaque département apporte des retours client différents
- Les ventes estiment connaître les demandes les plus urgentes, car elles parlent constamment aux clients
- Le marketing estime pouvoir exploiter la marque existante pour créer une nouvelle version, un nouveau goût, une nouvelle couleur ou une offre spéciale
- La R&D se concentre sur les fonctionnalités et bénéfices issus de nouvelles technologies ou applications
- Le responsable business veut des lancements qui contribuent au P&L d’ici la fin de l’année
- Chaque approche a une part de validité, mais peut tomber dans le biais de confirmation, en ne regardant que les informations qui soutiennent son propre point de vue
- Le problème plus profond est qu’aucun de ces modèles ne reflète directement le job du client
La course aux fonctionnalités dans laquelle Intuit est tombée
- Intuit a mené de vastes sondages demandant aux clients quelles nouvelles fonctionnalités ils voulaient, et ceux-ci ont fourni de longues listes de fonctionnalités souhaitées
- Selon Cook, alors CEO d’Intuit, les clients demandaient « 150 fonctionnalités », et l’équipe de développement a débattu pendant des semaines pour savoir lesquelles étaient les plus importantes
- Tous les membres de l’équipe pensaient faire le bon choix pour les clients, mais en réalité ils n’avaient pas de critères de décision
- Si l’on ne sait pas pour quel travail le client « recrute » le produit, il est difficile de distinguer les bonnes fonctionnalités ; Cook a comparé cela à naviguer sans boussole
Pourquoi les ventes de milk-shakes n’ont pas augmenté
- Une chaîne de fast-food, pour vendre davantage de milk-shakes, a fait venir des clients correspondant au profil du consommateur idéal et leur a posé des questions
- Devraient-ils être moins chers ?
- Devraient-ils contenir plus de morceaux ?
- Devraient-ils être plus consistants à mâcher ?
- Devraient-ils avoir un goût de chocolat plus prononcé ?
- Les clients ont exprimé ce qu’ils voulaient, mais cela ne disait pas clairement quoi faire
- La chaîne a tenté plusieurs choses en fonction des retours clients, mais quelques mois plus tard, les ventes de la catégorie milk-shake n’avaient pas évolué
Le job du milk-shake du matin révélé par l’observation
- La question a été reformulée ainsi : « quel travail les gens essaient-ils d’accomplir en venant dans ce restaurant et en recrutant un milk-shake ? »
- L’équipe a observé les clients en magasin pendant 18 heures par jour
- Quand achètent-ils un milk-shake ?
- Comment sont-ils habillés ?
- Sont-ils venus seuls ?
- Ont-ils aussi acheté d’autres aliments ?
- Le boivent-ils sur place, ou repartent-ils en voiture ?
- Beaucoup de milk-shakes étaient vendus avant 9 h, et les acheteurs venaient généralement seuls, n’achetaient qu’un milk-shake, puis repartaient en voiture
- Le job commun des clients du matin était de supporter un trajet long et ennuyeux vers le travail, et d’éviter la faim en milieu de matinée
- Il existait des alternatives concurrentes, mais aucune n’était parfaite
- La banane se mange trop vite, ce qui laisse à nouveau faim en milieu de matinée
- Le donut fait tomber des miettes et rend les doigts collants, salissant les vêtements et le volant
- Le bagel est souvent sec et peu savoureux, avec en plus le problème de devoir étaler du cream cheese ou de la confiture en conduisant
- Le milk-shake, épais et bu lentement avec une paille fine, occupe le temps, cale pour toute la matinée et rentre dans le porte-gobelet
Un même produit affronte des concurrents différents selon le moment de la journée
- Les gens recrutent le milk-shake pour deux jobs différents, dans deux situations différentes de la journée
- Le milk-shake du matin concurrence les bagels, les barres protéinées et les bouteilles de jus frais
- Le milk-shake de l’après-midi concurrence le fait de passer dans un magasin de jouets pour un enfant, ou de rentrer tôt à la maison pour jouer au basket
- Même pour un produit identique, lorsque le job change, les produits concurrents et les critères d’évaluation changent aussi
Cinq indices pour trouver le Job to be done
-
1. Chercher les jobs à proximité
- Même dans un monde centré sur les données, certaines grandes innovations partent d’une intuition sur un Job to be done
- Khan Academy est née du désir de Sal Khan d’aider son cousin à apprendre les mathématiques sans stress, et beaucoup de gens ressentaient la même difficulté
-
2. Rivaliser avec le choix de ne rien faire
- Si les consommateurs ne trouvent pas de solution satisfaisant leur job, ils peuvent choisir de ne rien faire
- Les entreprises ne doivent pas seulement chercher comment prendre des parts de marché aux concurrents existants, mais aussi regarder où se trouve la demande invisible
- Selon Chip Conley, responsable mondial de l’hospitalité et de la stratégie d’Airbnb, 40 % des « guests » Airbnb déclarent que, sans Airbnb, ils n’auraient pas voyagé ou seraient restés chez de la famille
-
3. Observer les comportements de contournement et de compensation
- OpenTable est né d’un ancien comportement de contournement autour des réservations de restaurant
- Après avoir trouvé un créneau possible avec des amis, on appelait le restaurant ; s’il n’y avait pas de place, il fallait recontacter les amis, chercher un autre restaurant, puis recommencer
- OpenTable a résolu ce job de réservation
-
4. Trouver ce que les gens détestent faire
- Clayton Christensen appelait cela des negative jobs, et ces jobs négatifs peuvent être de bonnes opportunités d’innovation
- Rick Krieger, ancien de la Harvard Business School, et ses partenaires ont lancé QuickMedx après avoir attendu plusieurs heures aux urgences pour un test d’angine de son fils ; ce service est devenu le précurseur des CVS MinuteClinics
- CVS MinuteClinic prend en charge immédiatement les patients sans rendez-vous, et des infirmiers spécialisés peuvent prescrire des médicaments pour des affections courantes comme la conjonctivite, les otites ou les angines
- Comme beaucoup de gens ne veulent pas aller chez le médecin si ce n’est pas indispensable, MinuteClinic s’est implanté dans plus de 1 000 pharmacies CVS dans 33 États
-
5. Observer les usages anormaux
- Lorsque les gens créent eux-mêmes des comportements de contournement ou de compensation pour terminer une tâche, cela peut signaler que ce job est important et que la frustration face aux solutions existantes est forte
- Ces situations peuvent déboucher sur des opportunités d’innovation à fort potentiel
La meilleure question
- W. Edwards Deming disait : « Si vous ne savez pas poser les bonnes questions, vous ne découvrirez rien »
- La meilleure question n’est pas de demander aux clients ce qu’ils veulent, mais : « pour quel travail avez-vous recruté ce produit ? »
1 commentaires
Avis de Hacker News
L’erreur classique en gestion de produit commence généralement par l’hypothèse que les utilisateurs connaissent leurs propres besoins. En réalité, c’est rare, et c’est au produit de comprendre le vrai besoin.
Tant que les gens ne l’utilisent pas réellement, rien ne prouve que ce que vous construisez est ce que les utilisateurs veulent ; et il ne faut pas considérer que ce qu’un utilisateur demande correspond forcément à un besoin.
Même si l’équipe commerciale dit « si on ne construit pas X, on ne signera pas le contrat », il se peut qu’une fois X construit, cela ne change rien. La cause, c’est que l’analyse côté ventes était erronée.
C’est particulièrement vrai pour les nouveaux produits : les utilisateurs ne les demandent pas d’eux-mêmes, il faut donc les expliquer et les montrer. L’exemple « quand la voiture est apparue, les clients voulaient un cheval plus rapide » correspond à ce cas.
Quand quelqu’un demande quelque chose, il faut en chercher la raison. Si vous allez au garage demander qu’on remplace l’alternateur et qu’on le fait tel quel, vous pouvez rester insatisfait ; mais en demandant « pourquoi faut-il le remplacer ? », on découvre que le problème venait du solénoïde, et en le réparant on répond au véritable objectif : pouvoir se déplacer.
C’est pourquoi un développeur senior a souvent un meilleur sens produit qu’un responsable produit. Quelqu’un qui a codé un ou deux ans, obtenu une certification puis basculé vers un poste produit aura du mal à rivaliser avec la profondeur d’un vétéran.
Quelle que soit l’hypothèse de départ, si l’on ne discute pas et que l’on ne creuse pas, on prend des décisions sous-optimales.
Je suis entièrement d’accord avec l’idée d’utiliser la recherche utilisateur pour comprendre l’espace du problème et celui des fonctionnalités, mais dans la pratique, j’ai vu bien plus de gens fabriquer des Segway que d’inventeurs de voitures.
Il arrive souvent qu’on construise quelque chose sur l’intuition d’un fondateur ou une mauvaise recherche utilisateur, puis qu’on rejette à la légère les demandes des clients comme de simples « chevaux plus rapides ». Je n’ai ni le temps, ni l’énergie, ni l’envie de m’adapter à des workflows personnalisés ajoutés en partant du principe que je ne connais pas mon propre domaine métier.
Il doit y avoir une différence entre B2C et B2B, mais je la vois rarement prise en compte quand ce genre de conseil est appliqué. Je sais que cela ne veut pas dire qu’il faut ignorer les retours utilisateurs, mais je l’ai vu interprété ainsi trop souvent ; il faut une nouvelle analogie.
Bien sûr, il ne faut pas le prendre au pied de la lettre, mais observer les comportements donne souvent plus d’enseignements que demander aux utilisateurs ce qu’ils veulent. Il faut toutefois bien concevoir le cadre d’observation pour pouvoir apprendre ce que l’on cherche à comprendre.
Par exemple : « il faudrait pouvoir se promener dans le vaisseau spatial et faire une sortie extravéhiculaire pour réparer la coque après un impact de micrométéorite ».
À l’inverse, il est aussi courant que des entreprises ou des développeurs appliquent ce raisonnement à l’excès et reprochent aux joueurs qui n’apprécient pas leur jeu d’avoir tort.
Comme les commerciaux sont ceux qui ont le plus de contacts avec les utilisateurs, les responsables produit ont généralement tendance à suivre leurs propos tels quels.
Quand on fait beaucoup de support par e-mail, on voit souvent des cas de problème XY déguisés en demandes de fonctionnalités. https://en.m.wikipedia.org/wiki/XY_problem
Quelqu’un demande une fonctionnalité, souvent assez facile à ajouter, mais j’essaie d’abord de comprendre le problème sous-jacent. Les clients expriment souvent leur solution plutôt que leur problème, et cette solution peut être une mauvaise approche, voire complètement erronée.
Pour ajouter une fonctionnalité de façon élégante, la documenter et la rendre utile à d’autres, il faut comprendre la vraie douleur qu’elle résout.
« Trouvez la douleur et supprimez-la » est aussi une technique de vente puissante. Parfois, une fonctionnalité est ajoutée non pas à cause d’une douleur du client, mais à cause d’une douleur interne à l’équipe commerciale ; on finit alors par intégrer une fonctionnalité que les clients réels n’utiliseront pas, simplement parce qu’un décideur la juge importante et qu’elle passe bien en démo.
C’est particulièrement vrai lors du remplacement de logiciels legacy : il y a toujours une pression pour migrer aussi tout un bric-à-brac dont on est presque sûr qu’il n’est plus utilisé et dont le coût de reconstruction dépasse la valeur.
Par exemple, certains responsables business n’arrivent pas à abandonner la génération de rapports que personne ne lit réellement.
L’article est bon, mais je déteste vraiment le titre. Il faut poser beaucoup de questions aux clients, mais il y a très peu de choses à prendre au pied de la lettre.
Implémenter telle quelle la fonctionnalité demandée par un client est le plus court chemin vers l’échec ; il faut continuer à poser des questions et creuser au-delà de « permettez-moi de faire X ».
Pour être juste, l’article dit en réalité à peu près cela, mais je suis fatigué des titres rebattus.
Je suis d’accord avec les recommandations de Christensen et Deming, et j’aimerais ajouter Sidney Dekker. En particulier, "Field Guide to Human Error" est très bon, et ses autres livres semblent aussi valoir le détour.
L’un des meilleurs moyens de vérifier qu’une solution est réelle et qu’elle se vendra à un client consiste à demander : « achèteriez-vous ça maintenant ? ». Si la réponse est « oui, envoyez la facture et lançons la commande », quelque chose est validé.
À l’inverse, une réponse comme « hmm, peut-être, je vais en parler au comité d’achat » indique qu’on cherche encore.
Même si le produit n’est pas encore prêt et qu’on ne peut pas aller jusqu’à une vraie vente, on peut enchaîner avec des questions du type de celles de Steve Blank : « paieriez-vous un million de dollars maintenant ? », « alors combien paieriez-vous ? », « si on vous le donnait gratuitement, l’adopteriez-vous immédiatement ? ». Ces réponses indiquent où le produit se situe réellement aux yeux du client.
https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
Par expérience, les clients ne savent pas ce qu’ils veulent. C’est pourquoi un fondateur a de bonnes raisons de vouloir créer quelque chose qui résout mieux ce problème.
Je déteste vraiment le conseil « ne construisez rien avant d’avoir validé ». Pour moi, il n’a littéralement jamais fonctionné, et cela revient à poser des questions orientées tout en se tirant une balle dans le pied.
Il faut avoir une certitude sur la raison pour laquelle on fait cela. Si vous vous lancez dans un secteur que vous ne connaissez absolument pas, votre probabilité d’échec est de 99 %. Si vous savez ce que vous faites, votre probabilité de succès devrait être d’au moins 60 %.
Un produit dont les gens comprennent au premier coup d’œil qu’il résout un problème est facile à vendre. Parce qu’on a vécu le même problème et qu’on a entrepris de le résoudre.
C’est pourquoi je pense que beaucoup de sites qui mettent la validation en premier rendent volontairement vague la description de la solution.
Vous étiez en quelque sorte le client archétypal.
La citation rebattue selon laquelle « si Henry Ford avait demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides » n’est pas devenue un cliché par hasard. La plupart des gens ne savent pas ce qu’ils veulent, et c’est pour cela que les bons concepteurs de produits sont très bien payés.
Ce qu’il faut distinguer, c’est la vision produit et la façon d’écouter les retours.
Concevoir un nouveau produit qui résout les problèmes des gens n’a pas de recette miracle : c’est un savoir-faire qui mêle expérience, intuition, compréhension technique, observation des alternatives existantes, anticipation des changements techniques/économiques/sociaux, etc.
En revanche, écouter les retours consiste à vérifier si ce que l’on a conçu fonctionne comme prévu, ce qui déroute les utilisateurs et quels sont les obstacles. Ici, les méthodes classiques comme l’observation des utilisateurs, les tests et les sondages sont utiles.
Cela paraît simple, mais ça ne l’est pas du tout. J’ai vu beaucoup de designers qui ne plient pas leurs principes même quand la réalité entre en conflit avec leur idéologie, et beaucoup d’entreprises qui, inexplicablement, ne corrigent pas des bugs subis par la majorité des utilisateurs et qui suscitent la colère sur les forums de support et les réseaux sociaux.
Ces deux compétences sont très différentes ; il est déjà difficile d’exceller dans l’une, et encore plus dans les deux. L’article prend Intuit comme exemple, mais je laisse au lecteur le soin d’analyser la dynamique d’une entreprise qui fait un travail vraiment remarquable en faisant du lobbying auprès du gouvernement pour maintenir le poison tout en vendant l’antidote.
Les clients veulent réduire la douleur liée à la déclaration d’impôts, tandis qu’Intuit fait du lobbying auprès du gouvernement pour que cette douleur reste bien présente.
L’histoire de notre produit a traversé tout ce spectre.
Au début, nous ne nous intéressions qu’à la façon dont nos clients, des banques, voyaient leur activité, et à la manière dont notre produit pouvait l’améliorer. Nous empilions rapidement des idées sans même savoir ce que nous faisions, et nous nous démenions pour répondre jusqu’aux moindres caprices des clients. Nous avions l’impression de ne pas mériter leur business.
À mi-parcours, les résultats ont commencé à arriver, et nous avons compris que si nous construisions le produit en essayant de satisfaire plus de dix clients chacun à sa manière, il ne resterait finalement rien.
Aujourd’hui, notre produit ressemble davantage à un package de conseil clé en main qu’à un logiciel ou une technologie particulière. Les clients nous demandent désormais de les guider sur la façon de gérer leur activité. Quand on se retrouve au volant de ce bus, on peut standardiser la stack logicielle avec beaucoup plus d’assurance. Récemment, le mot « ennui » est entré dans notre vocabulaire.
Ce qui est intéressant avec notre base de clients, c’est sa forte tendance à se déplacer en troupeau. Si l’on parvient à faire bouger quelques acteurs dans une direction donnée, on peut amener les autres à suivre presque sans effort. Je ne pense pas que cela ne s’applique qu’aux banquiers averses au risque.
Un piège courant que l’article omet est d’écouter une minorité de clients très bruyants.
Si vous ne lisiez que Hacker News ou d’autres plateformes technophiles, il n’aurait pas été étrange de penser qu’il existait une énorme demande pour un iPhone petit écran mais performant.
En réalité, les ventes de l’iPhone mini ont été décevantes. Cela signifie que les personnes qui écrivent beaucoup en ligne sur le hardware tech ne représentent pas l’ensemble de la clientèle iPhone.
Une faible proportion ne signifie pas que les unités expédiées étaient faibles.
En réalité, quelle que soit l’entreprise que vous créez, il est très probable que vous vendiez beaucoup moins que l’iPhone Mini. Alors, parce que ses ventes sont décevantes selon les critères d’Apple, faut-il licencier tout le monde et faire faillite ? Toutes les entreprises qui vendent moins de 20 millions d’unités devraient-elles être liquidées ? Les entreprises qui ciblent une clientèle plus petite que les volumes d’expédition d’un petit iPhone ne devraient-elles pas exister et être remplacées par des produits moyens destinés à des gens moyens ? Le Mac Studio, l’écran XDR et le MacBook 15 pouces à 4 000 dollars devraient-ils aussi disparaître ?
Je connais plusieurs personnes très satisfaites de leur iPhone mini, et elles n’ont désormais plus rien vers quoi évoluer. Cela dit, cette option est moins chère.
Si les gens savaient résoudre eux-mêmes leurs problèmes, ils ne paieraient pas pour cela.
Faire quelque chose avec un ordinateur demande certes un certain niveau de compétence technique, mais la plupart des choses peuvent être résolues en suivant des règles et en utilisant Excel de manière créative.
La valeur vient du fait de fournir aux gens un framework pour résoudre leur problème, de réfléchir à leur place aux cas limites auxquels ils n’avaient pas pensé, puis de compiler ce système de règles sous forme de programme.
Curieusement, demander aux clients ce qu’ils ne veulent pas fonctionne réellement bien.
Demander aux clients ce qu’ils veulent ressemble à de la conception par comité. Ce que les gens veulent, c’est une vision bien organisée et cohérente créée par un seul artiste, moins quelques éléments.