La roadmap produit dont un fondateur non technique a vraiment besoin

Pourquoi la roadmap par trimestres aux dates fixes se casse trop tôt, et la routine de quatre questions qui organise quoi construire, dans quel ordre, avec ceux qui codent pour vous.

Une fondatrice nous a montré sa roadmap produit six semaines après avoir bouclé sa seed. Elle était magnifique : un tableau Notion avec quatre colonnes, une par trimestre, vingt-trois fonctionnalités réparties sur des barres colorées jusqu’à décembre. Elle avait copié le format d’un template Miro. Le problème est apparu à la première réunion avec l’équipe qui allait construire. Personne ne savait dire ce qui devait être prêt en premier, ni pourquoi. La roadmap ressemblait à une promesse pour le board. Elle ne servait à rien comme instruction pour ceux qui allaient écrire le code.

Une roadmap produit est le document qui dit ce que votre entreprise va construire, dans quel ordre et avec quel objectif business derrière. Sur le papier, tout le monde est d’accord. En pratique, la plupart des fondateurs en phase précoce montent la mauvaise version : un planning avec des dates fixes qui vieillit en deux semaines. Pour un fondateur non technique, quelqu’un qui n’ouvrira pas l’éditeur de code et dépend d’une équipe ou d’un partenaire pour livrer, la bonne roadmap est autre chose. C’est une décision de séquence, pas un calendrier.

Ce qu’est une roadmap produit (et ce qu’elle n’est pas)

Il vaut la peine de séparer trois choses que l’on confond souvent.

Le backlog est la liste de tout ce qui pourrait être fait. Il est long, en désordre et grandit tout seul. Personne ne promet le backlog entier.

Le planning est une séquence de tâches avec des dates. Il fonctionne quand le travail est prévisible, comme un chantier au périmètre verrouillé. Le logiciel en phase précoce n’est pas prévisible, donc le planning devient vite une fiction.

La roadmap se situe au milieu. Elle répond à une question que le backlog et le planning n’abordent pas : compte tenu de tout ce que l’on pourrait faire, que va-t-on faire maintenant, et pourquoi cet ordre et pas un autre. Une bonne roadmap est un outil de communication et de priorité, pas un contrat de délai. La définition que Google met en avant pour cette recherche le dit déjà : ce n’est pas un planning statique aux dates fixes, c’est un outil adaptable qui relie la vision de long terme aux tâches de court terme.

La différence n’est pas sémantique. Elle décide si votre équipe construit la bonne chose ou se contente de dérouler une liste.

Pourquoi la roadmap par trimestres se casse trop tôt

La roadmap à quatre colonnes a une prémisse cachée : que vous savez, en janvier, ce qui comptera en septembre. Dans une entreprise mature, avec un produit en production et des données d’usage, cette prémisse tient parfois. Dans une entreprise de six mois, elle est presque toujours fausse.

Vous découvrez encore qui est votre client, quel problème fait vraiment mal et ce qu’il paie pour le résoudre. Chaque semaine d’usage réel du produit change votre liste de priorités. Quand cela arrive, la roadmap aux dates fixes devient un fardeau : soit vous l’ignorez (et elle perd son sens), soit vous la suivez à la lettre (et vous construisez des choses qui n’importent plus).

Il existe un nom pour expliquer pourquoi ces plannings explosent : le biais de planification, décrit par Daniel Kahneman. Les équipes sous-estiment systématiquement les délais et les coûts, même en sachant que des projets similaires ont pris du retard avant. Une roadmap de douze mois avec des dates, c’est le biais de planification transformé en présentation de slides. Elle rassure et fait perdre le focus.

Le vrai coût n’est pas le retard. C’est ce que vous n’apprenez pas. Chaque fonctionnalité que vous vous engagez à livrer à une date est un pari posé avant d’avoir de l’information. Plus la date est lointaine, pire est le pari.

Séquencez par le risque, pas par le calendrier

Le déclic mental est simple à dire et difficile à faire : arrêtez d’ordonner la roadmap par quand, et commencez à l’ordonner par risque.

Le risque ici signifie une incertitude qui peut tuer le produit. Toute idée de produit porte quelques hypothèses qui, si elles sont fausses, font tout tomber. « Les gens vont confier de l’argent à une app d’une marque qu’ils ne connaissent pas. » « Le médecin va troquer son tableur contre notre système. » « On peut livrer ça à un prix qui boucle les comptes. » Ces hypothèses sont votre vraie roadmap. L’ordre de construction devrait être celui qui teste la plus dangereuse en premier.

