Ah la roadmap. Un classique du PO. Présente dans toutes les descriptions de postes. Motif de peurs parfois: « Mais qu’est-ce que je vais bien pouvoir faire ?« . « Et si je me rate, c’est tout le temps de mon équipe que je mets à la poubelle« . J’en passe et des meilleures.
Il faut savoir relativiser. On a tous fait des erreurs. On continuera tous à en faire. Espérons juste qu’on en fasse des différentes !
Je me suis récemment fait une rétrospective de toutes les roadmaps que j’ai pu construire, et voici quelques apprentissages que j’ai envie de partager.
Plus qu’un livrable, un exercice
L’exercice de faire sa roadmap compte plus que la roadmap.
Quand on fait une roadmap, on fait un premier jet, et on s’aperçoit qu’il manque des choses. Ou qu’il nous faut plus d’infos ou de temps pour creuser le sujet. Qu’on manque de données pour étayer une hypothèse. Ou qu’il y a des dépendances et qu’on doit donc réorganiser les chantiers pour en tenir compte. Mais pour cela il faut d’abord discuter avec les autres équipes. Connaître un peu leurs feuilles de route respectives. Voire négocier avec elles pour récupérer un peu de leur bande passante…
Bref, on fait un plan de travail sur papier, et cela constitue une première itération de notre roadmap. C’est comme un prototype. Et plus on fait d’itérations, plus robustes deviennent nos hypothèses, nos estimations, … ; en un mot: notre programme de travail.
Prendre du temps pour faire sa roadmap, c’est donc diminuer la variabilité de la réalisation, et en limiter ainsi les coûts. C’est un investissement judicieux car « consommer » quelques heures voire quelques jours pour faire monter le niveau de confiance sur les sujets à engager et notre capacité à les adresser coûte moins que travailler sur les mauvais sujets et ne pas en être en maîtrise.
Du reste, toutes les roadmaps évoluent. Et c’est on ne peut plus normal. De nouvelles informations apparaissent. Le contexte autour du business change. Les ressources ne sont pas stables. Etc. C’est une erreur de s’attacher à sa roadmap pour en garantir coûte que coûte sa réalisation. L’apprentissage et l’adaptation sont beaucoup plus valorisables pour votre organisation.
Il faut donc moins s’attacher à sa roadmap qu’à l’exercice de réflexion qu’il y a derrière. Comme le résume Eisenhower : « In preparing for battle, I have always found that plans are useless but planning is indispensable »
Un point de départ, pas une fin en soi
Suivre une roadmap, ce n’est pas garantir que son produit avance
C’est tentant de se dire qu’une fois qu’on a posé des tâches sur une timeline, le tour est joué. Mais en fin de compte, ces tâches, il faut encore les réaliser. Et rien ne garantit ensuite qu’elles vont produire les effets escomptés. Et oui, tant que son impact succès n’est pas mesuré, une tâche reste une simple hypothèse de travail.
Ce qui compte pour faire avancer un produit, ce n’est pas de s’en tenir à un plan : c’est d’aller chercher des impacts. En tant que PO nous sommes censés être des maximisateurs de valeur, pas de multiplicateurs de projets. Alors si l’on veut vraiment faire avancer le schmilblick pour son organisation et éviter l’effet « feature factory » il est important d’adopter un état d’esprit centré sur les résultats (outcome) et non plus sur les projets (output).
Les résultats, les impacts, c’est ce qu’on trouve derrière les initiatives listées dans la roadmap. Leur pourquoi. En fin de compte pour faire une roadmap, ce n’est pas tant des projets qu’il vous faut prioriser, mais des problèmes.
Comme le résume Alfred de Musset : « Aimer est le grand point, qu’importe la maîtresse ? Qu’importe le flacon, pourvu qu’on ait l’ivresse ? » Une fois que vous êtes alignés sur la priorité de votre organisation (son « grand point« ) et la manière de mesurer votre contribution à cette priorité, peu importent les projets. Il ne sont qu’autant de tactiques. Et si ces tactiques ne sont pas les bonnes, autant en changer rapidement. Une fonctionnalité n’est pas un engagement. Quitte à vous engager, autant vous engager sur des problèmes à résoudre. Et ce, après avoir fait le nécessaire pour vous assurer que c’étaient les bon problèmes sur lesquels avancer.
C’est pour cela que c’est utile d’avoir une roadmap pilotée par objectif, par exemple, en utilisants des OKRs ou des North Stars Metrics. Ca permet de
- mettre l’impact au cœur de sa roadmap et de prendre de la distance par rapport aux projets qui ne sont dès lors plus des fins en soi, mais que des flèches pour atteindre une cible donnée.
- de faciliter l’alignement des équipes comme du métier sur ce le fait que ce que l’on cherche à faire compte plus que ce que l’on va faire ;
- de stimuler l’idéation en partant des impacts pour découvrir les initiatives qui pourraient nous y mener, un peu sur une approche Impact Mapping
Impact, impact, impact. Oubliez les efforts.
Avec travail bien séquencé, les gros sujets deviennent moins couteux.
Les Quick Wins : c’est bien, mais ça ne doit pas détourner l’attention. Quand on pense Quick Win, on a tendance à tomber dans le piège suivant : on systématise l’approche. Ca a marché une fois, deux fois et, si on reprend l’analogie de l’apprentissage par renforcement, les succès passés vont accroître d’autant notre propension à entreprendre le même genre de chantier, au détriment des chantiers plus conséquents.
On en devient presque craintif de faire des plus gros chantiers. Et on nous dit de tout découper, découper, découper… Alors on découpe, on multiplie les petits sujets, qui n’ont pas forcément de liens les uns avec les autres. Et on se retrouve à papillonner de sujet en sujet en se demandant bien comment on va pouvoir trouver un objectif à ce sprint ! Inutile de dire que sur le long terme, cette approche fatigue plus, diminue le focus, et selon moi a tendance à augmenter le coût du délai en adoptant un état d’esprit trop court-termiste.
Si le chantier semble gros, une bonne organisation vous permettre de mieux le digérer : c’est une question, notamment, de séquencement des développements, de pensée Pareto, et de choix techniques pour apprendre ou tester vite et construire de la qualité en minimisant le risque.
L’importance de l’effort à fournir réside dans le fait qu’on prépare mal le travail à faire. On a le droit d’être créatif. On ne va pas construire directement une solution optimisée en terme de performance. Plus on va se projeter dans ce qu’il y a à faire, plus on va anticiper les problèmes (ou admettre les inconnues connues). Cela va nous permettre de découper le travail en lots cohérents pour minimiser les risques, apprendre, et ainsi, diminuer le coût qu’on avait initialement anticipé pour atteindre tel résultat.
Par ailleurs, un focus sur la motivation de la fonctionnalité plutôt que sur les designs initiaux, et un peu de bande passante pour ajuster le tir en cours de route complèteront cette organisation de travail qui pourrait vous réserver des bonnes surprises en terme de delivery.
D’expérience, en 3 mois, sur une équipe, vous pouvez faire 2 bons chantiers avec suffisamment d’itérations pour qu’ils soient satisfaisants. Des choses qui figureraient sûrement dans votre liste si vous vous posiez la question « Qu’est-ce qu’il serait stupide de ne pas avoir fait dans 3mois » ?
Et toujours d’expérience, on s’aperçoit qu’on surestime tout, les impacts comme les efforts. Il ne faut pas non plus oublier que faire est la meilleure estimation : l’homme a naturellement tendance à sous-estimer les petites taches et surestimer les grosses. Alors ne vous concentrez pas trop sur les efforts. Si vous pensez qu’une action aura un gros impact, allez-y.
Aérer sa roadmap, c’est optimiser la valeur livrée.
C’est n’est pas blinder votre roadmap de projets qui maximisera votre impact.
Au contraire cela peut se révéler contreproductif à bien des égards. Sentiment d’urgence permanent qui empêche de prendre de la distance. Trop grand attachement aux plans initiaux. Incapacité à faire face aux imprévus qui pourtant ne manquent pas invariablement de se produire…
Alors si on a naturellement tendance à remplir tous les trous, si on pense que c’est optimisé quand tous les créneaux sont blindés, c’est peut-être que la nature a horreur du vide, n’est-ce pas ? Mais ce n’est pas une raison suffisante pour le faire. Au contraire, c’est capital de savoir garder de la place dans sa roadmap.
1. Pour garantir une certaine réactivité de son équipe, et gagner/garder ainsi la confiance de ses parties prenantes.
Plus vous travaillez en confiance avec votre écosystème, plus c’est simple de faire votre travail ensuite. Simple parce qu’on ne vous stresse pas avec un besoin de sur-reporting. Simple car vous pouvez facilement vous aligner avec d’autres équipes pour qu’elles vous débloquent sur une dépendance.
Il est important de garder de la bande passante pour les autres. Ca vous permettra de prendre rapidement des petits sujets qui émergent. D’absorber les imprévus de la prod. Ou de débloquer des équipes qui découvrent leurs dépendances tardivement. Il y aura toujours du variable qui n’émerge qu’après que vous ayez arrêté vos plans initiaux. Il faut se laisser du temps pour l’absorber sans déstabiliser la dynamique de l’équipe.
2. Pour garantir un rythme soutenable dans la durée.
Avec une roadmap trop chargée, probablement que l’on pourra tenir le rythme au début. Mais pour combien de temps ?
En plus, à remplir trop sa roadmap, on tombe dans l’écueil de l’inertie : on se sent obligés par rapport aux initiatives fixées et on a tendance à perdre l’objectif de vue. Et la part de discovery, dont la charge est difficilement anticipable, va avoir tendance à se réduire, avec comme conséquence des sujets moins bien cadrés, et donc un delivery qui diminue et apportera en plus moins de valeur ensuite.
3. Pour avoir le temps de prendre de la distance, de métaboliser ses apprentissages et de les partager.
Si on a trop la tête dans le guidon, on s’évertue à vouloir courir plus vite et on ne voit pas les raccourcis et autres opportunités qui s’offrent en cours de route.
Il faut donc savoir garder du temps pour faire respirer les devs, et se laisser le temps de respirer son-même, prendre de la distance avec des sujets sur lesquels on s’essoufle, ou éviter les effets tunnel.
Garder de l’espace dans un programme de travail c’est vital. Une route embouteillée n’avance pas. Dans vos journées remplies de réunions, rien qu’un retard de 5′ va inévitablement mener à une sérieuse amputation, voire une annulation des autres. Inévitablement, quand vous passez votre journée à multiplier les initiatives, vous perdez progressivement le fil (et c’est normal, nos capacités sont limitées) et en fin de compte, vous avez probablement l’impression que rien n’avance. Et ce ne sont que des exemples triviaux. Il y en aurait beaucoup d’autres.
La roadmap, c’est mieux de la faire avant 🙂
Une roadmap, ça s’anticipe.
Avant d’être un document de communication, c’est un document de travail qui s’efforce de résoudre la difficile équation d’aligner tout le monde sur les priorités, de concilier les besoins des différentes utilisateurs/métiers, de se coordiner avec les autres équipes produits, et de s’articuler autour des dates butoires… Et déjà, rien que recenser tous ces éléments prend un temps non négligeable, alors ne parlons même pas du jeu de Tetris qui s’en suit.
Ensuite c’est le support d’une réflexion. Or réfléchir, ça peut prendre du temps. Faire une une roadmap, c’est révéler des incertitudes et poser des hypothèses sur lesquelles on peut déjà commencer à itérer. Quelle cible atteindre ? Quelle probabilité de succès ? Quelle mesure du succès ? Quelle data est déjà disponible ? Quelles inconnues ? Quelles dépendances ou enablers ? Voilà un aperçu des questions auxquelles il faut apporter des réponses. Et tout cela ne se fait pas en un instant. Il faut déjà commencer le travail. Réfléchir à la mesure du succès. Trouver les données. Faire des designs préalables. Négocier pour trouver une place dans la roadmap d’autres équipes…
Enfin, une roadmap a une dimension sociale : tout ne dépend pas seulement de vous, ce qui peut rallonger les délais. Vous avez besoin de vous coordonner avec d’autres équipes pour aplanir les dépendances, de valider les besoins du métier, comprendre si il n’y a rien de bloquant à ce que vous projetez de faire, etc. Rien que chercher la donnée disponible est parfois une quête épique !
Anticiper est clé. D’autant que l’on ne fait pas qu’une roadmap, mais plusieurs itérations, et que ces itérations sont autant de prototypes qui vous permettront de maximiser le retour de vos investissements.
Une roadmap ça doit être lisible, pour tout le monde
Une roadmap est un instrument de communication.
Une roadmap c’est le produit d’un échange avec les différentes parties prenantes. Celles qui veulent se tailler la part du lion dans votre programme de travail (par exemple le fameux »métier »). Celles qui vont vous aider à faire avancer vos initiatives (par exemple, les autres équipes avec lesquelles vous êtes en dépendance). Celles qui vont vous aider à le cadrer (au premier rangs desquelles votre équipe, pardi !). La communication, le dialogue, c’est donc un élément qu’on retrouve à l’origine de la roadmap.
C’est aussi un élément que l’on retrouve dans sa finalité. En effet une roadmap donne de la visibilité aux autres acteurs pour permettre une meilleure articulation des toutes les parties du système, ce qui compte d’autant plus quand l’organisation est grande. Ca permet de dire aux autres produits ce que vous allez faire et éventuellement et de se coordonner. Ca permet de rassurer aussi vos parties prenantes qui ne sont pas avec vous tout le temps. Ca permet à votre équipe de se projeter sur le travail à faire durant la prochaine période et de s’organiser pour ce faire.
Il est donc important qu’elle soit lisible, à jour et accessible pour les différents publics qui peuvent être amenés à la consulter.
Pour améliorer la lisibilité, le premier conseil est de ne pas trop remplir sa roadmap. Une roadmap aérée est plus lisible et ce n’est pas que le seul intérêt (voir ci-dessus).
La lisibilité passe aussi par le fait d’éviter le jargon (c’est d’ailleurs valable aussi pour la formulation de vos OKRs ou de vos US) et un trop gros niveau de détails. Si vous avez à choisir le plus important, c’est que les gens comprennent dans quelle direction vous aller travailler. Rester sur un niveau macro qui ne donne à voir que les thèmes de votre roadmap, ie les impacts que vous cherchez à atteindre, est un moyen :
- non seulement d’alléger votre roadmap et de la rendre plus compréhensible, en affichant mécaniquement moins d’information que si vous y inscriviez les fonctionnalités prévues
- et aussi de ne pas créer un trop grand sentiment d’engagement par rapport à ces fonctionnalités, car encore une fois, votre programme est susceptible de changer, et à ce stade de maturité, vos fonctionnalités ne sont que des idées, peut-être mauvaises, et qu’il reste à tester.
Aussi, votre roadmap est un document vivant. Vous la mettrez peut-être à jour avec les autres équipes à des intervalles fixes, mais si ce n’était pas le cas pas mettez-vous des rappels pour ce faire. Comme toute forme de documentation, une roadmap a plus de valeur si elle est à jour.
Enfin, vous rangerez peut-être votre roadmap dans un endroit prévu à cet effet, mais tout le monde n’en aura pas l’adresse, ni le réflexe d’aller la consulter. De votre côté, vous avez bien une idée des personnes que cela peut intéresser. Ca ne coûte pas grand chose de leur envoyer un email contenant le lien vers la roadmap, ça vous permettra d’obtenir du feedback et ça valorisera vos parties prenantes qui se sentiront dans la boucle si vous n’avez pas eu l’occasion de leur présenter de vive voix.
Et ça continue, encore et encore
Comme d’habitude, il y aurait (beaucoup) d’autres choses à dire sur ce sujet. On aurale temps d’en reparler. Et si vous voulez vous aider à rendre votre roadmap plus robuste : vous pouvez surement vous inspirez de cette liste de 40 questions publiée par John Cutler. Mes préférées ?
- Challenge yourself to cut the scope here by 75%. Would that deliver some value? Should we pursue that first, even if it expands the overall scope a bit?
- Why now? Why is this the most important problem to solve right now? How might the financial outcome be different if we did this in six months, one year, or never? Explain how it “beats” a handful of other things you are considering.
- Who will this impact? Say I wanted to identify the customers/users this will impact, what query would I run? How might I quantify the impact over time?
