Après plusieurs années d’égarement dans la conception produit, je pense avoir enfin trouvé un modèle de développement de produit qui répond aux problématiques de l’approche MVP que la plupart des entreprises digitales utilisent au quotidien : le Minimum Lovable Product.

Le charme initial du MVP

La plupart des entreprises digitales utilisent la méthodologie lean, voire le lean UX côté design, pour gagner en vitesse et en qualité lors des phases de développement du produit.

C’est un modèle incroyable car il fonctionne qu’importe le secteur (bancaire, santé, social, etc.), qu’importe la taille de l’entreprise (grand compte ou petite startup) et qu’importe le public visé (B2B ou B2C) mais surtout il permet d’aligner l’ensemble des collaborateurs du projet sur une manière de travailler productive.

Pour le résumer simplement, l’approche MVP (The Lean Startup, Eric Ries) permet de mettre en production rapidement un produit afin de valider son potentiel auprès des utilisateurs ciblés. Cela évite donc le risque de créer un produit peu utilisé et donc limite le gaspillage de ressources, temps, argent, etc.

La conception itérative implique une priorisation des fonctionnalités et un découpage minutieux de la roadmap dans le temps selon 3 principes :

• la faisabilité : ce qu’il est possible de faire
• la viabilité business/métier : ce qui va apporter de la valeur au business et/ou au métier (surtout dans le cas des entreprises B2B)
• la désirabilité : ce que veulent les utilisateurs

Cette méthode permet d’avoir une vue 360º lorsqu’on priorise les fonctionnalités et de s’assurer que l’on prend en compte tous les enjeux clés du produit.

‍

‍

Pour autant, le modèle trouve rapidement ses limites, en effet, qui parvient réellement à mettre en production un MVP dont il/elle est fier et qui permet de valider les hypothèses établies ? Ne ressort-on pas toujours frustré de ce qui a été développé ?

Les tourmenteurs du MVP (et du MLP)

Toute conception de produit a ses contraintes qui influent sur les choix que nous faisons dans la priorisation de notre produit. Savoir gérer et anticiper ces contraintes est clé dans le succès du projet :

• Le temps.
• Élément important car souvent trop court.
• Principalement cruel lorsque le temps est associé à un jalon. Par exemple, pour les produits saisonniers comme les applications de rencontres, les loueurs de voiture mais aussi les démos au Comex.
• Impact : crée la panique dans la roadmap. On priorise les fonctionnalités jugées clés et on se répète tel un mantra “delivery”, “delivery” en se demandant ce qui rentrera ou ne rentrera pas dans les jours restants avant le grand show.
• Autrement dit, les fonctionnalités choisies sont sélectionnées par leur coût technique approximatif (car la conception n’est souvent pas encore entamée à ce moment-là) et non centrée autour de la valeur utilisateur. On crée au final plutôt un SMP (Strict Minimum Product) ou plus communément appelé POC (Proof of concept).
• Le budget.
• Element festif quand conséquent mais féroce quand trop petit. Souvent lié au temps.
• Impitoyable quand cela limite les ressources et donc la portée du produit. Par exemple, pour les lancements de produit à petit budget où le MVP va être clé pour débloquer des fonds.
• Impact : déception forte. On débute excité, motivé et rempli de bonnes idées créatives et originales mais on repart avec deux écrans et demi qu’on a peur de montrer à ses copains.
• Autrement dit, la phase d’idéation et de branding permettent à l’équipe de se projeter mais le début du projet croque le budget et les équipes techniques se voient contraintes de réduire le scope fonctionnel et graphique de manière drastique. On revient alors au SMP.
• Les compétences.
• Élément essentiel de la réussite du projet.
• On peut en manquer lorsque l’on a un déficit de ressources internes. Par exemple, un problème de recrutement de PM sur un projet ou de compétences produit.
• Impact : charge répartie sur tout le monde (ou sur une personne sans fortune) ou bien on décide de tout simplement oublier le besoin de cette compétence.
• Autrement dit, on ne réfléchit pas en terme de compétences nécessaires à la réussite du projet (produit, change, marketing, writing, etc. ) en fonction de son stade mais en terme de ressources actuelles staffées. Cela apporte beaucoup moins de valeur au produit.
• A tire d’exemple, je suis déjà tombée sur des projets où le PO faisait les maquettes et les wireframes sans avoir les compétences requises. Le résultat peut être parfois assez effrayant et c’est très painful pour les équipes.
• La complexité
• Élément souvent sous-évalué.
• À systématiquement anticiper dans la limite du possible. Par exemple, on cite souvent la faisabilité technique, mais on anticipe peu les dépendances politiques ou systémiques de type flux de validation long pour impliquer toutes les parties prenantes d’un projet.
• Impact : génère beaucoup de frustration auprès des équipes qui peuvent être contraintes par des dépendances extérieures qui ralentissent considérablement le projet ou par des contraintes de faisabilité qui peuvent réduire les possibilités fonctionnelles.

