Aujourd'hui, je partage avec vous un ensemble de méthodes pour prototyper et tester en un jour la viabilité, faisabilité et désirabilité d'un business en ligne.
Mes projets commencent généralement par un pain point ("point de douleur" en français). Il s’agit d'un problème précis, que je rencontre moi ou un segment clientèle précis, et qui ne possède pas encore de solutions viables.
Il est possible de trouver ce pain point de plusieurs manières :
Une fois ce pain point trouvé, le premier réflexe, noter cette idée dans un coin et vérifier qu'il ne possède pas de solution viable déjà existante (via alternativeto ou votre moteur de recherche favoris).
Quand l'idée a pris le temps de mûrir, je passe aux étapes suivantes.
Pas besoin de compétences techniques pour lancer un projet. Un ordinateur, un simple crayon et une feuille suffisent.
Votre produit n'est pas le produit. Votre business model c'est le produit.
La méthode RUNNING LEAN - Ash Maurya
Je réalise un Lean Canvas ou un Business Model Canvas.
Il s'agit d'un business model recensé sur une simple feuille de papier, rapide à créer et facilement transportable.
C'est à ce moment que l'on peut vérifier la viabilité du projet.
Il existe un moyen de vérifier de manière plus ou moins précise si votre proposition de valeur se trouve en accord avec le profil client.
Le canvas proposition de valeur créer par Strategyzer le permet.
Voici une vidéo réalisée par un des auteurs du livre si vous souhaitez en savoir plus.
Utile pour bien cerner le but du projet et pitcher le projet correctement, je rédige un Elevator Pitch sous cette forme :
Pour [les personnes ciblées par le produit/le service]
qui souhaitent [formulation du besoin des cibles],
notre produit est [description du type de produit/service]
qui [description du bénéfice majeur apporté par la solution].
A la différence de [la concurrence/la pratique actuelle]
notre produit permet de [éléments différenciateurs majeurs].
Un persona est une personne fictive à laquelle on assigne certaines caractéristiques (par exemple: âge, métier, aspirations, etc..). Il est censé représenter le profil type de notre solution. Cela permet de mettre au clair les personnes que l'on cible, de savoir à qui l'on s'adresse.
Les mots ont beaucoup d'importance quand on travaille à plusieurs sur un projet. Pour mieux se comprendre, il peut être utile de disposer d'un vocabulaire commun.
On définit et fixe un ensemble de mots qui correspond à notre solution. Ce vocabulaire fera partie intégrante du code source et sera utilisé par toutes les personnes qui participent au projet.
Ce principe se nomme Ubiquitous Language et est tiré du livre Domain Driven Design.
Pour rapidement créer des mockups (maquette d'une interface utilisateur), vous pouvez utiliser un outil comme balsamiq.
Et si vous avez des notions en développement web, il est parfois plus rapide de directement prototyper votre solution sur codepen.io ou codesandbox.io.
Sinon, une simple feuille et un crayon peuvent suffire.
Définir le chemin que va parcourir l'utilisateur permet d'avoir une vue d'ensemble de l'application, et de rapidement se rendre compte si la solution assure une bonne expérience utilisateur ou pas.
Un exemple de bonne expérience utilisateur serait par exemple de suivre la règle des trois clics.
De mon côté, je le crée sous la forme d'un diagramme d'activité. Ça ressemble à ça :
Pour vérifier la faisabilité technique du projet, je réalise une mini architecture technique. C'est l'étape où je réfléchis à ce que je vais utiliser comme langage de programmation, framework et librairies. Généralement, je définis ce genre de composants :
Je réalise généralement cette architecture technique à l'aide de draw.io, mais encore une fois, un crayon et une feuille suffisent.
Pour ne pas partir dans un développement technique interminable, il est souvent préférable de se limiter à un simple MVP (produit minimum viable).
Un MVP peut se présenter sous la forme d'une landing page (page de capture avec un appel à l'action), d'une simple vidéo ou les deux.
Elle doit se présenter comme l'unique solution à l'unique problème de votre unique segment de clientèle.
Note pour les développeurs : Dans le cas d'un projet avec comme cible des développeurs, j'ai tendance à écrire un simple fichier README.md que je publie sur Github page avec Docsify. Le résultat est plutôt joli et ça permet de suivre une logique de RDD.
La dernière étape consiste à partager le projet, récupérer un maximum de feedbacks, et vérifier si notre solution répond réellement et correctement à un problème existant. C'est à ce moment que sera dévoilée la désirabilité du projet.
De manière plus concrète :
On évite de cibler tout le monde, on cherche une source de trafic et on apporte un maximum de valeur à ces personnes afin de leur faire découvrir notre solution.
Pour ça, il faut que le projet soit suffisamment attractif et persuasif.
Évidemment, on respecte la vie privée, on évite de jouer avec les emails des gens, et on ne partage aucune information à des tiers.
Personnellement je n'utilise pas de solution SaaS comme Google Analytics, MixPanel ou ClickFunnels. Aucune information ne sort de mon infrastructure.
On privilégie les questions ouvertes tout en restant à l'écoute, le but n'étant pas de chercher à vendre le produit, mais plutôt de l'améliorer selon les besoins réels des utilisateurs.
On peut poser des questions du type :
"Quel est votre plus gros problème avec ce [domaine] ?"
"Comment vous sentiriez-vous si vous ne pouviez plus utiliser ce produit ?"
"Quelle solution utilisez-vous actuellement pour résoudre ce problème ?"
Acquisition : Comment les visiteurs vous trouvent ?
Activation : Première expérience de l’utilisateur
Retention : L’utilisateur revient-il ?
Referral : Est-ce que vos utilisateurs sont suffisamment contents pour en parler autour d’eux ?
Revenue : Comment gagnez-vous de l’argent ?
À partir de là, je pense qu'il faut plus d'un jour pour tirer suffisamment d'enseignements. Si le taux de rétention est élevé, et que 40% de vos utilisateurs déclarent qu'ils seraient très déçus s’ils ne pouvaient plus utiliser votre produit (test de Sean Ellis), alors vous pouvez passer à l'étape de conception. Je parlerai de cette étape dans un prochain article.
Dans le cas contraire, je réitère ce processus de 10 étapes, je créer des hypothèses, et je valide ou non ces hypothèses en fonction des enseignements (metrics et feedbacks).
L'idéal pour votre produit serait qu'il réponde correctement à ces 3 axes (viabilité, faisabilité et désirabilité), en un minimum de temps et sans dépenser trop d'argent.
Cet article a été réalisé dans le contexte où l'on travaille seul en tant qu'entrepreneur indépendant. Quand on travaille seul, on prend le temps de chercher, de trouver son inspiration et de réfléchir.
Cependant, il est tout à fait possible de réaliser ces même étapes avec plusieurs personnes (un Scrum Master, un Product Owner, un ou plusieurs développeurs, etc...).
Théoriquement, si vous avez déjà une idée qui a pris le temps de mûrir, que vous êtes quelqu'un de très productif, que vous avez les bons outils, une bonne expérience et que vous avez déjà automatisé certains process au préalable, je pense qu'il est possible d'avoir des résultats très intéressant en 1 jour, surtout si vous passez une grande partie de cette journée sur la phase de test.
J'ai essayé d'être le plus bref possible dans cet article, je vous conseille de lire les ressources ci-dessous si vous souhaitez aller plus loin.
N'hésitez pas à partager en commentaire quels sont vos process à vous ;)
Inscrit toi à la newsletter si tu ne veux pas rater le prochain article ;)