dimanche, juillet 19, 2015

La pratique du Lean Startup et du Growth Hacking dans l’entreprise



1. Introduction


J’ai fait du Lean Startup  un guide méthodologique de ma pratique de l’innovation numérique, chez Bouygues Telecom il y a quelques années et chez AXA aujourd’hui. Le livre d’Eric Ries est ma référence, mais de nombreux nouveaux livres sont parus depuis sur l’application pratique de la méthode et sur l’utilisation en entreprise. J’ai déjà mentionné le livre de Trevor Owens et Obie Fernandez, « The Lean Entreprise », aujourd’hui je vais consacrer ce billet à deux livres que j’ai lus récemment, « The Innovator’s method – Bringing the Lean Startup into your organization » et « Running Lean – Iterate from Plan A to a Plan That Works ». Lors d’un précédent billet sur l’entreprise 3.0, j’avais noté que les idées fondamentales de « l’entreprise libérée » se retrouvaient « partout », c’est-à-dire dans un très grand nombre de livres différents, mais parus récemment. La même remarque peut être faite au sujet des principes du Lean Startup, qui se retrouvent dans la plupart des livres récents qui parlent d’innovation dans le monde numérique. C’est certainement le cas pour deux « bestsellers » que je viens de terminer : « How Google Works » de Eric Schmidt & Jonathan Roseberg, et « From Zero to One » de Peter Thiel.

Il n’y a pas simplement une dissémination des idées et une intensification de leur popularité, il y a une maturation sur ce que signifie l’intégration du Lean Startup dans des entreprises matures, par rapport aux startups, et sur la façon de pratiquer. Comme toutes les transformations complexes, introduire le Lean Startup se fait par la pratique. J’ai choisi de commenter « The innovator’s method » car c’est ma nouvelle référence, mon livre préféré sur le sujet, parce qu’il est global et couvre l’ensemble du domaine de l’innovation numérique. En particulier, il fait une synthèse entre les précédents bestsellers de l’innovation et les idées plus nouvelles apportées par le Lean Startup. J’ai écrit récemment un article « L’entreprise numérique et l’innovation » pour la revue « Economie et Management », et je retrouve un alignement complet avec le livre de Nathan Furr et Jeff Dyer. Mon deuxième choix, celui de « Running Lean » d’Ash Maurya, est pour une raison opposée : ce n’est pas un livre conceptuel ni riche en histoire, mais c’est un merveilleux guide pratique. C’est clairement le meilleur livre que je connaisse pour pratiquer le Lean Startup, depuis le début – la définition du problème à résoudre – jusqu’à la phase de développement de l’usage, ce qu’on appelle le « Growth Hacking ». « Running Lean » donne un certain nombre de clés (métriques et principes) pour cette phase du co-développement de l’innovation avec les utilisateurs, à laquelle je consacrerai la dernière section de ce billet.

2. The Innovator’s Method


