La validation de la demande produit

Cet article est une transcription et traduction du podcast Demand Validation is Product Management publié sur le site ThisIsProductManagement le 9 Mars 2015

Steve Cohn, le fondateur de Validately, partage ces tactiques pour valider la demande d’une idée produit avant de le construire. Il explique pourquoi il pense qu’on devrait arrêter de faire des MVP (Minimum Viable Products= Produit Minimum Viable) et pourquoi les product managers doivent viser des Homeruns (c’est-à-dire des succès francs).

Les ouvrages mentionnés dans l’interview

Behind the Cloud par Marc Benioff

The Hard Thing About Hard Things par Ben Horowitz

Lean UX par Jeff Gothelf et Josh Seiden

Inspired: How to Create Products Customers Love par Marty Cagan

The Four Steps to the Epiphany par Steve Blank

The Startup Owner Manual par Steve Blank

Transcription de l’interview:

Mike Fishbein: Hey Steve, peux-tu nous parler un peu de toi?

Steve Cohn: Je m’appelle Steven Cohn, je suis le fondateur de Validately. J’ai une femme et deux garçons de trois et six ans. Ils sont pleins d’énergie, ça maintient réactif. J’ai été entrepreneur à plusieurs reprises, Validately est ma troisième startup. Nous sommes une entreprise financée par le capital risque aux premiers stades de sa croissance.

La validation de la demande telle qu’on l’entend, et bien fondamentalement lorsque vous fabriquez un produit, il y a deux questions auxquelles il est important de répondre.

La première est: «Ce produit est-il utilisable? Les gens peuvent-ils effectivement faire ce que vous souhaitez qu’ils réalisent?». Sinon, si ce n’est pas utilisable, les gens ne pourront donc pas le faire.

La seconde grande question est: « Est-ce que les gens souhaitent réellement l’utiliser? »

Voilà ce qu’est la validation de la demande.

On répond donc à la première question par des tests d’utilisabilité, on trouve de nombreuses informations sur internet expliquant comment faire cela. La validation spécifique de la demande est, je crois, un ensemble sous-estimé de tactiques de test et de procédures qui nécessitent aussi bien la technologie que le procédé approprié pour être répliquées. Fondamentalement, la question clé à laquelle vous voulez répondre est « Est-ce que les gens veulent vraiment utiliser ce produit, cette fonctionnalité?

La validation de la demande fait partie intégrante de la gestion de produit.

Mike Fishbein: L’entreprise de Steve est très intéressante. Il effectue des missions chez AlphaUX pour aider les chefs de produit de l’entreprise à mener des expérimentations sur des concepts de produits devant de vrais utilisateurs. Il a recueilli des fonds, tant de de Steve Blank, l’un des parrains du Lean et auteur de « The four steps to the epiphany » et « The startup owner’s manual », que de Marty Cagan, un partenaire du Silicon Valley Product Group et l’un des chefs de produit les plus influents. Je voulais savoir quel moment de génie partculier avait mené Steve à monter sa startup.

Steve Cohn: Pour ma première startup, je ne savais pas vraiment ce que je faisais mais j’ai trouvé un moyen de m’extirper et de parvenir à m’en sortir. Je l’ai en quelque sorte initialisée et j’ai poursuivi ma route ailleurs.

Ma seconde startup, en fait, bien que nous l’ayons vendue, fut un échec; ce n’était pas un aboutissement réussi. J’étais assez frustré par cette expérience, j’avais l’impression que tout au long de ce processus j’avais obtenu beaucoup de faux positifs. J’ai vraiment passé beaucoup de temps, environ un an à vrai dire, à rencontrer des équipes produit et des équipes de design, à lire tout ce que je pouvais et à intégrer comment l’innovation arrive sur le marché. Je suis tombé amoureux du concept du Lean et j’ai rencontré au cours de cette démarche quelques uns des grands maîtres à penser du Lean: Steve Blank, Marty Cagan, Jeff Gothelf, Laura Klein, de grands maîtres à penser qui ont écrit des livres à ce propos, qui en parlent régulièrement et animent des ateliers. Finalement, ce que nous avons fait, ce que nous avons réalisé c’est que la clé de la validation de la demande est de lier certains principes centraux du Lean et de trouver un moyen de répondre à cette question, de façon rapide pour une fonctionnalité particulière ou une idée de produit particulière, « est-ce que les gens souhaitent vraiment utiliser ceci? » L’élément clé ici est donc qu’il est très facile de définir et valider l’espace de problème et donc de parler, d’interroger les gens et dire « hey, est-ce que c’est un problème que vous rencontrez et que vous souhaiteriez résoudre? ».

