J’ai abandonné MVP | – Octets de produit de Rich Mironov

Après des années de lutte, je conseille à tous mes clients et chefs de produit coachés de ne plus utiliser le terme «MVP». Ne pas arrêter Faire validation, découverte, prototypage ou expériences, ils peuvent associer cet acronyme, mais pour supprimer l’étiquette de tous leurs documents, présentations et exposés. Pour supprimer les lettres MVP des roadmaps et des chartes produits. Pour le bannir de leur vocabulaire, ne pas le laisser traverser leurs lèvres. Voici pourquoi…

Presque sans faute, je trouve que le côté «fabricant» des éditeurs de logiciels (développeurs, concepteurs, responsables de produit, DevOps, rédacteurs techniques…) et le côté «go-to-market» des éditeurs de logiciels (ventes, marketing, support, client succès ..) ont des définitions inconciliables de MVP.

Les organisations créatrices se réfèrent à Eric Ries (et beaucoup plus tôt) pour les définitions MVP telles que “toute offre ou capacité qui nécessite le moins d’efforts pour construire tout en donnant à l’organisation la plus grande capacité en savoir plus sur les clients. » Il peut s’agir d’une description textuelle ou d’un croquis Balsamiq ou d’un prototype Web ou d’un flipbook non fonctionnel qui nous donne une chance de montrer à un étranger ce que nous voulons dire. Il n’est pas destiné à la vente ou aux revenus, mais à des apprentissage. Le «P» signifie nominalement «produit», mais c’est presque toujours pas un produit.

Les organisations de commercialisation veulent vraiment quelque chose à commercialiser et à vendre. Donc, malgré nos longs arguments académiques, ils se concentrent sur le mot «produit. »En fait, la définition la plus fréquente que j’obtiens des dirigeants de GTM est “Quelque chose que je peux vendre dès maintenant à des clients sélectionnés pour les revenus actuels, au lieu d’attendre encore quelques trimestres pour un produit parfait.” Et en quelques minutes, ceci est raccourci à «Quelque chose que je peux vendre maintenant.» Tout le monde est ravi de présenter (et de fermer) des clients en direct, même si nous n’avons pour l’instant que des maquettes de diapositives.

Les distinctions subtiles sont perdues. Nos avertissements, mises en garde et qualificatifs du côté des fabricants difficiles sont oubliés. Classé sous “excuses de la gestion des produits pour les dates de livraison manquantes.” Alors à mon humble avis, appeler quelque chose qu’un MVP invite au chaos.

Symptômes

Quelques mauvais résultats fréquents de cette confusion:

• Nous ne terminons jamais notre MVP. Les parties prenantes continuent d’élargir la définition de «terminé», car nous ne pouvons pas livrer un produit à revenus réels sans les fonctionnalités A, B, C, X, Y et Z. Cela court-circuite l’apprentissage et ralentit la livraison. L’ingénierie et le produit sont considérés comme des pertes de temps intellectuelles.
• Nous déployons trop tôt les efforts de marketing / support sortant. Le marketing a besoin de nombreux atouts de dernière génération: captures d’écran, déclarations de bénéfices validées, calculateurs de ROI, segmentation précise, clients de référence. Le support a besoin de guides d’installation, de sessions de formation, de FAQ, de catégories de rapports de bogues. Celles-ci (bien sûr) n’existent pas encore, car nous sommes encore en train de tester des énoncés de problèmes, des caractéristiques / fonctions et des exigences techniques. La plupart de cela changera, créant plusieurs séries de retouches au fur et à mesure que nous ajoutons des fonctionnalités / remote / update, remplaçons les simulacres par des visuels finaux; réviser les prix et l’emballage. Beaucoup de frustration et de temps perdu. Mais la pression pour des actifs trop tôt est irrésistible.
• Nous précipitons notre MVP «d’apprentissage» auprès de clients payants ou de prospects sérieux. Les commerciaux pensent que c’est réel et s’engagent trop tôt. Puisqu’il n’a que quelques fonctions partiellement fonctionnelles (ou pas du tout), tout le monde est embarrassé. Les équipes de terrain jurent de ne jamais vendre la version finale – chaque fois qu’elle arrive – et concluent que l’équipe de fabrication est incompétente. Le produit entièrement fonctionnel est mort à son arrivée, ayant déjà été étiqueté comme un échec.
• Il est interdit aux utilisateurs de produits et de conception / UX de montrer plus de prototypes aux clients payants. La distinction claire entre la validation et la vente est perdue, les équipes de compte protégeant à tout prix les clients individuels (et notre réputation). Les fabricants se contentent d’interroger nos propres employés sur les réactions probables des utilisateurs. Cela sape la raison pour laquelle les concepteurs et les chefs de produit ont besoin commentaires directs et réactions des utilisateurs en direct au début du cycle du produit: pour équilibrer la myopie interne, le biais de récence, le manque de contexte technique et nos nombreuses hypothèses erronées. Je préfère que nous apprenions nos dures leçons plusieurs mois avant l’expédition, à peu de frais, au lieu de nous excuser pour la v1.0.

