Product discovery : construire ce dont les gens ont vraiment besoin
La plupart des fonctionnalités livrées ne créent aucune valeur. La discovery continue, popularisée par Teresa Torres, réduit ce gâchis en testant avant de construire.
Un constat inconfortable circule dans l'industrie logicielle, appuyé par les mesures d'entreprises comme Microsoft ou Booking.com : une large part des fonctionnalités livrées n'améliorent pas les indicateurs qu'elles étaient censées servir — certaines les dégradent même. On construit beaucoup, on impacte peu. La product discovery est la discipline qui vise à réduire ce gigantesque gâchis.
Discovery contre delivery
La delivery, c'est bien construire le produit : coder, tester, livrer avec qualité. La discovery, c'est décider quoi construire — et surtout, éviter de bâtir ce qui ne servira à personne. Les deux sont indispensables et complémentaires, mais les équipes, sous pression de livrer, négligent presque toujours la première. Or livrer vite la mauvaise chose ne fait qu'atteindre l'échec plus rapidement.
« Tombez amoureux du problème, pas de la solution. »
La discovery continue de Teresa Torres
Teresa Torres a popularisé l'idée de continuous discovery dans son livre Continuous Discovery Habits. Le principe : au lieu d'une grande étude de marché tous les deux ans, l'équipe produit (le trio produit-design-tech) parle à des utilisateurs chaque semaine, relie chaque idée à un vrai problème via un « opportunity solution tree » (arbre qui connecte un résultat souhaité aux opportunités puis aux solutions), et teste des hypothèses en continu, par petites touches. On apprend un peu, souvent, plutôt que beaucoup, rarement.
Tester avant de construire
Le cœur de la discovery est de valider une idée pour quelques heures de travail, plutôt que de la découvrir fausse après des mois de développement. La boîte à outils :
- Entretiens utilisateurs — comprendre le problème réel, pas demander « quelle fonctionnalité voulez-vous ? ».
- Prototypes & maquettes cliquables — confronter une solution à de vrais utilisateurs avant de coder.
- Fausse porte (« fake door ») — un bouton qui mesure l'intérêt pour une fonctionnalité qui n'existe pas encore.
- Tests A/B — mesurer l'impact réel d'un changement sur le comportement, pas sur les opinions.
Marty Cagan (Inspired) résume les risques à lever avant de construire : désirabilité (les gens en veulent-ils ?), viabilité (est-ce bon pour l'entreprise ?), faisabilité (peut-on le faire ?), et utilisabilité.
Le changement de posture
La discovery demande de troquer la question « comment livrer plus vite ? » contre « comment être sûr que ça vaut la peine d'être livré ? ». C'est un changement d'état d'esprit autant que de méthode — passer d'une équipe « feature factory » qui exécute une liste, à une équipe responsable de résultats. C'est l'un des changements les plus rentables qu'une organisation produit puisse opérer.