Il y a un écart considérable entre quelqu’un qui dit « Oui c’est un problème auquel je suis confronté, j’aimerais qu’il soit résolu » et qui parle tout haut de ce que pourrait être une solution potentielle et quelqu’un qui valide effectivement la solution. Qui valide que l’espace de solution que vous avez en tête, est quelque chose qu’il voudrait utiliser et qu’il paierait si c’est un produit payant, ou qu’il utiliserait vraiment et en parlerait si c’est un produit de consommation. Ce sont deux choses différentes, donc la validation de la demande consiste à valider l’espace de solution et c’est ce que fait Validately.

L’idée ici est donc de déterminer des moyens de conduire des tests rapides de prototypes, de les soumettre à votre clientèle cible et de poser des questions. Structurez le test de façon appropriée, nous faisons ces recommandations sur la façon d’y parvenir sur Validately et Validately a également une académie de la recherche client Lean;c’est une plate-forme en ligne d’apprentissage sur la façon de mettre en œuvre ces techniques et par conséquent, les bonnes techniques et les bonnes technologies pour mener de rapides expérimentations sur des prototypes et valider la demande de l’espace de solution.

Mike Fishbein: Validately est né des expériences passées de Steve et s’assoit sur des clients potentiels. Il a mentionné précédemment avoir buté sur ce qu’il a appelé des faux positifs. Qu’entendait-il par là?

Steve Cohn: Laissez moi vous donner quelques statistiques intéressantes. Autour de 50% des fonctionnalités d’un produit type ne sont pas utilisées par les clients. La moitié de ce qui est fabriqué lors du lancement de production ne sera pas utilisée par les clients. Chacune de ces fonctionnalités était une bonne idée. Elles ont passé les tests de reconnaissance internes n’est-ce pas? Des personnes intelligentes qui travaillent très dur avaient une sorte d’hypothèse qu’ils pensaient suffisamment forte pour fabriquer cela.

Une autre statistique intéressante, autour de 30% du travail effectué par une équipe produit type, donc environ le tiers du travail effectué par une équipe produit est ce qu’on peut qualifier de retravaillé. Et la raison pour laquelle les gens se retrouvent à refabriquer des choses qu’ils ont déjà fabriquées ou à fabriquer des choses qui ne sont ensuite pas utilisées est que les équipes produit posent aux clients une question très simple. « Utiliseriez-vous cette fonctionnalité? » « Utiliseriez-vous ce produit? » Malheureusement, si c’était vraiment un bon indicateur de la demande, nos métiers seraient faciles. Tous les produits seraient super!

Le problème c’est que, et ce n’est pas que les gens nous induisent en erreur intentionnellement, je ne dis pas qu’il y a plein de mauvaises personnes, ce que je dis c’est qu’il y a une différence entre dire « Oui j’utiliserai hypothétiquement quelque chose » et s’y engager réellement. Ce que nous prônons donc à l’académie Validately sur la recherche client c’est ce concept appelé la question prix. Une question prix dit simplement que tant que dire oui ne coûte rien, la réponse n’a aucun sens. Ce n’est pas avant que vous lui donniez un coût et qu’ils commencent à vraiment analyser les compromis qu’ils auront à faire, que vous ne validez réellement s’ils pensent sincèrement ce qu’ils disent.

Après quand je parle de question de coût, certaines personnes disent « Mon produit est gratuit, je ne le fais pas payer. » ou « Vous savez nous ne pourrons jamais faire prépayer les clients pour quelque chose » ou d’autres réflexions de ce type.

