Écrire un document de roadmap qui explique les compromis
6 min de lecture
La plupart des documents de roadmap sont une liste classée sans raisonnement visible. Ça fonctionne bien jusqu’à ce qu’une partie prenante demande pourquoi la fonctionnalité B est au-dessus de la fonctionnalité A, et la réponse honnête est un mélange d’intuition et de qui a demandé le plus récemment, ce qui ne tient pas bien en réunion. Un PM qui présente une roadmap de six éléments à une salle de parties prenantes, chacune avec sa fonctionnalité favorite, peut passer toute la réunion à défendre l’ordre verbalement au lieu de pointer un raisonnement déjà présent sur la page.
Attention
Une liste classée sans raisonnement n’est pas une décision, c’est un espace réservé pour une décision. La première question difficile dans la salle révèle si le classement a vraiment été réfléchi.
Une roadmap qui ne peut pas expliquer son propre ordre n’est pas une roadmap. C’est une liste qui attend d’être redébattue.
Pourquoi un classement sans raison se refait débattre à chaque fois
Classer à l’instinct peut être juste, mais personne d’autre ne peut l’évaluer, donc chaque partie prenante avec une intuition différente a des raisons de s’y opposer. Sans raisonnement visible, la même conversation sur les compromis se reproduit à la réunion suivante, puis à celle d’après. Une roadmap présentée comme une simple liste ordonnée invite exactement le genre de débat qu’une roadmap bien raisonnée évite, puisqu’il n’y a rien sur la page avec quoi une partie prenante sceptique puisse s’engager, à part le souvenir du PM sur pourquoi il a fait chaque choix.
Imagine une revue de roadmap trimestrielle où un lead ingénierie demande pourquoi une fonctionnalité à plus petit impact est classée au-dessus d’une avec une portée attendue clairement plus large. Si la réponse honnête n’existe que dans la tête du PM, « ça semblait juste plus urgent », la réunion se transforme en négociation en temps réel avec qui insiste le plus fort. Si la même question est déjà répondue sur la page, « la fonctionnalité A se classe plus haut malgré une portée plus petite parce qu’elle débloque une intégration partenaire avec une échéance contractuelle le mois prochain », la conversation se déplace vers si ce raisonnement tient la route, ce qui est un bien meilleur endroit où elle peut aller.
Avant : classe les fonctionnalités à l’instinct, présente la liste, passe la réunion à défendre l’ordre depuis le début.
Après : donne à Claude les fonctionnalités candidates avec leur effort et leur impact, reçois en retour une roadmap classée avec le raisonnement de chaque place écrit, et arrive en réunion avec les compromis déjà sur la page.
Un processus pour une roadmap avec un raisonnement visible
- 1
Liste les candidates avec de vraies estimations d’effort et d’impact
Donne de vrais chiffres, même approximatifs, des semaines d’ingénierie pour l’effort, des utilisateurs concernés attendus pour l’impact, plutôt que des étiquettes vagues comme « gros » ou « petit ». Des entrées vagues produisent un classement sans rien de solide derrière.
- 2
Demande un classement avec une raison énoncée par élément
Demande deux phrases de justification par fonctionnalité, pas juste une liste classée. Le raisonnement est ce qui rend la roadmap défendable dans une salle pleine de gens avec leurs propres opinions.
- 3
Demande ce qui changerait le classement
Une fois un premier passage obtenu, demande quelles fonctionnalités sont les plus proches d’échanger leur place, et ce qui devrait être vrai pour que ça arrive. C’est là que les vrais compromis, pas juste l’ordre final, deviennent visibles.
- 4
Vérifie le raisonnement contre ce que valorisent vraiment les parties prenantes
Compare le raisonnement énoncé avec ce que tu sais importer aux gens dans la salle, revenu, rétention, dette technique. Un classement qui ne reflète que l’effort et l’impact peut encore manquer la vraie conversation.
Voici 6 fonctionnalités candidates avec des estimations d’effort approximatives et un impact attendu. Classe-les en roadmap pour le T3, et rédige deux phrases justifiant chaque classement.
”Si une partie prenante précise est connue pour pondérer une dimension plus lourdement que les autres, disons que la direction ingénierie se soucie plus de la réduction de la dette technique que ce que la liste suggère actuellement, cela vaut le coup de demander à Claude de pondérer le classement avec cette priorité explicitement nommée, plutôt que de présenter un classement unique qui suppose implicitement que tout le monde partage les mêmes priorités.
La direction ingénierie a signalé la dette technique comme une priorité plus grande que ce que ce classement reflète actuellement. Montre-moi comment l’ordre changerait si réduire la dette technique était pondéré aussi lourdement que l’impact utilisateur, pour que je puisse comparer les deux versions avant la réunion.
”
Dans Claude Tutorial
Rendre visible le raisonnement derrière un classement est transférable.
Transformer une décision à l’instinct en une décision avec un raisonnement énoncé et vérifiable s’applique bien au-delà des roadmaps. L’appli a une leçon complète sur le sujet, avec de la pratique qui se transfère à tout choix de priorisation que tu dois défendre.
Quand deux fonctionnalités sont vraiment proches
Parfois, la réponse honnête est que deux fonctionnalités sont suffisamment proches pour que les deux ordres soient défendables. Ça vaut le coup de le dire directement plutôt que de présenter une fausse certitude sur un classement précis. Une roadmap qui présente chaque classement avec une certitude identique invite une partie prenante à insister fort sur un cas serré comme s’il s’agissait d’une décision tranchée, quand le geste le plus honnête, et finalement le plus persuasif, est de le nommer comme un cas serré dès le départ.
Astuce
Demande à Claude de signaler quels classements sont des cas serrés par rapport à ceux qui sont tranchés. Une roadmap honnête sur ses cas serrés est plus crédible qu’une qui présente chaque classement avec la même certitude.
En regardant cette liste classée de 6 fonctionnalités, quelles paires sont suffisamment proches pour que l’ordre puisse raisonnablement s’inverser ? Sois précis sur ce qui devrait changer pour que ça arrive.
”Pour une paire vraiment serrée, ça vaut le coup de demander s’il existe un critère de départage au-delà de l’effort et de l’impact qui la tranchera avec plus de confiance, une dépendance, une échéance saisonnière, un engagement déjà pris envers un client, plutôt que de laisser la roadmap reposer sur un ordre arbitraire à pile ou face.
Ces deux fonctionnalités sont essentiellement à égalité sur l’effort et l’impact. Existe-t-il un critère de départage pratique, une dépendance entre elles, une échéance externe, n’importe quoi au-delà des chiffres, qui rendrait clairement l’une meilleure à construire en premier ?
”Continuer la lecture
- Transformer des tickets de support en thèmes prioritaires : d’où viennent souvent les estimations d’impact sur lesquelles repose un classement de roadmap.
- Transformer une fonctionnalité livrée en notes de version et point aux parties prenantes : ce qui se passe une fois qu’un élément de roadmap est réellement livré.
- Écrire un PRD à partir d’une demande de fonctionnalité d’une ligne : transformer une place de roadmap en spécification une fois qu’elle a été priorisée.