Minimum lovable product : où investir l’amour

Un minimum lovable product n’est pas un MVP plus soigné. C’est un MVP dont l’amour est concentré à un seul endroit. Comment un founder non technique décide où va cet amour, et quand « lovable » devient une excuse coûteuse pour surdimensionner le produit.

Un founder avec qui nous avons travaillé l’an dernier est arrivé au kickoff d’un build avec une liste de 41 choses que la première version « devait rendre géniales ». Des animations fluides sur chaque écran. Un tour d’onboarding sur mesure. Mode clair et mode sombre. Il avait lu trois articles sur la façon de construire un minimum lovable product pendant le week-end et il était arrivé convaincu que « lovable » voulait dire « soigné partout ». Cet instinct, plus que n’importe quelle erreur technique, est ce qui fait exploser les premiers builds.

Un minimum lovable product (MLP) est la plus petite version d’un produit que les gens aiment vraiment utiliser, et pas seulement tolérer. Il fait une chose si bien que l’utilisateur pardonne tout ce qui reste brut autour. Le mot qui piège le founder, c’est « lovable ». Il le lit comme un bouton de finition à pousser à fond. Ce n’en est pas un. L’amour est un budget, et tout le savoir-faire consiste à décider où le dépenser.

Alors nous lui avons construit autre chose que sa liste. Un écran, le parcours de réservation que ses clients toucheraient chaque jour, était vraiment bon : rapide, évident, difficile à rater. Les quarante autres choses étaient honnêtes et simples. Il a lancé en sept semaines au lieu de cinq mois. Ses dix premiers clients n’ont jamais mentionné le mode sombre. Ils ont mentionné le parcours de réservation, spontanément, dans trois des cinq premiers appels de vente.

Ce qu’est vraiment un minimum lovable product

Le terme vient de Laurence McCahill, de The Happy Startup School, qui l’a proposé en 2014 comme réponse à un vrai problème : le minimum viable product d’origine avait tourné, devenant un permis de livrer quelque chose à moitié cassé en l’appelant lean. Sa correction a été de changer la question. Au lieu de « quel est le minimum qu’on peut construire en lançant quand même », demandez « quel est le minimum qu’on peut construire et que quelqu’un va aimer ».

C’est une bonne correction. Mais quelque part entre 2014 et aujourd’hui, « lovable » a été aplati en « plus de features, plus beau design, expérience plus complète ». Cette lecture, c’est ainsi qu’un founder non technique se retrouve avec une liste de 41 points « doit rendre génial » et un build de cinq mois pour un produit que personne n’a encore payé.

La bonne lecture est plus étroite et plus utile. Un minimum lovable product concentre sa qualité. Il choisit le seul moment où l’utilisateur décide si la chose vaut son temps, et il rend ce seul moment indéniablement bon. Partout ailleurs, il reste délibérément et visiblement minimal. Le produit n’est pas soigné de façon uniforme. Il est déséquilibré exprès.

Minimum viable product vs minimum lovable product

Le débat MVP vs MLP est posé comme soigné contre pas soigné, et ce cadrage est faux. Les deux sont minimaux. La différence, c’est où vit le minimum.

Un minimum viable product demande à quel point le périmètre peut être petit tout en t’apprenant quelque chose de vrai sur la demande. Son risque, c’est d’être si maigre qu’il ne valide rien. Nous avons déjà écrit sur pourquoi la plupart des MVP sont trop petits pour valider quoi que ce soit de réel ; cet article-là porte sur la taille de la chose.

Un minimum lovable product prend le périmètre comme à peu près donné et pose une autre question : parmi les choses qu’on va construire, laquelle porte le verdict ? Son risque court dans l’autre sens. Là où un MVP échoue en étant trop maigre, un MLP échoue en répartissant sa qualité si uniformément que rien ne ressort et que le budget est épuisé avant le lancement. L’un est une décision de périmètre. L’autre est une décision de concentration. Tu prends la décision de MVP d’abord, puis celle de MLP à l’intérieur.

En clair : la question du MVP, c’est combien on construit. La question du MLP, c’est où va la qualité. Les traiter comme la même conversation, c’est ainsi que des founders finissent soit par livrer du déchet, soit par livrer en retard.

Quand « lovable » devient une excuse pour surdimensionner

Voici le mode d’échec dont aucun des premiers résultats de recherche ne te prévient, parce qu’ils sont surtout écrits pour des product managers d’entreprises financées, pas pour un founder qui dépense son propre runway.

