Comment réduire le périmètre de son MVP

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 feature que vous coupez n'est presque jamais la moins utile. C'est celle que personne dans la pièce n'a su défendre en une phrase. Couper, c'est révéler ce qu'on ne croyait pas assez pour le porter.

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.

Must : sans ça, on ne teste rien

Une fonctionnalité est un must uniquement si, sans elle, le parcours qui valide votre hypothèse centrale ne tient plus debout. Pas « sans elle ce serait moins bien », mais « sans elle l'utilisateur n'atteint jamais le moment de vérité ». La discipline : un must doit pouvoir se défendre en une phrase devant toute l'équipe. Si vous bafouillez, ce n'en est pas un. La plupart des MVP ont entre cinq et huit must réels, rarement plus.

Should : utile, mais le produit marche sans

Le should, c'est la zone dangereuse, celle où le scope dérive. Ce sont des fonctions sincèrement utiles dont l'absence dégrade l'expérience sans empêcher le test. La règle d'or : aucun should n'entre dans la V1. Vous les listez, vous les datez « après la preuve », et vous y revenez quand l'usage réel vous dira lesquels comptent vraiment. Beaucoup ne seront jamais redemandés.

Cut : on assume de ne pas le faire

Couper, ce n'est pas reporter dans une zone grise, c'est sortir explicitement du périmètre et l'écrire. Le second type d'utilisateur, le back-office riche, les intégrations « stratégiques », les cas limites rares : tout ça part au cut tant que le cœur n'a pas fait ses preuves. Écrire la liste des cut noir sur blanc protège l'équipe : la décision est prise une fois, on ne la rejoue pas à chaque réunion.

Défendre chaque must à voix haute

La dernière étape est un rituel, pas un document. Réunissez les décideurs, et faites défendre chaque must, un par un, par celui qui le porte. Une phrase, l'hypothèse testée, la conséquence de l'absence. Le must qui ne survit pas à cet oral redescend en should. C'est là que le périmètre fond vraiment, parce que la parole engage là où le tableur laisse tout coexister.

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.

5 à 8le nombre de fonctionnalités réellement « must » dans la plupart des MVP, parcours critique compris

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.