Alexandra Lung & Jessica Gantier - Leading fast innovation: 10 shades of MVP (EN)

[00:00:15] Bonjour à tous. Je suis Alexandra Lang.
[00:00:18] Et salut tout le monde. Je m'appelle Jessica Gantier.
[00:00:22] Et aujourd'hui, nous allons parler de la manière de mener une innovation rapide et, en particulier, des dix nuances du MVP. 114 millions. C'est le nombre de résultats de recherche sur Google lorsque nous recherchons le sujet MVP. Ce n'est peut-être pas très surprenant car le MVP ou Minimum Viable Product est devenu un mot à la mode, surtout dans le monde des produits ces dernières années. Mais c'est aussi un mot à la mode qui est utilisé de très, très différentes manières et pour des termes très différents, selon qui le fait. Le terme a été popularisé par Eric Rise, qui l'a défini comme un nouveau produit, une nouvelle version d'un produit, qui permet à une équipe de collecter le maximum d'apprentissages validés avec le moindre effort. Et souvent, quand je parle à différentes entreprises ou à différents PMs, il y a un aspect qui est un peu laissé de côté, c'est la partie apprentissage, et surtout la partie apprentissages validés. Et c'est pourquoi aujourd'hui nous allons parler des différentes nuances du MVP et surtout des expérimentations lean, car ce sont les meilleurs moyens d'obtenir des apprentissages validés.
[00:01:50] Aujourd'hui, nous allons partager comment nous utilisons l'expérimentation lean pour innover rapidement en testant nos idées tôt et souvent. Nous partagerons des exemples concrets de projets réels sur lesquels nous avons travaillé, ainsi que d'autres équipes d'innovation. Et notre objectif aujourd'hui est de partager cet état d'esprit avec vous et j'espère que vous serez aussi enthousiastes que nous à propos de ce sujet. qui peut vraiment vous aider à démarrer votre processus de test et à minimiser les risques de construire la mauvaise chose.
[00:02:25] Nous avons donc d'abord une petite scène pour vous et, euh, j'espère que cela résonnera avec certaines situations que vous avez vécues.
[00:02:40] Tu veux commencer, Jess ?
[00:02:41] Bien sûr. Alors, euh, Tu sais, Alex, je pense que nous devrions vraiment construire une fonctionnalité de chatbot. C'est ce que la direction nous demande. Nous devrions vraiment l'inclure dans notre feuille de route immédiatement. Je pense que c'est la prochaine grande étape pour notre entreprise.
[00:02:59] C'est une plutôt bonne idée, mais, euh, en fait, tu sais, nous n'avons pas vraiment le temps, comme l'équipe de direction, nous avons discuté et nous devons vraiment sortir cela, très, très vite. Et en même temps, tu sais, nous savons déjà ce que nous devons construire, nous connaissons nos utilisateurs, nous connaissons cette industrie. Je veux dire, je ne pense pas que nous ayons besoin de tester cela. Allons-y, nous n'avons pas le temps de le faire.
[00:03:24] Donc très souvent, euh, nous entendons que nous n'avons pas le temps de tester, nous n'avons pas le budget pour cela.
[00:03:33] Et bien des fois, nous faisons face à une situation où nous ne pouvons pas vraiment aller parler à l'utilisateur final autant que nous le voudrions. Euh, oui, tester est un investissement, faire de la recherche est un investissement, c'est vrai. Mais tester est le seul moyen de minimiser le risque de construire la mauvaise chose, et à long terme, cela vous fera économiser du temps et de l'argent.
[00:04:01] Alors, Pourquoi les expériences lean ? Encore une fois, c'est le moyen de minimiser les risques dans le développement de votre produit. Et ce que vous, habituellement ce que vous ferez, c'est que vous voudrez innover aussi vite que possible, vous voulez lancer des idées avant que vos concurrents ne le fassent. Mais personne ne veut se précipiter et pousser quelque chose qui ne sera jamais utilisé. La seule façon d'être innovant et de perturber un marché et de changer la vie des gens est de construire des choses que les gens utiliseront, dont ils auront besoin et qu'ils voudront acheter. Alors, euh, une autre chose à souligner est qu'il est très important de tester tôt. Parce que beaucoup d'études ont démontré que plus vous investissez de temps dans une idée, moins vous serez enclin à la laisser de côté ou à y renoncer, même si vous voyez des signes clairs qu'elle ne fonctionne pas bien. Très bien, donc les expérimentations lean sont un excellent outil pour faire deux choses : tester une idée ou explorer un sujet. En testant une idée, je veux dire tester votre hypothèse, votre conjecture, et cela peut être des hypothèses de conception mais aussi des hypothèses commerciales. Donc, un exemple concret serait de dire que nous pensons qu'en construisant une nouvelle fonctionnalité d'intégration, un nouveau flux d'intégration, nous allons augmenter le taux de conversion et nous aurons une plus grande adoption du produit. Ou par exemple, en construisant un nouveau programme de parrainage, nous allons stimuler notre acquisition, l'acquisition d'utilisateurs. Et un exemple pour explorer un sujet, donc quand on parle d'explorer un sujet, c'est plus dans cette phase exploratoire où vous essayez de comprendre votre espace problème. Par exemple, de quoi nos utilisateurs ont-ils besoin ? Quels sont leurs points faibles aujourd'hui ? Mais aussi comment perçoivent-ils notre marque ? Ou comment nous voient-ils par rapport à nos concurrents ou comment réagissent-ils en situation réelle en regardant notre produit ?
[00:06:16] Et l'idée clé derrière les expérimentations lean et ce qui rend cet outil si puissant, c'est que vous voulez créer un moyen d'apprendre de la manière la plus efficace, ce qui signifie minimiser les coûts, et augmenter la vitesse des tests autant que possible, mais aussi avoir des résultats clairs, tangibles et mesurables, comme vous en auriez dans une expérience scientifique.
[00:06:46] Alors, maintenant la question est, par où commencer ? Comme nous l'avons dit, nous avons toujours des tonnes d'idées, des tonnes d'hypothèses. Euh, et vous, nous ne pouvons pas tout tester, ce ne sera pas efficace, euh, nous ne pouvons tout simplement pas faire ça. Donc, ce par quoi nous commençons est d'identifier les hypothèses les plus risquées, les hypothèses les plus risquées ou ce qui tuerait notre projet si nous nous trompons à ce sujet. Ce qui semblait être une idée absolument géniale mais est extrêmement chronophage, serait vraiment complexe et très coûteux à construire, même si nous nous en tenons à une version POC ou MVP. Donc, ce que nous ferions d'abord, c'est un exercice de priorisation et nous nous concentrerions vraiment sur quelles sont nos trois hypothèses les plus risquées qui pourraient tuer notre projet ou notre entreprise si nous nous trompons à ce sujet.
[00:07:45] Ok, alors maintenant, voyons comment nous faisons cela. Il y a cinq étapes dont nous allons parler afin de mener des expérimentations lean. Le tout premier, euh, peut sembler évident, mais nous ne le faisons pas, les équipes ne le font pas toujours. Euh, le tout premier est de vraiment, euh, d'abord reconnaître que chaque fois que vous avez une idée de solution ou d'une nouvelle solution commerciale ou d'une fonctionnalité de produit, et ainsi de suite, à ce tout premier stade, ce n'est qu'une hypothèse. Nous pensons que cette nouvelle fonctionnalité aidera à générer plus d'engagement. Nous pensons que ce nouveau programme de parrainage générera plus de valeur commerciale et ainsi de suite. Donc ce ne sont que des hypothèses. Il est donc très important à ce premier stade, après l'avoir reconnu, que vous écriviez votre hypothèse avec votre équipe et que vous vous assuriez d'être alignés sur ce que cette hypothèse signifie exactement pour vous. La façon dont nous, euh, la façon dont vous la formulez habituellement est vraiment comme une hypothèse, nous commencerons par 'nous croyons que'. Et ici, je vais prendre un exemple d'une solution de chatbot. Nous pensons donc qu'en affichant un chatbot sur chaque page, les clients trouveront plus rapidement l'information qu'ils recherchent.
[00:08:59] Donc, maintenant que nous avons notre hypothèse écrite, la prochaine étape est de réfléchir à quelle est l'expérience que nous voulons, que nous voulons mener. Et en définissant l'expérience, nous garderons toujours à l'esprit quelle est l'expérience qui peut m'apporter le plus d'apprentissages autour de cette, euh, autour de cette hypothèse, mais aussi, euh, vous savez, est-ce que, est-ce que je peux faire ça ? Euh, combien, combien cela me coûte-t-il ? Est-ce que c'est quelque chose qui aura besoin, qui a encore besoin de développement et que nous devrons développer pendant deux mois ou est-ce que c'est quelque chose que je peux juste, je peux dessiner quelque chose sur une feuille de papier et je peux le tester tout de suite ? ou est-ce que c'est quelque chose que je peux simplement dessiner sur une feuille de papier et tester immédiatement.
[00:09:39] Et un exemple, en revenant à notre exemple, sur l'hypothèse avec le chatbot, une idée de test pourrait être : nous allons créer un prototype basse fidélité, et nous allons demander à cinq utilisateurs ce qu'ils feraient pour contacter notre entreprise. Donc dans ce cas, le test est le prototype basse fidélité et nous nous assurons de définir également le scénario dès maintenant, lorsque nous examinons notre hypothèse. Donc vous direz, d'accord, vous avez votre hypothèse, vous avez votre test, eh bien, vous êtes prêt à y aller et euh, et à exécuter le test. Mais pas si vite. Il y a une étape supplémentaire importante que vous devez franchir, qui consiste à définir clairement ce qui validera ou invalidera votre hypothèse. La raison pour laquelle vous devez faire cela à ce stade est simplement parce que vous voulez éviter les biais. Si vous ne définissez pas cela à ce stade et que vous lancez votre expérience, si certaines des réponses des participants commencent à valider votre hypothèse, vous serez très enclin à dire que tout va bien, et vous commencerez à vous attacher davantage à votre hypothèse dans certains cas également. Il est donc très important de définir ce critère de validation et de le définir de manière mesurable, de manière mesurable et objective.
[00:10:59] Donc ici, si je reviens à notre exemple, euh, un exemple de critère de validation pourrait être, quatre utilisateurs sur cinq cliquent sur le chat. Donc c'est quelque chose que vous ne discuterez pas après, c'est vraiment nous comptons combien d'utilisateurs cliquent réellement dessus. Mais dans certains cas, il est important de mélanger cette, euh, cette métrique, qui est très, euh, très, euh, un nombre, très mesurable, à quelque chose que nous, nous appelons observable, euh, comme un comportement plus observable également. Et dans ce cas, ce qui pourrait être intéressant est de voir si les utilisateurs observent le chat au premier coup d'œil. Et le mélanger à, ils cliquent sur le chat. En fait, il faut tenir compte du fait que lorsque vous faites un test utilisateur, les utilisateurs sont là pour effectuer ce test avec vous et ils mettront plus d'efforts dans la tâche que vous leur demandez d'accomplir. Dans un scénario réel, s'ils ne trouvent pas le chat tout de suite au premier coup d'œil, ils pourraient ne pas vouloir juste, vous savez, euh, naviguer d'avant en arrière sur votre site et, euh, et essayer de trouver ce bouton. Alors, euh, gardez cela à l'esprit, je pense que le mesurable est toujours important, mais dans certains cas, vous voulez aussi avoir des critères observables. Maintenant que nous avons tout cela, euh, laissez-moi vous donner un aperçu de la façon dont nous y arrivons habituellement. C'est un exercice collaboratif que nous faisons avec l'équipe, comme le chef de produit, le concepteur de produit, parfois nous impliquons certains ingénieurs ou des parties prenantes externes. Et généralement, nous partons d'une hypothèse qui est déjà définie par nous tous et, euh, les différents membres de l'équipe réfléchissent aux tests et pensent aux différents critères de validation et aux coûts. Et le fait d'avoir différentes idées nous aidera, à la fin, à comparer le coût et les apprentissages maximums en ayant toutes ces différentes idées sur des morceaux de papier. Et bien sûr, le temps et la connaissance collective, euh, les idées et les connaissances peuvent apporter de très bons résultats. Donc une fois que nous avons défini tout cela, nous allons effectivement lancer l'expérience. Et une fois que nous l'avons exécutée, nous arrivons à notre dernière étape, qui est l'analyse des résultats et la prise de décision. Donc, euh, normalement, si votre critère de validation était vraiment mesurable, euh, l'analyse des résultats sera une tâche assez simple et rapide, et, euh, de même pour la prise de décision. Quelque chose, quelque chose d'important dans la façon dont vous voyez les expériences lean et dont vous prenez la décision est d'être très conscient du fait que les expériences n'échouent pas, ce sont juste des hypothèses qui se révèlent fausses. Souvent, j'ai travaillé avec des équipes qui ont peur que si une hypothèse est invalidée ou est fausse, c'est comme si elles avaient échoué, elles avaient pensé à quelque chose qui n'était pas vrai ou était faux, et elles ont vraiment peur, elles vont essayer parfois de regarder les données d'une certaine manière qui fera que cette hypothèse semblera vraie en fait. Mais le fait qu'une hypothèse soit invalidée vous empêchera en fait de consacrer du temps ou de l'argent, ou généralement les deux, à quelque chose qui n'apportera aucune valeur à votre entreprise ou, dans certains cas, peut même tuer votre entreprise. C'est donc en fait une bonne chose de pouvoir invalider les idées qui ne sont pas les bonnes. Alors, gardez simplement à l'esprit que la seule, euh, la seule façon d'échouer en tant qu'entreprise ou en lançant un nouveau produit est de ne pas apprendre. Assurez-vous donc de vous concentrer sur l'apprentissage, ce qui est la, ce qui est la partie la plus importante.
[00:14:45] Très bien, alors maintenant, plongeons-nous dans la boîte à outils. Donc maintenant, cela va se rapporter à cette étape trois où vous définissez les expériences lorsque vous voulez trouver la bonne façon de tester votre idée. Nous partagerons des exemples très concrets et expliquerons les différents types d'expériences que vous pourriez utiliser, expliquerons à quoi ils servent et donnerons également des exemples.
[00:15:17] Donc, le premier type est le prototypage basse fidélité et c'est en fait l'exemple que nous avons utilisé, euh, là-bas pour tester l'idée du chatbot, c'est d'avoir un prototype. Les prototypes sont donc excellents, ils sont bon marché, ils sont rapides, vous pouvez ouvrir Figma dans vision ou n'importe quoi d'autre et y fabriquer quelque chose très rapidement, surtout si vous le gardez en basse fidélité. Et, euh, donc parfois c'est la manière exactement parfaite de tester votre idée. Mais parfois vous voulez essayer de tester quelque chose d'un peu complexe et c'est vraiment difficile de le maquiller avec un prototype, ou parfois ce qui est crucial pour vous c'est que vous testez votre idée en conditions réelles, pas dans le cadre de faire venir un utilisateur avec vous à table pendant une session de test utilisateur individuelle. C'est pourquoi nous voulons partager beaucoup plus d'exemples, beaucoup plus de façons de tester vos idées.
[00:16:18] Et en parlant de tests en conditions réelles, voici les tests A/B. Alors le test A/B est, je pense qu'il est assez populaire dernièrement, on entend beaucoup d'exemples. Et, euh, c'est vraiment, c'est vraiment intéressant, euh, les expériences à faire si vous voulez tester plus à grande échelle. Et aussi tester en situation réelle. Vos utilisateurs seront donc vraiment sur votre application ou sur votre site web, ils agiront vraiment comme ils le font normalement, sur une base normale. Et, euh, cela vous permettra en fait de simplement comparer vos différentes versions, euh, dans un scénario très, très réaliste. Ce qui est aussi intéressant avec les tests A/B, c'est la flexibilité. Vous pouvez, euh, souvent nous pensons aux boutons d'action quand nous, quand nous pensons aux tests A/B, mais nous pouvons tester beaucoup de choses. Et nous pouvons tester vraiment, disons, de petites choses, mais qui peuvent avoir un impact énorme pour une entreprise, ce qui peut être parfois juste une lettre ou vraiment, euh, un petit changement dans un, dans un libellé, ou parfois nous pouvons, euh, nous pouvons tester des choses vraiment plus grandes. Un exemple intéressant que j'ai vu il n'y a pas longtemps était l'utilisation des tests A/B pour, euh, pour tester la version d'essai, la durée de l'essai au début, euh, de l'acquisition d'utilisateurs. Donc il y a cette entreprise, ils ne savaient pas si, euh, la durée d'essai idéale pour un client était de deux semaines, quatre semaines ou six semaines. Ils ont donc utilisé les tests A/B afin de, euh, euh, d'obtenir la réponse à cette question. Alors soyez créatifs sur la façon dont vous voulez utiliser vos tests A/B. Et un exemple de projet sur lequel j'ai travaillé moi-même était un centre d'aide en ligne. Nous travaillions pour une entreprise de télécommunications et nous redessions leur centre d'aide, leur centre d'aide en ligne. Et notre principale question était : quelle est la meilleure façon de naviguer vers notre nouveau centre d'aide ? Il s'agissait donc vraiment du point d'entrée, où les clients voudraient-ils commencer. Et nous avions différentes idées et nous avons décidé de passer du test AB au test ABC parce que nous avions trois modèles d'interaction différents que nous voulions rechercher. Euh et à tester. L'un était une recherche dans l'en-tête. Le second était, euh, un menu déroulant du centre d'aide. Et, euh, un, euh, le troisième était un widget flottant sur chaque page. Donc, en fait, faire ce test nous a aidés à recueillir beaucoup d'informations sur l'utilisation et, euh, comment les clients commencent leur parcours et nous a aidés à choisir l'une des solutions, qui était, euh, dans notre cas, le menu déroulant. où les clients veulent commencer. Et nous avions une idée différente et nous avons décidé de pousser le test AB vers un test ABC parce que nous avions trois modèles d'interaction différents que nous voulions rechercher et tester. Le premier était une recherche dans l'en-tête. Un deuxième était, euh, était un menu déroulant du centre d'aide et, euh, un, euh, troisième était un widget flottant sur chaque page. Ainsi, réaliser ce test nous a aidés à recueillir de nombreuses informations sur l'utilisation et sur la façon dont les clients commencent leur parcours. Et cela nous a aidés à choisir l'une des solutions, qui était, euh, dans notre cas, le menu déroulant.
[00:19:05] Jess, tu veux faire un smoke test ?
[00:19:07] Absolument, oui. Donc, les tests de fumée. Euh, parlons des tests de fumée. Les tests de fumée sont une famille de tests avec le même concept. Donc vous construiriez une fausse porte d'entrée vers un service ou une fonctionnalité qui n'existe pas encore, que vous envisagez de développer ou de construire, mais que vous n'avez pas encore développée. Et par exemple, euh, vous pourriez construire une fausse page de destination, ou un faux bouton qui ne redirige vers rien. Et cette technique est vraiment géniale pour vous aider à suivre la traction de votre idée à grande échelle, mais aussi à la tester dans des conditions réelles. Alors, plongeons-nous dans l'exemple de Pivotal Tracker, par exemple. Pivotal Tracker est un outil pour gérer les carnets de commandes pour le développement de produits. Il est destiné aux chefs de produit et aux développeurs. Et à un moment donné, euh, ils ont atteint un niveau de maturité où ils se demandaient : quelle est la prochaine grande chose pour nous ? Quelle est la prochaine grande fonctionnalité qui va changer la donne pour nos utilisateurs ? Et ils ont pensé à cette fonctionnalité qui, comme une fonctionnalité globale, aiderait à l'alignement des équipes et à plusieurs équipes à mieux travailler ensemble et à gérer leurs dépendances. Et ils ont vraiment eu du mal à valider que cela serait suffisamment utile pour leur utilisateur afin qu'ils y investissent pour les prochains mois. Alors, ce qu'ils ont fait, c'est qu'ils ont créé un faux article de blog proposant de s'inscrire à une version bêta pour cette fonctionnalité qui n'existait pas encore et il n'y avait absolument pas de version bêta en réalité. Et euh, ils ont simplement utilisé ce formulaire très simple où les gens pouvaient s'inscrire et ils ont suivi le nombre d'inscriptions. Et euh, ils ont simplement utilisé ce formulaire très simple où les gens pouvaient s'inscrire et ils ont suivi le nombre d'inscriptions. Et ce formulaire d'abonnement leur disait simplement : « Okay, merci de vous être abonné à la version bêta, nous vous ferons savoir si vous êtes réellement, euh, un bon candidat pour la version bêta ou non. » Et ce qui s'est passé, c'est qu'ils ont, le test était
[00:21:15] a été un succès pour eux car ils ont atteint le taux de conversion qu'ils avaient déterminé au début, qui était de 10%. Et l'autre grande, euh, partie de l'utilisation de ce test et de ce type de test, c'est qu'ils avaient maintenant une liste d'utilisateurs intéressés par ce concept, par cette proposition de valeur, et ils ont utilisé cette liste pour les contacter et faire davantage de recherches exploratoires et affiner leur solution et leurs idées au fur et à mesure.
[00:21:49] Concierge et MVP, c'est une très bonne façon de tester et en fait d'affiner votre solution pendant le test. Cela consiste en un test où les actions sont effectuées manuellement par une personne et où l'utilisateur final en est conscient. L'inconvénient de ce test est qu'il n'est pas évolutif, bien sûr, car tout est manuel, vous devrez en fait implémenter l'automatisation par la suite ou le développement, mais l'avantage est qu'il est vraiment facile à mettre en place, il n'est pas coûteux et vous pouvez apprendre beaucoup et ajuster une grande partie de votre solution sur-le-champ également. Voici quelques, quelques exemples. Euh, le premier est un service de livraison de nourriture. Pour une grande marque de supermarché au Royaume-Uni qui voulait développer ce service de livraison haut de gamme. Et leur question au début était liée à la logistique en fait, c'était une question vraiment clé, une de ces questions risquées dont Jess parlait, cela pourrait en fait tuer cette fonctionnalité ou cette nouvelle offre. Alors, est-il possible de livrer en moins de 60 minutes ? Donc, en gros, ce que l'équipe a fait, c'est qu'elle avait un client qui participait à la recherche et qui a créé sa liste d'épicerie brute dans Google Keep. Donc, manuellement, ils ont simplement pris note de toutes les différentes épiceries sur leur liste. Et un membre de l'équipe a utilisé une GoPro et est allé préparer la commande et l'a livrée également.
[00:23:17] Ce qui était vraiment intéressant ici, c'est que non seulement ils ont validé la faisabilité logistique du service, mais ils ont aussi découvert de nombreux points douloureux et insights concernant la préparation de la commande et la livraison. Un exemple était, euh, par exemple, lorsque quelqu'un commande des bouteilles d'eau, celles-ci sont lourdes et ne pourront pas être, et assez grandes dans l'ensemble, donc elles ne pourront pas être livrées à vélo, ce qui est l'un des principaux moyens de euh, de livraison qui était imaginé au début. Donc, il y avait beaucoup de cas différents qui n'avaient pas été pris en compte au début et qui sont ressortis de ce test.
[00:24:02] Un autre exemple est un fournisseur d'énergie. Euh, c'était une startup qui était au tout début de son parcours et ils avaient beaucoup, beaucoup d'idées pour leur proposition de valeur. Donc, euh, ils étaient vraiment, les fondateurs se posaient vraiment la question : laquelle de ces propositions de valeur résonnera le plus auprès de notre cible ? Donc ce qu'ils ont fait, c'est qu'ils ont créé trois pages de destination différentes avec chacune des propositions de valeur et ils ont lancé trois campagnes Google AdWords. Et bien sûr, comme chacune de ces pages de destination offrait un moyen de s'inscrire au service également. Donc, euh, ils, en, en réalisant ce test très rapidement, ils ont pu choisir une proposition de valeur qui avait vraiment un bien meilleur taux de conversion.
[00:24:53] Très bien, donc le magicien d'Oz maintenant est un concept assez similaire au MVP Concierge. D'une manière que vous ferez semblant que votre système est une IA complexe effectuant des tâches complexes tout en effectuant la tâche manuellement. Mais cette fois, l'utilisateur final n'a aucune idée qu'il interagit avec euh, un être humain, donc il pensera qu'il parle simplement à la machine ou utilise une IA. Et quelqu'un de votre équipe effectuerait l'action manuellement. Et c'est excellent pour affiner une solution, euh, et concevoir une solution qui est vraiment complexe. Donc, pensez chatbot, IA, c'est la façon parfaite de tester, euh, comment vous, comment votre chatbot interagirait, le ton, quel type de, euh, quel type de choses proactives vous pourriez offrir à l'utilisateur et voir comment il réagirait. Donc, cela peut être une façon très puissante de euh, tester des choses compliquées à simuler. Un bon exemple est Zappos.
[00:26:04] Ainsi, aux débuts du e-commerce, le créateur de Zappos se demandait si les gens seraient prêts à acheter des chaussures en ligne sans les essayer, les toucher, les voir en vrai. Et ce qu'il a fait, ce qu'il a fait, euh, au lieu d'aller acheter tout un stock de chaussures que les gens n'achèteraient peut-être jamais et d'être confronté à tous les problèmes logistiques liés au fait d'avoir un stock. Il est allé euh, au magasin d'à côté et a pris des photos et après avoir eu un tas de photos de chaussures, il a mis en ligne un catalogue sur son site web. Et voir si quelqu'un achetait les chaussures et voir comment ça se passait. Et ce qui s'est passé, c'est que lorsque quelqu'un achetait réellement sur son site, il allait, courait lui-même au magasin, puis achetait les chaussures lui-même, puis les mettait dans une boîte et les envoyait à ses clients. Donc, bien sûr, ce n'est absolument pas, absolument pas évolutif, ce n'est pas ce qu'il visait à faire à long terme. Mais cela lui a permis de valider que les gens seraient prêts à acheter des chaussures en ligne. Et une autre bonne chose à ce stade de son entreprise, à ce tout début, est qu'il a pu comprendre quels types de chaussures étaient très demandés et quelles choses il devrait prioriser lors de l'achat de son stock réel.
[00:27:32] Un autre, okay, un autre bon exemple de cela est une startup appelée Aardvark. Donc cette startup a été achetée depuis, euh, et acquise par Google, je crois. Euh, mais à leurs débuts, c'était comme un moteur social et c'est assez similaire au concept de Quora. Et à un stade de leur développement, ils se sont vraiment demandé quel type de fonctionnalité ils devraient prioriser pour, euh, générer plus de croissance et encourager davantage d'interaction avec leur produit et fidéliser leurs clients. Et puis nous nous demandions, que devons-nous faire ? Que devrions-nous, que devrait faire notre algorithme ? Sur quoi devrions-nous nous concentrer en premier ? Ce qu'ils ont décidé de faire, c'est que pendant neuf mois, des stagiaires ont effectué manuellement ce que leur algorithme ferait, euh, à long terme. Ils ont donc examiné la conversation, les ont catégorisées et ont modéré manuellement les fils de discussion.
[00:28:34] Et ce qu'ils ont appris en faisant cela, euh, c'est la corrélation, vous savez, les schémas entre ce que font les utilisateurs expérimentés, les gens qui restent sur la plateforme, qui continuent à l'utiliser, qui sont en quelque sorte exigeants envers cette plateforme et qui reviennent, euh, ils voient que ce type de personnes a tendance à interagir avec plusieurs fils de discussion en même temps. Ils avaient donc, après cette expérience de neuf mois, une bonne idée solide de ce que sont les différentes catégories de conversations qui ont eu lieu, quel type de choses, euh, ils devraient adapter et automatiser avec leur algorithme et comment les construire, mais aussi quelle est la chose clé, quelle est la clé euh, les choses qu'ils devraient encourager pour que leurs utilisateurs restent fidèles à leur solution et reviennent sans cesse afin qu'ils puissent générer de la croissance. Et pendant cette phase, euh, de Wizard of Oz et cette phase très manuelle et brouillonne, ils ont quand même réussi à lever 30 millions.
[00:29:34] Wow, bel exemple. Euh, une autre, une autre façon de tester, euh, est d'utiliser les tests concurrentiels. Donc, si vous envisagez une fonctionnalité ou une capacité différente que vos concurrents possèdent déjà, vous pouvez parfois utiliser les produits de vos concurrents afin de tester réellement avec vos utilisateurs. Et euh, ce qui est intéressant dans ce type de euh, test, c'est que non seulement vous obtiendrez des informations sur euh, une solution, vous obtiendrez également euh, beaucoup d'informations sur la façon dont vos utilisateurs vous perçoivent, comment vos utilisateurs perçoivent vos concurrents, comment vos utilisateurs perçoivent également la marque de vos différents concurrents ou, eh bien, si vous choisissez seulement un de ces concurrents. Donc, une façon assez perspicace de tester. Souvent, nous y pensons de manière en ligne, mais j'ai un exemple, euh, de test concurrentiel réalisé hors ligne également.
[00:30:27] Alors, euh, il y a quelques années, je travaillais pour une société de location de voitures et, euh, je travaillais sur le repositionnement de cette, euh, de cette entreprise. Donc, la construction de la proposition de valeur et de l'offre de services. Et la question que nous avions était, quels sont les besoins et les comportements du client arrivant à l'aéroport ? Donc, en gros, la plupart de nos clients étaient des hommes d'affaires qui arrivaient à l'aéroport, donc c'était leur premier point de contact réel avec, euh, les services de location de voitures et, euh, et avec le service lui-même. Alors, euh, ce que nous avons fait, c'est que nous avons passé, euh, euh, presque une journée à, euh, à l'aéroport, en suivant les entreprises de location de voitures concurrentes. Donc nous n'avons pas eu à louer d'espace à l'aéroport nous-mêmes, nous n'avons pas eu à faire des tonnes et des tonnes de recherches. Nous avons en fait passé quelques heures, euh, à agir comme si nous étions les clients, euh, à faire la queue et à écouter toutes les différentes questions et, euh, toutes les différentes, euh, options que les utilisateurs de voitures de location, euh, partageaient. ou posant des questions à l'autre entreprise. C'était donc super instructif parce que nous n'avons pas seulement appris beaucoup sur leurs comportements, mais nous avons aussi beaucoup appris sur les questions et les services qu'ils recherchent.
[00:31:56] Oh, et le nom drôle.
[00:32:00] Oui, donc pique-nique au cimetière. Euh, qu'est-ce que c'est ? Ok, le pique-nique au cimetière consiste à contacter des personnes qui ont eu une idée similaire à la vôtre ou une entreprise similaire qui a échoué. Et la raison pour laquelle vous pourriez vouloir considérer cela est que euh, cela vous permettra d'apprendre d'eux, d'apprendre les pièges auxquels vous devriez faire attention, les pièges que vous devriez éviter. Euh, mais aussi quelles opportunités ils ont saisies ou non, afin que vous puissiez en quelque sorte corriger votre stratégie, adapter votre modèle économique ou essayer quelque chose d'un peu différent et éviter de refaire les mêmes erreurs que d'autres ont faites avant vous, en gros.
[00:32:51] Donc, nous avons partagé quelques exemples afin de voir à quel point vous pouvez aller loin et différemment dans les tests. Souvent, lorsque nous parlons à différentes personnes en produit ou en design, euh, nous entendons que les prototypes sont la première, euh, première façon de tester, euh, mais il existe tellement d'autres façons. Donc notre message ici est vraiment d'être créatif, en fonction du stade de votre produit, de votre produit, de votre entreprise, il y a toujours, euh, une façon et une manière différente de pouvoir, euh, mener une expérience allégée. Alors, assurez-vous d'être créatif et pour améliorer cela encore plus, nous avons deux derniers exemples sur la façon dont vous pouvez devenir vraiment créatif. Donc, euh, le premier exemple est une startup qui, euh, créait des vidéos éducatives pour les pianistes. Et ils venaient de démarrer leur entreprise et ils avaient une grande question très, euh, fondamentale pour leur entreprise, qui était : qu'est-ce qu'une bonne vidéo éducative pour le piano ? Alors, euh, ce qu'ils ont fait à l'époque, ils n'avaient pas, enfin, ils n'avaient pas de vidéo, ils n'avaient pas les moyens de créer réellement beaucoup de vidéos. Ils ont donc décidé de tirer parti des vidéos existantes, euh, existantes sur YouTube. Ils ont donc utilisé un service appelé Mechanical Turks, où, euh, différentes personnes à travers le monde, pour une certaine somme d'argent, qui est assez faible, taguent différentes vidéos populaires sur YouTube. Et ces Mechanical Turks, ils regardaient chaque vidéo et ils répondaient aux questions, qu'est-ce que c'est, quelle catégorie et quelles caractéristiques. Ainsi, en analysant les corrélations entre ces différentes, euh, questions qu'ils posaient, la popularité, la catégorie et les caractéristiques, ils ont pu, euh, comprendre ce qui ferait une bonne vidéo. Mais aussi, ce qui était super intéressant ici, c'est qu'ils n'avaient pas besoin de générer leurs propres données, ils pouvaient simplement utiliser les données publiques, et c'était une excellente base de départ pour eux pour en apprendre davantage sur ce qui ferait le succès de leur entreprise.
[00:35:03] Et un autre exemple assez simple est cette page kit que nous avons réalisée pour un projet avec une entreprise de télécommunications. Nous construisions donc un nouveau tableau de bord utilisateur, euh, et nous avions beaucoup d'idées très divergentes sur ce qui devrait figurer dans ce tableau de bord, comme quelle est la chose essentielle que l'utilisateur devrait voir immédiatement en se connectant à son compte. Et euh, vraiment, nous avions des débats sans fin sur ce qui devrait y être. Euh, nous avons donc décidé d'opter pour cette petite expérience de page de kit et de consacrer dix minutes de notre session d'entretien utilisateur de quarante-cinq minutes à donner de petits blocs de papier à nos participants. avec une page vierge, donc cette page vierge, euh, avec juste la barre de navigation en haut, de petits morceaux de papier, et leur demander de mettre ce qu'ils pensent qui devrait absolument y figurer. Euh, et et nous les avons observés, nous l'avons arrangé, ils ont en quelque sorte créé leurs propres composants quand les nôtres n'étaient pas suffisants, nous nous sommes un peu réadaptés ici, si vous voyez que la question fréquemment posée était trop longue et qu'ils ont décidé de la raccourcir.
[00:36:17] Et après seulement cinq entretiens, euh, nous avions déjà des schémas très clairs concernant, euh, quelles étaient les principales fonctionnalités, les principales informations dont ils avaient besoin. Et il y avait même des informations qui n'étaient pas sur notre radar et qui étaient super importantes pour nos utilisateurs.
[00:36:40] J'adore cet exemple parce que je pense que si nous avions opté pour un prototype et juste avec certaines des hypothèses, nous aurions dû passer par deux ou trois tests juste pour arriver à la même quantité d'apprentissages qu'ici.
[00:36:56] Et cela a vraiment aidé à avancer plus vite dans les débats. Très bien, alors récapitulons un peu ce dont nous avons parlé. Euh, donc nous espérons vous avoir convaincu de l'importance de tester vos hypothèses, de tester vos suppositions. C'est critique et vous devriez vraiment minimiser le risque de construire la mauvaise chose en testant tôt et souvent.
[00:37:22] Et nous avons également présenté notre cadre et les cinq étapes que nous suivons pour définir et exécuter des expériences. Donc, premièrement, l'important est d'identifier votre hypothèse, d'être conscient de votre hypothèse. Le second est de brainstormer sur une expérience, comment tester cette hypothèse. La troisième consiste à définir vos critères de succès. La quatrième est de l'exécuter, bien sûr, d'exécuter l'expérience et la cinquième étape est de mesurer les résultats.
[00:37:59] Et vraiment, ce qui est important, c'est de cultiver cet état d'esprit et de penser en dehors des sentiers battus, ne pas se lancer directement dans la construction de la fonctionnalité future, bien sûr, mais ne pas se précipiter vers le prototypage et se sentir bloqué dans cette méthode de test, il y a beaucoup de bonnes idées là-bas et vous pouvez les mélanger, les combiner, chercher l'inspiration partout. Euh, regardez vraiment ce qui vous convient au stade de votre développement et ce qui a du sens dans votre contexte.
[00:38:31] Nous arrivons donc à la fin de notre présentation et, euh, Jessica et moi-même aimerions vous laisser avec une question. Si vous pensez aux différentes idées dont vous discutez en ce moment avec votre équipe, comment allez-vous les tester ?
[00:38:52] Merci beaucoup.
[00:38:56] Merci à tous.

Transcription (Traduit)