« Lovable » est le mot le plus cher d’une réunion de kickoff. Il n’a pas de bords. N’importe quelle feature peut être poussée dans le seau « lovable », parce que toute feature pourrait, en principe, être plus charmante. Un dev qui veut construire la chose sophistiquée et un founder qui veut un produit premium seront d’accord l’un avec l’autre jusqu’à faire sauter le budget. Nous avons vu des premiers builds doubler de coût non pas parce que le périmètre avait grossi, mais parce que le mot « lovable » avait été appliqué partout sans que personne ne freine.

Le signe, c’est quand les demandes de finition se collent à des écrans que l’utilisateur ne voit presque pas. Des transitions animées sur l’écran de paramètres de l’admin. Un état vide magnifiquement dessiné pour un rapport que les premiers clients ne lanceront pas avant des mois. C’est du craft pointé sur la mauvaise cible. Un bon design fait de bonnes affaires, mais du design dépensé là où personne ne regarde n’est que du coût en habit chic.

La discipline d’un vrai MLP, c’est de dire « non, cette partie reste simple » à voix haute, exprès, et de pouvoir expliquer pourquoi. Si ton studio ne te dit jamais qu’une partie du produit est volontairement brute, tu ne construis pas un MLP. Tu construis un produit aimable maximal avec un budget minimal, et le compte ne tombe pas juste.

Le framework du budget d’amour : décider où va l’amour

Traite la lovability comme un budget fixe que tu alloues, pas comme un niveau de qualité que tu règles. Avant que le build démarre, fais passer les écrans et parcours candidats par quatre questions. Ceux qui marquent le plus haut récoltent l’amour. Tout le reste a le droit d’être honnête et simple.

1. L’utilisateur le touche-t-il au jour un, ou tous les jours ? Le parcours qu’un client touche à sa première session, et celui qu’il répète au quotidien, sont là où se forment les verdicts. Un écran de réservation utilisé vingt fois par semaine mérite l’amour. Un export en masse utilisé une fois par trimestre, non.

2. Est-ce le moment où il décide qu’on en vaut la peine ? Tout produit a un endroit où l’utilisateur te note en silence. Pour une fintech, la première transaction qui passe. Pour une marketplace, le premier match qui sonne juste. Trouve ce moment et dépense trop dessus, même si ce n’est qu’un seul écran.

3. La rugosité ici se lit-elle comme cassé, ou juste comme basique ? Certaines aspérités se lisent comme « tôt et concentré ». D’autres se lisent comme « ces gens ne savent pas faire du logiciel ». Un écran de paramètres simple, c’est bien. Un checkout qui paraît bancal est fatal, parce que l’argent rend les gens nerveux et que le bancal se lit comme du risque. Dépense l’amour là où la rugosité serait mal lue, comme de l’incompétence.

4. Est-ce là où on est différents, ou là où on est comme tout le monde ? Verse l’amour dans la partie qui est ta vraie raison d’exister. Les parties qui sont des prérequis, le login, un dashboard simple, peuvent ressembler à celles de tout le monde sans rien te coûter.

La plupart des produits ont un, peut-être deux parcours qui gagnent sur les quatre questions. C’est ton budget d’amour. Concentre là. Le vrai travail du framework, c’est de te donner, founder non technique, le langage pour défendre le « laisse-le simple » face à une salle pleine de gens qui veulent sincèrement tout rendre plus joli.

À quoi ça ressemble dans un vrai build

Le MLP du founder de réservation avait exactement une surface aimable : le parcours de réservation. Nous y avons consacré du vrai temps de design et d’ingénierie. Réponse sous la seconde, pas d’impasses, une confirmation qui inspirait de la solidité. Tout ce qui était derrière, les paramètres de compte, les rapports, les écrans de gestion d’équipe, a été construit pour fonctionner et rien de plus. Gris là où le gris suffisait.

Ses concurrents avaient des produits plus complets. Plus de paramètres, plus de finition répartie sur plus d’écrans. Ils mettaient aussi plus de temps à lancer quoi que ce soit et donnaient, à un nouvel utilisateur, l’impression d’un tas de « correct » au lieu d’une chose qui était excellente. Six mois après le lancement, il avait le budget et le feedback client pour rendre les écrans de rapports aimables eux aussi, cette fois en sachant exactement quels rapports les gens lançaient vraiment. C’est le bon ordre : gagne la surface suivante, ne la préconstruis pas.