Cela inverse l’instinct de la plupart des fondateurs, qui commencent par ce qui est facile à construire ou joli à montrer. Construire le facile en premier repousse la seule question qui compte : est-ce que ça marche ? Marty Cagan, du Silicon Valley Product Group, résume la bonne posture en une ligne : une roadmap devrait porter sur des résultats, pas des fonctionnalités. Vous ne planifiez pas de livrer des écrans. Vous planifiez de réduire l’incertitude.

La roadmap des quatre questions

Quand un fondateur nous demande de l’aide pour monter une première roadmap, nous ne commençons pas par l’outil. Nous commençons par quatre questions. Elles tiennent sur une feuille et organisent n’importe quelle liste d’idées dans un ordre défendable.

1. Quelle hypothèse, si elle est fausse, tue le produit ? Celle-là passe en premier. Pas la fonctionnalité la plus demandée, pas la plus facile. La plus dangereuse. Si vous ne savez pas si les gens paient, le premier item de la roadmap est la plus petite chose qui fait payer quelqu’un.

2. Qu’est-ce qui doit être en ligne pour le prochain événement externe ? Les fondateurs ne vivent pas dans le vide. Il y a une prochaine levée, un client phare qui a signé une lettre d’intention, une échéance réglementaire. La roadmap s’ancre sur cet événement réel, pas sur des trimestres génériques. Demandez : qu’est-ce qui doit exister, et fonctionner, avant cette date précise ?

3. Qu’est-ce qui peut s’apprendre moins cher avant de construire ? Toute hypothèse n’a pas besoin de code pour être testée. Parfois une landing page, dix entretiens ou une simulation manuelle répondent à la question pour un centième du coût. Ce qui peut se répondre sans construire quitte la roadmap d’ingénierie et entre dans celle du discovery produit.

4. Qu’est-ce qui est réversible et qu’est-ce qui ne l’est pas ? Les décisions réversibles (la couleur d’un bouton, le texte d’un parcours) ne méritent pas de place dans la roadmap. Les décisions difficiles à défaire (l’architecture de données, le modèle de facturation, la plateforme) la méritent. Mettez du poids là où l’erreur coûte cher.

Répondez à ces quatre questions et l’ordre apparaît presque tout seul. Ce que vous tenez cesse d’être une liste de souhaits et devient une séquence de paris, du plus risqué au moins risqué.

La roadmap est le contrat avec celui qui construit

Voici la partie que les templates produit ignorent, parce qu’ils ont été écrits pour des entreprises avec une équipe produit interne. Si vous êtes un fondateur non technique, il y a de bonnes chances que celui qui construit votre produit ne soit pas vous. C’est une équipe sous contrat, un partenaire logiciel, un développeur. Et alors la roadmap gagne une seconde fonction : c’est le document qui vous aligne avec ceux qui mettent la main dans le code.

Une roadmap vague est une marge pour le malentendu. « Système de paiement » peut signifier une intégration d’une semaine ou un moteur de facturation récurrente de deux mois. Quand l’item de la roadmap est clair sur le résultat visé (« le client peut payer un abonnement mensuel et recevoir une facture »), la conversation sur le périmètre, le délai et le coût devient honnête. Quand ce n’est qu’un titre sur une barre colorée, quelqu’un va être déçu.

C’est pour cela que nous traitons la roadmap et le document d’exigences comme des pièces du même système. La roadmap décide l’ordre ; l’exigence transforme le prochain item de la file en quelque chose de constructible. Un partenaire technologique qui mérite votre argent vous aidera à écrire les deux, et sera en désaccord avec vous quand l’ordre n’a pas de sens d’ingénierie. Un bon partenaire n’est pas une boîte noire. Il vous montre l’arbitrage avant de vous le facturer.

Comment monter la vôtre en un après-midi

Vous n’avez pas besoin d’un logiciel cher ni d’un cours. Vous avez besoin d’une structure simple et de la discipline de la garder honnête.

