MVP, MMF, PSI, WTF ? Première partie : Comprendre le MVP
Lorsque je travaille avec de nouveaux Product Owners, je constate fréquemment que nous sommes pris dans une mer de TLA (acronymes à trois lettres) quand vient le temps de commencer réellement à transformer leur Backlog d’idées en incréments de valeur libérables.
L’idée de décomposer le travail – décomposer nos grandes sorties de produits planifiées en plus petits incréments de valeur est l’endroit où beaucoup de nouveaux propriétaires de produits luttent. Comment pouvons-nous prendre cette feuille de route du produit et la transformer en quelque chose que mes équipes Scrum peuvent effectivement livrer sur une cadence courte et régulière ? Comment puis-je transformer cette énorme liste de fonctionnalités très importantes (VIF) en un ensemble itératif d’opportunités d’apprendre, de fournir de la valeur et de mettre réellement quelque chose entre les mains de nos clients ? En d’autres termes, ….
« Quel est notre MVP ? »
« Est-ce notre MMF ? »
« Pouvons-nous publier cette PSI en tant que MVP, ou avons-nous besoin de plus d’histoires faites avant d’avoir un MMF ? »
Egalement…. quoi??
Que signifient ces TLA ? En quoi sont-ils différents les uns des autres ? Comment sont-ils liés ? Pourquoi devrais-je m’en soucier ?
En commençant par le MVP (Minimum Viable Product), cette série en trois parties aidera les agilistes débutants à comprendre ce que signifient ces TLA. En quoi sont-ils différents les uns des autres ? Comment sont-ils liés ? Pourquoi devrais-je m’en préoccuper ? Elle permettra également de rappeler à ceux qui travaillent en Agile depuis un certain temps pourquoi ces concepts sont les chevilles ouvrières de l’agilité.
Pour les personnes qui commencent à apprendre Scrum, elles peuvent se tourner vers le Guide Scrum… et apprendre rapidement que le Guide Scrum est silencieux sur le comment de la transformation d’un produit en une collection de petits incréments de valeur libérables.
Le manque d’info autour de ce sujet important peut être vraiment frustrant pour les nouveaux propriétaires de produit. Espérons que le reste de cet article clarifiera les MVP, et il y a toujours des classes de Product Owner Scrum certifié à vérifier pour plus d’informations. Pour l’instant, plongeons dans le produit minimum viable.
Le MVP
Vous avez fait vos recherches, vous avez fait marcher les groupes de discussion des clients à travers quelques tours de Buy a Feature, et vous avez pris quelques décisions autour de ce à quoi votre prochaine version pourrait ressembler. En fait, vous avez engagé votre équipe de marketing et vous itérez à travers des idées sur la façon de faire un gros coup d’éclat – des annonces dans les magazines spécialisés, des Tweets promus, des posts Facebook…
Mais, il y a encore quelques questions lancinantes que vous avez autour de certaines des fonctionnalités sur lesquelles vous travaillez. Vous y avez pensé, vous les avez analysées, mais il y a cette voix dans votre tête qui continue à demander : » Mais comment le SAVOIR ? «
C’est là que le MVP entre en jeu – pas Steph Curry, mais le (peut-être mal nommé) produit minimum viable.
L’énigme du Lean Startup
Dans son livre « The Lean Startup », Eric Reis redéfinit de manière confuse le terme « Minimum Viable Product », ce qu’il explique dans une interview en 2015. En bref :
« Quelques mises en garde d’emblée. Le MVP, malgré son nom, ne consiste pas à créer des produits minimaux. Deuxièmement, l’utilisation par la définition des mots maximum et minimum signifie qu’elle n’est décidément pas une formule. »
Donc, si le monde de la propriété du produit et la communauté Agile ont redéfini le produit minimum viable pour qu’il ne s’agisse ni de créer le minimum ni des produits, alors qu’est-ce que c’est ?
Tout sur l’apprentissage
Cette voix agaçante à l’arrière de votre tête, se demandant s’il y a un moyen de sortir du piège de la paralysie de l’analyse dans lequel vous êtes, essayant de trouver un moyen de connaître réellement les réponses à certaines de vos questions, au lieu de vous analyser dans un sentiment plus profond de fausse sécurité ? C’est là que le produit minimum viable entre en jeu.
Lorsqu’un PSI (Potentially Shippable Increment) consiste à créer l’opportunité de livrer potentiellement quelque chose de valeur, et que le MMF (Minimum Marketable Feature) consiste à combiner ces éléments de valeur dans une collection de fonctionnalités qui résolvent les problèmes des clients, le MVP consiste à faire le minimum de travail que votre équipe peut faire afin de fermer une boucle d’apprentissage validée.
Dans la méthodologie Lean Startup de découverte de produits, l’une des habitudes les plus importantes à prendre est celle de valider des hypothèses et de créer des expériences. Dans les organisations plus traditionnellement réticentes au risque, la croyance que le risque doit être analysé hors de votre produit avant le lancement conduit à de longs délais et, de manière frustrante, à des hypothèses basées sur des données concernant les désirs et les souhaits des clients. Si nous sommes vraiment bons en analyse statistique, et si nous avons de très bonnes données sur une partie statistiquement significative de nos clients, nous pouvons faire un assez bon travail pour formuler une supposition éclairée sur ce que nos clients veulent.
Mais, à la fin de la journée, cela reste une supposition.
Lorsque nous créons des MVPs, nous construisons intentionnellement juste assez de fonctionnalités pour poser les bonnes questions à nos clients – achèteriez-vous ce produit ? Ces icônes ont-elles un sens ? Ce flux de travail vous frustre-t-il, ou vous aide-t-il à trouver votre prochain restaurant préféré ?
À ce stade, nous examinons des prototypes papier, des wireframes de sites Web, des maquettes d’interface utilisateur ; nous traversons la rue jusqu’au centre commercial pour montrer nos conceptions aux personnes les plus proches que nous pouvons, juste pour valider rapidement que nous sommes sur la bonne voie.
La magie de la création d’un bon MVP ne réside pas dans les outils ou les techniques, cependant ; c’est dans la discipline, lorsque vous voulez analyser les données d’une carte thermique d’un site Web pour déterminer quel schéma de couleurs fonctionne le mieux, de prendre plutôt des marqueurs et du papier, d’esquisser quelques solutions de basse fidélité et de demander à quelqu’un : » Laquelle de celles-ci préférez-vous ? «
.