Désolé pour ceux qui pensaient que cet article parlerait de LeBron James, je vais aborder un sujet qui me tient à cœur professionnellement et, malheureusement pour mon compte en banque, je ne suis pas joueur de basket, mais Product Owner.

Je travaille pour une société de conseil (Ippon Technologies) et nous développons des produits numériques pour différentes entreprises. Beaucoup d’entre elles viennent nous consulter avec des idées de produit et en demandant le développement d’un MVP parce qu’elles s’attendent à un produit rapidement en production. Hélas, le périmètre du MVP n’est pas toujours à la hauteur de leurs attentes initiales (la plupart ne sachant pas exactement ce qui se cache derrière le terme MVP) et cela amène à des situations de frustration.

À travers cet article, je souhaite partager avec vous, en quelques minutes, ma vision de ce qu’est un MVP pour clarifier ce concept et éviter les futures incompréhensions.

Le MVP “by the book”

Pour commencer, d’où vient le terme “MVP” ? “MVP” signifie “Minimum Viable Product”. Il a été popularisé par la méthodologie Lean Startup qui le définit comme quelque chose qui “permet à une équipe de récolter un maximum d’apprentissages validés à propos de ses clients en un minimum d’effort.”

Derrière le MVP se cache l’idée de mettre en place une solution, la plus minimale possible (donc pas toujours codée) et mesurer son impact sur les utilisateurs dans le but d’apprendre à propos de sa proposition de valeur, soit en validant l’impact (et donc en continuant à investir), soit en ajustant, soit en pivotant (en revoyant la proposition de valeur). Cette décision, basée sur des données, aide à réduire le risque (et donc le coût) de développer un produit qui ne sera pas utilisé.

Un MVP = une fonctionnalité

“M” comme “Minimum”. La tâche la plus difficile concernant la conception d’un MVP est de définir jusqu’où il est possible d’aller dans la réduction du produit à son minimum. À chaque réduction, si le produit continue à résoudre la problématique pour un type d’utilisateur, alors on peut continuer à essayer de réduire.

Le choix de la fonctionnalité à développer en priorité doit être basé sur des critères d’importance (par rapport à la proposition de valeur) et d’incertitude.

Potentiellement, un MVP peut être abandonné, il faut donc le développer le plus rapidement possible et bien adapter le périmètre et la qualité associée au niveau minimal requis.

Pour comprendre jusqu’où il est possible d’aller, prenons le fameux exemple de Dropbox.

Avant de commencer le développement de la plateforme, Dropbox a publié une vidéo sur Youtube expliquant leur produit, tout en ajoutant un lien en dessous de la vidéo pour ceux intéressés par le service. Pas une ligne de code, juste une vidéo : le moyen le plus simple pour eux de vérifier que des personnes étaient intéressées par ce service, en étant prêt à payer pour cela.
C’est seulement quand ils ont pu confirmer qu’il y avait un attrait du public, qu’ils commencèrent à coder leur service. Quel bénéfice tirer de cette approche ? S’ils avaient commencé à coder et qu’ils s’étaient rendus compte que personne n’était intéressé, alors ils auraient perdu beaucoup plus d’argent et de temps qu’en créant une courte vidéo expliquant leur concept.

L’exemple de Dropbox divise car certains n’y voient pas la notion de version initiale du produit (le “P” de “MVP”). On parle de MVP dans le cas de Dropbox puisqu’on met à disposition de potentiels prospects une présentation (vidéo) du produit et un moyen de valider qu’il y a une attente forte de ces prospects (landing page).

Contrairement à Dropbox, la plupart des MVPs sont bien plus qu’une simple landing page d’un site et une vidéo : ils sont la première pièce du produit final, mais cette première version doit être développée facilement et rapidement. Une technique pour accélérer le développement est celle du “Magicien d’Oz”, consistant à effectuer manuellement des actions qui seront à terme automatisées. Je vous renvoie à l’exemple de Zappos pour avoir plus d’informations sur ce sujet.

