Pourquoi les produits numériques échouent, et quoi faire pour l'éviter

Les échecs célèbres couvrent des produits très différents. Quibi, Google Wave, Jawbone, Pebble, Wunderlist, Rdio. Les raisons qui les ont tués sont à peu près les mêmes. Aucune de ces boîtes n'a échoué parce que l'équipe était paresseuse ou sous-financée. La plupart avaient du vrai talent, du vrai argent et de la vraie ambition. Elles sont mortes quand même. Les raisons sont étonnamment cohérentes d'une catégorie à l'autre, et elles apparaissent tôt, bien avant que l'échec public ne devienne visible.

Pourquoi ils échouent vraiment

1. Ils ne parlent pas aux utilisateurs assez tôt

La plupart des équipes SaaS sautent la vraie recherche utilisateur parce qu'elles pensent connaître l'utilisateur. Le produit finit parfait pour l'utilisateur imaginé, qui n'existe pas. Quibi a dépensé 1,75 milliard de dollars sur un service de streaming que personne n'avait demandé. Google Wave a livré à des utilisateurs perdus qui n'ont jamais compris à quoi ça servait, et les démos de lancement étaient surtout des employés Google qui montraient à d'autres employés Google. Les deux produits avaient des équipes brillantes. Les deux ont construit pour des utilisateurs qui n'existaient que dans des slides.

Le remède n'est pas « plus de recherche ». Le remède, c'est de la recherche à la bonne phase. Cinq entretiens avant d'écrire du code. Cinq autres après le premier prototype. Arrête quand tu n'es plus surpris par ce que les utilisateurs te disent. Refais une série quand la prochaine grosse fonctionnalité est prête. Les équipes qui réussissent ça ne sont pas celles avec les plus gros budgets de recherche. Ce sont celles dont les designers et les PMs parlent personnellement aux utilisateurs toutes les deux semaines, même quand ils pensent connaître la réponse.

