MVP : quelles fonctionnalités garder pour la V1 ?

La plupart des MVP échouent par excès : trop de fonctionnalités, trop de cas particuliers, trop de mois avant la mise en ligne. La bonne question n'est pas « que peut-on construire ? » mais « quel comportement unique prouve que le produit vaut quelque chose ? ».

Définir le comportement qui prouve la valeur

Identifiez l'action que l'utilisateur doit réussir pour que le produit ait servi à quelque chose : réserver, commander, générer, pronostiquer. La V1 est le chemin le plus court vers cette action. Tout le reste se juge par rapport à elle.

Séparer le parcours indispensable du confort

• Indispensable : sans cette étape, l'action principale échoue.
• Confort : l'action réussit sans, mais moins agréablement.
• Le confort se reporte en V2, même quand il est facile à développer.
• Une fonctionnalité facile mais inutile reste une charge de maintenance.

Garder l'administration et le support visibles

Corriger une donnée, désactiver un compte, comprendre pourquoi un envoi a échoué : ces gestes ne sont pas optionnels, même en V1. Un MVP sans outils d'exploitation transforme chaque incident en intervention dans la base de données.

Reporter les automatisations secondaires

Beaucoup d'automatisations peuvent commencer en manuel : un email envoyé à la main, un rapprochement fait chaque semaine. Automatisez quand le volume le justifie, pas avant. Le manuel assumé est un choix de V1 parfaitement valide.

Fixer un critère de sortie de V1

Décidez avant le lancement ce qui déclenchera la suite : un seuil d'usage, un retour récurrent, un segment qui paie. Sans critère explicite, la V1 s'étire indéfiniment et la V2 ne commence jamais.