La roadmap est le document de travail central du CPO. Elle définit le quotidien des équipes et traduit la vision stratégique en actions concrètes. Mais attention : une roadmap n'est pas un engagement annuel figé, et c'est là que la plupart des équipes se piègent.
C'est une des routes possibles vers une destination partagée. Elle évolue en permanence, au rythme des apprentissages et des contraintes.
J'ai vu des roadmaps construites comme des contrats (chaque trimestre engravé, chaque feature datée au mois près) et qui devenaient des sources de conflit dès la première semaine de retard. J'en ai vu d'autres si floues qu'elles ne servaient à rien : personne ne savait quoi faire le lundi matin. La bonne roadmap se tient entre ces deux extrêmes. Elle est assez précise pour orienter, assez souple pour absorber le réel.
Les 4 étapes de construction
| Étape | Objectif | Fréquence |
|---|---|---|
| Identifier les besoins | Collecter les inputs de tous les départements | Continue |
| Prioriser | Évaluer impact vs effort | Hebdo/Mensuel |
| Communiquer | Aligner les équipes sur la vision | Trimestriel |
| Piloter | Ajuster selon les retours terrain | Hebdo |
Du nord au quotidien : vision → OKR → roadmap
Avant de parler de format ou de priorisation, il faut comprendre d'où vient une roadmap. Elle ne sort pas de nulle part, et surtout pas d'une réunion où chacun propose ses idées préférées. Elle découle d'une chaîne logique qu'il faut tenir bout à bout.
En haut, la vision : où veut-on amener le produit dans deux ou trois ans, et pourquoi. Elle change rarement. En dessous, les OKR : les objectifs mesurables qu'on se fixe sur un trimestre ou un semestre, comme « augmenter la rétention à 30 jours de 40 % à 55 % », « réduire le temps de premier succès utilisateur de moitié ». Ces objectifs traduisent la vision en cibles concrètes pour une période donnée. Enfin, la roadmap : l'ensemble des chantiers qu'on pense devoir mener pour atteindre ces objectifs.
L'ordre compte. Une roadmap construite sans OKR au-dessus d'elle devient vite une liste de courses : des features juxtaposées sans qu'on sache laquelle sert quel objectif. Quand un sales pousse pour une fonctionnalité, la question n'est pas « est-ce une bonne idée ? » : presque toutes les idées sont bonnes dans l'absolu. La question est « quel OKR du trimestre cette idée fait-elle avancer, et de combien ? ». Si la réponse est « aucun », c'est un signal. Pas forcément un refus définitif, mais une mise en attente assumée.
Ce lien vision → OKR → roadmap est aussi ce qui rend la roadmap défendable. Quand le CEO demande pourquoi tel projet passe avant tel autre, on ne répond pas par une intuition. On remonte la chaîne : ce projet sert cet objectif, qui sert cette partie de la vision.
1. Identifier les besoins
Les besoins viennent de partout, pas que du CODIR :
| Source | Type d'input |
|---|---|
| Produit | Retours utilisateurs, analytics, UX research |
| Sales | Demandes clients, objections récurrentes, deals perdus |
| Marketing | Tendances marché, positionnement concurrentiel |
| Support | Bugs récurrents, frustrations utilisateurs |
| Tech | Dette technique, opportunités d'optimisation |
| Finance | Contraintes budget, objectifs de marge |
Cette collecte est continue. Chaque interaction client, chaque analyse de données peut faire émerger un nouveau besoin. Le piège classique : ne collecter qu'auprès des sources qui crient le plus fort. Le sales remonte les demandes des prospects en cours de deal, le support remonte les bugs urgents, et la roadmap finit dictée par l'urgence du moment plutôt que par la valeur réelle. Tenir un canal d'entrée structuré (un endroit unique où chaque demande arrive, avec son contexte et son demandeur) évite que les besoins se négocient dans les couloirs.
Un point souvent oublié : la dette technique et les besoins d'infrastructure sont des besoins comme les autres. Une équipe qui n'inscrit jamais ces sujets sur sa roadmap finit par ralentir sur tout le reste. Il faut leur réserver une part (disons un cinquième de la capacité) et la défendre comme on défend une feature client.
2. Prioriser
Une fois les besoins collectés, il faut trancher. Deux cadres simples suffisent dans la grande majorité des cas.
Le premier, impact / effort, est le plus accessible. On place chaque chantier sur deux axes : la valeur attendue, et le coût pour le réaliser. Les chantiers à fort impact et faible effort passent en premier : ce sont les évidences. Ceux à faible impact et fort effort tombent en bas de pile. Une matrice 2×2 dessinée au tableau en réunion fait déjà 80 % du travail et a l'avantage d'être lisible par tout le monde, y compris un CEO non-tech.
Quand on veut un peu plus de finesse, le cadre RICE ajoute deux dimensions :
| Critère | Question |
|---|---|
| Reach | Combien d'utilisateurs sont touchés sur la période ? |
| Impact | Quelle ampleur de changement pour chacun ? |
| Confidence | À quel point est-on sûr de ce Reach et cet Impact ? |
| Effort | Combien de personne-mois pour le réaliser ? |
Le score se calcule en (Reach × Impact × Confidence) / Effort. L'intérêt de RICE sur le simple impact/effort, c'est la confidence : elle force à être honnête sur ce qu'on sait vraiment. Un projet à fort impact théorique mais à confidence de 30 % redescend mécaniquement dans la pile, ce qui est sain, parce qu'on ne mise pas gros sur une hypothèse fragile sans l'avoir testée d'abord.
Attention : l'effort ne se limite jamais au développement. Incluez :
- Conception (Product, Design)
- Préparation marketing et go-to-market
- Formation support et sales
- Conformité réglementaire
J'ai vu des équipes sous-estimer d'un facteur deux le coût d'une feature parce qu'elles n'avaient compté que le temps des développeurs. Le jour du lancement, le support n'était pas formé et le marketing n'avait rien préparé. Les estimations en « T-shirt sizing » (S, M, L, XL) suffisent à ce stade : la précision viendra au moment de planifier, pas de prioriser.
En création d'équipe tech & produit, je vous aide à mettre en place les rituels et outils pour construire une roadmap efficace, et surtout à la communiquer pour aligner toute l'entreprise.
Comment prioriser les fonctionnalités de son produit
Priorisez chaque fonctionnalité selon sa valeur business attendue divisée par son coût total. Reliez chaque chantier à un objectif chiffré (rétention, conversion, revenu), tranchez avec une matrice impact/effort, et affinez avec RICE quand l'incertitude est forte. Ce qui ne sert aucun objectif passe en attente, pas en refus.
Prioriser, ce n'est pas classer des idées par préférence : c'est traduire chaque fonctionnalité en valeur d'entreprise, puis comparer cette valeur à son coût réel. Les deux cadres décrits plus haut (impact/effort et RICE) suffisent, à condition de leur donner un sens business plutôt qu'une note abstraite.
Voici comment je traduis chaque critère en langage de dirigeant, pour qu'un CEO non-tech puisse arbitrer avec moi :
| Critère du framework | Ce que ça veut dire côté business |
|---|---|
| Impact | Quel objectif chiffré ça fait bouger (rétention, conversion, panier, churn) ? |
| Reach | Combien de clients ou de revenu sont concernés sur le trimestre ? |
| Confidence | Est-ce une certitude marché ou un pari à valider ? |
| Effort | Coût total : produit, design, dev, support, marketing, conformité |
Trois réflexes évitent les erreurs les plus coûteuses. D'abord, ne jamais prioriser une fonctionnalité qui ne sert aucun objectif du trimestre : si elle ne fait bouger aucun chiffre, elle attend. Ensuite, traiter la confidence comme un garde-fou : un gain théorique énorme mais reposant sur une hypothèse non testée redescend dans la pile, parce qu'on ne mise pas gros à l'aveugle. Enfin, compter l'effort complet, pas seulement le temps des développeurs : j'ai vu des équipes sous-estimer d'un facteur deux le coût d'une feature en oubliant la formation support et le go-to-market.
Au tout début, quand le produit cherche encore sa traction, ce calcul prend une couleur particulière : la « valeur » d'une fonctionnalité n'est pas le revenu qu'elle rapporte, mais l'incertitude qu'elle lève. C'est tout l'enjeu de la phase où l'on cherche à passer du MVP au Product-Market Fit, et c'est exactement ce que montre l'exemple de roadmap plus bas.
Now / Next / Later plutôt que des dates
Voici le choix de format le plus structurant, et celui que je recommande à la quasi-totalité des équipes early-stage : abandonner les jalons datés au profit d'un découpage en horizons de confiance. C'est d'autant plus vrai quand on cherche encore à passer du MVP au Product-Market Fit : à ce stade, la roadmap est un outil d'apprentissage, pas un engagement de livraison.
| Horizon | Niveau d'engagement |
|---|---|
| Now | On y travaille, le scope est cadré, on s'engage sur la direction |
| Next | Ça vient ensuite, le « pourquoi » est clair, le « comment » bouge encore |
| Later | C'est sur le radar, ni cadré ni engagé : une intention, pas un plan |
La force de ce format tient à ce qu'il dit l'honnête vérité sur l'incertitude. Personne ne peut sérieusement promettre qu'une feature prévue dans six mois sortira tel jour : trop d'inconnues d'ici là. Le format now/next/later assume cette incertitude au lieu de la maquiller derrière un faux calendrier. Plus l'horizon est lointain, plus le niveau de détail et d'engagement baisse, ce qui correspond exactement à ce qu'on sait réellement.
Les jalons datés gardent leur place, mais dans des contextes précis : un engagement contractuel client, une contrainte réglementaire à date fixe, un lancement coordonné avec une campagne marketing. Là, la date est une vraie contrainte, pas une illusion de contrôle. Le réflexe à corriger : ne pas dater par défaut. On date quand une date existe vraiment dans le réel, pas pour faire plaisir au board.
Exemple de roadmap produit pour une startup early-stage
En early-stage, la roadmap ne sert pas à livrer des fonctionnalités : elle sert à lever des hypothèses. Tant que le Product-Market Fit n'est pas confirmé, chaque chantier doit répondre à une question dont la réponse change la suite du produit. Voici à quoi ressemble une roadmap orientée hypothèses, en format now/next/later, pour une jeune startup B2B fictive qui vient de lancer son produit.
| Horizon | Chantier | Hypothèse à valider |
|---|---|---|
| Now | Onboarding guidé en 3 étapes | « Si les nouveaux atteignent leur premier succès en moins de 10 min, ils reviennent » |
| Now | Tableau de bord d'usage minimal | « Les utilisateurs reviennent si on leur montre la valeur déjà produite » |
| Next | Intégration avec l'outil n°1 des clients | « L'absence d'intégration est le vrai frein à l'adoption, pas le prix » |
| Next | Invitations d'équipe | « Le produit se diffuse mieux en équipe qu'en usage solo » |
| Later | Facturation en libre-service | « Les clients sont prêts à payer sans passer par un commercial » |
| Later | Rapports exportables | « C'est un besoin d'achat, pas un confort » |
Trois choses à remarquer dans cet exemple. Le Now ne contient que deux chantiers : à ce stade, une équipe réduite qui s'éparpille n'apprend rien de net. Chaque ligne porte une hypothèse formulée, pas une feature : ce qui compte, c'est ce qu'on apprend en la construisant, pas la fonctionnalité elle-même. Et plus on descend vers le Later, plus l'engagement faiblit : la facturation en libre-service n'a de sens que si les hypothèses du Now et du Next se confirment d'abord.
Le piège classique de l'early-stage, c'est de remplir le Now de tout ce qui « ferait pro » (facturation, rapports, paramétrages avancés) avant même de savoir si quelqu'un revient sur le produit. La roadmap orientée hypothèses force l'ordre inverse : on valide la rétention et l'usage avant d'industrialiser la monétisation. C'est précisément la logique que j'applique quand j'accompagne un fondateur sur un Sprint Fondateur, où l'objectif n'est pas de tout construire, mais de construire ce qui confirme que le produit a un avenir.
3. Communiquer et gérer les parties prenantes
Une roadmap n'est utile que si elle est comprise et partagée. Et c'est souvent là que tout se joue politiquement.
Ce qu'il faut éviter :
- Un spreadsheet de 200 lignes incompréhensible
- Une liste de features sans contexte
- Un document que personne ne lit
Ce qu'il faut viser :
- Un récit clair : « Voici où on va, voici pourquoi, voici comment »
- Des objectifs plutôt que des features : « augmenter la rétention » plutôt que « ajouter les notifications push »
- Un format visuel accessible à tous, pas seulement aux PO
L'objectif : que chaque membre de l'équipe puisse prendre les bonnes décisions au quotidien, sans revenir demander validation.
La gestion des parties prenantes mérite une attention particulière, parce qu'une roadmap touche à des intérêts qui ne s'alignent pas spontanément. Le sales veut la feature qui débloque son deal. La tech veut payer la dette. Le marketing veut un lancement à effet. Chacun a raison de son point de vue, et c'est précisément le rôle du CPO de tenir l'arbitrage au niveau des OKR plutôt qu'au niveau des préférences individuelles.
Le bon réflexe n'est pas de dire non, mais de rendre l'arbitrage transparent. Quand on refuse une demande, on explique laquelle on a priorisée à sa place et pourquoi : quel objectif elle sert, quel score elle a obtenu. Un « non » expliqué se digère ; un « non » opaque crée du ressentiment qui ressort en réunion de comité. Pour les sujets qui dépassent l'équipe produit, le bon lieu d'arbitrage reste le comité de direction, où les priorités se confrontent au niveau des objectifs d'entreprise.
4. Piloter dans la durée
La roadmap vit au rythme de l'entreprise :
| Fréquence | Action |
|---|---|
| Hebdo | Revue avec les équipes Produit/Tech |
| Mensuel | Ajustement des priorités selon les retours |
| Trimestriel | Communication company-wide des objectifs |
Évitez deux écueils :
- Trop rigide : refuser tout changement crée de la frustration et déconnecte la roadmap du réel
- Trop chaotique : changer constamment détruit la confiance et empêche toute exécution
L'équilibre se trouve dans la cadence : on change les priorités à des moments prévus (la revue mensuelle) plutôt qu'au gré des conversations. Entre deux revues, on tient le cap. Cette discipline rassure les équipes : elles savent que ce qui est en « Now » ne sera pas balayé par la prochaine idée du CEO.
La roadmap est un artefact regénérable
Voici l'angle qui change tout, et qui découle directement de ce qui précède. La roadmap, en tant que document, n'est pas la vraie ressource. C'est un artefact : ce qu'on produit à partir de la vision, des OKR, des arbitrages et de leurs raisons. Si je perds le tableau Notion ou le Jira qui matérialise la roadmap, mais que je garde la vision, les objectifs du trimestre et la trace des arbitrages, je le reconstruis en une après-midi. L'inverse n'est pas vrai : un document de roadmap sans le « pourquoi » derrière chaque ligne est illisible et impossible à faire évoluer.
C'est exactement le raisonnement que je développe dans le code, le deck et la roadmap deviennent des artefacts : ce qui a de la valeur d'archive, ce n'est pas le livrable final, c'est la matière qui a permis de le produire. Pour une roadmap, cette matière tient en quelques éléments : la vision, les OKR, la trace des arbitrages avec leur justification, et les apprentissages tirés de ce qui a marché ou raté.
La conséquence pratique est libératrice. Si on accepte que la roadmap est régénérable, on cesse de la traiter comme un monument. On la régénère à chaque revue trimestrielle à partir de la vraie source. Ce n'est plus un document qu'on défend bec et ongles, mais l'expression du moment d'une réflexion vivante. Les équipes qui investissent dans la source (vision claire, OKR explicites, arbitrages tracés) passent beaucoup moins de temps à entretenir le document de roadmap, parce qu'il découle naturellement de ce qui est déjà écrit.
Qui porte la roadmap ?
Le CPO (ou le CTPO si les rôles sont fusionnés) est le owner naturel. Mais la construction implique :
- Le CTO pour la faisabilité technique et l'arbitrage de la dette
- Le CEO pour l'alignement stratégique et la vision long terme
- Les équipes pour les estimations et le feedback terrain
Owner ne veut pas dire décideur solitaire. Le CPO tient le cadre, anime les arbitrages et garantit la cohérence avec les objectifs, mais une roadmap construite sans la tech et sans les équipes terrain reste théorique. Pour approfondir le rôle du CPO dans cet exercice, consultez mon article sur les missions clés d'un CPO.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous