
Les startups savent ce qu’elles veulent offrir à leurs clients. Ce qu’elles ne savent pas, c’est comment transformer un pitch deck en un produit réellement utilisable.
Je voudrais vous parler de la solution que j’ai appliquée avec succès auprès de ceux avec qui j’ai travaillé : « Diviser pour mieux régner ».
« Combien de temps faudra-t-il pour le construire ? », demande le PDG après une présentation d’une heure remplie d’idées abstraites et de gestes théâtraux.
Comment le savoir ? Comment quiconque pourrait-il le savoir avec certitude ? Faut-il prendre l’estimation la plus pessimiste et la multiplier par trois ?
Peut-être bien…
Tout projet d’envergure mène inévitablement à une vallée du désespoir à un moment ou à un autre. Construire une entreprise devient une succession de tâches apparemment impossibles, d’une ampleur que vous n’avez jamais affrontée auparavant — le cauchemar de tout chef de projet. La feuille de route initiale ressemble à un journal de rêves : flou, incohérent, chaotique, et difficile à exprimer. Elle semble vous éloigner de l’objectif au lieu de vous en rapprocher. Cela décourage la plupart d’entre nous d’agir.
Et pourtant, une approche pragmatique m’a toujours permis de passer du fataliste « Laisse tomber ! » à l’hésitant « Par quoi je commence ? ».
Accepter l’incertitude
Lorsqu’il n’existe pas de manuel, on risque de s’accrocher à de fausses hypothèses jusqu’au bout, pour découvrir trop tard qu’on faisait fausse route. Neuf fois sur dix, il est alors trop tard pour changer de direction.
De nombreux fondateurs se sont vu recommander The Lean Startup, la « bible » de l’entrepreneur, comme protection ultime. L’idée est simple : construire un produit minimum viable (MVP), tester, échouer, recommencer jusqu’à ce que ça marche. Un MVP peut être n’importe quoi, d’une simple conversation avec un client potentiel à une façade web à moitié fonctionnelle qui simule un vrai produit mais ne fait rien, si ce n’est collecter les échecs d’utilisation. De la poudre aux yeux. L’objectif est de tester une hypothèse et d’économiser des ressources si l’idée n’est pas viable.
Remarque : il est souvent conseillé de rendre ce processus aussi peu convivial que possible, car des utilisateurs frustrés qui s’acharnent malgré tout sont un signal fort d’adéquation produit-marché.

Mais ça reste théorique. La plupart des gens qui recommandent ce livre ne suivent pas eux-mêmes son conseil principal — soit parce que c’est plus facile à dire qu’à faire, soit parce que c’est embarrassant à montrer, soit parce qu’ils ne construisent pas eux-mêmes.
Voici une plainte d’un collègue Chief Product Officer :
"J’ai du mal à tester des hypothèses avec des utilisateurs sans d’abord construire la fonctionnalité, la livrer et mesurer l’engagement. On pourrait aller plus vite si on n’avait pas à faire tout un cycle de développement, puis un autre pour récolter du feedback."Alors, quelle est la solution si vous ne pouvez pas toujours vivre selon les Dix Commandements d’Eric Ries ?
Diviser pour conquérir
Il n’y a qu’une seule façon de manger un éléphant : bouchée par bouchée.En science, comme dans d’autres disciplines, les problèmes insolubles sont souvent divisés en plus petits problèmes solvables. Les solutions partielles ainsi obtenues sont ensuite combinées pour résoudre l’ensemble. Cette méthode s’appelle diviser pour conquérir et s’inspire de la stratégie diviser pour régner, couramment utilisée en économie, en politique et en sociologie : diviser un pouvoir en petites parties gérables pour les contrôler séparément.
Cette approche descendante est particulièrement utile lorsque l’objectif est à peu près défini, mais que la feuille de route reste vague. Par exemple : je veux créer une fintech qui aide X à atteindre Y. Je veux écrire un livre sur Z. Je veux courir un marathon l’année prochaine. Vous devez savoir à peu près où vous voulez aller, même si la destination est lointaine. Plus l’effort est ambitieux, moins vous pouvez en faire d’un coup — et plus diviser pour conquérir devient pertinent.
Voici donc ce que j’ai répondu à ce CPO :
“Si tu ne peux pas éviter de construire avant de tester une hypothèse, structure-la de manière à pouvoir réutiliser certaines de ses parties si l’idée complète échoue. Nos nombreux tests ont abouti à une collection de ‘boîtes noires’ — tokens de design, fonctions lambda, scripts — que l’on peut réutiliser. Plus on mène d’expériences, plus il devient facile d’en monter de nouvelles avec nos briques Lego existantes.”Poulet contre concombre
Il existe de nombreuses manières de diviser un tout, mais je les classe en deux types :
- Ce que vous divisez détermine où vous le divisez.
- Vous choisissez la taille des portions.

Imaginez que vous découpez un poulet. Vous le couperez probablement au niveau des articulations. Le poulet “dicte” la façon la plus optimale de le découper après la mort. Ce serait inconfortable de trancher sa chair et ses os comme on tranche un concombre.
Note : en Asie, le poulet et le canard sont souvent tranchés entièrement, laissant à celui qui mange la responsabilité de cracher les carcasses fracturées, ce qui crée l’une des expériences utilisateur les plus pénibles.
Parlons du concombre, c’est un parfait exemple de la deuxième catégorie de division, où vous décidez de la forme et de la taille des morceaux dans lesquels vous voulez couper ce légume. Sauf si vous voulez sculpter une œuvre d’art dans un concombre, vous choisirez probablement des tranches rondes uniformes ou, de façon tout aussi régulière, des dés carrés pour votre salade.
Focus sur l’essentiel
Les startups sont comme des restaurants : extrêmement risquées, et leurs menus changent souvent. Comme vous, elles évoluent dans un contexte d’incertitude maximale où, selon la théorie des jeux, les décisions doivent être basées non seulement sur vous et vos utilisateurs, mais aussi sur ce que vos concurrents pourraient préparer. Cela dit, même si vous ne savez pas quels plats votre restaurant proposera demain, vous aurez toujours besoin de couteaux, d’un four et d’épices. Concentrez-vous là-dessus.
Je partage l’avis de Donella H. Meadow, qui affirme que les meilleurs systèmes sont résilients — ils continuent de fonctionner malgré les pannes et les corrections de cap. Leurs sous-systèmes sont immunisés contre les changements.
Une façon d’obtenir cette caractéristique pour vos produits est de suivre la philosophie Unix, qui considère que le tout est une collection de parties interconnectées. Chaque partie est responsable d’une seule chose, mais l’exécute de manière exceptionnelle. Les réorganiser permet d’exploiter de nouveaux potentiels et de pivoter sans douleur.
Construisez des blocs isolés, autonomes, résilients et réutilisables. Réorganisez-les et reconnectez-les jusqu’à atteindre votre objectif commercial global. En d’autres termes, diviser pour conquérir.
En écrivant sur ce sujet, j’ai réalisé qu’un seul article ne suffisait pas. Dans les suites, nous examinerons des scénarios réels des deux façons de diviser un tout en portions appropriées. La partie 2 sera dédiée aux blocs Lego autonomes de taille variable. La partie 3 portera sur des morceaux homogènes de taille équivalente.
Comment avez-vous résolu ce casse-tête ? Je suis sincèrement curieux.
Remerciements spéciaux
Les personnes brillantes suivantes ont aidé à découper cet article, évitant une boucherie amateur : Lilian T., Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, et Jason Collins.