À travers les produits que j'ai construits et conseillés, ceux qui ont rencontré des difficultés n'ont jamais manqué d'ingénierie. Ils manquaient de clarté sur qui ils servaient et quel problème valait la peine d'être résolu.

Le produit était correct. Le code compilait. Le design avait l'air professionnel. Le lancement a reçu des retours favorables. Et puis la troisième personne est arrivée et personne n'est revenu.

Le produit était la dernière chose à casser. La réflexion qui l'avait façonné s'était brisée en premier.

Le produit est la dernière chose qui casse

CB Insights a analysé des centaines de post-mortems de startups et a découvert que 35 % des startups échouent parce qu'il n'y a pas de besoin marché. Un autre 20 % se font dépasser par la concurrence. Ce sont les deux des échecs en amont.

Un sondage de 2026 de Wilbur Labs portant sur 200 fondateurs a révélé que 42 % souhaitaient avoir pivoté plus tôt. Ils avaient accroché au produit parce que le produit fonctionnait. Le problème n'était pas le produit. Le problème était que le produit résolvait la mauvaise chose, ou la résolvait pour les mauvaises personnes, ou au mauvais moment.

La qualité de la construction était correcte tout au long. La réflexion qui guidait la construction ne l'était pas.

Trois échecs en amont que je vois sans cesse

Après des années dans l'EdTech, la FinTech, la HealthTech, les entreprises de portefeuille PE et les organisations à impact, les mêmes trois schémas reviennent encore et encore. Ce ne sont pas des échecs techniques. Ce sont des échecs de clarté.

Le mauvais problème

Construire une solution avant de comprendre suffisamment le problème. C'est le plus courant. L'équipe tombe amoureuse de la solution et remonte le temps pour trouver un problème qui colle.

Chez Openfair, le concept de marketplace était solide mais le vrai problème n'était pas le mécanisme de transaction. C'était la confiance entre acheteurs et vendeurs. Les gens n'avaient pas besoin d'une autre marketplace. Ils avaient besoin d'une raison de croire que la personne de l'autre côté du deal était réelle et compétente. Le produit a dû être reconstruit autour de la confiance, pas autour du deal.

La leçon : la clarté du problème vient avant la clarté du produit. Si vous ne pouvez pas décrire le problème en une phrase qu'un étranger hocherait la tête, le produit se construit sur des suppositions.

Le mauvais public

Construire pour le public que vous voulez au lieu du public qui a le problème. C'est subtil parce que le public que vous voulez est souvent celui qui fait bonne impression dans un pitch deck, pas celui qui utilisera le produit quotidiennement.

Chez Paper, l'hypothèse initiale était que les enseignants étaient l'utilisateur principal. Les élèves l'étaient. Le produit a dû être restructuré autour du comportement des élèves, pas de l'intention des enseignants. Les élèves atterrissaient sur un écran blanc avec une boîte leur demandant de choisir un sujet. Ils hésitaient. Nous avons superposé le sélecteur de sujet sur un aperçu du chat en dessous. Les démarrages de session ont augmenté d'environ 25 %. Le produit n'a pas changé. La compréhension du public, si.

La leçon : parlez aux personnes qui l'utiliseront quotidiennement, pas à celles qui l'achèteront ou l'approuveront. L'acheteur et l'utilisateur sont souvent deux personnes différentes. Construisez pour celle qui serait déçue si elle disparaissait.

La mauvaise distribution

Construire un bon produit et supposer que les gens le trouveront. C'est le mythe le plus persistant dans la culture startup. « Construisez-le et ils viendront » a tué plus de produits que le mauvais code n'en a jamais tué.

Chez 1Health, le produit était prêt. Le problème de découverte n'était pas le produit. C'était arriver devant les bons patients et les bons fournisseurs au bon moment. Le produit fonctionnait. La distribution n'existait pas encore.

Des communautés r/startups et r/SaaS de Reddit, ce schéma domine les post-mortems. Les fondateurs décrivent avoir construit quelque chose d'utile, l'avoir lancé, et avoir regardé les analytics rester plat. Pas parce que le produit était mauvais. Parce que personne ne savait qu'il existait, et que les fondateurs n'avaient pas de plan pour comment le premier utilisateur le trouverait.

La leçon : la distribution n'est pas le marketing. La distribution est le produit. Si vous ne pouvez pas répondre « comment le premier utilisateur trouve-t-il ceci » en une phrase, le produit n'est pas prêt à être lancé.

Ce que je fais à la place

Avant de commencer quoi que ce soit, je réponds à trois questions. Qui a ce problème ? Comment le résolvent-ils aujourd'hui ? Qu'est-ce qui les ferait changer ? Si je ne peux pas répondre aux trois avec des spécificités, pas des abstractions, je ne suis pas prêt à construire.

« Tout le monde » n'est pas un public. « Les gens qui galèrent avec X » n'est pas un énoncé de problème. « Une meilleure solution » n'est pas une proposition de valeur. La spécificité est la stratégie.

J'ai appris ce rythme chez Grindstone, en travaillant sur un portefeuille d'entreprises. Celles qui peinaient n'avaient pas besoin de meilleurs produits. Elles avaient besoin de réponses plus claires à ces trois questions. Une fois les réponses claires, les décisions produit sont devenues évidentes. La roadmap s'est écrite toute seule. Pas parce que le travail était facile, mais parce que la réflexion était faite.

Une roadmap est une liste de paris. Les paris devraient porter sur le problème, pas sur la fonctionnalité. J'ai écrit à ce sujet auparavant : une roadmap est une liste de paris.

Les meilleurs produits que j'ai vus partagent un trait : ce sont ceux sans lesquels on ne peut plus vivre, pas ceux avec la meilleure interface. J'en ai aussi écrit : les meilleures interfaces sont celles qu'on ne remarque pas. Mais les meilleurs produits sont ceux dont on serait déçu de se passer. La différence est l'adéquation au problème, pas le design de l'interface.

Un test que vous pouvez faire cette semaine

Décrivez votre produit à quelqu'un qui ne vous connaît pas. Pas votre co-fondateur, pas votre conseiller, pas votre mère. Quelqu'un qui n'a aucune raison d'être poli.

Regardez son visage quand vous avez fini la première phrase. S'il demande « c'est pour qui ? » et que vous ne pouvez pas répondre spécifiquement, vous avez un problème en amont. S'il demande « pourquoi paieraient-ils pour ça ? » et que votre réponse commence par « parce que c'est mieux que... », vous avez un problème en amont. Mieux n'est pas une raison de changer. Mieux est une raison de remarquer. Changer nécessite un déclencheur, et le déclencheur n'est jamais « c'est mieux ». Le déclencheur est « je ne peux plus revenir à l'ancienne façon après avoir essayé ceci. »

Si la personne à qui vous l'avez décrit fait un haussement d'épaules, c'est des données. Si elle se penche en avant, c'est aussi des données. Le haussement d'épaules dit que le problème n'est pas assez net. L'avant penché dit que le problème est réel et que vous pourriez être proche.

Quatre-vingt-dix pour cent des efforts de développement de nouveaux produits échouent. La cause est presque toujours en amont de la construction. Le produit est la dernière chose qui casse. Commencez là, et remontez jusqu'à la réflexion qui l'a façonné. C'est là que vit la solution.