MVP – Quand Construire, Mesurer, Apprendre, ce n'est pas simplement jeter des choses contre le mur
Publié: 2017-05-29Et voir s'ils fonctionnent
Je suis toujours surpris lorsque les critiques se plaignent que l'approche Build, Measure, Learn de la Lean Startup n'est rien de plus que "jeter des produits incomplets hors du bâtiment pour voir s'ils fonctionnent".
Malheureusement, le diagramme Construire, Mesurer, Apprendre est la cause de cette confusion. À première vue, cela ressemble à un processus de tir prêt à viser.
Il est temps de mettre à jour Build, Measure, Learn vers ce que nous savons maintenant être le meilleur moyen de créer des startups Lean.
Voici comment.
Construire, Mesurer, Apprendre semble assez simple. Créez un produit, mettez-le dans le monde réel, mesurez les réactions et les comportements des clients, apprenez-en et utilisez ce que vous avez appris pour créer quelque chose de mieux. Répétez, en apprenant s'il faut itérer, pivoter ou redémarrer jusqu'à ce que vous ayez quelque chose que les clients adorent .
Développement de la cascade
Bien que cela semble simple , l'approche Build Measure Learn pour le développement de produits est une amélioration radicale par rapport au modèle Waterfall traditionnel utilisé tout au long du 20 ème siècle pour construire et expédier des produits. À l'époque, un entrepreneur utilisait un processus de développement de produits en série qui procédait étape par étape avec peu ou pas de commentaires des clients. Les fondateurs supposaient qu'ils comprenaient les problèmes/besoins des clients, rédigeaient des documents d' exigences techniques, concevaient le produit, implémentaient /construisaient le matériel/logiciel, vérifiaient qu'il fonctionnait en le testant , puis présentaient le produit aux clients lors d'une sortie officielle appelée premier client. .
Waterfall Development consistait à exécuter le document d'exigences. Alors que les premières versions du produit étaient partagées avec les clients lors des tests alpha et bêta, l'objectif de l'accès précoce des clients au produit était de découvrir des bogues et non de fournir des commentaires sur les fonctionnalités ou la convivialité. Ce n'est qu'après l'expédition et la tentative de vente du produit qu'une startup entendrait des commentaires substantiels de la part des clients. Et trop souvent, après des mois voire des années de développement, les entrepreneurs ont appris à leurs dépens que les clients n'achetaient pas leur produit parce qu'ils n'avaient pas besoin ou ne voulaient pas de la plupart de ses fonctionnalités .
Il a souvent fallu trois essais aux entreprises pour obtenir les bons produits. La version 1 a été construite sans les commentaires des clients, et avant que la version 1 ne soit terminée, le travail avait déjà commencé sur la version 2, il a donc fallu attendre la version 3 avant que le client ne soit vraiment entendu (par exemple, Microsoft Windows 3.0)
Les meilleures pratiques en matière de développement logiciel ont commencé à évoluer vers le développement agile au début des années 2000. Cette méthodologie a amélioré la cascade en créant un logiciel de manière itérative et en impliquant le client. Mais il manquait un cadre pour tester toute commercialisation hypothèses à l'extérieur du bâtiment. Avec Agile, vous pourriez finir par satisfaire toutes les fonctionnalités demandées par un client et faire faillite.
Puis vint le focus Build Measure Learn du Lean Startup.
Construire Mesurer Apprendre
L'objectif de Build-Measure-Learn n'est pas de construire un produit final à expédier ou même de construire un prototype de produit, mais de maximiser l'apprentissage grâce à une ingénierie incrémentale et itérative. (L'apprentissage peut porter sur les caractéristiques du produit, les besoins des clients, le bon prix et le bon canal de distribution, etc.) L'étape de "construction" fait référence à la création d'un produit viable minimal (un MVP). moins de fonctionnalités. C'est plutôt la chose la plus simple que vous pouvez montrer aux clients pour tirer le meilleur parti de l'apprentissage à ce moment-là . Au début d'une startup, un MVP peut simplement être une diapositive PowerPoint, une structure filaire, un modèle en argile, un exemple d'ensemble de données, etc. Chaque fois que vous créez un MVP, vous définissez également ce que vous essayez de tester/ mesurer . Plus tard, au fur et à mesure que l'on en apprend davantage, les MVP passent d'une fidélité basse à une fidélité plus élevée, mais l'objectif reste de maximiser l'apprentissage et non de construire un prototype bêta / complet du produit.
Recommandé pour vous:
Comment Metaverse va transformer l'industrie automobile indienne
Que signifie la disposition anti-profit pour les startups indiennes ?
Comment les startups Edtech aident la main-d'œuvre indienne à se perfectionner et à se préparer pour l'avenir...
Stocks technologiques de la nouvelle ère cette semaine : les problèmes de Zomato continuent, EaseMyTrip publie des...
Les startups indiennes prennent des raccourcis à la recherche de financement
La plate-forme de marketing numérique Logicserve met en sac un financement INR 80 Cr et se rebaptise LS Dig ...
Une amélioration majeure par rapport au développement de Waterfall, Build Measure Learn permet aux startups d'être rapides, agiles et efficaces.
Le diagramme à trois cercles de Build Measure Learn est une bonne approximation du processus. Malheureusement, l'utilisation du mot "construire" en premier est souvent source de confusion. Le diagramme semble impliquer de construire des choses et de les jeter hors du bâtiment. Une version plus détaillée du diagramme Build Measure Learn aide à clarifier le sens en ajoutant trois éléments supplémentaires : Ideas -Build- Code -Measure- Data -Learn.
La version en cinq parties du diagramme Construire Mesurer Apprendre nous aide à voir que l'intention réelle de la construction est de tester des "idées" - pas seulement de construire aveuglément sans objectif. Le cercle intitulé « code » pourrait facilement être intitulé « construire du matériel » ou « construire un génome artificiel ». Le cercle intitulé "données" indique qu'après avoir mesuré nos expériences, nous utiliserons les données pour affiner davantage notre apprentissage. Et le nouvel apprentissage influencera nos prochaines idées. Nous pouvons donc voir que le but de Build-Measure-Learn n'est pas seulement de construire des choses, le but est de construire des choses pour valider ou invalider l'idée initiale.
L'accent mis sur le test d'idées spécifiques contrecarre la préoccupation selon laquelle construire-mesurer-apprendre consiste simplement à jeter les choses contre le mur et à voir si elles fonctionnent.
Mais ce n'est toujours pas assez bon. Nous pouvons maintenant faire mieux.
Commencez par des hypothèses
Ce que Build-Measure-Learn manque, c'est que les nouvelles entreprises (à la fois les startups et les nouvelles idées dans les entreprises existantes) ne commencent pas par des "idées", elles commencent par des hypothèses (un mot fantaisiste pour les conjectures.) Il est important de comprendre que les mots " idée » et « hypothèses » signifient deux choses très différentes. Pour la plupart des innovateurs, le mot « idée » évoque une idée qui nécessite immédiatement un plan pour la concrétiser. En revanche, une hypothèse signifie que nous avons une supposition éclairée qui nécessite une expérimentation et des données pour valider ou invalider .
Ces hypothèses couvrent toute la gamme allant de qui est le(s) client(s), à quelle est la proposition de valeur (caractéristiques du produit/service), la tarification, le canal de distribution et la création de la demande (acquisition de clients, activation, fidélisation, etc.)
Que le Lean Startup commence par reconnaître que votre idée est simplement une série d'hypothèses non testées est une grande idée . C'est une très grande idée parce que ce que vous construisez doit correspondre à l'hypothèse que vous voulez tester.
Le produit minimum viable que vous devrez créer pour trouver les bons clients est différent du produit minimum viable dont vous avez besoin pour tester la tarification, qui est différent d'un MVP que vous créeriez pour tester des fonctionnalités spécifiques du produit. Et toutes ces hypothèses (et les produits viables minimaux) changent avec le temps à mesure que vous en apprenez davantage. Ainsi, au lieu de Build-Measure-Learn, le diagramme de construction de produits minimaux viables dans une Lean Startup ressemble à Hypothèses - Expériences - Tests - Insights.
Générer des hypothèses
En utilisant ce nouveau diagramme Hypothèses - Expériences - Tests - Insights, la question devient alors : "Quelles hypothèses dois-je tester ?" Heureusement, le canevas de modèle d'entreprise d'Alexander Osterwalder présente un aperçu visuel des neuf composants d'une entreprise sur une seule page. Elles sont:
- Proposition de valeur, produit/service offert par l'entreprise (ainsi que ses avantages pour les clients).
- Segments de clientèle, tels que les utilisateurs et les payeurs ou les mamans ou les adolescents.
- Canaux de distribution pour atteindre les clients et leur offrir la proposition de valeur
- Relation client pour créer la demande.
- Flux de revenus générés par la ou les propositions de valeur.
- Activités nécessaires à la mise en œuvre du modèle d'entreprise.
- Ressources nécessaires pour rendre les activités possibles.
- Partenaires Tiers nécessaires pour rendre les activités possibles.
- Structure de coûts résultant du modèle économique.
Et cela nous amène à la définition d'une startup : Une startup est une organisation temporaire conçue pour rechercher un modèle économique reproductible et évolutif .
Tester des hypothèses
Et une fois que ces hypothèses remplissent le Business Model Canvas, comment un entrepreneur procède-t-il pour les tester ? Si vous êtes un scientifique, la réponse est simple : vous faites des expériences . Il en va de même dans une Lean Startup. (La National Science Foundation a décrit la classe Lean LaunchPad comme la méthode scientifique de l'entrepreneuriat.)
Le processus de développement client est une méthodologie simple pour prendre de nouvelles hypothèses d'entreprise et sortir du bâtiment pour les tester. La découverte des clients capture la vision des fondateurs et la transforme en une série d'hypothèses de modèle d'affaires. Ensuite, il développe une série d'expériences pour tester les réactions des clients à ces hypothèses et les transformer en faits. Les expériences peuvent être une série de questions que vous posez aux clients, mais le plus souvent, un produit minimal viable pour aider les clients potentiels à comprendre votre solution accompagne les questions.
Donc, une autre grande idée ici est que les startups ne construisent pas de produits minimaux viables pour construire un prototype. Ils construisent des produits viables minimaux pour apprendre le plus possible .
Enfin, le but de la conception de ces expériences et de produits minimaux viables n'est pas d'obtenir des données. Les données ne sont pas le point final. Tout le monde peut collecter des données. Les groupes de discussion recueillent des données. Ce n'est pas un groupe de discussion. Le but est d'avoir un aperçu . Tout l'intérêt de sortir du bâtiment est d'informer la vision du fondateur . La perspicacité peut provenir de l'analyse des réponses des clients, mais elle peut également provenir de l'ignorance des données ou de la réalisation que ce que vous décrivez est un nouveau marché perturbateur qui n'existe pas, et que vous devez modifier vos expériences pour passer de la mesure des spécificités à l'invention. l'avenir.
[Ce message de Steve Blank est apparu pour la première fois sur le site officiel et a été reproduit avec permission.]