Lean product strategy
Construire a cessé d’être le plus dur.
La lean product strategy, c’est construire la plus petite chose qui teste l’hypothèse sur laquelle repose votre activité. Pendant quinze ans, la partie coûteuse était de la construire. Ce n’est plus vrai depuis cette année, et cela change ce à quoi sert la méthode.
Ce qu’elle dit vraiment
La définition qui circule — la plus petite version livrable du produit — n’est pas celle qu’a écrite Eric Ries. Pour lui, un MVP n’est pas nécessairement le produit le plus petit imaginable : c’est le moyen le plus rapide de boucler la boucle build-measure-learn avec le minimum d’effort. L’unité de mesure, c’est l’apprentissage. Le produit n’est que le moyen le moins cher de l’obtenir.
C’est pour cela qu’une landing page avec un vrai prix dessus, une fiche produit, une vidéo de deux minutes ou un formulaire auquel une personne répond à la main ont toujours compté. Aucun n’est une version réduite du produit. Chacun est une façon de poser une question qui coûterait sinon un trimestre.
Lue ainsi, la méthode n’a jamais parlé de livrer vite. Elle parlait de ne pas payer pour découvrir quelque chose qu’on aurait pu apprendre pour moins cher.
Ce qui a changé cette année
En septembre, Steve Blank a raconté ce qui est arrivé à sa promotion de Stanford. Chaque équipe est arrivée au premier cours avec un produit fini — le genre de chose qui prenait auparavant les dix semaines entières — parce qu’elles l’avaient construit avec l’IA en un week-end. Ces équipes ont ensuite appris moins que toutes celles d’avant.
Sa conclusion : un produit dès le premier jour signifie qu’un MVP ne prouve plus rien. Ni la discovery, ni le test d’hypothèse, ni le product-market fit, ni même le fait qu’on y croie. Construire coûtait assez cher pour prouver qu’on y croyait. Ce n’est plus le cas.
L’échec a une forme, et il vaut mieux la connaître avant de la rencontrer. Construire pour presque rien fait avancer une mauvaise idée plus vite. Un objet soigné se lit comme un progrès, alors l’équipe se met à collectionner les compliments au lieu de chercher la preuve qui la tuerait. Et une chose déjà construite est coûteuse à abandonner quel qu’ait été son prix : ces équipes ont pivoté plus tard que celles arrivées les mains vides.
Un avantage défendable a disparu avec. Le temps et l’argent nécessaires pour construire tenaient les concurrents à distance à eux seuls. Ce n’est plus le cas : le client à qui vous vendez peut générer une alternative dans la même semaine que vous. La distribution et les coûts de changement fonctionnent toujours ; être le premier à avoir quelque chose qui marche, non.
Comment nous la pratiquons
Rien de tout cela ne rend la méthode obsolète. Cela fait de sa moitié « décider » tout le travail, et rend sa moitié « construire » presque gratuite. Le travail se déplace donc vers l’avant.
Planifier la boucle à l’envers
Build, measure, learn est l’ordre dans lequel les choses arrivent, pas l’ordre dans lequel les planifier. Décidez ce que vous devez apprendre, puis ce qui tiendrait lieu de mesure, puis la plus petite chose qui produit cette mesure. Les équipes qui planifient à l’endroit construisent d’abord et cherchent une question ensuite.
Écrire le résultat attendu avant que quoi que ce soit existe
Pas une fonctionnalité, pas une user story : le changement de comportement qui compterait comme une réussite, et la fenêtre dans laquelle il doit arriver. Convenu par écrit, avant le premier écran. Tout ce qui est produit ensuite se mesure à cela au lieu d’être admiré.
Préférer le test qui n’est pas une construction
Un prix sur une landing page, un formulaire auquel on répond à la main, une semaine à rendre le service manuellement pour cinq clients. Ces tests ont toujours été légitimes. Maintenant qu’une chose construite prouve moins, ils prouvent comparativement plus — et ils restent plus rapides que le week-end.
Nommer l’hypothèse qui tuerait l’idée
Toute idée repose sur quelque chose qui, si c’est faux, rend le reste sans objet. C’est en général de savoir si quelqu’un paiera, ou si le comportement dont vous avez besoin existe déjà. C’est celle-là qu’il faut tester en premier, même quand c’est la plus difficile et la moins satisfaisante à tester.
Ce que ce n’est pas
Pas une approche à petit budget
Lean décrit la taille du pari, pas le coût. Une validation n’est pas gratuite — elle revient simplement à moins cher que de construire la chose et de le découvrir.
Pas sauter la recherche
C’est de la recherche, avec du développement greffé seulement là où construire est le moyen le moins cher qu’il reste de poser la question. Les entretiens ont toujours lieu. Ils ont lieu en premier.
Pas livrer et voir
Livrer sans avoir énoncé le résultat attendu n’est pas une expérience, c’est une mise en ligne accompagnée d’optimisme. Si personne n’a écrit ce qui compterait, rien de ce qui arrivera ensuite ne tranchera quoi que ce soit.
Pas un produit que le modèle a écrit vendredi
Quelque chose de généré en un après-midi et montré à personne est une idée non testée avec une interface. C’est la chose la plus convaincante dans la pièce, et la moins informative.
Questions fréquentes
Voir dans le plan produitNous avons déjà une roadmap. En avons-nous besoin ?
Seulement si personne ne sait dire ce qui doit être vrai pour que la première ligne vaille la peine d’être construite. Une roadmap est un ordre de travail ; ceci est la raison pour laquelle cet ordre est le bon. Les équipes sûres de leur roadmap et sans hypothèse énoncée sont celles à qui cela coûte le moins et fait gagner le plus.
N’est-ce pas simplement de la discovery ?
La discovery, c’est la partie recherche. Ceci, c’est la partie recherche plus une décision avec un chiffre attaché et une date à laquelle elle est tranchée. La différence se voit à la fin : la discovery produit des constats, ceci produit un arbitrage sur le fait de construire ou non.
Vous construisez vous-mêmes des MVP avec l’IA. N’est-ce pas exactement ce contre quoi vous mettez en garde ?
C’est précisément ce qui nous permet de le dire. Nous pouvons mettre un produit qui marche devant vos clients en quelques jours, et c’est bien ce qui fait de la décision la partie coûteuse plutôt que de la construction. La mise en garde ne porte pas sur le fait de construire vite. Elle porte sur le fait de traiter ce qu’on a construit vite comme une preuve de quoi que ce soit.
Qu’est-ce qu’on obtient au bout ?
Une décision, les preuves sur lesquelles elle repose, et ce qu’il faudrait pour la changer. En général une page, parfois un paragraphe. Quand la réponse est de construire, vous obtenez aussi le périmètre qui en découle — normalement plus petit que celui avec lequel vous êtes arrivé.
Combien de temps cela prend-il ?
Une première réponse en une à deux semaines, parce que les questions qui valent la peine d’être posées se répondent dans ce délai, sinon ce sont les mauvaises questions. Cela se déroule dans un abonnement plutôt qu’en mission séparée : c’est la première quinzaine de la plupart de nos missions.
Qu’est-ce qui doit être vrai pour que cela fonctionne ?
Si vous pouvez répondre en une phrase, vous n’avez probablement pas besoin de nous pour cette partie. Si la réponse demande une réunion et que les avis divergent, c’est ce qu’il faut trancher avant que quiconque construise.
Travailler avec nous