Roadmap NNL : aligner sans disperser

En product, on peut vite passer d'une opportunité à l'autre.

Un client remonte une demande intéressante. Un commercial voit un marché possible. Le support identifie un irritant récurrent. Une analyse Mixpanel ouvre une piste. Une requête SQL raconte autre chose. Quelqu'un lance un benchmark. Quelqu'un d'autre ouvre un Miro. Tout cela est utile, parfois. Mais à la fin, l'entreprise se retrouve avec beaucoup de matière, beaucoup de discussions, beaucoup d'énergie dépensée, et une question qui revient toujours :

Quand est-ce qu'on fait ça ?

Le problème n'est pas seulement le manque de temps. Le problème est le manque de direction lisible.

Une équipe produit peut avoir travaillé sérieusement, accumulé des études, des ateliers, des analyses et des hypothèses, sans que l'entreprise sache vraiment ce qui est prioritaire. Et quand rien n'est clairement tranché, tout reste mentalement ouvert. Les sujets ne sont pas faits, mais ils ne sont pas abandonnés non plus. Ils restent là. Ils reviennent en réunion. Ils pourrissent. Ils fatiguent.

Cette fatigue est intellectuelle, mais aussi morale. À force de travailler sur des sujets dont personne ne sait s'ils seront réellement faits, l'intensité baisse. On se dit : "De toute façon, ce ne sera peut-être jamais priorisé." Le travail perd de sa force parce qu'il n'est plus relié à une décision claire.

La roadmap Now / Next / Later répond à ce problème.

Mais seulement si on comprend bien ce qu'elle est.

Une roadmap NNL n'est pas un planning

La roadmap Now / Next / Later, ou NNL, ne cherche pas à dire précisément ce qui sortira tel jour, telle semaine, tel mois.

Elle remplace une logique de dates par une logique d'horizons de certitude.

• Now : ce que l'équipe fait maintenant.
• Next : ce que l'équipe prépare ou considère sérieusement.
• Later : ce qui reste dans le champ des possibles, mais n'est pas prioritaire.

Cette structure semble simple. Elle l'est. C'est même son intérêt.

Mais la simplicité du format ne doit pas masquer sa vraie fonction. Une roadmap NNL n'est pas une matrice de décision. Elle ne décide pas à la place du Product Manager. Elle ne remplace pas la stratégie produit. Elle ne remplace pas les arbitrages. Elle sert à rendre ces arbitrages visibles, discutables et communicables.

Une bonne roadmap NNL peut tenir sur une page. Idéalement, elle doit pouvoir être comprise sans lire un document de vingt pages. Ce n'est pas une base de données produit, ni un outil de gestion de tickets, ni un inventaire de tout ce que l'entreprise pourrait faire.

C'est une carte de direction.

Now, Next, Later : ce que chaque colonne veut dire

La colonne porte déjà une décision. La carte, elle, explique la valeur.

C'est un point important. On ne doit pas remplir les cartes avec des informations qui répètent le statut de la colonne. Si une carte est dans Now, on sait déjà qu'elle est engagée. Si elle est dans Next, on sait déjà qu'elle est candidate. Si elle est dans Later, on sait déjà qu'elle n'est pas prioritaire.

La carte doit donc répondre à une autre question : pourquoi ce sujet mérite-t-il une place ici ?

Now : ce qu'on fait

Now, c'est le travail engagé.

À ce stade, on doit avoir dépassé la discussion vague. On sait quel problème on traite, quelle valeur on veut créer, pour qui, avec quelles limites, et comment on saura si le sujet fonctionne.

Une carte Now doit donc être concrète. Elle peut porter une feature, une évolution produit, une amélioration structurante, mais elle doit surtout porter une promesse de valeur claire.

On doit pouvoir y trouver :

• la promesse de valeur ;
• la cible ;
• le problème actuel ;
• ce qui va changer ;
• ce qui est inclus et ce qui ne l'est pas ;
• les bénéfices attendus ;
• les indicateurs de succès ;
• ce qu'on peut dire aux clients ;
• ce qu'il ne faut pas promettre.

Le Now est aussi la colonne la plus contrainte. Elle est limitée par la capacité réelle de l'équipe à produire maintenant. Si une équipe peut traiter trois grands sujets, elle ne doit pas en afficher huit. Sinon la roadmap ne clarifie plus rien : elle fabrique une illusion d'engagement.

Next : ce qu'on prépare

Next, c'est le niveau des sujets sérieux.

