Construire une roadmap

Construire une roadmap est un exercice nécessaire à toute étape d'une entreprise Tech & Produit. Et c'est un exercice à refaire continuellement, pas juste une fois par an ou une fois par trimestre : une roadmap n'est pas un engagement fort et définitif sur le long terme, c'est une des routes possibles vers une destination fixée en commun entre les dirigeants d'une entreprise : c'est le moment où se rencontrent vision et stratégie.

Cet exercice est aussi l'occasion de faire parler et participer quasiment toutes les fonctions de l'entreprise. Qu'il soit product owner, développeur, Chief Marketing Officer, Sales Development Representative, designer, chargé de communication ou même RH ou comptable, chaque collaborateur peut avoir besoin de donner son avis sur la constitution de cette feuille de route. En effet, la roadmap est un document très opérationnel dans lequel toutes les caractéristiques de la vision peuvent se retrouver. Ainsi, si la vision implique de recruter un nombre important de développeurs, la direction RH ne sera pas la seule à être impactée : il est possible qu'il faille faire de la place pour des activités de préparation des tests techniques pour de nouveaux développeurs. Si la stratégie implique de mettre en place un nouveau système de paiement en plusieurs fois, les équipes Sales et Finances vont être fortement impactées et auront donc voix au chapitre sur ce sujet.

La construction d'une roadmap se fait en plusieurs étapes, impliquant chacune de bien déterminer objectifs et intervenants. En fonction des organisations, ces étapes peuvent légèrement varier mais le principe reste globalement identique

Identifier les besoins

La première étape est d'identifier les besoins de chaque équipe et des utilisateurs qu'ils peuvent représenter. En effet, si on peut comprendre assez aisément qu'un Product Owner va représenter les utilisateurs finaux et que les équipes Sales vont représenter les clients, un CFO peut aussi représenter le cabinet d'expert-comptable ou un DPO externe. Il est très rare de faire un exercice complet qui va nécessiter de voir chacune des équipes pour collecter tous ses besoins en une seule passe. En règle générale, cette étape d'identification des besoins se fait au fil de l'eau, des besoins pouvant émerger chaque jour suite à une réunion avec un prospect, une nouvelle analyse data des cohortes utilisateurs, un besoin en recrutement qui évolue, ... Néanmoins, dans certaines organisations qui mettent en place une structure produit pour la première fois, cette étape d'identification peut être assez lourde et longue. Elle est néanmoins nécessaire pour avoir une vue globale et être sûr de ne rien oublier. C'est aussi un bon révélateur de l'adéquation entre la vision et les moyens à disposition.

En termes de durée, si cette étape est réalisée pour la première fois ou qu'on pense avoir besoin de reprendre toute la roadmap, le temps à allouer à l'exercice peut être important si l'entreprise est grande. C'est aussi l'occasion de se reposer la question de l'organisation des équipes de réalisation : est-il toujours pertinent d'avoir une squad dédiée à tel groupe de fonctionnalités ou la valeur créée par l'ajout de nouvelles fonctionnalités à ce groupe a-t'il moins d'incidence que de travailler sur un tout nouveau produit ? Cette étape est donc un prisme par lequel vous allez pouvoir commencer à préparer votre organisation future. En effet, un C-Leve aguerri pourra identifier des premiers signaux faibles lors de cette phase préliminaire.

Prioriser

Dans l'étape suivante, on commence à prioriser les actions à réaliser. Pour ça, on peut utiliser des frameworks comme ICE (Impact Confidence Ease) pour mesurer le rapport, relatif entre besoins, entre la valeur créée par un développement et son coût pour la société. On peut aussi mettre en place des ateliers en présentiel pour prioriser un tas de cartes représentant les besoins. C'est alors l'ensemble des parties prenantes qui va définir petit à petit sa roadmap idéale en prenant en compte essentiellement les priorités. À cette étape, un ou plusieurs experts réalisation (technique, produit, design, ...) peut toutefois rappeler les dépendances entre les cartes pour éviter des situations dans lesquelles on construit une fonctionnalité sans être capable de l'activer (exemple trivial : le cas de la fonctionnalité "mot de passe oublié" qui devient plus prioritaire que la fonctionnalité "connection au compte"). Cette première étape de priorisation ne donne pas une roadmap définitive mais oriente fortement les futurs travaux en ayant aligné toutes les parties prenantes sur une version idéale.

