Préambule : Un constat flagrant
“On veut des roadmaps engageantes et justes”
“Faites-moi des roadmaps avec des dates précises à 9 mois”
“Pourquoi les roadmaps ne sont pas à jour avec les prochaines features prévues dans 2 quarters ?”
“Je veux des roadmaps harmonisées, consolidées et précises avec des jalons et des dates de MEP pour chaque feature sur l’année”
“Je veux des roadmaps précises, au sprint, sur 6 mois”
Des phrases comme celles-ci, prononcées généralement par un membre de la Direction, j’en ai entendu des dizaines et dizaines dans ma vie de PM, et dans mon quotidien de Coach Produit.
D’un côté j’entends le besoin de maîtrise et de reporting du management sur ce qui va sortir sur une année. Ainsi le besoin de communiquer sur ce qui sera fait, sur généralement une année, à l’ensemble de la Direction et de l’organisation, de manière concrète et reflétant un engagement des équipes.
De l’autre, j’entends la souffrance des Product Managers et des équipes Produit dès que le mot “roadmap” est prononcé : car on leur impose souvent une liste de fonctionnalités à délivrer. En somme du “quoi” parfois sans en comprendre le sens ou la problématique à résoudre, qui met les équipes Produit en posture d’exécutants.
Mais est-ce que les enjeux de chacun sont possibles ?
Pas vraiment, car en essayant de pousser les équipes Produit à construire ce genre de roadmap orientées uniquement “features”, sur une temporalité hyper longue, cela crée de la frustration, du stress et de la crispation car :
- ces roadmaps sont prises par le top management pour argent comptant : “la date de mise en prod de la feature, c’est ce qui importe et c’est gravé dans le marbre”
- les équipes Produit mentent en décalant sciemment des dates (parfois de plusieurs mois) pour anticiper l’inconnu, mais surtout pour s’acheter la paix (et in fine ne pas s’engager car elles n’en sont pas capables à l’instant T).
- ces roadmaps au niveau de granularité “features” sont non-maintenables (et souvent non-maintenues) car elles sont déjà surchargées donc irréalisables à partir du moment où elles ont été écrites
- elles sont fausses par définition : “Qui sait ce qu’il fera dans 6 mois ou 1 an ?”
- elles demandent beaucoup d’énergie pour quelque chose que l’on ne fera certainement pas
Des roadmaps, oui mais pourquoi ?
Lorsque j’interviens chez mes clients, ou lors de mes coachings de Product People de tous niveaux, la question des roadmaps est ce qui ressort généralement en premier - avec tous les symptômes et frustrations énoncés en préambule.
Je pose alors une série de questions :
“Pourquoi voulez-vous des dates ?”
“Quel est l’enjeu derrière la date ?”
“Qu’est ce que vous voulez communiquer à travers cet artefact ? A qui ? Et surtout pourquoi ?”
“Comment pourrait-on trouver ensemble une formalisation de ces roadmaps qui conviennent à tous : à l’organisation, au management, aux équipes Produit ?”
“Comment pourrait-on trouver ensemble une façon de construire et présenter des roadmaps avec du sens, que les équipes Produit soient fières de porter et qui sont le reflet de ce qu’elles essayent de mettre en œuvre ?”
Je dis aussi très souvent une vérité qui déplait beaucoup : “toutes les roadmaps de features sont fausses à partir du moment où elles ont fini d’être écrites”.
Oui c’est dur et provocateur, mais c’est un fait.
Cependant, c’est un fait qui permet d’aller toucher et creuser une problématique bien plus intéressante que l’artefact en lui-même : le sens que l’organisation donne à ces roadmaps de features et le besoin, certes légitime mais anxiogène pour les équipes, de savoir ce qui va sortir et quand (sans maîtrise de l’impact qu’on veut générer, ni cadrage desdites features en amont).
La roadmap de features est représentative d’une organisation centrée sur la production de fonctionnalités (ou “feature factory”). Par définition, on demande aux équipes de produire tout un tas de features et de s’engager sur des dates de mise en production. On se soucie assez peu du “pourquoi on le fait ?”, on est drivé par les outputs, plutôt que par les outcomes. Et généralement, il n’y a pas vraiment de vision produit, ni de stratégie associée.
En tant que Coach, lorsque j’accompagne une organisation, le contenu et la manière de construire les roadmaps sont un de mes repères pour mesurer la maturité Produit de l’organisation.
La question de l’engagement quand on vit dans monde évolutif
J’aime à rappeler qu’une organisation Produit est, comme toute organisation, vivante. Elle évolue, elle grandit, elle prend de la maturité, elle se pose des questions, elle passe par des étapes. La roadmap et sa construction en est une.
J’aime rappeler également que nous vivons dans un monde complexe et plein d’incertitudes où chaque plan ne résiste pas au contact avec la réalité.
Lorsque j’accompagne mes clients dans leur transformation vers plus de Culture Produit et un état d’esprit de pilotage par l’impact, je demande souvent aux équipes d’arrêter de maintenir les roadmaps de features, pendant un temps donné, pour se concentrer sur autre chose.
Car finalement l’engagement et ce qu’on va écrire dans une roadmap, doivent être le reflet de l’impact qu’on souhaite générer sur les utilisateurs et le business. Cela en revient à se concentrer sur le “pourquoi on fait les choses”, plutôt que le “qu’est ce qu’on va construire”.
Quand on sait pourquoi on fait les choses, on les raccroche à une stratégie Produit, elle-même répondant à une vision Produit. On peut alors en tant qu’équipe Produit travailler sur des Product Outcomes, cadrés dans le temps (souvent un trimestre). C’est sur cela qu’on peut s’engager réellement : car ils sont le reflet de l’impact que l’équipe veut générer sur ses utilisateurs. La feature, elle, n’en est qu’une résultante, un moyen d’y arriver.
Lorsque je fais cheminer les équipes que j’accompagne vers cet état d’esprit en travaillant avec eux sur la mise en place de cycle tactique trimestriel (en utilisant les OKR et le solution opportunity tree par exemple), je leur demande ensuite de retravailler leur roadmap sous un autre format : l’outcome-based roadmap.
Le format est simple, lisible et compréhensible par tous car il raconte quelque chose : une histoire, une trajectoire pour les 3 prochains mois.
L’outcome-based roadmap se construit simplement avec 3 colonnes :
- “Now” : le trimestre entier ou les 3 mois si on veut plus de granularité
- “Next” : ce qui sera sûrement adressé sur le trimestre suivant
- “Later” : voyez-le comme une sorte de “backlog ideas macro”
Et plusieurs lignes qui se ventilent sur les 3 colonnes avec :
- les impacts tactiques que l’équipe Produit veut générer sur le trimestre (ex : leur 2 KR tactiques) et les initiatives associées
- les phases de discovery : toujours chasser l’implicite et montrer ce qu’on fait.
De plus la discovery d’un quarter alimentera certainement les impacts tactiques des suivants (donc cela permettra d’y apposer par exemple des éléments sur le “next” ou le “later” en cours de quarter) - les chantiers techniques (notamment quand la dette est importante)
- les chantiers de qualité (notamment quand le backlog de bugs et que l’amélioration continue passe à la trappe par manque de temps)
Je demande aux équipes de remplir ces roadmaps toujours en raisonnant par le sens, en posant le pourquoi à chaque fois qu’ils posent un élément.
En définitif on obtient des roadmaps qui sont lisibles par toutes les parties prenantes, qui répondent aux objectifs stratégiques, qui sont le reflet d’une tactique claire sur laquelle les équipes s’engagent au quarter.
Les dates ne sont alors plus des problèmes car les équipes travaillent sur des cycles plus petits, en se mesurant en permanence, en testant des initiatives plus rapidement.
L’apprentissage et le changement de prisme sont clés
Le résultat est assez magique quand je vois les équipes Produit adhérer à ce nouveau format de roadmap, y prendre goût, la maintenir facilement, être fières de la présenter car elle reflète exactement ce pour quoi l’équipe œuvre pour faire évoluer son Produit en générant de la valeur (et vite).
Pour autant, vous l’aurez compris, adopter ce format de roadmap fait partie intégrante d’une transformation globale vers plus de maturité Produit, plus de sens, plus de pilotage, plus de mesure.