Ils ne sont pas encore engagés comme le Now, mais ils ne sont pas de simples idées. Ils peuvent encore être dans l'espace du problème. Ils peuvent déjà tendre vers une solution. Mais ils doivent au minimum avoir des signaux, une valeur envisagée et une raison claire d'être regardés maintenant.

Une carte Next peut contenir :

• le problème ou l'opportunité ;
• la valeur envisagée ;
• les signaux disponibles ;
• les questions à trancher ;
• les conditions de passage en Now ;
• l'impact business potentiel ;
• ce qu'on peut dire en interne ;
• ce qu'il ne faut pas dire aux clients.

Le Next doit rester limité. Si trop de sujets sont dans Next, rien ne peut réellement avancer. La colonne devient un pré-backlog politique : chacun y met son sujet pour qu'il reste visible, mais personne n'assume la contrainte.

Later : le champ des possibles

Later, c'est l'univers que l'entreprise accepte de garder visible sans s'y engager.

Cette colonne est utile parce qu'elle évite une brutalité inutile. Tous les sujets non prioritaires ne sont pas absurdes. Certains sont intéressants. Certains deviendront importants si le marché change, si un gros client signe, si une contrainte réglementaire apparaît, si une dépendance technique disparaît, ou si un saut technologique rend soudain possible ce qui ne l'était pas.

Mais Later n'est pas une promesse.

Une carte Later doit expliquer :

• la valeur possible ;
• la cible ;
• pourquoi le sujet reste visible ;
• pourquoi il n'est pas prioritaire ;
• les signaux disponibles ;
• les déclencheurs de réévaluation.

Là encore, la colonne doit être limitée. Si Later devient une liste infinie, la roadmap redevient un inventaire.

Le No : ce qu'on ne fera pas

Dans NNL, le plus important n'est pas toujours ce qui est écrit.

Le plus important est parfois ce qui n'y est pas.

Le No n'est pas une colonne formelle. Mais il est l'effet central de la roadmap : tout ce qui n'est ni Now, ni Next, ni Later est hors scope pour l'horizon courant.

Cela ne veut pas dire que le sujet est idiot. Cela ne veut pas dire qu'on ne pourra jamais en reparler. Cela veut dire : pour l'instant, sauf rupture majeure, on ne le fera pas.

C'est essentiel, parce que ce qu'on fait et ce qu'on ne fait pas sont les deux faces de la même décision.

Si l'entreprise dit qu'elle veut avancer sur l'automatisation, l'onboarding et la réduction du support, elle dit aussi qu'elle ne fera pas maintenant la refonte complète de l'interface, la marketplace d'intégrations, le module expert-comptable et les demandes spécifiques d'un petit segment client.

Ce renoncement n'est pas un dommage collatéral. C'est le mécanisme qui protège la concentration.

Une roadmap qui ne permet pas de dire non ne sert pas à aligner. Elle sert seulement à différer les conflits.

La contrainte de capacité est le premier garde-fou

Une roadmap NNL doit être physiquement contrainte.

Le Now est fixé par la capacité de l'équipe à produire à un moment donné. Pas par l'ambition de la direction. Pas par la pression commerciale. Pas par le nombre de sujets intéressants.

Si l'équipe a la capacité de faire deux grands sujets correctement, le Now doit contenir deux grands sujets. Peut-être trois si les sujets sont plus petits. Pas dix.

La même logique vaut pour Next et Later.

Un Next trop chargé bloque la circulation. Les sujets de Later ne peuvent plus remonter. Les sujets de Next restent candidats trop longtemps. Le système donne une impression de mouvement, mais il n'y a plus de vraie décision.

La contrainte de nombre oblige à justifier.

Elle oblige à se demander :

• pourquoi ce sujet plutôt qu'un autre ?
• quel problème sert-il ?
• quel objectif business soutient-il ?
• quel risque réduit-il ?
• quelle valeur apporte-t-il ?
• que refuse-t-on en lui donnant cette place ?

Une règle simple : la roadmap doit rester lisible sur une page. Si elle déborde, elle ne clarifie plus. Elle redevient un stock.

La stratégie avant la liste

Une roadmap NNL n'est pas une liste de sujets rangés dans trois colonnes.

Si elle n'est pas reliée à une vision produit et à une stratégie d'entreprise, elle devient seulement une présentation plus jolie du désordre existant.

Avant de remplir les colonnes, il faut donc savoir ce que l'entreprise cherche à accomplir. Croissance ? Rétention ? Expansion sur un segment ? Réduction du support ? Différenciation ? Sécurisation réglementaire ? Montée en gamme ? Réduction d'une friction critique ?

