Chez ExpertItLab, on a passé des années à vouer un culte méticuleux à nos roadmaps trimestrielles. Chaque clôture de trimestre ressemblait à un rituel parfaitement rodé : des feuilles de calcul impeccables, des barres colorées sur des diagrammes temporels Jira et des présentations soignées devant la direction avec des livrables garantis. Au premier trimestre, on livrait la refonte du module de facturation récurrente ; au deuxième trimestre, l'intégration des passerelles bancaires automatisées ; au troisième trimestre, le générateur de rapports analytiques avancés.
La direction générale était rassurée par ce calendrier déterministe, les équipes commerciales promettaient des dates fermes aux prospects, et l'équipe produit se sentait couverte par un plan approuvé.
Sur le plan de l'exécution pure, on a réussi un sans-faute : à la fin du deuxième trimestre, 100 % des fonctionnalités inscrites sur la feuille de route étaient déployées en production sans un jour de retard. Tous les feux étaient au vert.
Le réveil a été brutal lors de l'analyse détaillée des cohortes d'utilisateurs. Le générateur de rapports analytiques, qui avait mobilisé trois ingénieurs et deux designers pendant douze semaines, n'était utilisé régulièrement que par 3 % de nos clients actifs. Pire encore, notre rétention n'avait pas progressé, car la principale cause des désabonnements était une lenteur de synchronisation que personne n'avait traitée, faute de figurer sur la roadmap officielle.
C'est là qu'on a posé la question essentielle : pourquoi continuons-nous à traiter les roadmaps produit comme des calendriers contractuels de livraison de fonctionnalités plutôt que comme des paris stratégiques révisables d'apprentissage ?
Le syndrome de la Feature Factory et l'anesthésie de la responsabilité
Lorsque la réussite d'une équipe produit est jugée sur sa capacité à respecter une liste de fonctionnalités prévues six mois plus tôt, elle cesse d'être une équipe produit pour devenir une simple usine à fabriquer du logiciel au kilomètre, ce que l'expert produit John Cutler nomme la "Feature Factory".
Dans une usine à fonctionnalités, la question "est-ce que ce que nous venons de déployer a réellement résolu le problème de notre utilisateur et créé de la valeur mesurable ?" disparaît complètement. Tout ce qui compte pour l'équipe, c'est de clore le ticket à temps pour passer au projet suivant du calendrier. On fête les lancements de fonctionnalités avec des croissants et des félicitations, sans jamais revenir examiner six semaines après si le comportement des clients a changé dans le sens espéré.
Cette mécanique déresponsabilise tout le monde. Si une fonctionnalité échoue sur le marché, le product manager peut se défendre en affirmant qu'il a respecté à la lettre le cahier des charges validé par le comité de direction. Les développeurs ont écrit du code fonctionnel conforme aux spécifications. La direction a obtenu ce qu'elle avait commandé. Tout le monde a bien fait son travail dans les clous, mais l'entreprise s'appauvrit en accumulant de la dette technique et des fonctionnalités fantômes dont personne ne veut.
Le coût d'opportunité colossal des promesses formulées trop tôt
Le principal vice d'une roadmap fixée à un horizon de six à douze mois est qu'elle gèle l'allocation des ressources techniques dans l'état de nos connaissances le plus ignorant : le premier jour du projet.
Le premier jour où l'on imagine un produit ou une fonctionnalité majeure, c'est précisément le moment où l'on en sait le moins sur les difficultés d'adoption réelles, les réticences psychologiques des utilisateurs et les subtilités d'intégration technique. Au fur et à mesure que le développement progresse et que les premiers utilisateurs testent des versions préliminaires, de nouvelles découvertes capitales émergent chaque semaine.
Dans une organisation prisonnière de sa feuille de route rigide, ces découvertes ne sont pas perçues comme des opportunités de pivot stratégique, mais comme des menaces perturbatrices. Combien de fois a-t-on entendu dans des réunions de planification : "Cette remarque du client est passionnante et révélatrice, mais nous ne pouvons pas la traiter maintenant car nous devons impérativement tenir l'engagement pris sur la livraison du module prévu en novembre" ? On sacrifie volontairement une idée immédiatement rentable pour honourer une promesse obsolète gravée dans un document PowerPoint six mois plus tôt.
Pourquoi les clients demandent des fonctionnalités mais achètent des soulagements
Une autre illusion très répandue dans la gestion de produit consiste à construire sa feuille de route en compilant servilement les demandes formulées par les prospects lors des rendez-vous de vente ou par les clients les plus véhéments.
Un client qui réclame une fonctionnalité formule presque toujours sa requête sous forme de solution technique préconçue : "Il me faut impérativement un export Excel personnalisé avec 35 colonnes et des filtres paramétrables". Si l'équipe produit se contente de recopier cette demande dans sa roadmap, elle livre une usine à gaz complexe qui encombre l'interface.
En creusant la motivation réelle du client par l'observation de son quotidien, on découvre souvent que ce besoin d'export massif dissimule simplement une incapacité à extraire deux chiffres précis pour sa comptabilité hebdomadaire. Une simple notification automatisée par courriel le lundi matin règle son problème à 100 % en deux jours de développement, là où la construction de l'outil d'export réclamait six semaines d'effort. Bâtir une roadmap sur des listes de fonctionnalités demandées par les clients revient à prescrire des médicaments choisis par le patient sur catalogue sans avoir posé le moindre diagnostic clinique.
De la liste d'épiceries au pilotage par les résultats d'affaires (outcomes)
Rompre avec cette culture néfaste exige de transformer en profondeur la nature même de la roadmap. Il ne s'agit pas de renoncer à donner une vision et une direction à l'entreprise, mais de changer radicalement l'unité de mesure de nos engagements.
Au lieu d'écrire sur la roadmap "Développer le module X au trimestre 3", nous avons appris à formuler nos objectifs sous forme de problèmes à résoudre et d'impacts mesurables : "Au trimestre 3, notre pari prioritaire est de diviser par deux le délai moyen de règlement des factures chez nos clients utilisateurs de l'offre PME".
Cette distinction change tout. Si la première idée testée ne produit pas l'effet escompté au bout de trois semaines de déploiement en version bêta, l'équipe n'a aucune obligation de s'acharner dessus pendant deux mois pour cocher une case. Elle est au contraire incitée à couper court, à tester une autre hypothèse plus légère et à pivoter jusqu'à ce que la métrique de résultat métier bouge effectivement. L'autonomie de l'équipe réside dans le choix des solutions, tandis que la direction garde la maîtrise des priorités d'affaires.
Chez ExpertItLab, on a changé d'avis sur le rôle d'une feuille de route produit. On a jeté nos anciens diagrammes de Gantt aux oubliettes et renoncé définitivement à publier des calendriers de fonctionnalités à douze mois.
Nos roadmaps actuelles tiennent sur un tableau simple articulé en trois colonnes dynamiques : Maintenant (les deux ou trois problèmes critiques qu'on résout actuellement avec des hypothèses testées en production), Bientôt (les opportunités immédiates dont les contours se précisent), et Plus tard (les paris stratégiques à explorer quand les premiers auront produit leurs résultats). Les seules dates qui figurent encore dans nos documents sont des contraintes réglementaires légales indiscutables.
Le résultat de cette transition a été libérateur : nos équipes ont arrêté de se gargariser du nombre de tickets déployés par sprint pour célébrer les améliorations concrètes d'usage et de rétention chez nos clients. La qualité moyenne de ce qu'on livre a augmenté parce qu'on s'autorise enfin à jeter rapidement ce qui ne marche pas avant que cela ne devienne un fardeau technique permanent.
Voici la question qu'on pose à chaque responsable de produit et dirigeant d'entreprise : mesurez-vous la valeur de votre organisation au volume de code livré à l'heure, ou à l'impact réel et mesurable que ce code génère dans la vie de vos utilisateurs ?
