Une idée de produit numérique arrive en général comme une longue liste. Les clients réserveraient en ligne. L'équipe verrait l'agenda. Les rapports se mettraient à jour seuls. Paiements, connexions, une application mobile et une douzaine d'exceptions semblent tous indispensables avant que quiconque ait utilisé la chose. Un MVP, un produit minimum viable, est la façon dont une entreprise britannique réduit cette liste à la plus petite version qui répond encore à une vraie question. Le but est d'apprendre, en dépensant moins, avant de financer un chantier complet.
Ce qu'est un MVP, et ce qu'il n'est pas
Un MVP est la plus petite version avec laquelle un vrai utilisateur peut terminer le travail central. Pour une idée de réservation, cela peut être un service, une façon de demander un créneau, et une vue pour la personne qui doit l'honorer. Pour un outil interne, cela peut être une tâche répétée sortie d'un tableur et placée sur un écran que l'équipe ouvrira vraiment.
Ce n'est pas une image cliquable que seule l'équipe projet peut voir. Un prototype peut être utile plus tôt, pour vérifier que les gens comprennent les étapes. Il ne dit pas s'ils utiliseront le produit un mardi, quand ils sont occupés. Un MVP n'est pas non plus une copie à moitié finie du système complet, avec chaque menu présent et la plupart vides. Les menus vides n'apprennent rien, et ils donnent au produit l'air abandonné.
Un logiciel du commerce a le droit de gagner. Si un outil que vous pouvez acheter permet déjà de tester la demande, construire est la façon la plus chère de poser la même question. Le développement logiciel sur mesure a sa place quand ces outils ne correspondent plus à votre façon de travailler, quand les étapes manuelles mangent la semaine, ou quand des systèmes doivent se parler et ne le font pas.
Ce qui appartient à la première version
Incluez le chemin depuis le premier geste de l'utilisateur jusqu'au résultat qui vous importe. Nommez un utilisateur principal. Si vous ne pouvez pas dire qui c'est, la liste de fonctions remplace la décision.
- Le seul travail que le produit existe pour terminer.
- Assez du parcours pour qu'un inconnu, ou un membre de l'équipe, le finisse sans démonstration guidée.
- Des libellés clairs, un moyen d'obtenir de l'aide, et des données personnelles traitées conformément au UK GDPR.
- Un moyen simple de voir si les gens l'ont utilisé : des tâches terminées, pas un tableau de chiffres de vanité.
- L'intégration sans laquelle vous ne pouvez pas tester, et aucune autre. Un CRM, une étape de paiement ou un moteur de réservation n'entre dans la version un que si la question en dépend.
Laissez de côté les rôles supplémentaires, les packs de rapports, une application native pour iOS et Android, et une finition visuelle qui ne change pas la question. Le design compte encore. Un premier écran confus produit un faux « non ». Le design UI et UX avant le chantier est la façon de vérifier le parcours tant que le changer reste peu coûteux. Concevoir l'expérience d'abord évite des changements chers une fois que le code est ce que l'on édite.
Des étapes qui gardent le risque petit
Les étapes sont une suite de décisions, pas un tas de fonctions.
Nommer le risque
Écrivez la question à laquelle le MVP doit répondre. « Les clients existants demanderont-ils ce service sans téléphoner ? » est une question. « Construire une plateforme » n'en est pas une. Si la réponse est déjà oui, vous n'avez peut-être pas besoin d'un MVP. Vous avez peut-être besoin d'un vrai chantier, cadré sur un processus auquel vous faites déjà confiance.
Cartographier le parcours
Listez les étapes pour cet utilisateur, y compris les mauvaises : un créneau déjà pris, un champ qu'il ne comprend pas, une demande hors zone. C'est le cahier des charges. Tout ce qui n'apparaît pas dans le parcours attend.
Concevoir, puis construire la version mince
Des maquettes et une interface claire viennent avant le code, pour que l'équipe construise un plan que quelqu'un a déjà parcouru. Le chantier couvre ensuite ce chemin seulement. Les écrans d'administration existent pour qu'un collègue non technique puisse tenir la journée, pas pour que chaque futur rapport ait une entrée de menu.
Le mettre devant de vrais utilisateurs
L'équipe qui s'en servira, ou un petit nombre de vrais clients, est le test. Une salle de personnes polies ne l'est pas. Regardez s'ils terminent le travail sans aide. Notez où ils s'arrêtent. Cette preuve est le résultat du MVP, plus qu'une liste de demandes de fonctions recueillie dans la même réunion.
Continuer, changer, ou arrêter
Trois issues sont acceptables. Continuer, et financer la tranche suivante. Changer le parcours, parce que les gens voulaient un travail voisin. Arrêter, parce que la demande n'était pas là, et se réjouir que le produit complet n'ait pas été construit d'abord. S'arrêter est un usage réussi d'un MVP. C'est le risque que vous avez payé pour retirer.
Comment valider avant de dépenser davantage
La validation est un relevé de comportement. Comptez les tâches terminées. Parlez aux personnes qui se sont arrêtées à mi-chemin, et à celles qui ont fini et ne sont pas revenues. Une poignée d'usages réels vous en dira plus qu'une liste de fonctions plus longue, écrite à l'avance.
Gardez l'apprentissage attaché à la question d'origine. Si les clients terminent la demande mais que l'équipe ne peut pas l'honorer sans un tableur, la tranche suivante est la vue d'exécution, pas une application mobile. Si personne ne commence la demande, plus de fonctions ne répareront pas l'offre. Changez l'offre, ou arrêtez.
Les intégrations suivent la même règle. Relier un CRM, une passerelle de paiement, l'e-mail ou un moteur de réservation est courant quand le produit en a besoin. Tout faire dans la première version, « pour que ce soit prêt », cache quelle connexion comptait vraiment. Ajoutez celle dont le test dépend. Ajoutez la suivante quand le test le dit.
Après la première mise en ligne
Un MVP que les gens utilisent devient un produit dont il faut s'occuper. Les défauts, les petits changements et une personne nommée à appeler font partie de la poursuite de l'apprentissage. La maintenance et le support après le déploiement couvrent la surveillance, les corrections, les mises à jour de fonctions et l'aide technique, pour que la première version ne se fige pas la semaine de sa mise en ligne.
Web Works Rise est une équipe dirigée depuis le Royaume-Uni. Le bureau est à Birmingham, et un hub de développement en Tunisie ajoute de la capacité de livraison pour le travail britannique. Le travail part du problème métier, puis d'une version assez petite pour être testée. Si vous avez une idée de produit, ou un processus qui a dépassé son tableur, contactez l'équipe avec la question à laquelle il faut répondre. Cette question est le périmètre.