Le livre de de Nathan Furr et Jeff Dyer, « The innovator’s method », est très agréable à lire et je vous recommande donc sa lecture avec insistance. En particulier, la qualité narrative des anecdotes illustratives est remarquable – ce que je ne fais pas dans ce blog faute de temps J. Ici je vais me contenter de relever quelques points clés du livre,  qui touchent à la pratique du Lean Startup.


  • Le livre s’articule autour d’un schéma en quatre phases que j’ai reproduit ci-contre : (1) insight, (2) problème, (3) solution, (4) business model. La première phase est celle de l’intuition créative, celle où on identifie une idée qui pourrait être utilise, c’est-à-dire résoudre un problème et apporter de la valeur à un groupe de clients potentiels. La seconde phase est celle de la formalisation et validation du problème qu’on veut résoudre. La troisième étape est la réalisation du Minimum Viable Product. La flèche circulaire bleue de l’illustration exprime que cette décomposition n’est pas stricte et linéaire, il existe des interactions et des allers-retours. La dernière phase est la phase de croissance, celle où on développe l’usage et on construit le business modèle. Cette structure n’est pas différente de ce qu’on retrouve dans le livre d’Eric Ries, mais elle permet de mieux faire ressortir (cf. schéma) les liens avec les phases/pratiques de l’innovation : créativité, design thinking, développement agile, etc.

  • Le cœur du livre s’articule sur les principes du Lean Startup : résoudre un pain point, aller au plus vite vers le client pour tester sa solution, mesurer, pivoter si besoin, et surtout itérer. On retrouve des citations telles que celle-ci : « No one can foresee the problem when you face uncertainty. It’s all a guess, and there’s only one way to discover whether it’s right or wrong: by testing it in the market”.
      
  • Les auteurs s’appuient beaucoup sur l’expérience d’Intuit, en particulier pour expliquer la phase de caractérisation de problème. C’est un message fondamental et commun aux deux livres de ce billet : il ne faut pas se lancer dans le design et la réalisation de la solution sans avoir bien caractérisé le problème, c’est-à-dire les « pain points » que l’on souhaite résoudre. Although it may feel “slower” to start with the customer problem rather than the solution, you save time by deeply understanding the customer’s job-to-be-done”. Ce livre parle du concept intéressant de « pain-storming », l’application des méthodes de brainstorming à la caractérisation de ces pain-points : « The purpose of a pain-storm is to get crisp on what we think the problem is so we can test our hypotheses ». « Pain-storming involves creating a customer’s journey line to understand how customers now complete a task and identify their main pain points (and emotions) along the way ».
      
  • Un autre exemple tiré d’Intuit est la création de Labs (Intuit Labs) pour donner un accès direct à des “vrais clients” aux équipes d’innovation. L’accès aux clients est souvent une barrière infranchissable dans de nombreuses grandes entreprises en France. Pourtant, tous les livres que j’ai lus depuis 10 ans disent la même chose. Je cite celui-ci : « Teams need to run experiments with potential customers if they hope to discover the job-to-be-done and then nail the solution. Providing quick and easy access to various types of customers can facilitate rapid experimentation”. Cet accès doit avoir lieu le plus tôt possible, avant que la solution ne soit développée, sous la forme d’un site Web qui permet de faire des “smoke tests” (faire croire que le produit existe pour recueillir des premières réactions) : « To perform a smoke test, create a web site, advertisement, phone number, or other channel that describes the problem, theoretical solution, and provides an option to « learn more », « buy now », « reserve now » or some other call to action ».
      
  • Une mention très intéressante est faite de l’utilisation de la simulation pour valider des fonctionnements systémiques avant de construire une solution. L’exemple fournit est celui d’Amazon qui utilise la simulation pour comprendre et optimiser des questions de chaine d’approvisionnement.
      
  • La création de la solution est un processus itératif qui produit un MAP (Minimum Awesome Product). Le choix de cet acronyme souligne le fait que le MVP est plus que « viable », il doit être formidable. Ce point est très clairement expliqué par Ash Maurya (voir section suivante) : Le MVP est minimum parce qu’il embarque peu de UVP (Unique Value Proposition), mais il est formidable parce que chaque UVP doit l’être. Une erreur classique de l’application du Lean Startup est de faire des compromis sur ce qu’apporte le MVP pour aller vite (selon le principe du « fail fast »). Le MVP est minimal dans son contenu (le plus petit ensemble d’UVP nécessaires pour résoudre le pain point), mais il doit être « awesome » -sinon « fail fast » devient une certitude, et non pas un principe :). Je cite : « Some 90 percent of initial proposals don’t nail the solution to a significant problem. This explains why it’s folly to start by building a product or service before you discovered how it falls short”.
      
  • Cette citation illustre un des principes clés du livre “Nail it, then scale it”. Avant de consacrer du temps et de l’argent à faire croitre sa base client, il faut s’assurer que la solution a bien « résolu » (nail) le problème identifié. Les auteurs suggèrent l’utilisation du NPS (Net Promoter Score) comme métrique, et de vérifier qu’on a dépassé la valeur 10 avant de vouloir faire grandir la base client : « So start by shooting for a 9 or 10 NPS score with 10 people, and then you can think about progressing to the hundredth ».
      
  • Une des histoires les plus passionnantes, en plus de l’histoire introductive que je vous laisse découvrir, est celle de ChotuKool. Il s’agissait de créer un réfrigérateur pour le marché de l’Inde. Passé la première idée de faire un frigo « comme d’habitude mais plus petit et moins cher » (une idée « top down » qui a échoué face aux contraintes pratiques), les auteurs racontent la démarche d’ethno-marketing, consistant à aller sur place pour vivre la vie des futurs clients, heure par heure, pendant quelques jours. Cette partie m’a rappelé un exposé passionnant que j’avais entendu il y a 10 ans sur l’utilisation de cette pratique d’ethno-marketing chez Leroy-Merlin, et sur comment le fait de « vivre la vie » de quelques clients (artisans pros) avait permis de détecter des signaux faibles que l’analyse des tickets de caisse par Big Data (déjà) n’avait pas trouvé. La section « Ethnography to Explore Assumptions » est une des plus intéressantes, avec de multiples conseils pour observer et comprendre les futures clients.  
  • La fin du livre est consacrée au « Business Model Canvas », qui présent un recouvrement important avec le « Lean Canvas » dont je vais parler dans la prochaine section. Il y a cependant des contributions propres, sur les méthodes de fixation des prix et sur l’analyse des facteurs d’influences sur les clients. Par exemple, « Influencers fall into four categories : experts such as product reviewers, thought leaders, or products evaluators ; peers such as bloggers, coustomer reviews, and forum discussions ; media and press, whose attention shapes customer perception ; and reference customers, who create legitimacy and comfort with your solution in customer’s minds ».
      
  • On trouve dans le livre un chapitre consacré à « L’art du pivot ». La section page 172 est particulièrement intéressante et constitue un bon ajout au livre d’Eric Ries, avec beaucoup de conseils pratiques, fondés sur des métriques. Je vous recommande également dans ce chapitre l’histoire de Aardvark, qui illustre la tension entre la mission de la startup (ou du produit) et le feedback des utilisateurs. Dans le cas d’Aarvark, les demandes clients étaient en conflit avec le « positionnement stratégique » du produit. Ceci a causé un délai trop long pour prendre en compte certaines demandes … et a fait perdre une opportunité face à un concurrent. Je suis sensible à ce témoignage car c’est une situation que j’ai déjà vécue. Les témoignages des premiers utilisateurs sont plein de « pépites », mais qui sont souvent rejetées pour des raisons dites « stratégiques » alors que ceux qui fabriquent le produit sauraient parfaitement réaliser ces évolutions.
      
  • Pour conclure, j’ai également beaucoup apprécié les remarques sur les réunions et la bonne façon de les conduire. Ce petit exemple est un parmi une multitude de références implicites à la culture « Entreprise 3.0 / Entreprise libérée » que l’on trouve dans ces livres sur l’innovation. Les auteurs proposent 4 modèles de réunions : (1) les « All-hands meetings », informels qui impliquent tous les acteurs du projet ; (2) les meetings quotidiens de synchronisation, tels que les « stand-up meetings » ; (3) les « skip-level meetings » - qui permettent aux seniors managers d’appendre par le contact direct et sur le terrain avec ceux qui réalisent le produit (une version affaiblie des gemba walks) et (4) les réunions avec des acteurs externes, pour obtenir un point de vue neuf et iconoclaste sur le déroulement du projet.

