Nicolas Cynober's blog

Transformer votre idée entrepreneuriale en produit

J’ai eu récemment la chance de réfléchir à la création d’un nouveau produit innovant à partir d’une idée.

C’est un exercice assez rare en tant que Product Manager car la définition du produit original qui permettra à une entreprise de réaliser sa mission est souvent conduite par ses fondateurs et c’est d’autant plus le cas quand il s’agit d’un produit innovant.

C’est une étape essentielle dans un projet entrepreneurial parce qu’avant d’embarquer son premier développeur ou de contacter des investisseurs, il faudra rapidement avoir une idée du produit que l’on veut réaliser et de son coût.

Comme je viens de faire l’exercice, je me suis dit que ma méthode pourrait peut-être aider d’autres entrepreneurs. C’est le sujet de cet article.

Pour info, il s’agit d’une adaptation du framework que nous suivions à Pearltrees pour penser nos macro-fonctionnalités jusqu’à des produits complets comme Pearltrees Éducation ou Pearltrees Éditeur.

Voici les 9 étapes que j’ai suivies :

🌟 Rappel de la mission de l’entreprise

Je pars du principe que la mission de votre entreprise a déjà été posée en amont. On agit ici avec une casquette produit et notre fonction est de concevoir un produit qui remplira cette mission.

Imaginons que nous soyons Leboncoin et que notre mission soit la suivante :

Donner à chacun le pouvoir de mieux vivre au quotidien.

C’est beau.

🎯 Objectifs du produit

Il existe potentiellement une infinité de produits pouvant répondre à la mission de votre entreprise. Définir une liste d’objectifs hiérarchisés sera votre boussole et un outil précieux dans vos premières décisions produits qui seront structurantes. Par exemple, si l’on reprend l’exemple de Leboncoin, cela pourrait être :

  • Un lieu pour faire des économies en achetant d’occasion
  • Permettre de revendre ses objets plutôt que les donner ou les jeter
  • Rejoindre une communauté qui agit en faveur d’un monde plus durable

L’ordre est important et vous permettra de trancher des questions difficiles comme : est-ce que les utilisateurs doivent arriver sur la recherche d’objets à acheter ou sur l’ajout d’objets à vendre ?

À son lancement, le site sera vide de toute annonce et il pourrait être judicieux de pousser les utilisateurs à vendre leurs objets en premier lieu… Et bien non, on les fera atterrir sur une recherche d’objets à acheter (c’est l’objectif n°1) et on règlera le problème du « catalogue vide » via d’autres leviers plus secondaires.

🤕 Besoins profonds des utilisateurs

Je ne vais pas vous dessiner une pyramide de Maslow mais il s’agit bien là d’identifier les besoins profonds que vous allez chercher à adresser en priorité. Faire des économies ou gagner du temps sont des classiques à ne pas négliger mais vous pouvez probablement les compléter par des besoins plus spécifiques.

Si on reprend notre exemple, je verrai bien :

Faire des économies, rapidement et en sécurité

En conséquence, on mettra très certainement en avant le prix et son évolution (c’est le moment d’acheter), la distance du vendeur (je ne vais pas traverser la Bretagne pour une table basse), ses options de livraisons (car ça ne tiendra jamais dans ma voiture) et sa vitesse de réponse moyenne (car sur Amazon ça arrive demain), et le tout dans un environnement protégé (cela va de soi, mais on en fera quand même des caisses).

🕵 Produits de référence

Je vous suggère d’identifier 2 ou 3 produits de référence à étudier en détail. Je ferais un article dédié sur « comment analyser un produit » mais d’ici là, contentez-vous d’étudier en détail :

  • L’onboarding : la page d’accueil, l’inscription et les étapes qui s’ensuivent. Concentrez-vous sur le fond : qu’est-ce qu’on vous raconte ? Qu’est-ce qu’on vous incite à faire en premier ?
  • L’architecture du produit : à la manière d’un bâtiment, quels sont les murs porteurs ? Astuce : l’app mobile ayant des fortes contraintes d’espace disponible, il y a plus de chance que la hiérarchie des fonctionnalités soit plus clairement exposée.

Sur toutes vos observations, demandez-vous systématiquement pourquoi ? Quels problèmes ont-ils rencontrés ? Est-ce la solution la plus simple pour y répondre ? Quelles étaient les alternatives ? Est-ce un standard ?

Dans notre exemple, si on revient en 2006, date de création du bon coin, je verrai bien un benchmark des solutions suivantes :

Ebay

Craigslist

Amazon

🔠 Vocabulaire

Le terme d’onboarding est assez usuel dans la conception d’un produit, tout comme le panier dans un site e-commerce, mais vous vous rendrez vite compte qu’il vous faut nommer tous les lieus, objets et interactions sociales pour les concevoir à plusieurs.

Définissez votre vocabulaire clairement, simplement et assurez-vous qu’il soit connu de tous.

Alors, mon annonce, je la publie, je l’ajoute ou je la dépose ?

Petit avertissement sur la communication avec votre équipe technique : qui dit langage de programmation, dit vocabulaire. Votre équipe technique a ses propres contraintes de nommage et moins de flexibilité que vous pour en changer. Laissez-les diverger sur un vocabulaire propre, mais assurez-vous qu’ils restent bilingues.

🧭 Approche

Récapitulons, nous avons des objectifs, une liste de besoins, des produits comparables et un vocabulaire, on pourrait ouvrir un paperboard et commencer à dessiner non ? Encore un peu de patience, je vous propose une dernière étape de cadrage.

À ce stade de la réflexion, il existe encore une infinité de produits pouvant répondre aux objectifs que nous nous sommes fixés, choisir une approche va réduire considérablement le champ des possibles.

