Derrière l'hypercroissance des startups ne se cache pas seulement des "growth hacks", mais un processus continu d'idéation, de priorisation, de test et d'apprentissage. Cette dynamique, appelée "Product Flywheel", est la clé d'une croissance saine et soutenue, loin des illusions du Growth Hacking.
Maintenant que le soufflé du Growth Hacking est un petit peu retombé, il est temps de parler de choses sérieuses.
L’obsession de ces 15 dernières années a été : comment toutes ces licornes sont passées d’une croissance en dents de scie à de l’hypercroissance ?
Beaucoup de malins, des pseudo “growth hackers”, se sont engouffrés sur ce créneau, inondant le web avec des contenus dont les titres étaient juste une variante de “How [company] went from 0 to X millions users in Y months”.
Accompagnés du fameux graphique de croissance exponentielle qu’on aime bien, ponctué de 2-3 grosses étapes de croissance.
Je ne dis pas que c’est des mythos. C’est la plupart du temps ce qui est arrivé.
On parlait alors à tout va de “growth hacks”, à l’origine de ces différentes étapes de croissance ; les 10 amis en 7 jours de Facebook, le programme de referral de Dropbox, le hack de Airbnb avec Craigslist.
Ça fait rêver ! Et surtout ça fait croire à n’importe qui qu’il peut y arriver, en faisant un copier/coller du hack.
Bizarrement, 99% des gens qui ont lu ces articles n’ont pas construit de licorne.
Étrange…
Pas tant que ça.
En fait un growth hack est précédé de dizaines de cycles de test and learn.
Si on passait ces courbes de croissance au rayons X, voici ce qu’on verrait.
Il y a toujours plusieurs mois de croissance faiblarde avant un point d’inflexion : c’est la période où l’équipe teste plein de trucs qui ne fonctionnent pas énormément, qui peaufinent peaufinent peaufinent jusqu’à ce que le hack soit mûr et booste la croissance.
Et bien souvent, les growth hacks connus ne sont responsables que d’un petit pourcentage de la croissance.
La croissance provient plutôt d’une centaine d’idées moins spectaculaires, mais qui fonctionnent.
Mais alors on va me dire “mais moi aussi j’ai plein d’idées, et pourtant on n’a toujours pas de croissance”.
Parce que la deuxième réalité, et c’est de loin le plus important, c’est que ces boîtes ont mis en place un système d’apprentissage très efficace pour y arriver.
Non elles ne lancent pas des idées “géniales” sorties de leurs têtes en croisant les doigts pour que ça marche (ou pas).
Les plus grosses boîtes le disent : quoiqu’il arrive, les 2/3 des idées que l’on teste n’ont aucun impact.
Elles priorisent les meilleures idées en fonction de la connaissance qu’elles accumulent. Et plus elles deviennent sachantes, meilleures sont leurs idées.
Chaque bonne idée apporte de plus en plus de croissance. De plus en plus vite.
Et ces idées s’accumulent rapidement.
Voilà ce qu’est l’hypercroissance.
Les boîtes qui s’en sortent le mieux sont celles qui apprennent le plus vite. Point.
Quand est arrivée la vague du Growth Hacking, on a vite retenu que les paillettes (les hacks d’acquisition) et a on vite mis de côté le côté plus compliqué : le process pragmatique nécessaire pour y arriver.
Sean Ellis, jeune père du Growth Hacking a bien vu que sa création était utilisée à mauvais escient. Il s’est donc senti obligé de sortir un livre pour remettre sur le devant de la scène ce process, certes compliqué à mettre en place, mais magique en tous points !
Ces startups suivent tous un process précis.
Avant toute chose, elles rassemblent leurs équipes autour d’un objectif commun, leur North Star Metric.
Ensuite, elles imaginent des idées pour atteindre cet objectif. La phase d’idéation. Si possible, pas au hasard, en se basant sur des infos, mais je ne vais pas spoiler l’étape 4 du cycle.
Elles ne foncent pas tête baissée dans le développement. Certaines ont plus de potentiel que d’autres. Certaines sont juste des intuitions quand d’autres sont plutôt sûres, certaines sont lourdes à construire quand d’autres peuvent être des quick-wins.
C’est évident qu’elles se concentrent sur celles qui ont potentiellement le meilleur retour sur investissement. C’est la phase de priorisation.
C’est à partir de là qu’on rentre dans le dur, il est temps de confronter ces idées au monde réel. Ça ne veut pas dire qu’on les développe coûte que coûte, on s’assure plutôt qu’on avait vu juste (ou pas) sur leur potentiel.
Parce que plus une idée est avancée, plus elle risque de nous coûter cher.
Alors souvent on fait du quali au début, on passe par des tests légers (smoke tests, MVPs) et on confirme quand on peut avec de la donnée quanti.
Le but est d’emmagasiner le plus d’apprentissage possible pour dérisquer une idée. Savoir si elle vaut la coup d’être développée.
C’est la phase de Test.
Si tous les voyants sont au vert, on développe la feature pour de vrai.
Enfin, on termine avec la phase de Learning. Qui a en fait débuté dès le début du cycle car la priorisation ICE nous demande de dérisquer une idée en apportant des preuves réelles.
Une fois que le cycle se termine, on a appris plein de nouvelles choses et tout ce nouveau savoir permet d’avoir de nouvelles idées. Bien plus éclairées.
C’est reparti pour un tour. Tous plus smarts qu’on ne l’était au début du tour précédent et donc en apportant des idées encore meilleures.
Flywheel, c’est la traduction de roue d’inertie. Son principe : elle est auto-alimentée par son élan.
C’est ce qui décrit le mieux la magie du process Ideate > Prioritize > Test > Learn.
Si on a tout bien mis en place, ce cycle prend de la vitesse.
En produit, plus tu vas analyser ce que tu testes, meilleures seront les idées qui en découlent, et mieux tu priorises, plus la valeur (et donc la croissance) arrivera vite. C’est un cercle (ultra) vertueux.
Au départ ce ne sera pas fameux fameux. Les idées fleuriront un peu au doigt mouillé, la priorisation hésitante, les systèmes d’analyse pas parfaitement configurés.
Mais ce “pas fameux” bien étudié et amélioré va nous donner des idées un peu meilleures. Puis, ces dernières aussi testées et analysées vont nous en donner encore des meilleures. Vous voyez le truc venir ?
Tout cela en apportant de plus en plus de valeur à vos utilisateurs, et donc de la croissance (car oui, il ne faut pas oublier que c’est ça le but !).
Et disons que la version anglophone, “flywheel”, sonne mieux que notre version “roue d’inertie”, non ?
Bienvenue à la Product Flywheel.
Récapitulons.
Vous avez un objectif clair de croissance et grâce à votre Product Flywheel vous générez de plus en plus d’idées qui permettent petit à petit d’atteindre cet objectif.
On peut donc dire que plus la vitesse de votre flywheel est grande, plus la croissance de votre produit est exponentielle.
Mais pour y arriver, la vitesse de votre product flywheel et donc de votre croissance va dépendre de 4 facteurs.
C’est simple. Sans moyen d’analyser notre travail, pas de flywheel.
Comme a dit Noah Kagan, “If you didn’t measure it, it didn’t happen”.
Que ce soit en quali ou en quanti, il faut savoir rapidement déterminer ce qui va et ce qui ne va pas, et pourquoi.
Cette analyse doit être assez claire et actionnable pour nous permettre à tous d’imaginer d’autres idées.
Si on est prêt à l’analyser, chaque idée peut apporter de l’énergie à notre flywheel. Bonne ou mauvaise, l’idée va nous permettre d’apprendre des choses.
Mais soyons honnêtes, nous allons clairement plus vite si nous priorisons des idées avec un gros potentiel et peu d’efforts pour les mettre en place.
Je le répète, le but de cette flywheel est avant tout de faire croitre notre produit.
Ça peut paraître titanesque comme changement de méthodologie. Pour rendre les choses plus faciles, la question à se poser n’est pas “quelles features doit-on construire et lancer ?” mais plutôt “quelles idées doit-on tester en priorité ?”.
Vous allez voir ça fait un bien fou.
Grâce à la priorisation ICE, vous allez avoir la réponse à cette question presque automatiquement !
Une roue d’inertie tourne car par principe absolument rien l’en empêche. Il suffirait d’un grain de sable pour casser l’élan.
C’est pareil pour notre Product Flywheel. Vous allez voir la magie s’opérer que si les processus d’idéation, de priorisation, de test et d’analyse fonctionnent sans accrocs.
Un maillon faible et on perd le rythme. La magie s’évapore.
Cela fait des années que je coache des équipes produit en essayant du mieux que je peux d’insuffler cette philosophie.
Mais il faut avouer que c’est clairement impossible avec les outils qui sont à notre disposition. Trop de friction. On abandonne avant d’y arriver.
En même temps, on utilise des outils de Project Management pour faire du Product Management…
C’est pour cela que j’ai décidé de construire Flywheeel, le premier outil livré avec tous ces process intégrés, pour éviter toute prise de tête et permettre de lancer une Product Flywheel en quelques minutes.
Dans un prochain article, on sort de la théorie et on passe à la pratique. Je vous explique comment monter une Product Flywheel simplement, quelle que soit la taille de votre boîte.
.png){kind=small}