Votre MVP n’est ni minimal, ni viable, ni un produit

Chaque fois que je parle de produits minimaux viables avec des fondateurs de startups axés sur les produits, je me retrouve souvent dans une conversation frustrante. Le terme MVP est un tel terme impropre; un bon MVP n’est pas viable, et ce n’est certainement pas un produit. Il y a de fortes chances que ce ne soit pas aussi minime que vous le souhaitez, pensez-y.

Dans le monde des startups lean, les fondateurs doivent rester hyper concentrés sur la manière d’échouer le plus rapidement possible. Idéalement, vous échouez, ce qui signifie que vous vous retrouvez avec une entreprise qui fonctionne. Un grand nombre des approches « essayer d’échouer » impliquent d’examiner vos opportunités commerciales et d’envisager où votre entreprise pourrait échouer à l’avenir. Ensuite, allez comprendre cette partie.

Il ne sert à rien de créer la meilleure plate-forme au monde pour vendre des Beanie Babies si toute la clientèle est déjà satisfaite d’eBay et ne changerait pas, même si votre produit est supérieur. Il ne sert à rien de créer un excellent cadenas spécifiquement pour les scooters de covoiturage s’il s’avère que les sociétés de scooters ne se soucient pas du vol des scooters. Ce serait formidable s’il y avait un moyen de savoir si quelqu’un achèterait votre produit avant d’écrire une seule ligne de code.

Alors, où les MVP entrent-ils en jeu ? En tant que startup, vous avez une hypothèse ; un MVP est la plus petite quantité de travail que vous pouvez faire pour confirmer ou infirmer votre hypothèse. Eric Ries – oui, le gars qui a écrit « The Lean Startup » – utilise le célèbre MVP de Dropbox comme exemple. Ce n’était pas un produit à part entière, plein de fonctionnalités. Ce n’était pas un produit avec beaucoup de fonctionnalités supprimées. C’était une vidéo, montrant comment un produit pourrait fonctionner. La réponse à cette vidéo a été la confirmation dont l’entreprise avait besoin : si elle la construit, elle pourra trouver une clientèle pour son produit encore à construire. C’est donc ce qu’ils ont fait : ils ont construit le produit et sont devenus un énorme succès.

Concevoir un bon MVP

Concevoir un bon MVP signifie sortir des sentiers battus. Combien peu de code pouvez-vous écrire ? Pouvez-vous vous en sortir sans faire de design ? Si votre plus grande question est de savoir si vous pouvez attirer des clients pour un coût d’acquisition de clients qui a du sens, pourriez-vous lancer simplement une campagne publicitaire et une page de paiement, puis simplement rembourser celui qui passe une commande ? Si cela semble amusant mais que vous vous inquiétez du risque de marque, pourriez-vous créer une fausse marque et obtenir une réponse à votre produit ?

L’astuce consiste à bien réfléchir à l’hypothèse – qu’est-ce qui doit être vrai à propos de votre produit, du marché, de l’espace problématique dans lequel vous entrez, des clients que vous espérez attirer et du paysage concurrentiel ? Dans quelle mesure êtes-vous sûr que vos hypothèses sont correctes ? Concevoir un bon MVP est un art, mais cela commence par une très bonne question. Voici quelques exemples:

