CB Insights publie chaque année une analyse des raisons pour lesquelles les startups échouent. Depuis des années, la première raison est la même : « aucun besoin de marché ». Pas une mauvaise exécution. Pas un manque d'argent. Pas une mauvaise équipe. Le produit ne résolvait tout simplement pas un problème suffisamment important pour que les gens changent leur comportement.
Cette statistique est stupéfiante quand on considère les efforts qui entrent dans la création de produits. Les équipes passent des mois — parfois des années — à concevoir des systèmes, écrire du code, débattre d'architecture et perfectionner des flux. Et la raison la plus fréquente d'échec est que personne n'a demandé si tout cela résolvait un vrai problème.
Créer des produits que les gens veulent vraiment n'est pas un talent. C'est une discipline. Elle a une méthode, et cette méthode peut s'apprendre.
L'erreur produit la plus courante est de tomber amoureux d'une solution avant d'avoir profondément compris le problème. C'est presque universel chez les fondateurs pour la première fois et étonnamment fréquent chez les expérimentés. Le schéma est toujours le même : quelqu'un a une idée, il la trouve convaincante, et il commence à construire. Le client est une pensée secondaire — quelqu'un à convaincre, pas à comprendre.
L'antidote n'est pas compliqué mais nécessite de la discipline : passez plus de temps sur le problème que vous ne le pensez nécessaire, avant de considérer des solutions. Parlez aux gens qui ont le problème. Observez-les travailler. Comprenez les solutions de contournement qu'ils utilisent aujourd'hui et pourquoi ces solutions sont imparfaites. Seulement alors vous aurez suffisamment de contexte pour concevoir quelque chose qui correspond vraiment.
Le bon développement produit n'est pas une ligne droite — c'est une boucle. Chaque itération autour de la boucle est une occasion de remplacer des suppositions par des preuves. Les équipes qui créent des produits que les gens veulent sont celles qui complètent cette boucle rapidement et souvent.
La boucle n'est pas une formalité. Chaque étape a un résultat spécifique qui devient l'entrée pour la suivante. Sauter des étapes — le plus souvent passer directement du Problème à la Construction — est ce qui produit des produits qui ratent leur cible.
Tous les problèmes ne valent pas la peine d'être résolus. Un bon problème produit a trois qualités : il est fréquent (affecte les gens souvent, pas rarement), il est intense (les gens le ressentent suffisamment pour vouloir un soulagement), et les solutions existantes sont véritablement inadéquates (pas juste légèrement différentes de ce que vous construiriez).
L'erreur est d'optimiser pour la première qualité et d'ignorer les deux autres. « Les gens perdent du temps en réunions » est fréquent. Mais si la douleur est faible — si les gens ont trouvé des solutions de contournement suffisamment bonnes — le problème ne vaut peut-être pas la peine d'être résolu commercialement. Et s'il existe déjà douze outils faisant ce que vous voulez faire, vous avez besoin d'une raison très spécifique pour laquelle le vôtre serait choisi.
La recherche a mauvaise réputation dans les cercles produit — elle est associée à des consultants lents, à d'épais rapports et à des conclusions que personne ne lit. C'est un échec d'exécution, pas de la pratique. Une bonne recherche produit est rapide, spécifique et change ce que vous construisez.
L'objectif de la recherche n'est pas de confirmer que le problème est réel. Vous devriez déjà croire cela avant d'investir massivement dans la recherche. L'objectif est de comprendre le problème suffisamment profondément pour savoir à quoi ressemble une bonne solution : qui a spécifiquement le problème, dans quel contexte, ce qu'ils ont déjà essayé, les mots qu'ils utilisent pour le décrire, et à quoi ressemblerait « résolu » pour eux.
Une hypothèse est une prédiction spécifique et falsifiable sur ce que vous croyez être vrai. Elle force la clarté. Si vous ne pouvez pas écrire une hypothèse claire, vous ne comprenez pas encore suffisamment bien le problème pour construire une solution.
Une hypothèse produit utile a trois parties :
Le signal est la partie la plus importante — et la plus souvent omise. Sans signal préengagé, chaque expérience « a un peu fonctionné ». Les équipes trouvent des façons d'interpréter des données ambiguës favorablement. Une hypothèse sans condition de falsification n'est qu'un vœu.
La phase de construction est là où la plupart des équipes passent trop de temps. L'objectif n'est pas de construire le produit — c'est de construire le minimum qui vous donnera un signal sur votre hypothèse. Ce sont des objectifs différents et ils produisent des résultats très différents.
Pour la plupart des hypothèses en phase initiale, le minimum est bien moins que ce que les équipes pensent. Pouvez-vous faire manuellement ce que le logiciel ferait, pour dix personnes, pour tester si elles valorisent le résultat ? Pouvez-vous assembler des outils existants et tester le flux de travail avant de construire une nouvelle infrastructure ? Pouvez-vous esquisser un prototype et le tester avec cinq utilisateurs avant d'écrire du code ?
La discipline ici est de demander, avant de construire quoi que ce soit : « Qu'est-ce que j'essaie d'apprendre ? » et « Quelle est la chose minimale qui me permettrait de l'apprendre ? » La réponse est presque toujours plus petite que ce que l'équipe veut construire.
Après le lancement — que ce soit un prototype, un pilote manuel ou une fonctionnalité déployée — la phase de mesure est là où les équipes se trompent le plus souvent elles-mêmes. Elles demandent aux utilisateurs s'ils ont aimé. Les utilisateurs disent oui. L'équipe marque l'expérience comme validée.
Le sentiment n'est pas un signal. Le seul signal fiable est le comportement : les gens ont-ils fait la chose ? Sont-ils revenus ? Ont-ils payé ? Ont-ils parlé à quelqu'un d'autre ?
Pour la mesure quantitative, instrumentez avant de lancer. Sachez quelles actions spécifiques vous suivez. Fixez un seuil à l'avance — « nous considérerons cela validé si X% des utilisateurs complètent Y dans Z jours ». Pour la mesure qualitative, menez des entretiens de suivi structurés, pas des enquêtes de satisfaction ouvertes.
La phase d'apprentissage consiste à mettre à jour votre modèle mental de l'utilisateur et du problème, pas seulement à décider quoi construire ensuite. Les équipes qui sautent cette étape collectent des données mais n'accumulent pas de compréhension. Elles exécutent rapidement mais n'améliorent pas leur jugement avec le temps.
Une bonne session d'apprentissage demande : Qu'avons-nous prédit ? Que s'est-il vraiment passé ? Que nous dit l'écart sur nos suppositions ? Quelle est maintenant la chose la plus importante que nous ne savons pas ?
Le résultat de la phase d'apprentissage est une définition de problème plus précise, une hypothèse révisée, ou — si l'expérience a clairement échoué — une décision de poursuivre une direction entièrement différente. Tous ces résultats sont précieux. Le pire résultat est l'ambiguïté : « nous avons appris des choses mais ne savons pas quoi faire ensuite ». C'est un signe que l'expérience n'était pas suffisamment spécifique.
Le développement produit n'atteint jamais un stade où vous arrêtez de faire tourner cette boucle. Les questions changent — au début vous validez si le problème est réel ; plus tard vous validez si un élément de solution spécifique fonctionne — mais la structure est toujours la même. Observer, formuler une hypothèse, tester, apprendre.
Les équipes qui créent des produits que les gens veulent ne sont pas celles qui ont l'intuition initiale la plus astucieuse. Ce sont celles qui complètent la boucle le plus rapidement et le plus honnêtement. La vitesse d'apprentissage, pas la vitesse de livraison, est l'avantage concurrentiel.