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 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 :

Règles 1, 2 & 3 du MVP
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.

POC

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, plus souvent, marketing. En d'autres termes : vérifier qu'il y a de la "traction". Apporter des réponses, donc, valider une idée, qu'il s'agisse de vous convaincre de consacrer plus de temps sur le sujet ou de convaincre de potentiels 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. 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.

MVP

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 ainsi d'en faire peu, mais très bien. On est en production, ce qui implique de la robustesse (application "production ready") : une parfaite gestion des erreurs, des logs, de la redondance, des sauvegardes, du monitoring et bien sûr de la sécurité. L'idée est de fidéliser vos utilisateurs par un service non seulement utile, mais de surcroît agréable (Minimum "Lovable" Product, diront certains). Le MVP, c'est des mois de travail avec une vraie équipe et le financement adéquat.

Et il faut bien sûr pouvoir itérer dessus : apporter fréquemment de la valeur, tenir la cadence. Le MVP repose donc sur des fondations techniques très solides, la qualité de code (lisibilité, modularité, tests…) et l'outillage de développement (CI/CD) "qui va bien". Autant dire que du no-code y a rarement sa place…

Conclusion

Vous ne mettrez peut-être pas les mêmes mots sur ces 2 objectifs : valider une idée et acquérir des utilisateurs. Il n'empêche que ce sont des objectifs bien distincts et souvent confondus.

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