Pour compléter cette priorisation, il faut ensuite la valider avec une première passe d'estimation plus réaliste. À ce stade, il n'est probablement pas nécessaire de faire des estimations précises en nombre de jours de développement. Des estimations à assez haut niveau (TShirt Sizing par exemple) sont largement suffisantes pour s'assurer qu'aucune fonctionnalité ne s'est retrouvé à une mauvaise place. Par contre, il est important de ne pas penser les estimations que via leur coût de développement : une fonctionnalité va aussi prendre du temps à être conçue par un Product Owner et un Product Designer, à être préparée encore en amont par une équipe marketing, à être validée sur des aspects commerciaux, financiers, juridiques, ... Ces étapes peuvent paraitre plus courtes et donc négligeables par rapport aux étapes de développement mais elles ont néanmoins un coût important. De plus, avec des équipes engineering souvent plus développées que les autres équipes de l'entreprise, le coût relatif pour ces équipes est souvent très important et pourrait compromettre fortement la capacité à livrer une nouvelle fonctionnalité dans les temps.

A l'issue de cette phase d'estimation, le owner de la roadmap (souvent le CPO) présente une nouvelle version mise à jour aux parties prenantes. Cette version prend en compte la roadmap idéale validée par tous, les estimations à haut niveau réalisées par chaque équipe (ou par un représentant de chaque équipe plus probablement) ainsi que de nouvelles réflexions autour des dépendances entre ces fonctionnalités. A la vue de ces nouveaux éléments, les parties prenantes revoient cette nouvelle roadmap et valident une version.

Communiquer et aligner les équipes

L'étape suivante est celle qui est le moins documentée tout en étant, de mon point de vue, la plus importante : la communication de cette roadmap afin d'aligner les équipes sur les travaux futurs. Avoir une roadmap est un travail qui peut coûter énormément de temps et d'énergie dans certaines organisations. Ne pas la communiquer ou mal la communiquer revient à perdre une partie de son intérêt dans l'alignement des équipes. En effet, même si votre roadmap est très voire trop précise, des questions arriveront forcément en cours de route. Une équipe alignée sur votre vision d'ensemble n'aura aucune difficulté à répondre rapidement et efficacement à ces questions. A l'inverse, une équipe qui ne fait qu'appliquer un plan reviendra à chaque fois vers vous dès qu'une incompréhension surviendra.

Préparer la communication de la roadmap nécessite un vrai travail de management visuel. Au moment de la construction de votre roadmap, des feuilles A4 ou un fichier Excel peuvent être très précieux pour gagner du temps en se focalisant sur le fond et pas sur la forme. Entre C-Level ou représentants des différentes équipes, ce compromis s'entend sans difficulté et ne pose en général pas de problèmes majeurs. Par contre, quand vous présentez votre feuille de route à des personnes n'ayant pas participé à sa rédaction, vous ne devez pas présenter une succession de fonctionnalités mais une histoire qu'ils vont pouvoir s'approprier et faire vivre par eux-mêmes. Ainsi, la communication de votre roadmap se fait en général avec une présentation de type Powerpoint qui va mettre plus l'accent sur les besoins que sur les réelles réalisations attendues. Ces réalisations peuvent servir d'exemple pour illustrer les besoins exprimés mais il serait contre-productif de tous les citer.

En général, la roadmap précise (sous Excel, Notion, ...) sera présentée en amont aux Product Owners ou aux Product Managers pour leur donner un degré de compréhension et d'adhérence encore plus important. Il sera ensuite de leur responsabilité de présenter ces détails à leurs équipes une fois que l'histoire derrière ces fonctionnalités aura été bien comprises. C'est aussi une manière de responsabiliser des squads : leur donner la vision globale de leur impact sur la société et ses actifs puis les laisser découvrir par eux-mêmes les détails pour donner corps à cette vision. Ils seront alors d'autant plus à même de surmonter les questions et incertitudes qui arriveront immanquablement lors de l'exécution de cette feuille de route.

Suivre le cycle de vie

Pour un CPO, le travail autour de la roadmap ne s'arrête pas le jour où celle-ci a été présentée à l'entreprise. C'est au contraire le démarrage de la partie opérationnelle qui s'amorce. Régulièrement (toutes les semaines, tous les mois, ...), le CPO et ses équipes vont revoir les objectifs qui avaient été fixés et les ajuster si besoin. Ils vont aussi collecter de nouveaux besoins qui surviennent et ajuster leur feuille de route en conséquence. Des ajustements à la marge ne nécessiteront qu'une communication localisée dans l'équipe ou les équipes impactées alors que des ajustements plus structurels nécessiteront un nouvel alignement global de l'entreprise.

Par expérience, une communication globale est intéressante à faire tous les trimestres même si tous les aspects d'une roadmap ne changent pas tous les trois mois. Néanmoins, une communication plus éparse aurait comme impact de rendre cet exercice trop exceptionnel et donc moins ancré dans les mœurs de l'entreprise. A l'inverse, une communication globale plus régulière entretiendrait du flou et donnerait l'impression d'une feuille de route sans cesse en mutation ce qui peut créer des désalignements et donc faire perdre du focus, du temps et de la qualité aux équipes.