(Re)découverte du Lean Startup – Validated Learning

1. Est-ce que le validated learning est adopté dans les sociétés clientes que nous avons connues ?
2. En conclusion

Dans ce premier billet de notre série sur “The Lean Startup” et son impact perçu dix ans plus tard, Dominique Hak et Kim Dang, tous deux PO chez Néosoft, vous proposent leur analyse sur la notion de “Validated Learning”.

Selon Eric Ries, les startups ne sont pas uniquement destinées à faire du profit ou servir des clients. Elles existent avant tout pour apprendre à construire un business pérenne. Un des aspects du Lean Startup consiste d’ailleurs à éviter de dépenser trop d’argent avant d’apprendre par le terrain si son business model est réellement viable. Ces apprentissages sont validés ou invalidés grâce à une approche structurée / scientifique constituée d’expériences fréquentes qui permettent aux entrepreneurs de tester chaque élément de leur vision : la vérification de la validité des concepts (ou “validated learning”).

Le “validated learning” consiste en de petites unités de progrès qui permettent de vérifier rapidement si notre produit / stratégie va dans la bonne direction ou non. Il est généralement constitué des étapes suivantes :

1. Définir un objectif / une hypothèse que l’on souhaite vérifier
2. Définir les indicateurs qui représentent cet objectif, avec des seuils associés qui définissent la confirmation / l’infirmation
3. Mettre en place les actions que l’on estime nécessaires pour atteindre notre objectif
4. Analyser les données – s’est-on approché de l’objectif ?
5. Améliorer et essayer de nouveau ou pivoter (i.e. changer de direction)

Alors, est-ce que le validated learning est adopté dans les sociétés clientes que nous avons connues ?

Pour adopter le validated learning, il faut déjà reconnaître que gagner de la connaissance apporte de la valeur. Pour nous, par rapport à 2011, la notion d’incertitude nous semble beaucoup plus reconnue aujourd’hui par les entreprises “classiques” dans lesquelles on a exercé, et avec elle vient la valorisation de la connaissance acquise et le droit de se tromper. Cette prise de conscience se cristallise avec la reconnaissance répandue du Manifeste Agile, né de la constatation que le contexte évolue en même temps que l’on parcourt le chemin, et que l’entreprise gagnerait à adopter un comportement intégrant cet état de fait. Ce n’est pas neutre du tout pour une entreprise qui est installée et reconnue dans son marché, et où le sentiment de maîtrise s’appuie sur des années d’expérience.
Une fois que l’on a pris conscience de l’intérêt de continuer à découvrir son marché et surtout de suivre ses transformations, on cherche naturellement une méthode pour le faire. Beaucoup de grands comptes de tous les secteurs industriels ont adopté Scrum qui, par son approche empirique et son cycle de développement itératif sous forme de sprints, contient naturellement beaucoup d’éléments du validated learning : on se met des buts business raisonnables, on développe rapidement, on inspecte et on discute.
On tend donc vers la même direction que la finalité du validated learning. Mais alors, si l’on applique Scrum, on fait forcément du validated learning sans le nommer ? C’est un peu plus complexe que ça. Scrum et les bonnes pratiques qui l’entourent facilitent et encouragent la possibilité de faire du validated learning, mais nous avons principalement vu les deux écueils suivants :

• le syndrome de la sérendipité (ou de manière moins pédante : “Je ne sais pas ce que je cherche, mais j’espère le reconnaître quand je le verrai.”), qui est un défaut de méthode;
• l’extrapolation inconsciente, qui est un défaut d’appréciation d’une situation.

Malgré la mise en place de méthodes agiles pour la réalisation de produits, au cours de nos expériences, nous avons – malheureusement – fréquemment rencontré le cas où ces méthodes n’étaient implémentées que pour mettre en œuvre les convictions du management ou des équipes métiers. On produit quelque chose qu’on livre entre les mains d’un utilisateur et on regarde ce qui se passe, sans forcément avoir défini ou s’être aligné en amont sur l’hypothèse que l’on souhaitait vérifier.
Cette approche revient à faire une suite de mini-projets (tels les cycles de V sur la période du sprint) où l’on vérifie la correspondance à l’expression de besoin initial plutôt qu’à la réponse du problème identifié, ce qui appauvrit considérablement les enseignements que l’on peut tirer et ouvre la porte à l’interprétation des données dans le sens qui nous arrange le plus. Le manque d’engagement en amont sur des hypothèses à vérifier empêche souvent de factualiser, et donc de challenger le résultat obtenu : ce dernier n’est pas actionnable.