Un test de bon sens avant de commencer : les décisions de finition se prennent quand tu valides les designs, pas quand le code part. Si tu ne connais pas la différence entre un wireframe, un mockup et un prototype, tu donneras du feedback cosmétique sur le structurel et du feedback structurel sur le cosmétique, et ton budget d’amour fuira dans le cycle de revue avant qu’une ligne de code soit écrite.

Comment briefer un studio pour un minimum lovable product

Si tu paies quelqu’un pour construire ça, le brief est l’endroit où le budget d’amour se définit ou se perd. Trois choses à mettre par écrit.

Nomme la seule surface aimable explicitement. Pas « que ça fasse premium ». Écris : « Le parcours de réservation est la seule expérience qui doit être vraiment bonne. Dépensez ici. » Un bon partenaire questionnera ou confirmera ton choix. Un prestataire boîte noire dira juste oui et te facturera de la finition partout. Les partenaires tech ne devraient pas être des boîtes noires ; l’aller-retour sur l’endroit où va la qualité est exactement la conversation qui en vaut la peine.

Nomme ce qui reste simple. C’est la partie que les founders sautent, et c’est la partie qui protège le budget. « Les paramètres, les rapports et la gestion d’équipe doivent fonctionner correctement et avoir un aspect standard. Ne passez pas de temps de design à les rendre spéciaux en v1. » Mettre la rugosité par écrit la transforme en décision plutôt qu’en accident.

Relie-le à l’argent. Le budget d’amour sort de la même poche que tout le reste, alors sache quelle est cette poche. Nos textes sur combien coûte le développement d’une application et sur la décision de construire ou d’acheter qui se situe en amont de tout ça couvrent les chiffres. La version courte : chaque écran que tu rends aimable est un écran que tu paies au prix premium. Une surface premium tient dans presque n’importe quel budget. Dix, c’est ainsi qu’un premier build devient, en silence, une deuxième levée.

Questions fréquentes

Quelle est la différence entre minimum viable product et minimum lovable product ?
Un MVP porte sur le périmètre : le plus petit build qui teste encore une vraie demande. Un MLP porte sur la concentration : prendre ce périmètre et rendre une expérience centrale vraiment bonne, en laissant le reste délibérément simple. Tu décides du périmètre du MVP d’abord, puis tu décides, à l’intérieur, où va la lovability. Ils sont séquentiels, pas concurrents.

Qu’est-ce qu’un minimum lovable solution ?
La même idée, appliquée à des outils internes ou opérationnels plutôt qu’à un produit destiné au client. La surface « aimable » est là où ton équipe passe le plus de temps. Un dashboard d’opérations quotidiennes mérite un vrai soin ; un écran de config utilisé une fois par mois, non. Concentre la qualité là où vont les heures.

Qu’est-ce qu’un minimum acceptable product ?
Un minimum acceptable product, c’est le plancher : ça marche et ça ne te fait pas honte, mais aucune partie n’est faite pour être aimée. C’est une cible correcte pour un outil interne jetable. C’est une cible faible pour tout ce qu’un client choisit d’utiliser, parce que « acceptable » génère rarement du bouche-à-oreille. Un MLP coûte un peu plus qu’un minimum acceptable product et concentre ce surcoût à un seul endroit.

Qu’est-ce qu’un minimum lovable product chez Amazon ?
Cela renvoie généralement à la pratique du « working backwards » d’Amazon, écrire le communiqué de presse et la FAQ avant de construire. C’est une méthode pour forcer la clarté sur ce que les utilisateurs vont aimer avant de commencer, compatible avec tout ce qui précède. Outil différent, même instinct : décide ce qui doit être aimé avant de dépenser.

Où un founder non technique doit-il investir l’amour en premier ?
Sur le seul parcours que les clients touchent le plus et par lequel ils te jugent, en général la première action réelle qu’ils font dans le produit. Rends cette chose indéniablement bonne. Laisse le reste honnête et simple jusqu’à ce que les clients te disent quoi améliorer ensuite.

Un minimum lovable product n’est pas le maximum que tu peux te payer pour soigner. C’est la seule chose que tu refuses de livrer brute, entourée de tout ce que tu as eu le courage de laisser simple. Choisis bien cette chose, et tes dix premiers clients te diront si tu as choisi juste.