Abandonnez vos idées préconçues et apprenez pourquoi les entreprises prospères embrassent le MVP comme une clé pour rendre leurs clients heureux.
Par Arbi Vartan et Jeff Brinkerhoff
Slalom aime Agile. Nous sommes enthousiasmés par les avantages réels et mesurables que nous avons vu les entreprises en tirer, et nous parlons de certains de ses plus grands avantages dans une série d’articles de blog et un webinaire Agile gratuit – à regarder à la demande.
Le MVP, ou produit minimum viable, est fondamental dans la pratique d’Agile. Et c’est aussi quelque chose qui génère de la résistance. Nous avons entendu nos clients dire des choses comme : » Nos cadres ne veulent pas le minimum – ils veulent la meilleure qualité possible. » En effet, pourquoi ne voudriez-vous pas faire de votre mieux ? C’est une excellente question, mais qui repose sur une mauvaise compréhension du MVP.
Créé par Frank Robinson en 2001, et popularisé par Eric Ries à travers son livre Lean Startup, le MVP est devenu un pilier des équipes produit performantes dans le monde entier. Pourquoi Google a-t-il été si dominant pendant si longtemps ? Pourquoi Apple fabrique-t-elle certains des produits les plus populaires au monde ? Pourquoi Netflix a non seulement survécu, mais a prospéré au-delà de son modèle économique initial ? De nombreux facteurs y ont contribué, mais le point commun est qu’ils utilisent tous le MVP.
Alors, qu’est-ce que le MVP ? Voici la définition d’Eric Ries : La version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissage validé sur les clients avec le moins d’effort.
Comme cette définition l’indique clairement, le MVP n’est pas un produit avec le moins de fonctionnalités possibles nécessaires à un lancement public. Il n’a rien à voir avec le lancement public d’un produit du tout. Au contraire, le MVP est la clé de l’utilisation de la méthode scientifique pour construire des produits. C’est purement un mécanisme d’apprentissage validé, utilisé pour tester des hypothèses et découvrir ce qui répondra aux besoins des clients.
Lâchez le terme si vous le devez-mais gardez le concept
A Slalom, nous avons intégré le concept du MVP à la fois dans la façon dont nous construisons des produits pour les entreprises et dans la façon dont nous nous associons avec elles pour récolter les bénéfices de l’incorporation des principes et pratiques Agiles dans leur modèle d’affaires. Cependant, après plus de vingt transformations Agiles d’entreprises et des centaines de partenariats dans différents secteurs, nous avons constaté qu’il est parfois plus simple de ne pas imposer l’utilisation de termes tels que le MVP. Certains ont opté pour le terme » Minimum Lovable Product « , et Henrik Kniberg (surtout connu pour son travail avec la culture d’ingénierie de Spotify) propose d’utiliser les termes Earliest Testable, Earliest Usable, et Earliest Lovable Products.
Tous ces termes sont bons. Agile concerne des équipes plus heureuses et plus productives – pas la terminologie. Notre approche de ce concept Agile ou de tout autre concept Agile mal interprété et peu clair est de sauter le mot et de poser les trois questions suivantes :
- Pourquoi le faire ? Dans le cas du MVP, il s’agit d’apprendre rapidement, ainsi que des principes sous-jacents : satisfaction du client, amélioration continue et simplicité.
- Que faudrait-il pour le faire dans mon entreprise ? Oh, le pouvoir du cadrage ! Au lieu de demander si vous pouvez le faire, nous nous concentrons sur les obstacles – organisationnels ou autres. La réponse à cette question prend souvent la forme d’une adhésion d’individus que l’on croyait inamovibles.
- Et si on ne le faisait pas ? Une autre stratégie de cadrage : se concentrer sur les coûts de la persévérance dans le statu quo. Cela peut créer un sentiment d’urgence et établir un alignement autour d’une nouvelle façon de travailler.
Voici une histoire sur les dangers du statu quo : Un projet pour une entreprise avec laquelle nous avons récemment travaillé impliquait de passer six mois sur une version majeure d’un logiciel ayant un impact sur plus de 200 utilisateurs internes. Ils se sont enfermés dans une pièce et ont terminé la construction et tous les tests. Et ce n’est qu’à ce moment-là qu’ils ont sollicité les commentaires d’une poignée d’analystes commerciaux par procuration, et non de véritables utilisateurs. Ce type d’activité, qui intervient trop tard pour avoir un impact réel et qui n’est pas véritablement axée sur l’apprentissage validé, peut difficilement être qualifié de sollicitation de commentaires. C’est vraiment une tentative de valider l’inévitable.
Le résultat était prévisible. Puisque tant de temps et d’argent avaient déjà été dépensés, ils se sont sentis obligés d’aller de l’avant, et les 200 utilisateurs ont tous rejeté le nouveau logiciel en raison de ses performances lentes et de son manque de convivialité. Six mois et plus de 12 millions de dollars dépensés, avec pour seul résultat un pointage du doigt entre les équipes commerciales et technologiques.
Imaginez maintenant ce même scénario avec un MVP déployé à un groupe d’utilisateurs finaux au début du projet. Les développeurs pourraient immédiatement apprendre ce qu’ils faisaient mal, puis déployer d’autres MVP en améliorant chacun d’entre eux de manière itérative jusqu’au déploiement d’un produit final-développé avec et approuvé par de vrais utilisateurs. Autre avantage : les utilisateurs du groupe de test seraient complètement investis dans le projet et l’évangéliseraient auprès de leurs pairs.
Nous avons vu exactement ce scénario se dérouler, et c’est pourquoi nous croyons si fermement au MVP – quel que soit le nom que vous choisissez de lui donner.