3. Running Lean


“Running Lean” de Ash Maurya est disponible depuis 2012 (2010 pour la première éditition en e-Book). Dès le début, il a rencontré un grand succès aux Etats-Unis avec des critiques très positives. Je l’ai feuilleté dans une librairie en 2013 et je me suis dit « pas beaucoup de contenu, je connais déjà tout cela … ».  Maintenant que je l’ai lu en détail, je me rends compte de mon erreur. Ce livre est une véritable mine d’or pour la mise en pratique du Lean Startup. Il ne cherche pas à vous convaincre d’adopter le Lean Startup, il y a d’autres livres pour cela, celui d’Eric Ries ou « The innovator’s method » par exemple. « Running Lean » est un « how to guide », dans la grande tradition américaine. Je vais me livrer à mon exercice favori de rapporter les points essentiels que j’ai noté, mais c’est contre-indiqué, puisqu’il s’agit de pratique. « Running Lean » est un livre qui se met en oeuvre, une suite de choses à faire. Le meilleur conseil que je puisse donner, et que je suis en train de m’appliquer, est de partir d’une vieille idée qui dort dans un coin du cerveau et de passer les étapes et les outils les uns après les autres.  Le message principal est le même que précédemment : il faut travailler sur le problème, sans relâche, avec des utilisateurs, pour être sûr qu’on travaille sur la bonne question. Pour reprendre une citation de Ash Maurya :  “Life is too short to build something that nobody wants”.
  • En particulier, l’outil central, le lean canvas, est une pratique qui doit devenir obligatoire dans le monde de l’innovation numérique : « A single page-page business model is meach easier to share with others, which means it will be read by more people and probably will be more frequently updated ». Le Lean Canvas, dont le schéma est reproduit dans la figure qui suit, est composé des réponses à 9 questions clés, organisées de façon logique. Ce canvas s’insipire de canvas précédents (cf. le Business Model Canvas évoqué précédement) et représente le fruit d’une longue évolution. Vous ne trouverez pas de justification des 9 cases, mais c’est clairement le résultat de l’expérience et de l’itération.



  • Une des cases les plus importantes du canvas est celle des « Unique Value Proposition ».  Le parallèle avec les Unique Selling Propositions (un des classiques du marketing) est évident, mais l’accent est mis sur l’usage, l’expérience et sur l’histoire à raconter au client. Il est d’ailleurs intéressant de noter que la méthode sépare trois domaines : le problème, les USP (histoires qui donnent la légitimité à la solution, qui définissent le « job-to-be-done » pour reprendre les termes de Furr et Dyer) et les features clés de la solution (ce qui concrétise la solution). Trouver ses UVP est un gros travail, qui exige une approche itérative et beaucoup de remise en cause : UVP is hard to get right because you have to distill the essence of your product in a few words that can fit in the headline of your landing page”. Les UVP définissent ensuite une “boussole” pour la réalisation du MVP. Même si  l’agilité donner une souplesse sur comment construire les features, la promesse des UVP ne doit pas être compromise : “The job of you UVP is to make a compelling promise.  The job of the MVP is to deliver that promise”.
  • Une section intéressante traite de l’organisation de l’équipe. Le point de départ est la constatation classique, et que j’ai cité plusieurs fois, qu’il faut assembler dans la même équipe les compétences de marketing produit, de développement et de design (« three must-haves », p. 58). L’organisation proposée s’appuie sur deux équipes : la « problem team » qui est responsable de la définition du problème et des UVP, la « solution team » qui construit le MVP. « The problem team is mostly involved with « outside the building » activities such as interviewing customers …. The solution team is mostly involved with “inside the building” activities such as writing code, running tests, deploying releases, an so on.”

  • La section la plus développée, logiquement, est celle qui porte sur la caractérisation du problème, en particulier en interaction avec des futurs utilisateurs. « The fastest way to learn is to talk to customers. Not releasing code, or collecting analytics, but talking to people”. Le chapitre 6 est très riche et contient des conseils très utiles. Il commence par une section sur les « surveys and focus groups » qui peut sembler dogmatique (si on le prend à la lettre) mais qui me semble pertinent. En deux mots : méfiez vous des « surveys » qui supposent que vous connaissez déjà les questions à poser, et évitez les « focus groups », car vos clients ne peuvent pas formuler leurs besoins (le classique « It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them » de Steve Jobs) et le travail en groupe produit du « group think » qui converge trop vite et passe à côté des pépites. Une fois que l’on a compris que le focus group est là pour capturer le problème et pas la solution, et une fois qu’on se rappelle qu’il faut également des entretiens individuels, il est facile de réconcilier les points de vue. A lire donc pour éviter les erreurs, mais de mon point de vue les focus group restent des bonnes méthodes : en « problem search » et en « prototype validation »  (solution interview – avec ce conseil « “don’t ask customers what they want, measure what they do”). Ce chapitre met également en valeur les apports du Design Thinking  et propose de nombreuses références pour aller plus loin, dont le Human-Centered Design Toolkit de IDEO. On  retrouve ici les mêmes idées que dans l’ethno-marketing : préferer le qualitatif sur le quantitatif (en amont), préférer les signaux faibles et les « insights » aux moyennes et aux « concours de popularité ». Un autre conseil très intéressant est de bien comprendre les alternatives qui existent déjà pour résoudre le problème qui a été identifié. S’il n’y en a pas, le problème n’est probablement pas si intéressant : « a problem with no solution is not worth being solved most of the time”.
      
  • Dans l’esprit d’Eric Ries et la tradition Lean Startup, ce livre insiste sur le fait que les fonctionnalités doivent être tirées par les feedbacks clients et non poussées (« features must be pulled not pushed “). Le même message a été brillamment développé par Jared Spool cette année à USI.  On trouve par exemple ce conseil : Building great software is hard. Give your MVP a chance. First troubleshoot and resolve issues with existing features", qui est parfaitement en ligne avec ce que nous savons sur les analyses de dissatisfaction des applications mobiles. Une métaphore intéressante: « Your MVP should be like a great reduction sauce – concentrated, intense and flavorful »,  qui se combine très bien avec l’importance de l’analyse des émotions et de l’empathie des utilisateurs préconisée dans le livre précèdent.
  • Un des thèmes important du livre est celui des métriques, et en particulier l’utilisation des «Pirate Metrics » (AARRR : Acquisition, Activation, Retention, Referal, Revenue). On trouve dans le livre plein de conseils du type « Retention before Virality » (cf. section précédente), sur lesquels je reviendrai dans la section sur le Growth Hacking. Mais notons tout de suite l’importance de mesurer la viralité des produits, le « referal rate ». On trouve également le slogan « Metrics are People First », qui me semble essentiel : il faut pourvoir comprendre les personnes qui sont derrière les chiffres : « While I am a big proponent of building a metrics-driven culture, there is a lot more to building a great product that numbers. For starters, you have to be able to go to the people behind the number ». Un point très important et bien expliqué est l’analyse par cohorte, qui permet de comprendre les « cycles de vie » des utilisateurs et d’éviter que plusieurs phénomènes se superposent. Ash Maurya fait également référence au Sean Ellis Test : Ce test permet de dire qu’un produit a atteint un niveau suffisant de satisfaction (ce que l’on appelle avoir obtenu de la « traction »), lorsque 40% des gens qui ont fait l’effort d’utiliser le produit (mesuré avec la métrique Activation)  déclarent qu’ils seraient « vraiment décus » si le produit était abandonné.

