Ce que doit réellement contenir un MVP

L’expression « produit minimum viable » a été étirée au point de ne presque plus rien vouloir dire. Pour les uns, c’est une page d’atterrissage ; pour les autres, le produit complet avec une fonctionnalité en moins. Aucune de ces définitions ne vous aide à décider quoi construire lundi matin.

Partez de l’hypothèse la plus risquée

Tout produit repose sur une conviction qui pourrait être fausse. Parfois c’est une question de demande : quelqu’un paiera-t-il pour cela ? Parfois c’est technique : pouvons-nous traiter ceci de façon assez fiable pour inspirer confiance ? Le MVP existe pour tester la conviction dont il serait le plus coûteux de découvrir qu’elle est fausse.

Écrivez cette hypothèse sous forme d’une phrase avant de cadrer quoi que ce soit. Si votre liste de fonctionnalités ne la teste pas, c’est la liste qui est mauvaise.

Minimum ne veut pas dire bâclé

Réduire le périmètre n’est pas la même chose que réduire la qualité. Un petit produit qui fonctionne est un test ; un grand produit qui casse n’est que du bruit. Si la connexion est instable, vous n’apprenez rien sur l’intérêt de ce qui se trouve derrière.

Ce que nous gardons en général

—Un parcours complet dans le produit, de bout en bout, sans impasse.

—Les comptes utilisateurs, si la valeur dépend du retour des utilisateurs.

—L’instrumentation, car un MVP que vous ne pouvez pas mesurer n’a rien testé.

—Un moyen de joindre une vraie personne, qui reste le retour le plus riche que vous obtiendrez.

Ce que nous coupons en général

—Les outils d’administration qu’un tableur peut couvrir les premiers mois.

—Les écrans de réglages, qui traduisent le plus souvent une décision que vous n’avez pas encore prise.

—Les plateformes supplémentaires, tant que la première n’a pas montré que l’idée tient.

Rien de tout cela n’est une règle. C’est une position de départ que nous discutons, projet par projet — et nous préférons en débattre la première semaine plutôt qu’au sixième mois.