POC vs. MVP : nous ne serons pas d'accord

De manière surprenante, le sujet est passionnel, voire polémique. Mais, avant de rentrer dans le vif du sujet, actons si vous le voulez bien notre accord sur une chose : le caractère minimal du MVP. L'idée est d'aller en production rapidement pour itérer — l'essence-même de l'agilité.

D'où mon heuristique personnelle : si vous pensez que votre MVP est trop petit, c'est qu'il est encore trop gros. Reid Hoffman, cofondateur de LinkedIn, formulait la même idée en ces termes : "If you’re not embarrassed by the first version of your product, you've launched too late." Difficile de lui donner tort.

Cela dit, je constate une confusion quasi systématique entre POC et MVP. Clarifions les choses, et pour ce faire, comme souvent, il suffit d'écouter les mots.

Un Proof of Concept est, en bon français, un démonstrateur. Son but est de répondre à une question, qu'elle soit d'ordre technique ou marketing. En d'autres termes : vérifier qu'il y a de la "traction marché". Apporter des réponses, donc, valider une idée, qu'il s'agisse de vous convaincre de passer plus de temps sur le sujet ou de convaincre des investisseurs de vous suivre. Il est fréquent de faire plusieurs POCs au cours de la vie d'un produit.

Le POC, c'est le quick & dirty assumé : en faire le moins possible pour obtenir le maximum de réponses. Si des maquettes suffisent pour obtenir du feedback, go for it! Vous auriez tort de vous en priver. Le No Code a lui aussi toute sa place dans un POC. Et s'il faut produire du code, c'est bien la seule fois où je vous dirai de "penser jetable". Encore une fois, le but est d'obtenir des réponses, pas de constituer un actif pour votre entreprise. On ne construit pas sur un POC, on le jette. Il faut donc aller vite : quelques jours, 1 ou 2 semaines maximum. Au-delà, c'est déjà trop.

L'objectif du Minimum Viable Product est tout autre : il vise à acquérir des utilisateurs. Pour cela, votre produit doit aider ses utilisateurs à réaliser un Job To Be Done minimal. Dit autrement, le MVP doit rendre un service qui, à lui seul, justifie l'adoption du produit, voire surpasse le coût du changement si l'utilisateur utilisait préalablement un service concurrent (un MVP est donc par essence contextuel : il dépend de la concurrence).

La philosophie du MVP est donc d'en faire peu, mais très bien. On est en production, ce qui implique de la robustesse. Votre produit doit être production ready : une parfaite gestion de la sécurité, des erreurs, des logs, de la redondance, des sauvegardes, du monitoring, etc. L'idée est de fidéliser vos utilisateurs par un service non seulement utile, mais de surcroît agréable. Certains parlent d'ailleurs de Minimum Lovable Product. Par conséquent, construire un MVP requiert des mois de travail avec une vraie équipe et le financement adéquat.

Une bonne pratique consiste à concevoir le plus tôt possible un Walking Skeleton , c'est-à-dire des fondations techniques en matière de modularité, d'architecture, de test, de sécurité, d'opérations (CI/CD) etc. Cette étape est cruciale pour limiter la dette technique  et maintenir la capacité à produire vite sur le long terme. N'oubliez pas en effet que le MVP n'est qu'un point de départ, une base sur laquelle vous allez itérer.

Vous ne mettrez peut-être pas les mêmes mots sur ces étapes qui jalonnent la vie d'un produit : 1. Valider une idée et 2. Acquérir des utilisateurs. Il n'empêche que ce sont des objectifs bien distincts et qu'il vous coûtera cher de les confondre.

Posez-vous donc la bonne question : qu'êtes-vous en train de construire ?