Demandez à n'importe quel product manager de vous montrer sa roadmap. Il y a de fortes chances qu'elle ressemble à ceci : une liste de fonctionnalités, classées par trimestre, avec des estimations de dates qui glissent mystérieusement vers le futur dès qu'on s'en approche.
Ce n'est pas une roadmap. C'est un backlog déguisé en promesse.
Le problème de fond
La roadmap traditionnelle répond à la mauvaise question. Elle répond à "que va-t-on livrer ?" alors qu'elle devrait répondre à "quel problème allons-nous résoudre, et comment mesurerons-nous le succès ?"
Cette confusion est rarement malveillante. Elle vient d'une pression très humaine : les parties prenantes veulent des certitudes, les équipes veulent de la visibilité, et la roadmap devient l'objet sur lequel tout le monde projette ses attentes.
Le résultat ? Un document figé qui devient rapidement obsolète, mais que personne n'ose remettre en question parce qu'il a été promis.
Ce que devrait être une roadmap
Une roadmap est une hypothèse de valeur dans le temps. Elle dit : "On pense que si on résout ce problème pour cette audience dans ce délai, on créera ce niveau d'impact."
Cette formulation change tout :
- Elle reconnaît l'incertitude — les problèmes sont plus stables que les solutions
- Elle crée un contrat d'apprentissage — on livre pour apprendre, pas juste pour livrer
- Elle donne un critère de succès — une feature livrée sans impact est un échec, pas une réussite
Comment j'aborde la priorisation
Je structure les roadmaps autour de trois colonnes, pas de dates :
Now — Ce qu'on construit en ce moment, avec une hypothèse claire et des métriques de validation.
Next — Ce qu'on a bien compris et qui est prêt à être planifié, mais pas encore engagé.
Later — Des zones d'exploration, pas des promesses.
Cette structure force une honnêteté : si vous ne savez pas quelle métrique va changer avec une feature, elle n'a rien à faire dans "Now".
La conversation difficile
Le vrai travail, c'est de changer la conversation avec les stakeholders. Ils veulent un Gantt, vous leur proposez des hypothèses. Ça peut sembler moins rassurant — et pourtant c'est infiniment plus honnête.
Ma règle : toute entrée dans une roadmap doit répondre à quatre questions :
- Quel problème utilisateur résout-on ?
- Quelle métrique va bouger ?
- Comment le validera-t-on ?
- Qu'est-ce qu'on arrêtera si ça ne fonctionne pas ?
Si vous ne pouvez pas répondre à ces quatre questions, la feature n'est pas prête à entrer dans votre roadmap. Elle est dans votre backlog — et c'est très bien ainsi.
Une roadmap honnête est un outil de conversation, pas de promesse. Utilisez-la pour aligner, pas pour rassurer.