Notre étude des produits de référence a montré qu’il existait plusieurs approches pour réaliser un site de vente d’objets d’occasion. Pour Leboncoin, je la décrirai de la manière suivante :

Comprendre immédiatement qu’il s’agit d’un coin, une sorte de brocante en plein air, pas spécialement raffiné ni chaleureux, où je vais faire rapidement des bonnes affaires.

L’approche va avoir des conséquences fortes sur le produit et le design. Elle va vous permettre de poser l’architecture et les murs porteurs dont je parlais précédemment et de donner une direction pour définir votre identité visuelle.

Petite parenthèse sur le design car on n’en a pas trop parlé pour le moment. Vous trouviez le Leboncoin moche ? Son design est pour moi une conséquence directe de l’approche qui a été choisie.

✍️ Maquette du cas d’usage principal

Il s’agit ici de définir un et un seul cas d’usage à décrire de bout en bout. Il faut choisir le cycle utilisateur qui sera le plus critique pour le succès de votre produit. Je ne vais pas décrire maintenant ce qu’est un bon produit, mais vos efforts maintenant et dans le futur devront se porter en priorité sur ce cycle utilisateur.

Le cycle doit commencer le plus en amont possible et être le plus réaliste possible :

  • L’exhaustivité du cycle vous permettra de ne rien oublier et de vous conditionner comme un vrai utilisateur qui découvre votre produit.
  • Le réalisme vous permettra de réduire les biais de présentation à des personnes extérieures à votre projet.

Par exemple, si je me mets dans la peau d’une personne qui ne connait pas Leboncoin et qui cherche dans Google “Appareil à raclette d’occasion”.

Je m’arrête sur la demande de connexion car vous avez compris le principe mais il faudrait pousser jusqu’au message au vendeur.

📋 Identification des cas d’usage secondaires

À ce stade, il n’est pas nécessaire de réaliser des maquettes des autres cycles, mais il vous faudra les énumérer afin d’avoir une idée du chantier qui se présente devant vous.

Je vous recommande une approche pyramidale pour ne rien oublier. Décomposez votre produit en quelques sous-ensembles et itérez. Cela peut être des listes à puces, un mindmap, des boites dans des boites… Vous obtiendrez ainsi une cartographie complète de votre produit qui vous sera très utile sur le long terme.

Dans notre exemple cela pourrait être :

  • Présentation des produits
    • Détail d’un produit
      • Photos
        • Carroussel
        • Zoom
        • Etc.
      • Description
      • Livraison
      • Etc.
    • Liste des produits
    • Recherche
    • Recommandations
    • Etc.
  • Système social
    • Profil utilisateur
    • Messagerie
    • Notifications
    • Etc.
  • Onboarding
    • Page d’accueil
    • Tunnel d’inscription
    • Etc.
  • Support utilisateur
    • Changer de mot de passe
    • Préférences
    • Etc.

Pas besoin d’être exhaustif, 3-4 niveaux de profondeurs doivent suffir.

⏱️ Estimation du temps de développement

Nous avons coutume de dire à Pearltrees qu’on peut tout estimer en 5 minutes, même envoyer une fusée sur la lune. L’astuce, c’est qu’il y a deux chiffres qui vont sortir de cet exercice, le temps et la marge d’erreur.

La marge d’erreur est principalement impactée par :

  • L’expérience de la personne qui estime
  • Le temps passé à estimer
  • La quantité d’information à sa disposition

Le troisième point est piègeur car toute l’information n’est jamais disponible. La marge d’erreur n’est donc jamais à 0%, même 24h avant la date de sortie du produit. Le jeu consiste donc à itérer et réestimer régulièrement quand vous aurez plus d’expérience et d’information disponible.

Qui peut estimer ? N’importe qui. Si vous voulez faire repeindre votre salon, vous vous doutez bien que cela prendra plus d’une heure et moins de deux semaines, soit 7 jours en coupant la poire en deux. Je ne suis pas peintre et j’estime ma marge d’erreur à 50%. Le projet prendra donc entre 3 jours et 10 jours.

Faites le même exercice sur votre produit en vous appuyant sur votre cas principal et la liste des cas secondaires, vous obtiendrez le nombre de journées homme de développement nécessaire avec une première marge d’erreur.

Si vous comptiez sortir une première version de votre produit dans 1 an, vous serrez en mesure d’estimer si un associé CTO suffit ou s’il faut lever des fonds pour recruter une armée de développeurs.

Pour un site comme Leboncoin en version beta, j’arrive à :

3 125 jours de développement avec une marge d’erreur de 50%, soit 8 ETP pendant une année (entre 4 et 13).

J’ai calculé ça en 5 minutes sans lister les fonctionnalités de manière exhaustive mais si l’objectif était de sortir une beta dans un an et que vous êtes actuellement tout seul il vous faudra soit :

  • Augmenter les ressources. Par exemple, embaucher une équipe technique de 8 personnes.
  • Allonger le délai de sortie. Par exemple, sortir une beta dans 2-3 ans qui sera développée par 2 cofondateurs.
  • Réduire le périmètre. Par exemple, se limiter aux fonctionnalités critiques dans un premier temps et itérer.

🙏 En conclusion

J’espère que vous avez trouvé cette méthode intéressante, voir utile ? Si vous voyez des étapes manquantes ou superflux, vos commentaires sont les bienvenues !

Si vous êtes arrivé jusqu’ici, vous êtes courageux car j’anticipais pas un article aussi long 🤣 N’hésitez pas à me suivre sur LinkedIn pour être notifié du prochain article 🔔