Le MVP : appropriation vs approximation
Le fameux MVP (Minimum Viable Product), popularisé par Eric Ries en 2009, qu’en est-il aujourd’hui ? Dominique HAK et Kim DANG, PO chez Néosoft vous proposent leurs retours…
Encore un article au sujet du MVP ?!
Pourquoi avons-nous choisi de vous en proposer un énième à ce sujet ? Outre le fait que c’est une notion clé du livre “The Lean Startup” d’Eric Ries, nous sommes convaincus que dans certains contextes ce terme peut être galvaudé, réduisant ainsi considérablement sa capacité à limiter le risque.
Donc avant de nous lancer dans l’examen approfondi du MVP et de sa raison d’être, nous vous proposons de revenir à la définition de base : Qu’est-ce que le MVP selon Eric Ries ?
“Le MVP est la version du produit qui permet de parcourir complètement la boucle Construire-Mesurer-Apprendre avec un minimum d’effort et le développement le plus rapide”
Bref, le MVP, c’est la version minimale de notre produit, qui permet de tester une hypothèse business fondamentale à travers les retours des utilisateurs que ce dernier aura générés. On donne à voir l’ensemble des fonctionnalités essentielles, ce qui permet notamment de répondre à la question que se posent la plupart des entrepreneurs : “Mon problème vaut-il la peine d’être résolu ?”
“M” : une lettre soumise à interprétation…
D’ailleurs, lorsque l’on parle de “version minimale de notre produit”, qu’entend-on par “minimal” ? S’agit-il du minimum de fonctionnalités ? d’exigences ? de contraintes ? En pratique, l’étude “MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product” menée par Valentina Lenarduzzi et Davide Taibi montre que la définition de “minimum” du MVP peut être comprise différement en fonction des contextes. L’étude relève pas moins de cinq interprétations différentes :
Minimum au sens de…
… Fonctionnalités
- permettre au produit d’être déployé
- cibler les opportunités de marché
- créer un produit viable pour le client
- tester l’hypothèse business fondamentale
- permettre de tester le produit dans le marché
- identifier la fonctionnalité la plus viable à travers une expérimentation itérative du marché
… Exigences
- répondre aux besoins des “early adopters”
… Plus petite implémentation possible
- inciter les clients à fournir des feedbacks et recommander le produit
- apporter de la valeur aux clients
… Minimum d’effort
- collecter un maximum d’enseignements au sujet des clients
- tester l’hypothèse business fondamentale
- développer un produit qui inclut juste suffisamment de fonctionnalités pour permettre de collecter des retours des “early adopters”
- collecter des retours des utilisateurs
… Organisation de valeur minimum
- accélérer les ventes aux premiers utilisateurs
Initialement, c’est bien la version “minimum d’effort” qui était promue – non seulement au sens de la difficulté, du travail, mais également au sens économique – car elle permet de maximiser l’apprentissage grâce aux retours des utilisateurs : on souhaite être fixé sur la validité de notre problème avant d’avoir trop investi dans sa résolution. Attention cependant : le MVP se veut “minimaliste”, pas bâclé ni défectueux. Pour qu’il remplisse pleinement sa fonction, il devra incarner la solution à un besoin hypothétique ; solution dont on devra pouvoir mesurer l’impact. Cela demande une grande maturité dans la réflexion.
Et le prototype dans tout cela ?
Selon l’OCDE, un prototype est un modèle original qui possède toutes les qualités techniques et toutes les caractéristiques de fonctionnement du nouveau produit. Toutefois, à la différence du MVP (qui a pour objectif de valider une hypothèse fondamentale business : “Mon problème vaut-il la peine d’être résolu ?”) le prototype a pour objectif de vérifier la faisabilité technique : “Mon produit est-il réalisable ?” Dans certaines entreprises, le prototype est plutôt appelé Proof Of Concept ou POC.
… qui ne doit pas éclipser les autres !
Le MVP au sens d’Eric Ries devrait donc être un artefact assez rare. On le rencontrera au lancement d’un produit disruptif ou alors lors de changements majeurs de type “pivot”… Et pourtant, on a souvent vu des équipes utiliser ce terme ; parfois même pour désigner autre chose qu’un produit : ”C’est le MVP de la fonctionnalité”, “Fais-moi un rapport d’utilisation, niveau MVP”, etc. Si c’est aussi votre cas, il ne faut pas s’en offusquer. C’est plutôt un signe de bonne santé de votre façon de travailler : on veut avancer pas à pas, de manière itérative et incrémentale sur les sujets.
On sent donc bien un besoin de décliner le concept derrière le MVP, mais pour d’autres granularités que le produit, et à d’autres niveaux d’aboutissement que le V de “Viable”. “Et bien ça existe (et même depuis longtemps) !” nous diront les mieux renseignés. Pour les autres, laissez-nous enrichir votre vocabulaire d’une ribambelle de nouveaux mots qui forment ce que l’on appellera la galaxie des “artefacts minimalistes”, décrits par exemple dans cet article, dont on a extrait le graphique suivant :
Pour les autres, laissez-nous enrichir votre vocabulaire d’une ribambelle de nouveaux mots qui forment ce que l’on appellera la galaxie des “artefacts minimalistes”, décrits par exemple dans cet article, dont on a extrait le graphique suivant :
“Est-ce que c’est important d’utiliser le bon terme ?”
C’est une question qui a aussi fait débat chez nous. Tout le monde s’accorde à dire que le but est d’éviter les incompréhensions entre les différentes parties prenantes quant aux promesses du livrable et aux moyens engagés. Ceci dit, un changement de vocabulaire permet certainement d’impulser et de faciliter un changement de comportement. C’est la raison pour laquelle Scrum a pris le terme “Sprint” par exemple, et pas “itération” : pour que les équipes qui travaillaient déjà de manière itérative, mais pas en Scrum, soient rappelées qu’il existe des différences. Ainsi, utiliser “MMP” à la place de “MVP” peut encourager tout le monde à apprécier la différence de maturité attendue entre les deux : ils sont “minimalistes”, mais ce terme n’a pas la même signification selon que l’on veuille qu’il soit plutôt “viable” ou “marketable”…
Résumons :
Historiquement, la priorité était de faire accepter le concept même d’itération et de frugalité : soit le M de Minimum. Aujourd’hui, il peut être intéressant de laisser les autres membres de la famille minimaliste prendre la place qu’ils méritent afin de qualifier un peu plus ce minimum :
- Dans quel but ? C’est la deuxième lettre du triptyque utilisé : “viable”, “marketable”, “lovable”, etc.
- Sur quel artefact ? C’est la troisième lettre : “product”, “feature”, “release”, etc.
À défaut d’une pause, un exemple s’impose
Vous êtes à la division produit de chez McDonald’s. Vous vous demandez si un McSushi serait une bonne idée… Quelles peuvent-être les étapes clés ?
MVP
On décide de partir sur un MVP de type “Smoke Testing” ou “prétotype” : on met à jour les bornes de commande dans certains restaurants (pour avoir une couverture géographique par exemple) afin qu’elles proposent nos sandwichs à la commande. On peut imaginer faire varier les prix, et décliner le McSushi sous différents formats : saumon/thon/california. Si le client commande, on lui indique simplement que le sandwich est en rupture de stock et on l’encourage à faire un autre choix…
Au bout de l’expérimentation, on a validé (ou pas) que c’est “viable” dans la mesure où les hypothèses pour que ce produit trouve son marché sont maintenant confirmées : la demande, la composition du sandwich (grâce au visuel), et le prix. C’est “minimum” : on n’a même pas de produit !
MMP
Devant le succès de mon MVP, je veux avancer d’un pas et capturer au moins une part du marché que je vise avec mon produit. On peut imaginer ne lancer que le McSushi “Saumon”, le plus populaire, dans un nombre restreint de restaurants, ou une zone où l’approvisionnement est plus simple par exemple… Chaque sandwich commandé serait fait à la commande, sur place, dans une annexe mobile du restaurant (food truck, container aménagé, etc.). C’est “marketable” : on essaie de tendre vers quelque chose de durable, rentable, avec un produit tangible consommé par une catégorie ou sous-catégorie de ma clientèle visée. C’est “minimum” : on s’est concentrés sur comment mettre le sandwich dans les mains de consommateurs avec une logistique la plus rapide possible à mettre en place.
MMR
Les résultats du MMP sont encourageants. J’ai plein d’options pour le MMR suivant : ajouter les autres types de McSushi qui auront l’air prometteur, étendre l’offre à plus de restaurants, ou plus probablement industrialiser le cycle de production du sandwich. Cela doit rester “minimaliste” : dans l’idéal et pour des raisons de time-to-market, mon but est de faire une release cohérente à chaque fois qu’un de ces besoins précis est prêt.
Chercher le poids de forme de son livrable
Dans cette démarche de mettre le juste effort pour valider notre l’hypothèse business sous-jacente au livrable, nous avons été confrontés à deux types d’écueils :
- Le premier est le cas où l’impression d’un manque de qualité détourne l’utilisateur de notre produit. “Ah c’est moche, il ne me fait pas envie”. Du fait de cette impression, l’utilisateur n’est pas attiré par le produit qui aurait pu être une solution à son problème. Ce qui ne permet pas de répondre à notre question business fondamentale.
- Le second cas, plus répandu dans les entreprises ayant pignon sur rue, consiste en un manque de frugalité dans la conception du produit. Par peur que les clients soient réticents à payer pour ce dernier ou qu’il puisse endommager l’image de marque de l’entreprise, on a tendance à enrichir le produit avec les fonctionnalités qui ne seraient pas – de prime abord – indispensables, allongeant ainsi le cycle Build-Measure-Learn. Ceci a pour conséquence d’augmenter le coût de réalisation et de retarder la récupération des feedbacks, augmentant ainsi le risque. De plus, la multitude de fonctionnalités rend plus difficile l’interprétation des retours de clients, ce qui nuit à valider notre hypothèse business fondamentale.
Dangers que l’on peut illustrer comme suit :
En conclusion
À l’origine désignant un livrable tangible, on a l’impression que le terme “MVP” est devenu un adjectif “magique” facilitant la gestion de l’incertitude en regroupant plusieurs vertus : frugalité, empirisme, construction itérative, fail-to-learn… Accolez “MVP” en tant que qualitatif à quelque chose (exemple : “On rédige un MVP de l’article et on verra.”) et tout le monde comprend qu’il y a une part d’inconnu associée à cette entreprise, mais qu’au lieu d’être source de stress et d’immobilisme, on veut au contraire aller à sa découverte, avec une prise de risque raisonnable. Cependant, l’utiliser en ce sens large et dérivé peut être très trompeur sur le niveau de frugalité attendu derrière le terme “minimum”. Une façon de faire est de partager un vocabulaire commun grâce à cette nouvelle galaxie d’artefacts “minimalistes”. De la même façon que les équipes Scrum énoncent clairement leur Definition of Done ; pourquoi ne pas enrichir votre vocabulaire avec ces artefacts minimalistes et avoir pour chacun d’eux une “Définition of minimum” ? Car comme on le dit :
- “Shipping beats perfection…” : vous voulez poser vos questions au marché rapidement.
- “… Until it does not” : tout en suivant l’augmentation naturelle des attentes suscitées par votre produit.