Les fondateurs arrivent souvent à la première réunion avec une longue liste de fonctionnalités, fruit de mois de réflexion sur le produit. Cette liste est précieuse, mais presque aucune de ces fonctionnalités ne devrait être intégrée à la première version. Un MVP a pour but de répondre à une question essentielle : cette idée spécifique fonctionne-t-elle pour de vrais utilisateurs, et pas seulement en théorie ?
La difficulté principale lors de la définition du périmètre d'un MVP n'est généralement pas de décider quoi inclure, mais plutôt quoi omettre, en particulier les fonctionnalités qui semblent indispensables. Un système de connexion avec réinitialisation de mot de passe, connexion via les réseaux sociaux et gestion de profil paraît essentiel, mais si l'hypothèse fondamentale à tester est de savoir si les utilisateurs se serviront de la fonctionnalité principale, un point d'entrée beaucoup plus simple peut tout aussi bien remplir cette fonction.
Une méthode efficace pour distinguer l'essentiel du superflu consiste à se demander ce qui se passerait si une fonctionnalité était absente pour les cent premiers utilisateurs. Souvent, la réponse est qu'une procédure manuelle, un e-mail ou une solution de contournement simple suffiraient temporairement, le temps que l'équipe évalue la viabilité de l'idée principale. Ce délai temporaire est généralement un compromis acceptable pour une première version plus rapide et moins coûteuse. Il est également important de définir à l'avance les enseignements que vous souhaitez tirer de cette première version, et pas seulement ce que vous souhaitez livrer. Les données d'utilisation, les retours directs et les points d'abandon sont d'autant plus significatifs si vous savez au préalable ce qui constitue un bon ou un mauvais signal. Sans cela, il est facile de concevoir la deuxième version en fonction des retours les plus insistants, plutôt que des éléments réellement importants. Développer le produit complet à terme n'est pas une erreur, et un bon MVP ne doit pas contraindre l'équipe sur le plan technique. L'erreur consiste à supposer que davantage de fonctionnalités au lancement augmentent les chances de succès. Dans la plupart des cas, une version plus modeste, déployée plus rapidement auprès des utilisateurs finaux, est plus instructive qu'une version plus importante dont le déploiement prend deux fois plus de temps.