Comment définir une portée MVP en 3 heures

Lorsque j'ai été recruté en tant que chef de produit par une société de traitement des paiements en phase de démarrage, l'entreprise avait du mal à créer et à fournir un système de gestion des stocks en temps opportun. La solution en place était une simple application de clavier qui n'était pas conviviale et, par conséquent, provoquait un important désabonnement des clients. Mon travail consistait à diriger une équipe chargée de créer le système d'inventaire qui étendrait les capacités de l'application au-delà de la fonctionnalité du clavier.

Parce que nous devions fonctionner sur un calendrier tronqué, j'ai créé une approche simple mais radicalement efficace pour concevoir, concevoir et construire un produit minimum viable (MVP) avec des fonctionnalités de base qui correspondaient à ce que nos utilisateurs recherchaient. Le processus a condensé la portée d'un MVP en une session intensive de trois heures - au lieu de jours ou de semaines - et a permis à notre équipe de gagner des mois de développement.

Ce processus de cadrage MVP accéléré peut être utilisé pour guider n'importe quelle équipe de produit et peut être appliqué à la création de n'importe quel produit zéro-à-un.

Présentation du cas d'utilisation

Problème : la fonctionnalité simple du clavier de l'application ne permettait pas aux utilisateurs, qui étaient des fournisseurs, de gérer l'inventaire ou de sélectionner des articles à ajouter à la commande d'un client.

Contraintes : la direction de l'entreprise voulait une solution livrée en huit semaines ; une éventuelle levée de fonds dépendait, en partie, du succès d'une version améliorée du produit.

Contexte : À partir d'une analyse du marché et après avoir passé du temps avec plusieurs de nos utilisateurs, j'ai déterminé que ces fournisseurs avaient besoin d'un système de gestion des stocks pour rationaliser leur flux de vente. Je les ai regardés traiter les commandes des clients : d'abord, ils ont écrit les articles demandés sur des morceaux de papier, ont utilisé des calculatrices pour compter les articles, puis ont saisi les commandes dans l'application. Ils utilisaient trois outils alors qu'ils n'auraient dû en avoir besoin que d'un seul.

Solution : nous devions développer une solution permettant aux utilisateurs de charger leurs inventaires dans un catalogue numérique, de gérer ces inventaires et d'appuyer sur des articles sélectionnés pour les ajouter au panier d'achat d'un client, le tout dans l'application.

La décision du Design Sprint

Parce que nous savions déjà quel produit nous devions développer, j'ai choisi de renoncer à un sprint de conception typique - un atelier de quatre à cinq jours dans lequel les équipes collaborent pour identifier un défi commercial majeur, recueillir les idées des clients sur la façon de résoudre le problème, développer un concept pour un produit, concevoir un prototype et commencer à le tester.

Les sprints de conception sont une méthode efficace pour créer des MVP, pour ceux qui ont besoin d'identifier les problèmes fondamentaux et qui disposent d'un temps appréciable pour développer des solutions. Dans les entreprises en démarrage ou les nouvelles unités commerciales dans les organisations existantes, cependant, les problèmes fondamentaux sont généralement évidents : les concepts ont été développés et l'adéquation produit/marché a généralement été déterminée avant l'arrivée des chefs de produit, des ingénieurs et des concepteurs.

L'organigramme suivant détaille les étapes que j'ai suivies lorsque j'ai décidé que la meilleure façon de poursuivre ce projet était de sauter le sprint de conception et de commencer par la session de trois heures, également connue sous le nom de lancement de l'équipe. Lors de cette réunion, les participants réfléchissaient et généraient des dizaines d'idées de fonctionnalités, puis réduisaient la liste à ce qui était requis pour le MVP.

Le processus de développement MVP

Préparation

Avant la session de trois heures, vous souhaiterez recueillir des informations sur vos utilisateurs en conversant et en observant des clients actuels ou potentiels et en effectuant des études de marché.

Ensuite, créez une présentation pour les concepteurs et les ingénieurs. Il doit expliquer :

• Le problème que vous essayez de résoudre.
• Le produit que vous construisez.
• Comment le produit résoudra ce problème en termes de métriques et d'UX.
• L'impact prévu du produit sur votre entreprise et celle de votre client.
• Les missions et objectifs au niveau de l'entreprise et de l'équipe et les résultats clés (OKR), ainsi que la manière dont le produit aide à accomplir ces missions et à atteindre ces OKR.

La présentation doit donner aux concepteurs et aux ingénieurs une solide compréhension du produit pour procéder à la définition du MVP.

La réunion de lancement de trois heures

Le lancement doit impliquer toute l'équipe de développement, leur permettant de participer à chaque étape du processus, de l'idéation et de la création de l'histoire au développement du concept MVP. Cela inclut les chefs de produit seniors, juniors et associés ; propriétaires de produits ; les chefs de produit (le cas échéant) ; concepteurs UX ; ingénieurs logiciels; et ingénieurs AQ.

Petit conseil : bien que ce ne soit pas orthodoxe, je recommande d'inclure des ingénieurs avant la phase de construction. Ils fournissent généralement de bonnes idées et ont une passion pour le produit qu'ils essaient d'améliorer. La plupart d'entre eux aiment participer à la définition du MVP ; cela les aide à s'investir davantage dans le projet et à être valorisés par les autres équipes.