4. Growth Hacking et Conclusion


Le growth hacking est un ensemble de pratiques pour développer l’usage qui commence à être formalisé suite au partage d’expérience des startups … et d’autres entreprises innovantes. Facebook, Twitter, LinkedIn, AirBnB et DropBox utilisent les techniques de growth hacking pour leurs propres applications. Il existe un excellent site en français pour la communauté des Growth Hackers.  Je vous recommande également  le slideshare de Mattan Griffel pour une introduction au sujet. Le terme a été inventé précisément par Sean Ellis. Pour reprendre les mots d’Aaron Ginn, « Growth hacker » est un nouveau mot pour une pratique qui existe depuis longtemps chez les meilleurs product and internet marketers de la Sillicon Valley. Il s’agit de mélanger des principes de marketing (viral) et de design de produit, parce que dans le monde numérique, il est possible de le faire ! C’est ce qui justifie le nom : le growth hacker est un hybride marketing / développeur, et le produit devient son propre outil de distribution et promotion.

Il y a trois idées fondamentales dans le growth hacking. Premièrement, l’utilisation des métriques AARRR et le fait de piloter la croissance en partant de la donnée, en prenant des décisions à partir de chiffres. Deuxièmement, la construction de modèles de croissance (growth models), dans la tradition de l’innovation accounting d’Eric Ries, qui sont des modèles analytiques de croissance représentant des hypothèses qui sont ensuite validées et actionnées … ou invalidées. Troisièmement, l’utilisation du produit comme outil de distribution virale et sociale. Cet aspect doit être pensé dès le début de la construction du MVP, je cite Seth Godin : « Virality is not something that you do to a product. It is something that the product is ». A côté des grands principes, il existe une multitude de pratiques et d’astuces pour accélérer chacune des phases. Le « definitive guide to growth hacking » de Neil Patel & Bronson Taylor est un bon exemple.