En fait il y a trois versions de la question de prix, de la façon de donner un prix à la réponse donnée au test : le temps, la réputation et l’argent. Ça n’est donc pas obligatoirement de l’argent.

Le temps correspond à leur volonté à vous consacrer du temps pour vous aider à résoudre le problème, en se basant sur ce qu’ils ont vu du prototype. Ce qu’ils ont vu est-il suffisamment convainquant pour eux, le problème est-il suffisamment important à leurs yeux pour qu’ils soient prêts à donner de leur temps gratuitement? Et c’est encore une chose qui revient souvent « Puis-je payer les gens pour leur temps? » Vous ne pouvez cependant pas payer les gens pour leur temps car vous ne saurez alors pas s’ils sont vraiment intéressés par votre produit ou par le fait d’être payés. Cela nous ramène aux vieilles expériences scientifiques que nous apprenons au lycée lorsque l’on a une seule variable à la fois. Si les variables que vous introduisez sont l’argent et la demande, ce sont alors deux variables vous devez donc en garder une constante. Et je vous le dis définitivement car je le vois encore et encore, si les gens s’intéressent au problème que vous résolvez et qu’ils sont suffisamment convaincus par le prototype de la solution, ils vous donneront leur temps gratuitement, pour continuer à travailler avec vous à la construction d’un bon produit qu’ils aiment. Ils le feront.

La réputation comprend une forme de partage social ou le fait d’amener d’autres personnes vers le produit ou vers le processus. L’argent vient sous forme de prépaiement pour un produit ou de la signature d’un contrat. Certaines personnes disent « vous ne pouvez raisonnablement pas amener les gens à prépayer les choses ». Côté consommateur, Kickstarter est un très bel exemple de ça. Côté BtoB, je le vois tout le temps, il y a des tonnes d’exemples d’entreprises, je l’ai fait aussi dans mes startups, nous avons vendu des produits en cours de développement, nous avons régulièrement pré-vendu des logiciels et du matériel informatique aux clients avant même qu’ils ne soient construits. Ça se passe dans des grandes entreprises et des petites entreprises avec de gros clients et des petits clients.

La clé c’est de s’assurer de poser la question aux clients car tant que vous ne leur avez pas fait faire ce compromis, vous n’en comprenez les raisons. La clé ici, c’est que vous ne cherchez pas toujours une réponse positive. L’intérêt de mener ces expériences en soumettant les prototypes aux clients, c’est autant d’obtenir une réponse négative que positive. Parce que lorsque la réponse est négative, la question suivante est vraiment importante. Pourquoi? C’est là que les clients peuvent vous le dire, les clients sont vraiment excellents dans ce domaine. Les clients ne peuvent pas prévoir le futur, ils ne peuvent pas prévoir les solutions, ils peuvent vous dire ce qui n’est pas convainquant concernant quelque chose qui se trouve devant eux.

Mike Fishbein: Steve nous détaille ce sur quoi les chefs de produit buttent régulièrement quand il s’agit de susciter des retours sur des concepts de produit. Mais comment ces défis diffèrent-ils d’une startup à une grande entreprise?

Steve Cohn: Je pense que la grande différence c’est que dans une grande entreprise vous avez une quantité considérable d’éléments qui apportent leur contribution et leur influence au cours du processus. C’est ce qui rend le travail de gestion de produit plus difficile dans les grandes entreprises.

Dans une startup en tant qu’entrepreneur, lorsque vous montez une entreprise vous êtes le chef de produit, c’est généralement comme ça que ça marche, ou certains des fondateurs le sont généralement. Vous entendez certaines choses mais si vous utilisez une approche Lean, vous pouvez laisser les données parler d’elles mêmes.