Les sujets doivent ensuite être évalués à travers des risques clairs.

On peut reprendre ici les grands risques product popularisés par Marty Cagan :

• est-ce bon pour l'entreprise ?
• est-ce que le client veut l'acheter ?
• est-ce que l'utilisateur veut l'utiliser ?
• est-ce faisable techniquement ?

Ces questions évitent de remplir la roadmap avec les sujets les plus bruyants. Une demande commerciale importante peut être légitime. Une douleur support peut être critique. Une opportunité marché peut être réelle. Mais la roadmap ne doit pas être la somme des pressions entrantes.

Elle doit être la traduction visible d'une stratégie.

Comment remplir une carte sans faire de l'administratif

Le piège classique consiste à transformer la roadmap en formulaire.

En produit, on adore parfois créer des champs, des statuts, des tags, des workflows, des sous-catégories, des règles de validation. Cela donne une impression de sérieux. Mais si l'information n'aide ni à décider, ni à comprendre, ni à communiquer, elle alourdit le système.

La bonne règle est simple : la colonne porte la décision, la carte explique la valeur.

Il n'est donc pas nécessaire de mettre dans chaque carte :

• son horizon ;
• son niveau d'engagement ;
• son rôle ;
• sa nature administrative ;
• une répétition du statut.

La carte doit plutôt rendre le sujet compréhensible.

Pour une carte Now, on doit pouvoir comprendre ce qui va changer et comment on mesurera le succès.

Pour une carte Next, on doit pouvoir comprendre pourquoi le sujet est sérieux, ce qu'il reste à trancher et ce qui le ferait passer en Now.

Pour une carte Later, on doit pouvoir comprendre pourquoi le sujet reste visible et pourquoi il n'est pas prioritaire.

Tout le reste doit rester léger. Parfois, un tag suffit.

Roadmap NNL et backlog : deux objets différents

La roadmap NNL n'est pas un backlog.

La roadmap sélectionne les grands sujets dignes d'attention. Le backlog organise le travail à faire sur les sujets sélectionnés.

La différence est importante.

Dans la roadmap, on peut avoir une initiative comme :

Automatiser la saisie des documents papier.

Dans le backlog, cette initiative sera découpée en problèmes, fonctionnalités, tâches techniques, tickets de design, stories, critères d'acceptation, dépendances, tests, corrections, itérations.

Le backlog est plus fin. Il est opérationnel. Il sert à produire.

La roadmap, elle, sert à aligner.

Le risque est de faire du backlog la poubelle de la roadmap. Un sujet n'est pas dans Now, pas dans Next, pas dans Later, mais on ne veut pas vraiment le tuer. Alors on le met dans le backlog. Il restera là. Il vieillira. Quelqu'un le retrouvera six mois plus tard. Il faudra rediscuter. La charge mentale reviendra.

Si un sujet n'est pas dans la NNL, il ne doit pas automatiquement entrer dans le backlog.

Sinon le backlog absorbe tous les renoncements que la roadmap n'a pas assumés.

Roadmap interne et roadmap client

Il faut probablement deux roadmaps.

Une roadmap interne et une roadmap client.

La roadmap interne peut être plus complète, plus stratégique, plus nuancée. Elle peut contenir des hypothèses, des arbitrages, des limites, des raisons de non-priorité, des sujets sensibles, des débats encore ouverts.

La roadmap client doit être une traduction.

Pas une extraction automatique. Pas une copie filtrée. Une traduction manuelle, prudente, produit et commerciale.

Ce travail est trop subtil pour être automatisé correctement. Ce qu'on peut dire à un client dépend du niveau d'engagement réel, du risque de promesse implicite, du contexte commercial, du segment, de la maturité du sujet et de la capacité de l'entreprise à tenir le message.

Un sujet en Now peut souvent être communiqué, avec des limites claires.

Un sujet en Next peut parfois être évoqué comme direction de réflexion, mais il ne doit pas être vendu comme engagement.

Un sujet en Later doit être manié avec prudence. Le simple fait de le montrer peut créer une attente.

Là encore, ce qu'on ne fait pas compte autant que ce qu'on fait. La communication client change selon les choix assumés par la roadmap.

Gouvernance : qui décide, et à quel rythme ?

Une roadmap NNL a besoin d'un propriétaire.