La pratique du Growth Hacking s’intégre parfaitement dans la vision du lean startup telle que présentée dans le premier livre que j’ai cité. Avec mon collègue Stéphane Delbecque d’AXA, nous avons détourné le schéma de Dave Landis pour obtenir la figure suivante. La dernière étape, de croissance, s’appuie sur ce que nous appelons le Customer Feedback Learning Loop (CFLL).



Le CFLL est construit sur trois canaux d’écoute :
  • Le canal implicite, qui s’appuie sur le Web & Mobile Analytics, consiste à étudier ce que les utilisateurs font avec le produit, l’application mobile, etc.
  • Le canal explicite collecte les verbatims des clients, depuis les commentaires dans les App Stores jusqu’au  enquêtes clients sur le terrain (cf. section précédente) en passant par les formulaires et outils de feedbacks qui sont tissés dans l’application.
  • Le canal social consiste à faciliter l’organisation des utilisateurs sous forme de communautés, pour passer d’un dialogue one-to-one à un dialogue social/communautaire, dont l’expérience enseigne qu’il est beaucoup plus riche.
Ce que les deux livres que je viens de résumer nous enseignent, c’est qu’il y a une courbe de maturité à suivre dans le growth hacking. La première étape est de construire une application satisfaisante, en fixant le cap à la fois sur les UVP (la promesse) et l’excellence de l’expérience (disponibilité, rapidité,  simplicité, etc.). Cette satisfaction se mesure par exemple par le NPS, mais aussi en appliquant le Ellis Test sur le ratio MAU (monthly active user) / Activation. La seconde étape est de solidifier cette satisfaction dans la durée, en observant les métriques de rétention. La troisième étape est celle de la viralité, mesurée par le « Referral rate ». Comme cela a été dit précédemment, il ne faut activer la viralité que lorsque la rétention est acquise, mais ces mécanismes doivent être construit dans le produit depuis le départ (c’est d’ailleurs vrai de l’ensemble de la problématique de la scalabilité, comme le disent Eric Schmidt et Jonathan Rosenberg «  Scaling needs to be a core part of your foundations »). La dernière étape est celle de l’accélération de la croissance virale par le marketing traditionnel, c’est-à-dire la communication, la publicité, la promotion, etc.