Le Minimum Loviable Product

Le Minimum Viable Product, MVP de son p’tit nom, est le premier lot de développement d’un produit, d’un service où d’une fonctionnalité, bien connu dans l’univers du Product Management & Product Design.

Le concept du MVP est génial : il permet de tester l’hypothèse d’une idée, ramenée à son stricte essentiel, afin d’en valider son potentiel. Il évite donc de développer une première solution trop complexe/trop coûteuse, sans être assuré de résultats positifs. Mais je trouve souvent difficile de savoir où placer le curseur de la première solution livrée; Dans un MVP, comment s’assurer que ce qu’on délivre est suffisant pour juger de l’efficacité de la solution ?

Aussi, la notion de MVP me pose souvent problème, en particulier lorsqu’il est défini à travers un prisme technique, et pas suffisamment sur la proposition de valeur pour l’utilisateur. Ce cas se rencontre beaucoup au sein d’orgas Produit, où les roadmaps débordent souvent de projets qui se suivent et s’enchainent, rythmées par des délais de Delivery et des jours alloués par projet. De l’idéation au développement, le MVP est trop souvent vu comme un réflexe : Que pourrions-nous sortir rapidement ?

Le MVP est déceptif

Le MVP est déceptif à plusieurs égards. En pensant MVP dès la phase d’idéation, puis en priorisant les idées, ce sont souvent les solutions les plus rapides d’implémentation qui sont retenues. Cependant, tant que la conception n’est pas définie et les développements pas débutés, ces estimations se font souvent au doigt mouillé. Combien d’idées ambitieuses sont trop souvent mises de côté, au profit de celles jugées plus facilement réalisables (et qui coûteront quand même 3 fois plus qu’estimé)?

En étant trop guidé par la rapidité de conception et de développement, acceptons-nous imperceptiblement de faire moins d’efforts pour moins de résultats ?

En phase de conception, le Product Designer travaille souvent de pair avec le Product Manager. Lors de cette phase, si le projet a manqué de cadrage, de nombreux cas d’usage éclosent et complexifient l’expérience : la conception du MVP prend alors une tournure d’un ambitieux chantier.

Aussi, si la Tech n’intervient pas suffisamment tôt dans le Design, il arrive alors que s’applique à nouveau un “filtre MVP” à la livraison des maquettes : on réduit alors le scope fonctionnel d’une solution déjà légère, et donc la qualité de la solution proposée aux utilisateurs.

Ensuite, parfois dans la douleur, souvent en retard, le MVP sort enfin. Les équipes passent à un nouveau sujet et l’itération sur le lot fraichement sorti ne sera alors plus prioritaire, et certains projets resteront ainsi longtemps figés à leur stade MVP. Au grand Damn des designers, mais surtout, des utilisateurs.

Mon constat dans tout ça : Le MVP doit être un outil utilisé dans un contexte dans lequel il a de l’intérêt : dans le cadre d’un POC ou en tant que première brique d’un plan bien dessiné. En dehors de ce cadre, il biaise et limite les efforts, et réduit notre capacité à atteindre nos objectifs. Comment pourrions-nous améliorer ça ?

Comment pourrions-nous garantir un premier lot satisfaisant ?

Dans le cadre de mon job de VP Design, dans une démarche de DesignOps et en m’intéressant à différentes méthodes, mon intérêt s’est porté sur la méthode Shape Up. Pour consulter le ebook de la méthode, c’est par là ♥️. À travers une démarche apportant un cadre et une cadence à la conception, la méthode Shape Up repose sur 3 grands principes :

• L’étude du projet : Les contours du projet sont dessinés et scopés en amont, à travers des objectifs, des contraintes et une esquisse de concept.
• La priorisation : Les projets étudiés sont régulièrement repriorisés. Pour chaque projet sélectionné, un temps de conception et développement est défini à travers un appétit. Plus la notion d’appétit est grande, plus le projet est important et sa durée sera longue.
• Le développement d’une solution sur un temps donné. Une équipe pluridisciplinaire est autonome pour concevoir et développer une solution sur un sprint de 2 ou 6 semaines.

Le cadre & le temps

Cette lecture m’a inspiré ! J’ai trouvé cette méthode intéressante pour optimiser nos phases de Conception et Delivery. J’y ai pioché 2 choses intéressantes :

• De mieux cadrer un projet, en amont de la conception : on évite de découvrir des problématiques pendant la conception = on gagne du temps.
• De définir le temps que nous voulons engagé sur un projet, en sortant de la logique de quantité de jours disponibles, et en se questionnant sur la quantité nécessaire pour atteindre nos objectifs. En identifiant mieux les critères que nous désirons pour un premier lot, on gagne en qualité de solution. On accepte ici de se donner plus d’ambition donc d’effort de développement; finalement, est-ce vraiment plus long qu’un projet dont des deadlines sont courtes mais peu fiables et qui entrainent habituellement des retards au planning ?