• Est-il possible pour nous de réduire quatre heures de tâches comptables manuelles à un script exécutable en trois minutes ? Il s’agit d’un MVP technique – vous devez probablement pirater du code pour voir si vous pouvez automatiser de manière fiable les tâches manuelles.
• Pouvons-nous trouver quelqu’un qui est prêt à payer pour automatiser cette tâche ? Dans certains cas, la réponse sera « non » – oui, vous pourriez faire gagner du temps à un comptable junior, mais dans certaines industries, les gens ne se soucient tout simplement pas du temps que les employés subalternes consacrent à des tâches manuelles. Dans ce cas, vous devez déterminer si vous pouvez trouver 20 à 30 clients prêts à payer pour cela. N’oubliez pas que quelqu’un qui dit « oh, ça a l’air d’être une bonne idée » est différent de celui qui met la main dans ses poches et réellement vous payer de l’argent.
• Le design est-il important pour ce produit ? Beaucoup de logiciels B2B sont horriblement laids. Ce n’est pas parce que les bons designers n’existent pas, mais parce que ce n’est tout simplement pas une priorité ; les personnes qui doivent utiliser le produit peuvent préférer un meilleur design ou une UX plus simple, mais les décideurs s’en fichent et les utilisateurs n’ont pas leur mot à dire. En d’autres termes : ne dépensez pas la moitié de votre budget de développement pour rendre quelque chose plus facile à utiliser, si vous ne trouvez pas d’analyse de rentabilisation pour cela. Surtout s’il s’avère que vous finissez par développer par inadvertance le mauvais ensemble de fonctionnalités dans le processus.
• Un titulaire nous copiera-t-il et nous détruira-t-il ? Si vous avez un certain nombre de titulaires dans votre espace, faites des recherches et voyez comment ils ont réagi aux autres startups. S’ils ont tendance à les acquérir, tant mieux. S’ils ont tendance à copier leurs fonctionnalités et innovations puis à les écraser, moins bien. Un peu de recherche sur Google (et, bien sûr, la lecture de TechCrunch pour votre secteur) peut vous éviter bien des maux de tête à l’avenir. Si les titulaires volent régulièrement des innovations, investissez davantage dans les brevets et mettez de l’argent de côté pour les avocats.
• Cette fonctionnalité a-t-elle un sens pour nos clients ? Il se peut qu’une très forte minorité de vos clients demandent la même fonctionnalité, mais vous ne seriez pas la première entreprise à avoir lancé une nouvelle fonctionnalité en grande pompe pour être accueillie par un haussement d’épaules collectif. Les clients bruyants ne parlent pas pour l’ensemble de votre clientèle, alors soyez judicieux dans la façon dont vous préparez votre carnet de commandes – si une fonctionnalité n’ajoute pas de valeur significative aux objectifs commerciaux globaux de votre entreprise, ne la priorisez pas par rapport à celles qui le font. Une façon de concevoir un MVP autour de cela consiste simplement à ajouter un bouton à votre interface utilisateur et à suivre le nombre de personnes qui cliquent dessus. Jetez un « à venir bientôt! » message lorsqu’il est cliqué, par exemple. Oui, c’est ennuyeux pour les utilisateurs, mais c’est beaucoup moins cher que de passer plusieurs cycles de développement à ajouter une fonctionnalité que presque personne n’utilisera.

En un mot, la clé est de réfléchir très attentivement à la question, puis de trouver des façons élégantes et simples de poser cette question. Au lieu du code d’expédition, une enquête pourrait-elle fonctionner ? Une démo vidéo pourrait-elle vous apporter les réponses dont vous avez besoin ? Pouvez-vous appeler 50 clients et leur poser des questions circonspectes et voir s’ils suggèrent la fonctionnalité à laquelle vous pensez comme solution potentielle au problème ? Ils peuvent vous surprendre de deux manières : vos clients peuvent soit vouloir massivement ce que vous suggérez (super !), soit ils peuvent le détester (également super – cela signifie que vous n’avez pas à perdre de temps et d’argent à développer quelque chose qu’ils ne font pas voulez) ou ils peuvent avoir une manière complètement différente de résoudre le problème qui touche le point idéal, est moins cher à développer et les aide à se sentir impliqués dans votre processus.

Je n’ai pas de suggestion pour un meilleur nom pour MVP, mais ne tombez pas dans le piège de le considérer comme un produit, viable ou, nécessairement, petit, simple ou facile. Certains MVP sont complexes. L’idée, cependant, est de dépenser le moins possible de vos précieuses ressources pour obtenir une réponse à vos questions.