Rassemblez tout le monde dans une salle de conférence ou un espace de travail virtuel. Dans notre cas, nous étions 10 personnes. Bloquez trois heures.

Le produit et les parcours utilisateurs (60 minutes)

1. Faire la présentation. (15 minutes)

2. Commencez à identifier tous les utilisateurs de votre produit. Même si vous n'avez pas encore identifié de flux ou de fonctionnalités, vous pouvez définir le nombre de flux à créer. (10 minutes)

   Petite astuce : ne faites pas trop d'ingénierie en ajoutant plus de personnages que nécessaire. Après la publication du MVP, les commentaires des clients révéleront si vous avez besoin de rôles supplémentaires.

   Exemple de cas d'utilisation : nous avions trois personnages : le responsable du magasin (ou administrateur), le caissier et le client final. Il y avait d'autres personnalités potentielles de niveau supérieur, telles que le propriétaire du magasin, mais pour les besoins d'un MVP, celles-ci pourraient être couvertes par l'administrateur.

3. Cartographiez le parcours utilisateur du début à la fin. Attribuez une couleur à chaque persona pour aider à identifier chaque étape du flux qu'un utilisateur rencontrera. Pour les réunions en personne, affichez des notes autocollantes sur un mur ou utilisez un tableau blanc. Pour les réunions virtuelles, utilisez un tableau FigJam ou quelque chose de similaire. (35 minutes)

   Petit conseil : demandez à l'équipe de partager toutes ses idées et d'être plus précis. Chaque étape du flux deviendra une fonctionnalité à construire - et chaque utilisateur aura un flux séparé - mais le processus de description des étapes sera le même.

   Exemple de cas d'utilisation : voici la liste des fonctionnalités de notre personnage de caissier :

   • Ouvrez l'application de point de vente.
   • Connectez-vous à l'aide d'un code PIN.
   • Identifiez le premier article à acheter par le client.
   • Identifiez la quantité de l'article.
   • Identifiez tout article supplémentaire à acheter par le client.
   • Ajouter une réduction sur un article (le cas échéant).
   • Additionnez le coût de tous les articles du panier (à ce stade, le prix d'achat total, y compris la taxe de vente, s'affiche).
   • Terminer la caisse et le traitement des paiements.
   • Confirmez l'achat.
   • Autoriser le client à ajouter un pourboire.
   • Fermez la vente.
   • Afficher le total de toutes les ventes quotidiennes.
   • Obtenez un délai d'expiration après une période d'inactivité prédéterminée (par exemple, cinq minutes).

   Remarque : Cette liste détaille la plupart des fonctionnalités auxquelles nous avons pensé pour ce personnage. Nous avons proposé environ 60 fonctionnalités au total pour tous les personnages, avec un chevauchement minimal, en tant que caissier, gérant de magasin et client final, tous interagissent avec l'application de différentes manières. Selon le type de produit que vous développez, il peut y avoir beaucoup plus de chevauchement de fonctionnalités entre les types d'utilisateurs.

   

Fonctionnalités essentielles des parcours utilisateurs (45 minutes)

1. Regroupez les fonctionnalités de chaque type d'utilisateur dans les parties distinctes de chaque parcours utilisateur sur un tableau blanc réel ou virtuel. Ensuite, tracez une ligne horizontale au tableau. Au-dessus de la ligne, identifiez les ensembles requis pour que le produit fonctionne. En dessous de la ligne, placez les fonctionnalités qui sont agréables à avoir mais qui peuvent attendre les versions ultérieures. (30 minutes)

   Petit conseil : divisez les concepteurs et les ingénieurs en groupes pour terminer cette étape, puis réunissez-vous à nouveau pour comparer les notes. Ceci est particulièrement utile dans les réunions de 10 personnes ou plus.

   Exemple de cas d'utilisation : pour notre application, nous disposions à ce stade de 12 ensembles de fonctionnalités, qui couvraient le chargement d'articles dans le catalogue d'inventaire, leur tarification, la sélection d'articles à ajouter au panier d'un client, le paiement et la clôture de la vente, la réorganisation d'un inventaire faible, et plus. Nous avons finalement réduit le nombre d'ensembles de fonctionnalités à quatre.

   Ce processus d'élimination nous a permis de déterminer que la connexion de sécurité d'un utilisateur n'était pas nécessaire lors de la première itération de l'application. Ni l'un ni l'autre n'ajoutait une réduction ou un pourboire. Nous avons également décidé que le caissier n'avait pas besoin de pouvoir afficher le total de toutes les ventes quotidiennes dans le cadre d'un MVP, contrairement au gérant ou au propriétaire du magasin.