C’est souvent plus qu’un simple problème de vocabulaire. Mais nous pouvons réduire la confusion / la frustration en choisissant des mots sans ambiguïté avec des significations claires. Voici un ensemble de remplacements:

«Validation du problème» ou «Test de concept» (NON REVENUS)

• Les outils peuvent être des travaux à faire, des toiles, des cartes de voyage, des prototypes papier, des histoires de héros, des interviews sur ce que vous avez acheté à la place
• Objectif: comprendre si nous avons identifié le bon problème racine. Pouvons-nous savoir ce qui est vraiment cassé et tester quelques solutions imaginaires? Dans quelle mesure les prospects potentiels sont-ils enthousiastes?

«Flux de travail conceptuel» ou «Test UX» (NON REVENUS)

• Les actifs peuvent inclure des simulacres, des flipbooks ou des interfaces Web cliquables sans logique interne
• Objectif: voir si des exemples d’utilisateurs peuvent effectuer une tâche. Quels intrants manquons-nous? Avons-nous nommé les choses correctement? Le workflow A ou la mise en page B testent-ils mieux?

«Validation du concept d’ingénierie» (NON REVENUS)

• Peut inclure des exemples de données exécutés via des algorithmes partiels ou des tests d’évolutivité ou du code «bonjour le monde» pour l’intégration d’API
• Objectif / questions: X fonctionnera-t-il? Cela fait-il exploser nos serveurs cloud? Pouvons-nous trouver des signaux exploitables dans les données? Notre architecture est-elle sensée? Les premiers essais techniques modifient-ils notre champ d’application ou identifient-ils des capacités manquantes?

“Test bêta technique” (NON REVENUS)

• Peut utiliser une première version avec des fonctions de base mais une sécurité limitée, une vérification des erreurs, des cas de coin, de la documentation. Nous l’installons / le configurons probablement pour le victime utilisateur de test.
• Objectif: voir si un ou deux clients sympathiques peuvent faire fonctionner une première version du produit (gratuitement). Que pouvons-nous apprendre sur leur environnement? Où sont-ils coincés? De quoi d’autre avons-nous besoin pour réussir les déploiements en volume?

«Programme des premiers utilisateurs» (REVENU)

• Nous aurons besoin d’un produit fonctionnel assez complet pour un nombre restreint de vrais clients, complété par de nombreux TLC et une aide pratique. La direction des produits doit avoir une liste de contrôle de qualification détaillée pour s’assurer que ce sont des clients «sympathiques» qui répondent à toutes nos exigences techniques. Dans l’idéal, aucun ne négocie actuellement de gros accords de licence avec nous.
• Objectif: à la fin, nous voulons qu’ils nous paient quelque chose et soient une référence de vente.

«Disponibilité totale du marché» (REVENU)

• Nous avons tout ce dont nous avons besoin pour recruter un large éventail de clients payants. Cela inclut les logiciels entièrement testés, la documentation, les prix / emballages, les numéros de pièce, les actifs marketing, la génération de prospects ciblée, la veille concurrentielle, la formation au support, l’escalade des problèmes, les matériaux des partenaires / canaux, etc.
• Objectif: déployer un produit gagnant pour des revenus remarquables, une renommée du marché, des clients enthousiastes et une gloire reflétée pour l’équipe de fabrication.

Octet sonore

Vous pouvez choisir les étapes et les artefacts adaptés à votre situation. Mais il semble essentiel de donner à ces étapes noms clairs et difficiles à mal interpréter qui indiquent clairement si des revenus sont impliqués. Pas de BS, pas de positionnement, pas d’obscurcissement. Nos équipes de fabricants et nos groupes de commercialisation travaillent trop dur pour que nous nous confondions. Passons les mille heures suivantes à nous demander si quelque chose est minimal, viable ou un produit.