Le signe que tu fais ça mal : tu décris ton utilisateur en adjectifs (« professionnels occupés qui se soucient de productivité ») au lieu de comportements précis (« power users d'Excel qui maintiennent trois tableurs personnels et détestent chaque nouvel outil qui en remplace un »). Les utilisateurs-adjectifs sont imaginés. Les utilisateurs-comportements sont réels.

2. Ils itèrent trop lentement

Une équipe passe six mois à construire la fonctionnalité X, puis apprend du feedback utilisateur que ce que les gens voulaient, c'était la fonctionnalité Y. Chaque semaine avant que tu livres, le coût d'avoir tort se cumule. Le calcul n'est pas subtil : une équipe qui livre en deux semaines et apprend qu'elle s'est trompée a payé deux semaines. Une équipe qui livre en six mois et apprend la même chose a payé six mois et construit six mois d'infrastructure de support pour la mauvaise chose.

Livre la plus petite version qui fait quelque chose d'utile. Mets-la devant cinq utilisateurs. Répare ce qu'ils cassent. Recommence. Les équipes qui survivent à de mauvaises idées sont celles qui trouvent la bonne avant que la piste ne s'épuise. L'erreur classique : l'équipe qui retarde le lancement pour ajouter « juste une fonctionnalité de plus » et livre trois mois en retard avec un produit pas meilleur que la version qu'elle aurait pu livrer à temps.

La version cachée du même piège : l'équipe qui livre vite en esprit mais lentement en pratique parce que chaque release passe par six semaines de QA, deux tours de revue parties prenantes, et une fenêtre de lancement qui s'ouvre une fois par trimestre. Regarde la cadence réelle de livraison, pas celle déclarée. Si ton code est en production dans la semaine où il a été écrit, tu peux itérer. Si ça prend un mois, tu ne peux pas.

3. Ils sautent les tests d'utilisabilité

Les designers trouvent leur interface intuitive parce qu'ils l'ont conçue. Les utilisateurs la trouvent confuse parce qu'ils ne l'ont pas conçue. Un test de trente minutes avec trois utilisateurs fait remonter plus de problèmes d'usabilité qu'une semaine de revue interne. C'est vrai même pour des designers avec vingt ans d'expérience. Le biais est structurel : tu ne peux pas dé-savoir ce que tu as mis à l'écran. L'utilisateur, lui, peut.

Chaque changement de design qui compte devrait passer par au moins trois vrais utilisateurs avant d'arriver en production. Des outils comme Maze et UserTesting rendent ça moins cher que le coût d'avoir tort en prod. Encore moins cher : envoie le prototype à cinq collègues hors du projet, donne-leur une tâche, regarde en silence. Les mêmes tests qui coûtent 500 $ sur une plateforme produisent l'essentiel de leurs insights dans les deux premières sessions, peu importe la plateforme.

Les tests d'utilisabilité qui comptent le plus sont ceux que l'équipe ne voulait pas faire. Le bouton dont tout le monde était d'accord qu'il était évident. Le flow que personne n'a remis en question. Teste ceux-là en premier. Les tests dont tu connais déjà les résultats sont ceux qui valent le moins le coup.

4. Ils choisissent la mauvaise base technique

Le mauvais stack veut dire que l'équipe ne peut pas livrer vite, ou que le produit s'effondre quand l'usage grossit. Pebble et Wunderlist avaient tous les deux de vrais utilisateurs mais ne pouvaient pas tenir économiquement à l'échelle. Pebble avait des coûts unitaires hardware qui n'ont jamais marché. Wunderlist avait une architecture de synchronisation qui devenait coûteuse à l'échelle d'usage de Microsoft. Les deux avaient des utilisateurs fidèles. Aucun n'avait de chemin pour faire fonctionner le produit à l'échelle où il s'est retrouvé.

Choisis la techno que l'équipe connaît déjà plutôt que celle qu'elle aimerait apprendre. La techno ennuyeuse livre des produits. La techno à la mode livre des réécritures. L'équipe Postgres-et-rendu-côté-serveur va sortir plus que l'équipe GraphQL-et-microservices pendant les trois premières années de n'importe quel nouveau produit. Après, ça dépend de si la portée de l'équipe a dépassé sa prise.

L'autre mode d'échec technique, c'est le sur-engineering trop tôt. Construire pour dix millions d'utilisateurs quand tu en as dix. Ajouter une architecture microservices avant d'avoir un product-market fit. La plupart des produits qui échouent techniquement échouent parce qu'ils ont passé les premières années à construire une scale dont ils n'avaient pas besoin, et il ne leur restait plus de temps pour construire le produit que l'utilisateur voulait vraiment.

5. Ils pourrissent par la politique interne

Le produit perd son cap quand trop de voix ont le même poids sur les décisions de design. Une équipe où chaque PM, chaque eng lead et le CEO ont chacun un vote sur l'UX livre la moyenne de toutes les opinions, ce qui est médiocre par construction. La moyenne n'est pas une stratégie viable dans un marché saturé. Le produit a besoin d'un point de vue. La politique dilue le point de vue jusqu'à ce qu'il disparaisse.

Nomme une seule personne responsable de chaque décision et dis-le explicitement. Va avec elle par défaut sauf si les données utilisateur disent autre chose. Le consensus lent tue plus de produits que les mauvaises décisions. L'équipe qui livre une feature clairement fausse et en apprend quelque chose a avancé plus que celle qui a débattu six mois et livré un compromis que personne n'aimait.

Un signal précis : compte le nombre de réunions où la même décision est prise plusieurs fois. Trois, c'est normal dans une organisation saine. Huit, c'est de la dysfonction. Douze, c'est le bruit d'un produit qui meurt. Quand on est rendu à douze, les gens dans les réunions savent ce qui se passe. Personne ne veut le dire à voix haute.

Ce que les échecs célèbres ont en commun

La plupart avaient de l'argent. Certains avaient de vrais utilisateurs. Aucun n'avait un product-market fit à partir duquel itérer. Tous ont manqué de marge avant de pouvoir en trouver un. Quibi ne pouvait pas pivoter parce que la prémisse entière du produit était le format que personne ne voulait. Google Wave était trop complexe à expliquer dans les huit secondes qu'on accorde à un nouvel outil. Jawbone s'est fait coincer aux deux bouts de sa gamme : par Apple en haut, par des alternatives moins chères en bas. Rdio avait la meilleure app musicale mais s'est fait dépasser sur les licences de contenu par Spotify, qui a ensuite itéré plus vite sur les fonctionnalités sociales. Le pattern : chacun avait quelque chose qui aurait pu marcher. Aucun ne l'a trouvé avant que le budget s'épuise.

La partie ingrate

La prévention, c'est ennuyeux. Parle aux utilisateurs. Livre vite. Teste souvent. Choisis une techno que tu comprends. Décide qui décide. Rien de tout ça n'est nouveau et rien n'est difficile. Les boîtes encore là sont celles qui l'ont fait avec constance quand les échecs célèbres ne l'ont pas fait.

La version plus dure du même conseil : fais-le quand c'est inconfortable. Parle aux utilisateurs quand leurs retours pourraient forcer un reset de la roadmap. Livre vite quand la version est gênante. Teste l'utilisabilité de la fonctionnalité que tout le monde voudrait sauter. Choisis une techno ennuyeuse quand l'équipe est excitée par le nouveau framework. Prends la décision impopulaire quand le consensus serait plus lent et plus facile. Les équipes qui survivent à leurs mauvaises idées n'ont pas de meilleurs instincts. Elles ont des boucles de feedback plus courtes entre la mauvaise idée et le changement de cap.

Si l'article a une seule affirmation pratique, c'est celle-ci : la plupart des échecs produit sont visibles six mois avant qu'ils n'arrivent. Les signes sont généralement là. L'équipe sent généralement que quelque chose cloche. La raison pour laquelle l'échec arrive quand même, c'est que personne ne veut être la personne qui le dit. Sois cette personne plus tôt. Le coût d'avoir tort est petit. Le coût d'attendre, c'est la boîte.