Quelques fonctionnalités obligatoires pour une version finale peuvent être absentes (ou réduites) pour un MVP. Avez-vous réellement besoin d’une fonctionnalité de connexion pour valider votre proposition de valeur ? Avez-vous réellement besoin d’automatiser des tâches qui peuvent être faites manuellement ? Avez-vous besoin d’être compatible avec tous les types d’appareils/écrans ? Ce qui est nécessaire pour un MVP (conçu pour adresser des “early adopters”) n’est pas le même que celui pour une première version complète adressant une audience plus large. Souvenez-vous, le premier iPhone n’avait pas de fonction copier-coller. Est-ce que cela a empêché l’iPhone de devenir un succès ?

Procéder à cette réduction de périmètre n’est pas évidente pour le client et s’avère compliquée à comprendre pour ceux ne maîtrisant pas le concept de “Test and Learn” et de développement itératif et incrémental.

Valider l’impact

“V” comme “Viable”. Un MVP est utile pour valider la pertinence d’un produit, donc il est important de savoir quel est le retour sur investissement attendu (ROI). Cela peut être de générer des revenus, aider dans la promotion d’un produit ou d’un service, réduire des coûts ou améliorer l’image de marque.

Les bons produits sont conçus pour avoir un impact positif sur leurs utilisateurs. Le “MVP” est la première étape pour analyser l’impact du produit sur son audience cible. La définition des fonctionnalités d’un MVP doit être liée aux KPIs associés à la vérification de cet impact. Si on revient à l’exemple de Dropbox, le ROI est basé sur la génération de revenus. L’idée du MVP n’était pas seulement de savoir si les gens étaient intéressés par l’utilisation du service, mais surtout s’ils étaient prêts à payer pour cela. Avoir un KPI indiquant que les gens étaient intéressés et un autre indiquant qu’ils n’étaient pas prêts à payer aurait potentiellement pousser Dropbox, non pas à abandonner son projet, mais à repenser son business model.

Transformer un “Minimum Viable Product” en “Most Valuable Product” est facilité par l’adoption d’une approche scientifique basée sur l’observation des comportements des utilisateurs et la validation systématique des impacts au travers de la récolte de données d’usage.

C’est un Produit

“P” comme “Product”. Un MVP doit être une version minimale du produit permettant de valider qu’il répond à un besoin méritant d’être résolu. Cela peut être juste une “landing page” expliquant la proposition de valeur ou un peu plus. Le MVP peut aussi être une version manuelle du futur produit offrant le service (cf la technique du magicien d’Oz vue précédemment) ayant comme unique but de valider l’attraction du service pour une population donnée.

On pourrait dire qu’une maquette ou une démonstration peuvent faire le même travail de validation, mais un MVP est livré en production et visible d’une population plus importante (mais pas trop), dans le but de valider s’il commence à résoudre les problèmes de cette population. Doit-il être accessible par le plus grand nombre ? Cela dépend du contexte, mais il est préférable de se limiter, dans un premier temps, à une audience de “early adopters” qui pourraient être intéressés par la proposition de valeur.
Le produit est alors une “beta version”, il faut donc faire attention à l’image du produit (et de la marque).

Conclusion

Alors que le but d’un POC (Proof of Concept) est de dérisquer la faisabilité technique d’un produit, le but d’un MVP est de dérisquer la problématique business la plus critique de ce produit, et à moindre frais.

Souvent, les incompréhensions reposent sur la définition de “Minimum”. Notre responsabilité en tant que Product Owner/Manager est de réduire autant que possible le périmètre du produit pour récupérer du feedback le plus tôt possible, et en tirer les enseignements conséquents. Penser simple et accepter que tous les cas ne seront pas traités n’est pas toujours facile à faire entendre au client, mais c’est primordial dans la démarche.

Avant de parler de MVP, il faut que tout le monde comprenne en quoi consiste un développement itératif et incrémental. Un MVP est juste une première étape menant à un produit à succès, et il faut être clair avec les parties prenantes sur ce qui va être développé et pourquoi, dans un premier temps, “seulement” ça.