Product discovery : savoir quoi construire avant de coder

Tu sais construire. Alors face à une idée, ton réflexe c'est d'ouvrir l'éditeur et de livrer une version. Sauf qu'une statistique tue ce réflexe : d'après le rapport 2019 de Pendo, environ 80 % des fonctionnalités d'un logiciel sont rarement ou jamais utilisées. Autrement dit, quatre fois sur cinq, le code que tu écris ne sert à personne. La product discovery, c'est la discipline qui t'évite d'en faire partie.

Ce n'est pas un rituel agile de plus. C'est le travail, continu, qui consiste à décider quoi mettre dans le produit, pour qui, et dans quel ordre, en t'appuyant sur des preuves plutôt que sur ton intuition. Pour un fondateur qui cherche encore ses premiers utilisateurs, c'est la différence entre six mois de dev bien placés et six mois gaspillés.

Product discovery : ce que c'est vraiment

La product discovery répond à une seule question : « qu'est-ce qui mérite d'être construit ? ». Elle vient avant la phase de livraison (le dev), et elle ne s'arrête jamais complètement. Tant que tu ajoutes des choses au produit, tu fais de la discovery, consciemment ou pas. Le choix, c'est de la faire bien.

Le piège quand on sait coder, c'est de confondre « je peux le construire » avec « ça vaut le coup de le construire ». Tu vois l'archi, tu sens la solution, tu codes. Mais sentir qu'un truc serait utile n'est pas une preuve que quelqu'un l'adoptera ou le paiera. La discovery remplace cette intuition par des signaux concrets : ce que les gens font déjà, ce qu'ils contournent à la main, ce pour quoi ils dépensent du temps ou de l'argent.

Les chiffres convergent tous vers la même leçon. Pendo chiffre à 80 % les fonctionnalités rarement ou jamais utilisées. En parallèle, l'analyse de post-mortems de CB Insights place « pas de besoin marché » en tête des causes d'échec, à 42 %, devant le manque de cash. La discovery attaque exactement ce risque-là, et elle le fait pour le prix de quelques conversations, pas d'un trimestre de code.

Le danger n'est pas de mal coder une fonctionnalité. C'est de parfaitement coder une fonctionnalité dont personne ne veut.

Product discovery ou validation d'idée : ne pas confondre

On mélange souvent les deux, et ça coûte cher. La validation d'idée est un moment : tu testes si un problème vaut la peine d'exister, au tout début. La product discovery est un processus continu : une fois l'idée validée, elle te dit quoi construire ensuite, fonctionnalité après fonctionnalité, tant que le produit vit. La première ouvre la porte, la seconde guide chaque pas une fois à l'intérieur.

Concrètement, la validation d'idée se fait avec des entretiens client et une poignée de signaux de marché. La discovery reprend le relais dès que tu as un début de produit : elle transforme le flot d'idées (les tiennes, celles des utilisateurs, celles que tu copies à des concurrents) en décisions. Sans elle, tu construis la fonctionnalité la plus récente ou la plus réclamée par le dernier qui a crié, pas la plus utile.

Les quatre risques à lever avant d'écrire du code

Marty Cagan, dans son travail chez SVPG, formule la discovery autour de quatre risques à tester avant de s'engager dans le dev. C'est la grille la plus utile pour un fondateur solo, parce qu'elle t'oblige à nommer ce que tu ne sais pas encore.

Cagan le dit sans détour : les bonnes équipes partent du principe qu'au moins la moitié de leurs idées ne marcheront pas, et les meilleures tablent sur trois sur quatre. Ce n'est pas du pessimisme, c'est la réalité du produit. Toute la discovery consiste à découvrir ces idées mortes avant de les avoir codées, pas après les avoir mises en prod.

Ta boucle de product discovery en pratique

Pas besoin d'une équipe produit ni d'outils compliqués. La discovery d'un fondateur solo tient en une boucle courte que tu répètes à chaque décision importante. L'objectif : passer le moins de temps possible entre une idée et la preuve qu'elle vaut (ou pas) le coup.

1. Collecte les problèmes, pas les demandes. Un utilisateur qui réclame un bouton te donne sa solution, pas son besoin. Creuse : « pourquoi tu veux ça, qu'est-ce que ça t'évite ? ». Tu cherches le problème derrière la demande, souvent résoluble autrement.
2. Cadre avec les jobs to be done. Reformule chaque besoin en termes de progrès que la personne cherche à faire. Ça range tes idées par problème réel et pas par caprice. Le prisme des jobs to be done t'évite de construire dix variantes du même truc.
3. Priorise sur la preuve, pas sur l'envie. Demande-toi pour chaque idée : combien de gens ont ce problème, à quel point ça leur fait mal, et quelle preuve j'en ai ? Une idée sans preuve attend. Une douleur répétée et chère passe devant.
4. Teste avant de coder. Maquette, page de capture, démo Loom, prototype no-code : fais toucher la solution à cinq personnes de ta cible avant de l'écrire. Si personne ne mord, tu viens d'économiser des semaines.
5. Construis petit, mesure, recommence. Livre la plus petite version qui prouve ou casse l'idée. Regarde l'usage réel, pas les compliments. Puis recommence la boucle avec ce que tu as appris.

Cette boucle n'est rien d'autre que la méthode du MVP appliquée en continu, idée par idée, au lieu d'une seule fois au lancement. Tu arrêtes de deviner, tu commences à découvrir.

Décider quoi ne pas construire

Le vrai muscle de la discovery, ce n'est pas de trouver de bonnes idées : tu en as déjà trop. C'est d'en tuer la plupart. Chaque fonctionnalité que tu ajoutes alourdit le produit, dilue ton message et te coûte de la maintenance à vie. Un « non » bien placé vaut dix fonctionnalités codées.

Avant de lancer un dev, passe l'idée au crible. Si tu ne peux pas cocher franchement, c'est que la discovery n'est pas finie.

De la bonne fonctionnalité au premier utilisateur

La product discovery t'évite de construire dans le vide, mais elle ne remplace pas la distribution. Une fonctionnalité parfaitement choisie ne vaut rien si personne ne la découvre. C'est pour ça que la discovery et l'acquisition avancent ensemble : les gens que tu interroges pour découvrir deviennent tes premiers utilisateurs, et les canaux où tu les trouves deviennent tes canaux de lancement. Pour aller plus loin, démarre par des entretiens client solides, structure ce que tu apprends avec les jobs to be done, et garde en ligne de mire l'objectif réel : itérer vers le product market fit avec des gens qui existent.

Le fondateur qui gagne n'est pas celui qui livre le plus de fonctionnalités. C'est celui qui a découvert, avant de coder, lesquelles méritaient d'exister, et qui sait déjà à qui les montrer le jour où elles sont prêtes.