2. Affiner la liste des fonctionnalités. Demandez « Si cela était omis, le produit fonctionnerait-il toujours ? » Si la réponse est oui, laissez cette fonctionnalité en dehors du MVP et conservez-la pour une itération ultérieure du produit. Si la réponse est non, vous devez inclure cette fonctionnalité dans le MVP. À la fin de ce processus, vous saurez ce qui est vraiment nécessaire pour rendre votre produit fonctionnel. Souvent, cela consistera en seulement trois ou quatre fonctionnalités pour chaque ensemble. (15 minutes)

   Remarque : évitez de créer trop d'ensembles de fonctionnalités dans le MVP. Bien que vous deviez anticiper les opinions dissidentes sur ce qui est le plus important à inclure, c'est votre travail en tant que chef de produit de prendre la décision. Vous avez fait vos recherches et disposez de données pour étayer vos décisions. D'après mon expérience, de nombreux produits sont initialement construits de manière plus robuste qu'ils ne le devraient, et la plupart des entreprises préféreraient mettre quelque chose entre les mains des utilisateurs pour les tester et les commentaires le plus rapidement possible.

Conception, test et ingénierie du produit (75 minutes)

1. Demandez aux concepteurs d'intégrer les fonctionnalités de base dans une conception filaire du MVP, que les ingénieurs utiliseront pour créer l'architecture du produit. (45 minutes)

2. Permettez aux spécialistes du produit et aux concepteurs de travailler ensemble sur des tests UX légers de la conception filaire. (15 minutes)

   Remarque : Il existe très peu de scénarios de gestion de produit dans lesquels vous devez créer sans impliquer le client final, mais dans le cas d'un test et d'un développement rapides, vous pouvez tester un prototype de conception en interne ou avec des amis et de la famille qui ne connaissent pas votre produit. S'ils sont confus, certains de vos utilisateurs le seront aussi.

3. Donnez les structures filaires conçues aux ingénieurs pour qu'ils commencent à construire l'architecture du MVP. Ils n'auront pas tout ce dont ils ont besoin, ni le temps, pour créer une solution complète, mais ils peuvent commencer, et l'architecture qu'ils construisent sera utilisée lors de la réalisation du MVP. Pendant ce temps, les équipes de produit et de conception peuvent continuer à tester leurs structures filaires avec des membres de l'équipe interne ou des amis et de la famille agissant en tant qu'utilisateurs. Faire travailler les équipes simultanément sur cette étape permet de gagner du temps. (15 minutes)

Au fur et à mesure que vous deviendrez plus apte à utiliser ce processus, il deviendra plus facile d'identifier les fonctionnalités qui sont les composants essentiels d'un MVP et celles qui peuvent être créées ultérieurement. La pratique vous empêchera également de créer les mauvaises choses : vous pourriez avoir quelque chose en tête pour la liste "plus tard", pour apprendre par la suite qu'aucun client n'en veut.

Résultats et principaux points à retenir

Avant nos efforts, notre application était un clavier avec les chiffres de 0 à 9, un point décimal et un bouton de charge. En raison de cette limitation et du flux de travail inefficace qu'elle a créé, au cours d'une année, notre rétention a été faible - environ 20 %. Bien que nous ayons acquis de nouveaux utilisateurs plus rapidement que nos concurrents, nous les avons perdus presque aussi rapidement.

Tout au long du processus de création du MVP, nous avons construit quatre ensembles de fonctionnalités clés, qui étaient tous de portée minimale mais de haute qualité. Un utilisateur peut désormais :

1. Chargez des articles dans l'inventaire directement à partir d'un appareil mobile en utilisant simplement une caméra, en saisissant un nom et en saisissant un prix.
2. Sélectionnez ces articles et ajoutez-les au panier d'un client.
3. Clôturez la vente tout en visualisant les articles en vente.
4. Voir le nombre d'articles vendus dans un laps de temps donné.

Les clients ont adoré le produit amélioré. Le taux de rétention était de 45 % parmi les nouveaux utilisateurs qui ont profité de la fonctionnalité de catalogue pour payer au moins cinq fois au cours de la première semaine de chargement des articles.

Grâce à l'efficacité de notre processus de cadrage MVP, nous avons construit et livré notre application entièrement finie en environ deux mois. Ce processus aurait probablement pris quatre mois ou plus avec une approche de développement traditionnelle, si jamais le produit avait été construit.

Ce processus accéléré permet d'économiser du temps et de l'argent. Un sprint de conception complet peut coûter cher. Commencer par la réunion de lancement rend mon processus plus économique dès le départ, et ces économies sont amplifiées par le calendrier de développement global beaucoup plus court.

Cependant, les deux processus peuvent également fonctionner en tandem : si votre équipe a terminé un sprint de conception pour définir un problème métier de base et la solution que vous devez créer, vous pouvez utiliser mon processus pour définir plus efficacement votre portée MVP.

N'oubliez pas que ce processus n'est que le début : un MVP est un travail en cours qui sera encore affiné dans les versions ultérieures. Une fois qu'il est entièrement construit et prêt à être livré, je recommande d'ajouter un commutateur bêta que les utilisateurs peuvent désactiver pour revenir à l'ancienne expérience de l'application. L'utilisation d'un logiciel de comportement, tel que Heap, pour suivre le nombre d'utilisateurs qui utilisent cette option vous donnera une bonne idée de ce qui doit être ajouté ou modifié pour améliorer votre produit lors de la prochaine itération.