Je tente l’hypothèse que chaque projet n’a pas à être pensé MVP, mais première version délivrée à travers un Minimum Lovable Product. La nuance réside dans le fait que certains projets connaitront des itérations rapides, et d’autres beaucoup moins, d’où l’importance de délivrer de la qualité en une fois.

Le Minimum Lovable Product

On pourra identifier comme candidat au Minimum Lovable Product un sujet sur lequel nous avons de forts enjeux de résultats et peu de capacité à itérer dessus dans un futur moyen terme. Sur les MLP, on augmente nos efforts de Delivery et les standards du lot développé.

Pour un projet de conception sur lequel un MLP est attendu, il démarrera par une phase de cadrage, qui aura pour objectif de définir toutes les étapes nécessaires à la phase de conception. L’objectif ici est de mener les workshops d’idéation nécessaires pour décider d’une solution sur laquelle partir en conception. Suite à ça, une phase d’études (utilisateurs, produit, business, tech) est menée pour identifier les contraintes, soulever les problématiques et dessiner les contours de la solution.

• Quels sont les objectifs ?
• Quelle est l’étendue du parcours ?
• Qu’est ce qui est attendu ?
• Qu’est ce qui n’est pas attendu ?
• Quels sont les différents scénarios ?
• Quels sont nos enjeux et nos contraintes ?
• Quelles sont nos inconnues ?

À l’issue de cette phase, nous obtenons : un document de cadrage, un croquis de vision et de solution, des objectifs clairs et une estimation Design et Tech.

Design x Product x Tech = ♥️

Il est désormais temps de concevoir et développer la solution dans le respect des estimations effectuées. Pour cela, une squad est composée du Design, de la Tech, du Produit et d’autres référents métiers (Business, Marketing, UXR) nécessitant une contribution. Cette équipe vit le temps de la conception du projet et a pour objectif de développer une solution satisfaisante dans le temps qui lui est imparti, en totale autonomie, tant qu’elle atteint les objectifs fixés.

Deux secrets de réussite selon moi : la collaboration de l’équipe et la qualité de la méthode utilisée ♥️. Parmi celles que j’ai testées, voici celles que j’ai trouvées efficaces :

• La méthode FOCUSED : je trouve l’approche Discovery Discipline intéressante à appliquer sur un projet lorsqu’une phase de Discovery spécifique doit être menée avant la conception. Bien planifiée, elle apporte un cadre, des livrables activables et une conception garantie utilisateur.
• Le Design Sprint : S’inspirer des 3 premiers jours du Sprint de Knapp pour aligner les équipes sur une problématique complexe et favoriser la résolution et la co-conception rapide.
• La méthode RITE : Sur une semaine, la première solution prototypée est testée et corrigée à chaque problème d’utilisabilité rencontré. Tester 2 fois, corriger, re-tester, corriger … Cette méthode permet d’aller vite dans l’amélioration de la solution et un Delivery plus rapide.
• La stratégie Design, de manière générale ! Je trouve nécessaire d’identifier et d’estimer la meilleure stratégie à adopter, dans une logique d’efficacité et de respect d’une conception centrée utilisateur.

Une fois conçu, testé et ajusté, le prototype part alors en Delivery. Et grâce à l’implication de la Tech à travers toute la phase de conception, l’alignement est (quasi) total. Les user stories sont mappées, traduites, et priorisées dans un backlog : les développements peuvent commencer ! Encore mieux, ils peuvent parfois débuter avant la fin de la conception tant la vision de la solution est claire. Le cadrage et la conception collaborative permettent un respect des estimations prévues et le premier lot délivre une expérience satisfaisante.

Les avantages de dédier plus de temps à la conception d’un projet permettent le développement d’une solution de meilleure qualité et ainsi d’obtenir de meilleurs résultats. Les équipes prennent également plus de plaisir lors de la conception, et sont plus fières de la solution proposée. Tout benef’ quoi 🫶

En conclusion

Le portrait du MVP dressé plus haut n’est pas glorieux, mais le MVP, je l’aime quand même. Je le trouve puissant lorsqu’il est utilisé à bon escient : Dans le cadre d’un POC pour valider la viabilité d’un business, ou bien en tant que première brique d’un projet plus ambitieux. Sur les autres cas, je trouve que la mauvaise habitude du MVP freine fortement les ambitions, moyens et les résultats fixés et obtenus. C’est en diversifiant les approches vis à vis de nos projets que nous changerons ces réflexes. Je pense que le Minimum Lovable Product doit trouver sa place dans la boite à outils du Product Management & Product Design. Bien utilisé, il permettra d’investir dans des solutions pérennes et qualitatives.

Cependant, tout est toujours une question de curseur, et s’il faut garder une chose de cet article, tout dépend toujours du contexte, toujours jongler avec les contraintes et toujours garder le cap de délivrer le maximum de valeur pour l’utilisateur ✨ ! (#pioupioupaillettes 🦄)

☕️ N’hésitez pas à me contacter si vous voulez échanger sur le sujet.

Suivez UX Moustaches sur Instagram pour plus de contenus sur l’UX et le Produit !