Par exemple :

Au cours d’une de nos missions, une fonctionnalité conséquente développée par notre équipe offrait un taux de transformation de 10 pourcents, pour un total de 300 cas par jour. L’équipe était contente jusqu’à ce qu’un top manager révèle une attente 10 fois supérieure en nombre de cas.
Dans ce cas précis, le manque d’alignement en amont sur les objectifs de départ a résulté en une frustration et un sentiment d’injustice pour les deux parties à la fin : management comme équipe.
La fonctionnalité a été développée dans sa totalité, sans alarme ou consensus sur la santé du produit au cours de la réalisation puisque aucun but factuel n’avait été partagé. Quel dommage ! En l’occurrence, on aurait pu voir bien plus tôt que le nombre de cas candidats était à la base trop faible pour espérer atteindre 3 000 transformations, et donc réfléchir à un pivot par exemple…

Le deuxième écueil est un peu plus subtil et vient d’une tendance à surestimer parfois notre connaissance de notre business. Comme le dit Mark Twain : “Ce n’est pas ce que nous ignorons qui nous met dans le pétrin, mais ce que l’on tient pour certain alors que la vérité est autre”. Et du coup, la tentation est grande de sauter des étapes :

• On pose d’un coup une hypothèse composite, qui est en fait la résultante de plusieurs hypothèses méritant d’être évaluées de manière indépendante, sous risque de ne pas pouvoir en discerner les mérites / démérites individuels.
• On a bien décomposé mais on ne regarde pas les métriques avant que toute la proposition ne soit livrée, pour ensuite ne se concentrer que sur l’impact financier pour la compagnie…

On n’a pas encore changé l’unité de valeur qui mesure le succès d’un produit ou d’une équipe. Souvent, seuls les objectifs business financiers éveillent l’intérêt d’un certain niveau de hiérarchie. Du coup, les étapes intermédiaires sont vues comme inutiles : elles ne sont pas analysées ou n’alimentent pas une réflexion sur un changement de comportement éventuel ou une mise à jour de la roadmap du produit. C’est tout à fait acceptable sur les points qui sont simples ou complexes au sens cynefin – modèle qui préconise l’approche d’un problème en fonction de sa catégorie : simple, compliqué, complexe ou chaotique – mais même pour une entreprise établie de taille plus importante, ça peut être intéressant de se demander si l’on est vraiment dans une zone connue, ou si notre certitude est en fait plus une intuition dénuée de fondement.

En conclusion

On a bien l’impression que le monde de l’entreprise “classique” a parcouru du chemin depuis 2011 : expérimenter, et chercher le succès à tâtons est une option qui existe en plus de la simple exécution d’un plan. Il faut maintenant savoir quand l’utiliser et comment.

Selon nous,

• Si l’on est dans le connu et stable (et que l’on s’en est assuré), la démarche du validated learning est peut-être trop contraignante, et certaines étapes peuvent être allégées.
• Si l’on est sur un environnement plus incertain (ce qui demande beaucoup de maturité et d’humilité à une entreprise établie pour le détecter), des outils peuvent contribuer à mieux bénéficier des avantages du validated learning, tels que :
  • L’A/B testing, qui consiste en une comparaison relative d’une solution A par rapport à une solution B. Elle permet de pallier la peur de l’échec qui pourrait résulter du cas où notre hypothèse de départ serait invalidée.
  • L’utilisation de la méthode Objectives and Key Results, qui repose sur la définition d’objectifs et la mesure de résultats clés, permettant ainsi à la fois d’aligner la vision de la stratégie de l’entreprise avec celle des équipes et de définir ensemble des indicateurs actionnables.
  • Scrum, dont l’objectif de sprint peut également être formulé de sorte à vérifier une hypothèse.

Et vous, où en êtes-vous de l’application du validated learning ? Certaines de ces étapes vous posent-elles des difficultés dans votre quotidien ? Avez-vous réussi à faire bouger des lignes ?