Dans les grandes entreprises, ce qui est difficile c’est que vous avez différents constituants. Le marketing vous dit « un concurrent vient de lancer son article, on en parle beaucoup, il faut que nous lancions cela également. » Un commercial vous dit « hey, mes clients disent qu’ils ne renouvelleront que si nous ajoutons cette fonction. Nous devons absolument le faire car c’est un gros contrat. » La finance vous dit « j’ai besoin d’une pondération des risques pour tous ces différents produits que tu prévois de fabriquer et pourquoi ne prévois-tu pas de fabriquer celui-ci, il est supposé avoir une plus grande pondération des risques que cet autre là? Nous devons construire celui-là d’abord. » Un cadre dirigeant d’une grosse entreprise dit « j’ai eu cette super idée sous la douche hier sur la façon d’édifier une énorme entreprise, vous devez tout de suite fabriquer ce produit pour moi . » C’est ce qui fait que c’est si difficile dans les grandes entreprises.

Il y a une citation de Jim Barckstale qui dit « Si nous avons des données, regardons les données, si tout ce que nous avons sont des opinions, prenons la mienne» C’est fondamentalement ce qui se passe en gestion de produit dans beaucoup de grosses entreprises.

La solution à ce problème c’est de conduire ce que nous appelons « Lean customer resource« . Lancez des tests de validation de la demande en phase prototype avec vos clients. Faites une expérimentation rapide et obtenez des données qui disent:

« Oui monsieur ou madame la directrice commerciale, vous avez cette bonne idée, nous en avons fait un prototype, vous nous avez dit qu’il correspondait exactement à ce que vous vouliez voir, nous avons testé cette bonne idée, ce prototype, sur des clients et voici les données, voici ce qu’ils ont dit. » Pourquoi le construirions-nous si les données ne sont pas concluantes ou pas aussi enthousiasmantes que nous le souhaitions?

« Oui madame la directrice marketing, notre concurrent vient de lancer ce produit et cil fait parler de lui dans la presse. Nous en avons fait un prototype, nous avons mené de rapides expérimentations avec nos clients et voici les données, les réactions, la validation de la demande. « 

Maintenant, si la validation de la demande est haute, qu’elle passe la question du prix, que les gens sont super enthousiastes à l’idée de donner leur temps, leur réputation ou leur argent en rapport au prototype qu’ils ont vu, construisez le vite, lancez le vite!

Souvent ce qui me fait rire lorsque je regarde les produits et les articles des concurrents et que je les suis, c’est que souvent une entreprise va dire « oh ils viennent de lancer cet article, il faut que nous le construisions. »

Alors que de l’autre côté, l’entreprise qui l’a construit regarde ses analyses en se disant « mais pourquoi personne n’utilise cela? »

Le problème des grandes entreprises c’est donc d’avoir une procédure de validation d’un produit construite sur des opinions, des antidotes, des projections et des budgets etc c’est d’estimer une valeur, se dire « ça apportera de la valeur à notre entreprise, dans le quadrant en haut à droite si on se réfère aux pondérations de risque. » Enfin, c’est là-dessus que ça se base. Si ce n’est pas basé sur des tests de la demande, ça se base sur des projections, des opinions et des antidotes. Et nous savons pertinemment que ce n’est pas fiable.

Mike Fishbein: Les grandes entreprises ont de nombreuses parties prenantes. Et tous ont leurs opinions. Cependant, quand il s’agit d’innovation, la plupart des opinions s’avèrent fausses lors du premier contact avec le client. Avoir autant de personnes dont l’opinion doit être prise en considération rend même difficile la construction d’un produit minimum viable, plaçant des obstacles au simple fait d’obtenir le moindre retour concernant le concept du produit.

Steve Cohn: Le concept de produit minimum viable (MVP: Minimum Viable Product) est remarquable. Il se base sur la mise en œuvre d’expérimentations Lean pour valider ou invalider des hypothèses. Je l’adore. Je me l’approprie et l’encourage complètement. Le problème vient de la mauvaise compréhension du mot produit dans produit minimum viable. Pour les praticiens du Lean, un prototype est un produit, un MVP qui n’a pas de code est un produit. Pour la plupart des gens en gestion de produit, un produit est quelque chose que vous expédiez, qui peut être utilisé par les clients.

