Le problème
Quand « il manque une feature » devient une cachette
Dans beaucoup de startups, la traction stagne pendant que le backlog grossit. La narration par défaut est simple : si seulement nous avions cette intégration, ce tableau de bord, cette conformité, le marché comprendrait enfin la valeur. Cette histoire est séduisante parce qu’elle propose un levier concret—le code—et un coupable externe—le timing, le prospect trop exigeant, la concurrence bruyante. Elle évite une vérité plus désagréable : vous ne savez peut‑être pas encore qui achète, pourquoi maintenant, à quel prix, et par quel canal un message tient.
Le problème n’est pas le produit en soi ; c’est la lucidité—la qualité de ce que vous croyez savoir sur le marché par rapport à ce que vous avez réellement observé. Une équipe peut shipper avec discipline et rester dans le brouillard stratégique si chaque release n’est pas attachée à une croyance falsifiable. Dans ce régime, le produit devient une machine à réponses sans questions nettes. Vous accumulez des capacités sans savoir lesquelles sont pertinentes pour un segment précis. Les prospects « intéressants » se multiplient sans se ressembler ; chacun tire la roadmap dans une direction différente.
La douleur est double. D’abord opportunité : vous brûlez du temps sur des paris décorrélés de la décision d’achat réelle. Ensuite humain : les équipes engineering ressentent le cynisme quand leurs sprints ne changent pas les métriques ; le commercial blâme le produit ; le fondateur blâme le marché. Personne ne nomme le vide central : contrat d’hypothèse absent entre les fonctions. Sans ce contrat, « problème de produit » est le symptôme le plus commode.
La lucidité fait mal parce qu’elle peut impliquer d’avouer que des mois de travail ont visé le mauvais ICP, le mauvais wedge, ou le mauvais niveau de prix. Ce n’est pas un échec moral : c’est un résultat d’apprentissage si vous le capturez tôt. Plus vous retarderez cette conversation, plus le produit devient une identité—et plus le pivot coûte cher émotionnellement. Le problème de fond est donc : comment rendre la lucidité aussi actionable que le backlog, pour que dire « non » à une feature soit une preuve de leadership, pas de friction personnelle.
Pourquoi ça échoue
Pourquoi la lucidité perd contre le backlog
Les organisations produit sont optimisées pour livrer. Les outils—tickets, sprints, CI—excellent à transformer une spécification en code déployé. En revanche, elles sont rarement équipées pour stocker les hypothèses marché avec la même granularité. Résultat : la vélocité produit devient une métrique de confort alors que la vélocité d’apprentissage—combien de croyances testées par semaine—reste implicite. Dans ce déséquilibre, toute discussion stratégique finit par se traduire en tâches parce que c’est la langue commune.
La lucidité exige aussi des pertes visibles. Choisir un ICP étroit signifie écrire des emails « non prioritaire pour l’instant » à des leads qui semblaient prometteurs. Monter un prix pour tester la valeur perçue risque des refus plus durs. Demander un pilote payant révèle que l’enthousiasme démo ne se convertit pas. Ces moments sont socialement coûteux ; le backlog offre une échappatoire noble : « on améliore l’expérience » au lieu de « on affronte le refus ».
Les parties prenantes externes renforcent parfois la confusion. Certains investisseurs demandent une roadmap « impressionnante » sans ancrer chaque item dans une preuve. Certains grands comptes vous demandent des fonctionnalités sans engagement ; dire oui flatte l’ego et remplit le tableau de bord d’activité. Sans gouvernance interne, ces demandes deviennent des proxy de validation—alors qu’elles ne sont que des signaux de curiosité.
Enfin, la lucidité est difficile à photographier. Une release a une capture d’écran ; une vérité sur l’acheteur a un tableur et des notes brutes. Dans une culture où « montrer » prime, le produit gagne par défaut. Briser ce biais demande des artefacts de lucidité aussi soignés que le design : synthèses d’entretiens, cartes de décision, critères d’échec écrits—pas pour la forme, mais pour forcer l’alignement. Tant que ces artefacts restent informels, le problème « produit » continuera d’être le réceptacle des incertitudes non dites.
Méthode concrète
Méthode : contrat de lucidité par initiative
Adoptez une règle simple : aucune initiative majeure sans ligne de lucidité. Une ligne contient : croyance marché ; signal qui la renforcerait ; signal qui la détruirait ; délai ; propriétaire. Si vous ne pouvez pas remplir ces cinq cellules, vous n’avez pas une spec produit—vous avez une aspiration.
Revues de lucidité (45–60 minutes, hebdo ou bi-hebdo) : parcourir les initiatives en cours. Pour chacune, poser « Qu’est-ce qu’on sait maintenant qu’on ignorait il y a quinze jours ? » Si la réponse est vide, la vélocité est probablement du bruit. Ensuite : « Quelle décision acheteur cette release facilite-t-elle ? » Pas « rendre la vie plus facile »—décision : signer, renouveler, élargir le périmètre, recommander en interne.
Matrice ICP : listez vos segments candidats avec trois colonnes : douleur observée (verbatim), pouvoir d’achat (preuve), urgence (événement déclencheur). Choisissez un segment primaire pour les quatre prochaines semaines. Les autres passent en « file froide » avec message honnête. Ce choix est politiquement difficile ; c’est là que la lucidité se distingue du pessimisme.
Prix et valeur : séparez « prix demandé » et « prix accepté ». Faites une micro-expérience : offre avec engagement minimal, ou alternativement deux packages pour voir où le silence apparaît. Documentez les objections mot pour mot.
Canal : une hypothèse de canal par sprint—pas douze tactiques à la fois. Critère : arriver à N conversations qualifiées avec un script stable.
Tableau « croyance / preuve » : colonnes date, croyance, preuve pour, preuve contre, décision suivante. Partagé avec commercial et produit. Quand une croyance survit trois cycles sans nouvelle preuve, elle est reléguée au rang de risque nommé—plus de statut « évident ».
Ce cadre ne remplace pas la vision ; il ancre la vision dans des points de contact falsifiables avec le marché. Il rend acceptable de dire : « Nous arrêtons cette feature parce que notre ligne de lucidité indique un mauvais segment—pas parce que l’équipe est lente. »
Exemple
Exemple : six mois de « demandes clients »
Une SaaS reçoit des demandes de trois verticales différentes. Chaque AE rapporte un « besoin critique ». Le produit orchestre une série de releases qui agrègent des cases à cocher : exports, rôles, intégrations partielles, rapports. Les démos s’allongent ; la complexité augmente. Pourtant le taux de conversion pilote stagne et le NPS interne côté engineering baisse.
Une revue de lucidité révèle que les trois verticales n’ont ni le même acheteur, ni le même substitut, ni le même cycle. La « feature manquante » était en réalité trois histoires différentes compressées en un seul backlog. La décision lucide : geler une release, couper deux verticales du discours commercial pendant six semaines, et concentrer les entretiens sur une seule chaîne décisionnelle. Résultat : moins de features livrées, mais hausse du taux de passage pilote → payant dans ce segment—parce que le message et le produit cohérent enfin avec un problème unique.
Le contrepoint : une équipe refuse la coupure « pour ne pas froisser » des leads tièdes. Elle prolonge le multi-segment. Les six mois suivants répètent le même plateau—preuve que la lucidité n’est pas un exercice de communication ; c’est un choix de renoncement informé. Le renoncement fait mal ; l’absence de renoncement coûte plus cher.
Cet exemple montre aussi le rôle du verbatim. Les décisions ont basculé quand l’équipe a collé au mur dix citations clients contradictoires et a été forcée de choisir laquelle représentait l’ICP primaire. Tant que les insights restent dans des têtes, le produit reste une souppe. La lucidité est souvent collaborative : commercial apporte les phrases réelles, produit traduit en scope, direction tient la ligne sur le segment. Sans ce triptyque, « problème produit » reste un fantôme.
Ce qu'il faut faire maintenant
Actions immédiates
1 — Gelez une release ou une feature en cours qui n’a pas de ligne de lucidité écrite. Pas pour toujours : le temps de remplir le contrat (croyance, signal pour, signal contre, date).
2 — Planifiez une revue lucidité de soixante minutes dans les sept jours avec commercial + produit + un cofondateur. Ordre du jour unique : qu’est-ce qu’on sait sur l’acheteur qui mérite de changer la roadmap ?
3 — Choisissez un ICP primaire par écrit pour les quatre prochaines semaines. Publiez-le en interne. Les exceptions doivent être nommées comme telles, pas absorbées en silence.
4 — Mesurez une métaphore simple : nombre de décisions acheteur documentées (oui / non / plus tard avec raison) par semaine. Si elle ne bouge pas malgré les sprints, vous n’aviez pas un problème de vélocité.
Pour des critères d’hypothèses et d’arrêt structurés, utilisez le guide stress-test. Si votre roadmap ressemble à une liste de souhaits sans ancrage, l’article roadmap probablement inutile pose les bons garde-fous. La lucidité n’est pas un état d’esprit : c’est une discipline de réunion et un format de document que vous répétez jusqu’à ce qu’ils deviennent plus fiables que l’instinct seul.
Pour aller plus loin
Lumor confronte votre idée à 13 rôles IA pour stress-tester vos hypothèses, révéler les angles morts et livrer un verdict, des scores et un plan d’exécution.