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.