Tout le monde sait qu'un MVP doit être petit. Personne n'arrive à le rendre petit. Chaque fonctionnalité a son avocat, sa bonne raison, son « mais si un client demande ça ». Réduire le périmètre, ce n'est pas un exercice de bon sens, c'est un exercice de courage : il faut dire non à des idées qui ne sont pas mauvaises, juste pas prioritaires.
Réduire le périmètre de son MVP, c'est garder le seul parcours qui teste votre hypothèse la plus risquée, et reporter tout le reste. La bonne méthode n'est pas de lister ce qui serait utile, mais de classer chaque feature en must, should ou cut, puis de défendre chaque must à voix haute. Ce qu'on ne sait pas défendre, on le coupe.
Si vous cadrez votre tout premier produit, le cadre d'ensemble est dans le guide du MVP au PMF. Ici, on regarde l'opération précise et inconfortable : couper.
La feature qu'on garde « au cas où » est un aveu
Quand une fonctionnalité reste dans le scope avec pour seule justification « au cas où », ce n'est pas une décision, c'est une absence de décision. Personne n'a osé la défendre vraiment, personne n'a osé la couper. Elle survit par inertie, et elle coûte : du temps de build, de la surface de bug, de la complexité dans l'interface, du retard sur la mise en marché.
Le test est simple. Pour chaque feature, demandez à voix haute : « Quelle hypothèse précise cette fonctionnalité teste-t-elle, et que se passe-t-il si on la retire du premier lancement ? » Si la réponse tient en une phrase claire, c'est probablement un must. Si la réponse est floue, hésitante, défensive, vous tenez votre prochaine coupe.
La méthode : must, should, cut
Oubliez les matrices à quatre quadrants et les scores pondérés. Sous pression, une équipe a besoin de trois cases, pas de douze. Chaque fonctionnalité candidate tombe dans l'une d'elles, et la règle de répartition est volontairement brutale.
Le « non » est un acte de design, pas un échec
Dans la tête de beaucoup de fondateurs, couper une fonctionnalité revient à appauvrir le produit. C'est l'inverse. Un produit n'est pas la somme de ce qu'il fait, c'est la clarté de ce pour quoi il existe. Chaque « non » resserre cette clarté. Le designer qui compte n'est pas celui qui ajoute, c'est celui qui retire jusqu'à ce qu'il ne reste que l'essentiel et que l'essentiel devienne évident.
Cette logique rejoint directement la question du volume : un MVP ne se mesure pas en nombre de features, mais en complétude d'un seul parcours, comme je le détaille dans combien de fonctionnalités dans un MVP. Réduire le périmètre et compter les features sont les deux faces de la même discipline.
Pourquoi un regard externe coupe mieux
Le plus dur, quand on coupe son propre produit, c'est qu'on a un attachement à chaque idée. Vous avez vendu cette feature à un associé, promise à un early adopter, imaginée à 2 h du matin. Un externe n'a pas cet historique affectif. Il pose la seule question qui compte, « ça teste quoi ? », sans ménager personne, et il assume le « non » à votre place quand vous n'y arrivez pas.
C'est exactement le rôle que je joue en cadrage de MVP : forcer la défense de chaque must, écrire les cut noir sur blanc, et protéger la V1 de la dérive. Un périmètre trop large, c'est aussi la première cause d'un budget qui dérape, comme je l'explique dans MVP qui coûte trop cher. Couper tôt, c'est dépenser juste.
On taille votre périmètre ensemble ?
J'interviens comme CTO fractional armé d'IA pour ramener votre MVP au seul parcours qui prouve votre hypothèse.
Découvrez le Sprint Fondateur, ou réservons 30
minutes pour trier votre scope avant de lancer le build.
Top comments (0)