Tout le monde peut proposer. Tout le monde peut contester. Les sales doivent pouvoir remonter ce qu'ils voient. Le support doit pouvoir porter les irritants récurrents. Les développeurs doivent pouvoir alerter sur les risques techniques. Les dirigeants doivent pouvoir rappeler la stratégie. Les clients doivent pouvoir influencer par leurs problèmes réels.

Mais à la fin, il faut un décideur.

Dans la plupart des organisations produit, ce décideur doit être le Product Manager, ou la personne qui porte réellement l'arbitrage produit. Il doit écouter tout le monde, mais il doit aussi trancher. Sinon la roadmap devient un compromis mou entre jeux d'influence.

Le rythme de revue doit être assez lent pour éviter la discussion permanente, mais assez régulier pour rester connecté à la réalité.

Un rythme trimestriel est souvent une bonne base.

Trop court, on risque de transformer la roadmap en débat politique ou en discussion de comptoir. Trop long, on risque de garder des sujets qui ne sont plus alignés avec la stratégie, le marché ou la capacité réelle.

Des points mensuels peuvent exister avec les sales et les stakeholders, à condition qu'ils ne deviennent pas un jeu de pouvoir. Leur rôle doit être de faire remonter des signaux, pas de renverser la roadmap à chaque nouvelle opportunité.

Les règles d'entrée et de sortie doivent rester simples.

Un sujet entre dans la NNL s'il a assez de valeur, de signaux, de lien stratégique et de capacité disponible pour mériter une place.

Un sujet sort si un sujet plus fort entre, si la stratégie change, si les signaux disparaissent, si la faisabilité s'effondre, ou si une rupture majeure redistribue les priorités.

Pas besoin de créer trop d'administratif. Une courte note ou un tag peut suffire pour expliquer pourquoi un sujet est sorti.

La faiblesse d'une roadmap : elle fixe les choses

Une roadmap sert à fixer une direction.

C'est sa force.

Mais c'est aussi sa limite.

Même une bonne roadmap NNL peut créer un effet de verrouillage. Elle protège contre la dispersion, mais elle peut aussi empêcher de traiter de petites améliorations évidentes, très utiles, très attendues, mais trop petites ou trop opportunistes pour devenir des sujets de roadmap.

C'est là qu'un mode commando peut avoir du sens.

Pas comme une colonne supplémentaire. Pas comme une exception permanente. Pas comme un moyen de contourner les arbitrages.

Comme une respiration contrôlée hors roadmap.

Par exemple : un temps sacralisé le vendredi, une équipe minimale, un dialogue direct, peu de bureaucratie, un sujet choisi à la discrétion du Product Manager, une forte conviction de valeur, un effort limité, et une coupure des sollicitations habituelles.

L'intérêt est de traiter ces petites choses qui font bouger le produit et montrent aux clients que l'entreprise avance. Pas les grands chantiers incertains. Pas les paris stratégiques. Les sujets où l'on sait déjà qu'il y a de la valeur, parce que la douleur revient souvent, parce que le support la voit, parce que les clients la formulent, parce que l'équipe connaît le produit.

Exemple simple : un client doit produire un document administratif et récupérer des données dans dix écrans différents. La solution idéale serait peut-être un module complet. Mais un export texte ou Markdown, même imparfait, peut déjà lui faire gagner plusieurs heures.

Ce n'est pas la roadmap.

C'est une respiration autour de la roadmap.

Et les bugs ?

La théorie est propre. La réalité l'est moins.

Dans la vraie vie, il y a les bugs, la maintenance, les régressions, les urgences, les irritants, la dette technique.

La roadmap NNL ne remplace pas la gestion opérationnelle du produit.

Les bugs se gèrent souvent au quotidien, selon leur gravité, leur impact client, leur fréquence, leur risque et leur visibilité. Tous les bugs n'ont pas vocation à entrer dans la roadmap. S'ils y entrent tous, la roadmap cesse d'être un outil de direction.

La dette technique demande un autre traitement. Une dette n'est vraiment une dette que lorsqu'on décide de la régler. Avant cela, c'est souvent un inconfort, un risque latent, une complexité, une faiblesse d'architecture, parfois connue depuis longtemps. Elle devient un sujet produit quand l'entreprise décide que son coût est désormais supérieur au coût de traitement.

Certains sujets techniques peuvent donc entrer dans la NNL. Par exemple s'ils bloquent une stratégie, ralentissent fortement l'équipe, exposent l'entreprise à un risque, dégradent la qualité client, ou empêchent un changement produit important.

Mais là encore, il faut être clair : la roadmap porte une direction. Elle doit coexister avec une gestion quotidienne des bugs et une stratégie explicite de traitement de la dette technique.

