Accélérateur de Startup : la boucle build-measure-learn
La boucle build-measure-learn est un des cinq grands principes de la méthodologie Lean Startup. Il s’agit d’une boucle de feedback dont le but est de transformer des incertitudes, des suppositions et des risques en connaissances et en certitudes qui finiront par guider les organisations et les entreprises vers le progrès. Grâce à ce processus, les inconnues peuvent être transformés en connaissances que la startup peut utiliser dans le développement de ses produits, et de ses opérations commerciales de manière générale. Ce principe s’oppose à la méthode “waterfall” où chaque étape du développement d’un projet (analyse, design, implémentation, validation, etc.) est réalisée entièrement avant de passer à l’étape suivante. Cela résulte souvent, après de nombreux mois, voire de nombreuses années, à un résultat inadéquat car uniquement basé sur des hypothèses qui ne se vérifient que très rarement. Au contraire, le but de build-measure-learn n’est pas de construire un produit final ni même un prototype (une première ébauche fonctionnelle), mais de maximiser l’apprentissage grâce à un développement incrémental du produit.
Build
Dans la phase “build”, l’objectif est de construire un produit minimum viable (MVP) dans le but de tester un certain nombre d’hypothèses aussi rapidement que possible. Avant qu’elle ne puisse le faire, la startup doit bien entendu d’abord comprendre quel est le problème qui nécessite d’être solutionné. La première chose à faire dans cette phase de construction est de déterminer les détails de ce que l’on veut tester et d’essayer de comprendre comment tout va s’organiser ensemble. Il faut mettre en place une méthode solide de collecte de données, afin de recueillir des résultats fiables et exploitables. Ensuite vient la construction de l’expérience proprement dite. Il est important de penser simple et petit. Beaucoup de startups ont tendance à voir trop grand et se retrouvent vite débordées et incapables de tirer un enseignement valable de la situation désordonnée qui en résulte. Il est plutôt préférable de construire l’incrément le plus petit possible tout en restant suffisant pour valider ou rejeter l’hypothèse qui a été faite auparavant. Cet incrément ne doit pas forcément être un “vrai” produit fonctionnel mais il doit être le plus proche possible d’une vraie expérience afin de ne pas fausser les résultats. Dans le cas de logiciels ou d’applications web, il n’est pas rare de tester une hypothèse en simulant le produit avec une présentation PowerPoint. De même, les outils pour recueillir les données ne doivent pas forcément être fortement technologiques. Cela peut très bien se faire via la tenue d’interviews ou via la distribution de questionnaires.
Measure
Dans cette deuxième phase, la startup doit déterminer si des progrès réels ont été réalisés ou non afin de pouvoir prendre une décision sur la suite à donner au projet. Cela se fait en mesurant les résultats obtenus via l’expérience réalisée durant la phase “build”. Pour permettre la mesure, Eric Ries suggère de mener des activités telles que l’A/B testing, le monitoring en temps réel, les entonnoirs de conversion, les études de cohortes, etc. Il est important de pouvoir comparer le résultat attendu par l’hypothèse de départ avec ce qui s’est réellement passé. Il est également important de se baser sur des métriques actionnables, c’est-à-dire qu’elles doivent montrer de façon claire un lien de cause à effet. Beaucoup de startups font l’erreur de ne se baser que sur des métriques de vanité (“vanity metrics”) qui font du bien à l’égo car elles ne peuvent faire qu’aller vers le haut (le nombre total d’utilisateurs par exemple), mais qui apprennent peu de choses sur la façon dont les utilisateurs réagissent réellement envers le produit. Une fois les résultats correctement organisés, il est important de réussir à les présenter correctement afin qu’ils soient accessibles à tous et auditables par quiconque. C’est la régle des trois “A” que les métriques doivent respecter : actionables, accessibles et auditables. Une fois toutes ces étapes réalisées, les décisions à prendre pour faire évoluer le produit seront beaucoup plus évidentes.
Learn
C’est à ce stade que la startup devra prendre une décision basée sur les mesures accumulées : faut-il continuer sur cette voie ou faut-il pivoter ? Persévérer, dans ce contexte, signifie poursuivre avec les mêmes objectifs, tandis que le pivot implique de modifier une partie ou la totalité des aspects de la stratégie du produit. Pour prendre cette décision délicate, Eric Ries conseille de tenir une réunion “pivot or perservere” à intervalles réguliers où se réunissent les responsables du développement du produit ainsi que les responsables du business. Il propose d’y inclure éventuellement des externes qui auront un oeil neuf sur les tenants et aboutissants de la startup et des solutions qu’elle propose. Si tout se passe comme prévu ou presque comme prévu par les hypothèses de départ, il est de coutume de persévérer, de continuer sur la même voie, en optimisant ce qui est optimisable afin d’améliorer les résultats. Au contraire, si les hypothèses ne sont pas vérifiées et qu’on se rend compte qu’on est dans une impasse, il est utile de considérer un pivot afin d’explorer de nouveaux horizons. Il existe plusieurs types de pivot : le “zoom-in pivot” (se concentrer sur une seule feature du produit et supprimer les autres), le “zoom-out pivot” (ajouter plus de features car les features de base ne sont pas suffisantes), le “customer segment pivot” (continuer avec le même produit, mais le proposer à un autre type d’utilisateurs), le “customer need pivot” (continuer avec le même type d’utilisateurs, mais leur proposer un autre produit), le “plaform pivot” (passer d’une application à une plate-forme), le “business architecture pivot” (passer d’un modèle high margin/low volume à un modèle low margin/high volume, ou l’inverse), le “value capture pivot” (changer le modèle de monétisation), le “technology pivot” (changer la technologie), etc. Une fois le décision de pivoter ou de persévérer est prise, ces conclusions devront être documentées et partagées. Grâce à ces conclusions, il est désormais possible de retourner à la phase “build” et de continuer à construire le produit. La boucle est bouclée.