‍

‍

Le déclin programmé du MVP

Toutes ces contraintes influent sur la qualité du produit délivré. Les équipes mettent souvent en production un équivalent de SMP ou de POC et restent ensuite dans une démarche très delivery de “machine à fonctionnalité” qui maintient le produit dans un état de MVP permanent.

Or, un produit qui ne répond qu’aux attentes de base ne maximise pas la satisfaction des utilisateurs. Si les utilisateurs s’attendent à avoir une fonctionnalités car elle répond aux principaux enjeux du produit et/ou du service proposé, l’émotion ressentie par le complétion de cette attente sera neutre. A l’inverse, si le produit ne couvre pas cette attente de base, leur émotion sera négative. Ils seront frustrés voire énervés. Cette théorie est très bien mise en avant par la courbe de Kano (Dr Noriaki Kano, 1980) qui modélise la satisfaction des clients vis à vis de la complétion de leurs attentes :

Pour maximiser la satisfaction des utilisateurs et des clients, un produit doit posser des fonctionnalités attractives qui jouent sur l’affect et l’émotionnel. Ces fonctionnalités, si présentes, maximisent le ressenti positif des utilisateurs. Chez BAM, nous appelons ces fonctionnalités “Lovable”.

C’est le bombo des fonctionnalités “must-have” et des fonctionnalités “lovable” qui permet un produit ou un service de performer.

Avoir une démarche lovable est un levier d’engagement fort de l’utilisateur dans le temps. Cela permet de se poser les bonnes questions :

• Comment faire en sorte que l’utilisateur revienne ?
• Pourquoi ne pourra-t-il pas se passer de l’outil ?

Coté marché, être le premier à sortir un produit ne suffit plus, il faut marquer les esprits. Il y a aujourd’hui 3,5M d’applications en production sur le Google Play Store, or, les utilisateurs ont un temps limité donc ne pourront pas passer beaucoup de temps sur chaque application (c’est 3,6h/jour en moyenne par Français). J’aime à dire que c’est contre toutes ces app qu’on est en concurrence pour l’attention des utilisateurs et non pas juste ses concurrents directs .

Côté utilisateur, il faut accepter de ne pas adresser tout le monde, le mieux est de restreindre la cible afin de répondre à une vraie intention de l’utilisateur final. Plus la cible est précise et connue, plus le produit lui sera adapté.

Conclusion

Le déclin du MVP est proche car le modèle ne répond pas aux conditions actuelles de conception et de marché. Il ne permet pas de rester concentrer sur les utilisateurs et leur engagement auprès du produit. La vraie solution est le MLP :

“The minimum viable product was appealing because it was cheap, and you could get it to market faster. But we are not anymore in a world where being the first is enough. If startups truly want to stand out, they need to strive toward creating a minimum lovable product instead.” Jiaona “JZ” Zhang, VP of Product at Webflow and formerly of Airbnb, WeWork, and Dropbox.

Pour en savoir plus, vous pouvez écouter l'épisode de podcast Design +, dans lequel j'ai eu l'occasion de parler de ce sujet plus en profondeur avec Laurent Gallen.