Ces deux sujets méritent leurs propres articles.

Exemple : une roadmap NNL simple

Prenons un SaaS B2B de gestion administrative.

L'entreprise sert des clients qui doivent produire régulièrement des documents, centraliser des informations et réduire du travail manuel. L'équipe produit est limitée : elle ne peut pas mener cinq grands chantiers en parallèle. La stratégie du trimestre est de réduire la friction utilisateur et de renforcer la valeur perçue sur les usages récurrents.

Une roadmap NNL pourrait ressembler à ceci.

Now

Export fiscal simplifié

Promesse : permettre à l'utilisateur de générer rapidement un fichier contenant les informations nécessaires à une démarche administrative.

Valeur : éviter plusieurs heures de recherche et de copier-coller dans différents écrans.

Limite : ce n'est pas encore un module fiscal complet. C'est un export utile, fiable, compréhensible.

Indicateurs : nombre d'exports, baisse des demandes support liées à cette démarche, retours qualitatifs des clients concernés.

Réduction d'un irritant d'onboarding

Promesse : réduire le temps nécessaire pour réussir la première configuration.

Valeur : améliorer l'activation et réduire les blocages précoces.

Limite : on ne refond pas tout l'onboarding, on traite le point bloquant principal.

Indicateurs : taux d'activation, temps jusqu'à première valeur, tickets support sur l'étape concernée.

Next

Automatisation de saisie documentaire

Valeur envisagée : réduire le travail manuel sur les documents papier ou PDF.

Signaux : demandes clients récurrentes, temps support élevé, opportunité de différenciation.

Questions à trancher : niveau d'automatisation réaliste, qualité attendue, faisabilité technique, coût d'erreur acceptable.

Condition de passage en Now : périmètre réduit, valeur claire, solution techniquement maîtrisable.

Reporting d'activité amélioré

Valeur envisagée : donner aux clients une vision plus claire de leur activité et de leurs points de blocage.

Signaux : demandes commerciales, feedbacks clients, usage fréquent des exports existants.

Questions à trancher : quels indicateurs sont vraiment actionnables, pour quels profils, avec quelle fréquence d'usage ?

Later

Module avancé d'IA

Valeur possible : automatiser davantage l'analyse et la préparation de documents.

Pourquoi visible : sujet stratégique possible, évolution rapide du marché.

Pourquoi non prioritaire : dépendances techniques fortes, risque de promesse excessive, valeur encore insuffisamment cadrée.

Déclencheur : saut technologique, demande forte d'un segment prioritaire, preuve d'usage sur un cas réduit.

Marketplace d'intégrations

Valeur possible : connecter le produit à davantage d'outils clients.

Pourquoi visible : peut soutenir l'expansion.

Pourquoi non prioritaire : coût élevé, dispersion probable, besoin client encore trop hétérogène.

Déclencheur : concentration claire des demandes sur quelques intégrations critiques.

Portail expert-comptable

Valeur possible : créer une expérience dédiée à un acteur externe important.

Pourquoi visible : sujet intéressant pour certains segments.

Pourquoi non prioritaire : impact encore incertain, risque de complexifier le produit principal.

Déclencheur : signature d'un gros client ou stratégie explicite sur ce segment.

Hors NNL

Certains sujets ne sont pas dans la roadmap.

Par exemple :

• refonte complète de l'interface ;
• demandes spécifiques d'un petit client ;
• fonctionnalités avancées pour un segment non prioritaire ;
• intégrations isolées sans signal marché ;
• expérimentation IA trop générale.

Ces sujets peuvent être intéressants. Ils ne sont simplement pas dans la direction actuelle.

Et c'est précisément ce qui rend la roadmap utile.

Conclusion

Une roadmap NNL réussie ne donne pas l'illusion que tout est possible.

Elle donne à l'entreprise la force de faire peu de choses, mais de les faire vraiment.

Elle clarifie ce qui est engagé, ce qui se prépare, ce qui reste possible, et ce qui est hors scope. Elle réduit la dispersion. Elle protège le backlog. Elle rend les renoncements discutables au lieu de les cacher. Elle donne au Product Manager un cadre pour écouter, arbitrer et communiquer.

La NNL n'est pas parfaite. Elle ne règle pas les bugs, la dette technique, les urgences, ni les petites opportunités à forte valeur. Mais elle donne une chose rare : une direction assez claire pour que l'entreprise puisse avancer sans tout rouvrir en permanence.

Et dans beaucoup d'organisations produit, c'est déjà énorme.