Pendant longtemps, je pensais qu’avoir une bonne idée et de solides compétences techniques suffisait pour lancer un produit.

J’avais tort.

Avec le recul, je me rends compte que j’ai construit un produit sans m’assurer qu’il répondait à un véritable besoin. Cet échec m’a appris une leçon bien plus précieuse que n’importe quel succès : un produit ne vaut rien s’il ne résout pas un problème réel.

Tout a commencé avec le Web3

Comme beaucoup, j’ai découvert le Web3 à travers le Bitcoin, Ethereum et l’engouement autour des NFTs.

Mais ce qui m’intéressait n’était pas la spéculation. Je voulais comprendre la technologie derrière tout cela : la blockchain.

J’ai donc commencé à suivre des formations gratuites, à lire de la documentation et à expérimenter. Ayant déjà de bonnes bases en développement Web2, la transition vers les outils du Web3 s’est faite assez naturellement.

J’ai appris à développer des smart contracts avec Solidity, dont la syntaxe rappelle Java, mais aussi avec Vyper, plus proche de Python.

Petit à petit, une idée est née.

Pourquoi ne pas rendre cette technologie accessible ?

En découvrant cet univers, j’ai eu l’impression que l’apprentissage du Web3 restait réservé à une communauté assez fermée, contrairement au Web2 où les ressources étaient beaucoup plus accessibles.

Je voulais contribuer à démocratiser cet apprentissage.

J’ai alors décidé de créer une plateforme EdTech gratuite permettant à chacun d’apprendre le Web3.

Comme le disait Ban Ki-moon :

« L’éducation n’est pas un privilège. C’est un droit acquis à la naissance. »

Cette citation résumait parfaitement la vision que j’avais pour ce projet.

Le lancement… et la réalité

J’ai développé la plateforme moi-même.

J’ai conçu les fonctionnalités.

J’ai préparé le lancement.

Je prévoyais même de publier le produit sur Product Hunt et d’autres plateformes.

Puis…

Rien.

Pas de croissance significative.

Peu d’utilisateurs.

Très peu de retours.

L’erreur que je n’avais pas vue

Aujourd’hui, je peux résumer mon erreur en une phrase :

J’ai lancé un produit d’innovation incrémentale sans m’assurer qu’il répondait à un besoin réel dans son réseau de valeur.

J’avais imaginé un problème.

Puis j’avais validé… ma propre hypothèse.

Sans données.

Sans interviews utilisateurs.

Sans étude du marché.

Sans démarche de découverte.

Autrement dit, j’ai sauté directement à la phase de développement.

Je suis tombé dans un piège fréquent chez les ingénieurs : penser que construire est la partie la plus difficile.

En réalité, construire le bon produit est bien plus difficile que construire un produit.

Ce que cette expérience m’a apporté

Cet échec m’a amené à me poser une question simple :

Comment les entreprises qui réussissent construisent-elles des produits qui répondent réellement aux besoins du marché ?

C’est cette question qui m’a fait découvrir le Product Management.

J’ai compris que développer un produit n’était qu’une partie du travail.

Avant de développer ou d’écrire la première ligne de code, il faut comprendre les utilisateurs, identifier leurs problèmes, tester des hypothèses et valider que le problème mérite réellement d’être résolu.

C’est cette manière de penser qui m’a ensuite conduit vers le Product Engineering, une approche qui combine la culture produit avec l’excellence de l’ingénierie pour construire des produits qui créent de la valeur.

Ce que je retiens

Si je devais résumer cette aventure en une seule phrase, ce serait celle-ci :

Les utilisateurs n’attendent pas qu’on leur construise quelque chose. Ils attendent qu’on résolve un problème qui compte pour eux.

Mon projet n’a peut-être pas connu le succès que j’espérais, mais il m’a appris quelque chose de bien plus important que le développement d’une plateforme : il m’a appris à construire en partant des utilisateurs plutôt que de mes intuitions.

Alors, si vous développez un produit aujourd’hui, prenez le temps d’explorer le problème avant de construire la solution.

Et si votre équipe pratique déjà cette approche, continuez comme ça : vous êtes sur la bonne voie pour décrocher le premier Ballon d’Or de l’agilité.

(Promis, je viendrai moi-même vous remettre le trophée. 😄)

Seth Lawson