Ce que j’entends sans arrêt c’est « appelons cela la version MVP, retirons 20% de ses fonctions et appelons le MVP. » Et ce qui se passe c’est que vous le construisez, vous l’expédiez et les gens ne l’aiment pas. Au lieu de l’appeler MVP, appelons le MVE soit expérimentation minimum viable (Minimum Viable Experiment), car l’objectif d’un MVP est de lancer une expérimentation rapide sur le marché pour valider ou invalider des hypothèses. Ça a plus de sens pour moi de faire une expérimentation plutôt qu’un produit.

Ce que je souhaite faire c’est changer les attentes concernant ce qu’un MVP devrait permettre en réalité, c’est à dire permettre de valider un apprentissage. Valider un apprentissage grâce à cette expérimentation, c’est vraiment l’objectif d’un MVP. Si vous regardez les deux mots l’un à côté de l’autre, qu’est-ce que vous attendez d’une expérimentation? Un apprentissage. Qu’attendez-vous d’un produit? La plupart des gens vous répondraient, de la croissance n’est-ce pas? Et bien ce n’est pas l’objectif d’un MVP. L’objectif d’un MVP est de valider un apprentissage. Alors appelons le MVE, expérimentation minimum viable car ainsi les attentes sont définies intrinsèquement. Personne n’attend d’une expérimentation de prendre de l’ampleur, de croître, personne ne s’attend à ce qu’elle réjouisse les clients. C’est un vecteur d’apprentissage. Voilà ce qu’est réellement un MVP. Je pense que le P dans MVP va à l’encontre de ce concept, qu’il embrouille les gens. Donc je me dis, appelons-le MVE. C’est fondamentalement la même chose qu’il y a derrière mais je pense que la formulation de produit viable est ce qui empêche de le comprendre complètement et de l’utiliser comme il devrait l’être.

Mike Fishbein: Ok, je comprends, les expérimentations minimum viables sont plus efficaces que les MVP à l’échelle de l’entreprise. C’est en fait la prémisse de la création d’AlphaUX. Mais comment les expérimentations minimum viables impactent réellement les résultats pour les entreprises du Fortune 1000?

Steve Cohn: C’est la clé. Ecoutez. Nous sommes dans le business du homerun. Si vous êtes dans la gestion de produit, vous devez tirer au-delà du périmètre du terrain; vous devez essayer de frapper un homerun. De manière cohérente. Il n’y a qu’une seule façon de faire cela. Quiconque connaissant un tant soit peu le baseball sait que les batteurs de homerun frappent hors du périmètre. Les innovations sont vraiment frappées hors du périmètre. Vous ne frapperez pas 1000, vous ne frapperez même pas 500 fois pour l’innovation. La façon d’obtenir des homeruns dans le business de l’innovation c’est de frapper beaucoup de mauvaises balles. C’est de revenir à la charge sans arrêt, c’est de faire beaucoup d’essais. Et la façon de faire ça avec des ressources limitées, c’est de mener des expérimentations sur des prototypes. Par opposition à devoir attendre et utiliser des ressources pour fabriquer et coder et mettre les choses en production puis les peser, les mesurer et utiliser des analyses et ce genre de choses. Donc l’idée ici est de mener de nombreuses expérimentations en phase de prototype, donner à votre équipe assez de flexibilité pour tirer hors périmètre et être créatifs et essayer des choses folles qui ne marcheront probablement jamais ainsi que des moyens.

Mike Fishbein: Ça a du sens. Alors, comment les chefs de produit savent-ils quand ils ont frappé fort? On nous interroge sans arrêt sur la signification statistique et d’autres indicateurs qui devraient être pris en compte.

Steve Cohn: Je pense très sincèrement qu’AlphaUX est un maître à penser sur le sujet. Nous travaillons beaucoup en collaboration avec AlphaUX et je pense qu’une grande part de leur production est très intelligente: leur façon de faire de nombreux tests ponctuels de prototypes et de mener des expérimentations à grande échelle sur de nombreuses catégories différentes afin d’obtenir une signification statistique.