Utilisez trois horizons au lieu de dates : maintenant, ensuite et plus tard. « Maintenant », c’est ce qui est en construction ou démarre dans les prochaines semaines, et ça devrait être court, deux ou trois items au maximum. « Ensuite », c’est ce qui vient après, si ce qui est maintenant confirme les hypothèses. « Plus tard », c’est le parking des idées que vous ne voulez pas oublier, mais sur lesquelles vous ne vous engagez pas. Ce format (popularisé sous le nom de now/next/later) a une vertu rare : il est honnête sur ce que vous ne savez pas. Personne n’est tenu à une date qu’il n’a pas promise.

Pour chaque item dans « maintenant », écrivez une phrase de résultat, pas de fonctionnalité. « Réduire le temps d’inscription de dix minutes à deux » dit plus que « refaire l’onboarding ». Le résultat guide les cent petites décisions que l’équipe prendra sans vous demander.

Révisez la roadmap à un rythme fixe, toutes les deux à quatre semaines, avec celui qui construit. La révision est le produit. Une roadmap qui ne change jamais n’est pas stable ; elle est ignorée. L’outil où vous dessinez ça (un tableur, un tableau Notion, un Miro) est la partie la moins importante de toute l’histoire. La séquence est ce qui compte.

Avant de déplacer un item de « ensuite » vers « maintenant », faites-le passer par le même test que vous utiliseriez pour décider quelles fonctionnalités viennent en premier : réduit-il la plus grande incertitude qui reste ? Sinon, il est probablement dans le mauvais horizon.

Les erreurs que l’on voit le plus

Trois schémas reviennent dans presque toutes les premières roadmaps que nous relisons.

Le premier est de confondre roadmap et backlog. Le fondateur déverse soixante items sur le tableau et appelle ça une roadmap. Une roadmap avec soixante items ne priorise rien ; elle enregistre seulement du désir. Si tout est dans la roadmap, rien n’y est.

Le second est de vendre la roadmap comme une promesse de date à l’investisseur. Le board demande de la prévisibilité, le fondateur livre un Gantt de douze mois, et à partir de là chaque retard devient une conversation difficile qui n’avait pas besoin d’exister. Il est plus fort de montrer la logique de la séquence (« on prouve X avant de dépenser sur Y ») que de promettre septembre.

Le troisième est de construire ce qui est facile au lieu de ce qui est risqué. C’est l’erreur la plus humaine, parce que livrer fait du bien. Mais de la vitesse à construire la mauvaise chose n’est pas du progrès. C’est juste de la dette qui s’accumule plus vite.

Une roadmap produit bien faite n’est pas celle qui a le plus de cases. C’est celle qui rend clair quel est le prochain pari de l’entreprise, et pourquoi. Pour un fondateur non technique, cette clarté vaut plus que n’importe quel template : c’est ce qui sépare une équipe qui construit avec intention d’une équipe qui déroule une liste à laquelle plus personne ne croit.

Questions fréquentes

Quelle est la différence entre une roadmap et un backlog ?
Le backlog est la liste de tout ce qui pourrait être fait, sans ordre ni engagement. La roadmap est la tranche priorisée : ce que vous allez faire maintenant et ensuite, et pourquoi. Le backlog est un stock ; la roadmap est une décision.

Une roadmap produit a-t-elle besoin de dates ?
Au début, presque jamais. Les dates fixes en phase de forte incertitude deviennent une fiction. Préférez les horizons (maintenant, ensuite, plus tard) et ancrez seulement sur le prochain événement externe réel, comme une levée ou un client phare. Les dates détaillées ont du sens quand le produit a déjà de l’usage et de la prévisibilité.

Y a-t-il un exemple de roadmap produit simple ?
Le format le plus utile pour commencer a trois colonnes : maintenant, ensuite et plus tard. Dans « maintenant », deux ou trois items, chacun écrit comme un résultat (« permettre le paiement d’un abonnement mensuel »), pas comme une fonctionnalité. C’est un exemple qui tient dans un tableur et dit plus qu’un template plein de barres colorées.

Quel outil utiliser pour faire la roadmap ?
Celui que vous avez déjà. Un tableur, un tableau Notion, un Miro ou un Canva font le travail pareil. L’outil n’améliore pas la séquence ; il dessine seulement la décision que vous avez déjà prise. Dépensez votre énergie sur l’ordre, pas sur le visuel.

Qui doit monter la roadmap si je ne suis pas technique ?
Vous définissez la direction et les priorités business ; celui qui construit aide à ordonner par ce qui est faisable et à estimer l’effort. Si vous externalisez le développement, la roadmap doit être construite avec le partenaire. C’est le document qui garde les deux côtés sur la même page.