Lors de mes missions dans les DSI, j’ai souvent entendu parler de MVP, alors qu’en fin de de compte, il s’agissait de donner un peu du cachet agile à un terme qui n’est plus à la mode : le bon vieux Lot.

Ici, je tente de clarifier ce qu’est un MVP.

Le MVP (Minimal Viable Product) se concentre sur l’apprentissage

Traduction française : Produit Viable Minimal

Expérimenter au plus près du client, apprendre et valider ou pivoter… au plus bas coût possible

Source : Ash Maurya, LeanStack

Dans son livre “Lean Startup”, Eric Ries définit le MVP comme suit :

« Le Minimal Viable Product est cette version du produit qui permet d’effectuer un cycle complet de la boucle Construit-Mesure-Apprend avec la quantité minimum d’effort et le moins de temps de développement possible ».

Par la “boucle Construit-Mesure-Apprend », l’auteur veut dire que ce sont les données recueillies de manière empirique, au contact du client, qui vont valider (ou non) qu’une idée, supposée bonne, l’est effectivement.

La principale raison d’être des MVPs est d’apprendre le plus directement possible du client si ce que l’on pense avoir de la valeur, en a effectivement… pour lui. Il ne s’agit pas nécessairement de lui délivrer cette valeur (ce que ferait la future livraison de produit).

Pour compléter l’explication de la raison d’être du MVP, Eric Ries écrit plus loin :

« Contrairement à un prototype ou à un test de concept, un MVP est conçu non pas seulement pour répondre à des questions de design produit ou à des problématiques techniques, mais surtout et avant tout tester des hypothèses business fondamentales*. »

*Par « hypothèses business fondamentales », l’auteur veut dire : les hypothèses de viabilité marketing et fonctionnelle faites sur le client.

D’une définition plus générale vers une définition plus stricte du MVP

Dans son excellent article What is a Minimum Viable Product (MVP), Ash Maurya, auteur de « Running Lean », restreint la définition du MVP et en crée une plus stricte, qui apporte des clarifications bien utiles.

A l’origine, stricto sensu, le MVP n’est pas forcément un produit développé, ni même un Proof Of Concept (POC)

Si l’on suit la définition d’Eric Ries présentée plus haut, le MVP pourrait ne pas être un produit du tout, ni une application développée. Il peut s’agir :

• d’un entretien client
• d’une démonstration (de fonctionnalités, mais avec ou non un produit fonctionnel)
• d’une teaser page (présente le produit pour capturer l’éventuel intérêt)
• d’un smoke test

Pour donner un exemple de smoke test, dans « Lean Startup », l’auteur donne l’exemple de DropBox, pour lequel le premier MVP fut une vidéo de démonstration technologique de trois minutes destinée aux early adopters. La construction de la vidéo a permis de mesurer une augmentation de la liste d’attente de la beta du produit de 5000 personnes à 75000 personnes quasiment du jour au lendemain.

Cela leur a permis d’apprendre qu’il y avait un véritable intérêt pour l’idée et le produit tels qu’ils étaient présentés.

Ainsi, cette vidéo a permis d’effectuer un cycle complet de la boucle Construit-Mesure-Apprend.

Le smoke test original de Dropbox

Une définition plus stricte du MVP, en en faisant un produit utilisable (mais toujours dans un but de test d’hypothèses)

Dans son article mentionné plus haut, Ash Maurya propose la définition suivante :

Un Minimum Viable Product est la plus petite chose que vous pouvez construire, qui délivre de la valeur client (et qui, comme bonus, capture une partie de cette valeur en retour).

Délivrer de la valeur, c’est délivrer un service… Et donc créer une fonctionnalité produit qui rend effectivement ce service. Et face à ce service rendu, on peut commencer à s’attendre à un revenu en retour (direct ou indirect).

Source : Ash Maurya, LeanStack, avec modification (Release 0.1)

Le MVP est d’abord adressé aux early adopters, puis à la masse par l’A/B testing ou approche similaire

Le MVP s’adresse a différents types de clients, à différents stades, dans le but principal d’obtenir des données réelles de terrain, voire des retours sur la viabilité potentielle d’une hypothèse du produit.

• Au tout début du développement du produit aux early adopters, à qui il sera présenté directement.
• Lorsque le produit est au moins en partie livré aux utilisateurs, à un sous-groupe de clients au travers de techniques comme l’A/B testing.

Cela permet de décider rapidement et à coût minimal s’il faut persister avec l’hypothèse ou pivoter.

Le MVP n’est pas destiné à être un produit complet livrable

La tentation est forte de donner une apparence agile à des pratiques qui finalement ne changent pas, mais le plus important, c’est que la valeur qu’apporte l’approche MVP en est incomprise et diluée.

Le MVP a pour but d’apprendre en livrant une valeur hypothétique et incrémentale. Cet apport de valeur ne sera validé que par des données obtenues suite à l’utilisation du produit. Si elle est validée, on mettra la fonctionnalité définitivement dans le produit. Si elle n’est pas validée, on la retirera.

C’est un incrément, pas un lot, ni une version finale d’un produit.

Cela ne veut cependant pas dire que la qualité du développement doit être compromise !!! Ce n’est pas un POC qui part en Prod ! C’est un développement le plus simple possible qui part en Prod pour vérifier la valeur de l’idée.