Nous venons de publier, de co-écrire un article dans UXmag qui a reçu un grand nombre de réactions, sur l’approche d’AlphaUX et leur collaboration avec l’équipe de Validately. Je pense que la chose qu’il faut comprendre à propos de la validation de la demande c’est que ce n’est pas un remède miracle car ce n’est pas une garantie à 100%. Vous ne pouvez donc pas tester un prototype, même si vous êtes assuré que de nombreuses personnes vont pré-payer, finalement vous ne pouvez pas garantir la demande sans l’ombre d’un doute.

Lean consiste à réduire le gaspillage. Elle permet de retirer les choses qui ne marcheront vraiment pas. C’est cela que les tests de validation de la demande permettent. C’est trouver un moyen de dire « ceci était notre hypothèse, nous pensions que ce serait exaltant, les clients ne sont pas exaltés, les réactions ne sont pas très bonnes, mettons-la de côté et passons à autre chose. » C’est mettre la priorité uniquement sur les choses qui permettront de prendre un virage, qui auront l’impact le plus fort et mettre en avant les produits qui ont la plus haute probabilité d’être un succès sur le marché .

Mike Fishbein: Bien, nous comprenons bien la validation de la demande, Steve. C’est maintenant le moment de ma partie préférée de ce podcast, le benchmark. Nous avons posé à Steve et tous ceux que nous avons interviewé une série de questions pour voir comment ils se situent.

Steve Cohn: Comment je parviens à ne pas céder au doute pour Validately? Nous avons un processus de contrôle production qui, je crois, est extrêmement efficace et nous permet de bouger très rapidement. Nous commençons par le design, les éléments de la validation de notre processus de développement viennent plusieurs semaines en amont de l’écriture du code, du développement de notre produit.

Nous avons plusieurs hypothèses sur des fonctionnalités, des idées, des demandes qui nous arrivent principalement via mes interactions avec les clients. Je recherche les similitudes parmi les besoins dont me parlent les clients. Je passe plus de la moitié de mon temps à parler et interagir avec des clients et des prospects.

Ensuite nous en faisons un prototype, nous utilisons Validately pour mener de rapides expérimentations sur ce prototype en suivant les mêmes techniques que celles que nous exposons au sein de l’académie et nous cherchons les motifs qui se répètent dans les demandes avec ces prototypes. Nous apprenons de cela, nous répétons le processus et une fois que nous nous sentons confiants, nous le lançons alors en processus de développement. Actuellement nous développons par sprints d’une semaine mais nous voudrions nous orienter vers un travail en continu.

Qu’est-ce que je lis en ce moment? Et bien, actuellement je lis « Behind the Cloud » le livre de Mark Benioff sur la force de vente mais parmi ce que j’ai lu récemment et que je trouve super il y a « The hard thing about hard things » de Ben Horowitz je pense que c’est un très bon livre. « Lean UX » de Jeff Gothelf est une bonne lecture et une autre bonne lecture c’est le livre écrit par Marty Cagan « Inspired: how to create products customers love ».

Un cauchemar que j’ai eu récemment? Et bien Validately en est aux premiers stades de son développement; nous avons autour de 70-80 clients actuellement ce qui est bien en BtoB mais toujours à un stade précoce. Et nous avons fait face à une forte saisonnalité fin décembre début janvier. Vous prenez un peu de recul, vous vous dites que c’est logique, les gens ne mènent pas d’expérimentations pendant Noël et le Nouvel An. Et début janvier les gens recommencent à lancer les choses après un peu de vacances. Mais vous regardez votre tableau de bord et vous souhaitez voir les indicateurs revenir. La bonne nouvelle c’est que février a été vraiment bon et il semblerait que ça va être un mois record pour nous. Mais nous continuons à apprendre des choses. Nous cherchons toujours à déterminer où nous rencontrerons le point critique et nous effectuons des projections là-dessus pour nos actionnaires pour avoir l’air de savoir ce que nous faisons hahaha 🙂 ! Nous faisons un peu semblant dans certains cas.

Autres ressources.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *