Le premier trimestre touche à sa fin, il est temps de ressortir ta Roadmap... La Roadmap produit est-elle une source de stress et de conflit dans ton équipe ? Tu n’es pas le/la seul(e) ! Réaliser une bonne Roadmap est vu comme l’un des exercices le plus difficile dans le rôle du Product Manager. Cet article reprend en détail la définition, les caractéristiques et les avantages de construire une Roadmap itérative ainsi que les erreurs les plus courantes lors de la création d‘une Roadmap produit.
La Roadmap est un vaste sujet qui a fait couler beaucoup d’encre !
La Roadmap représente ton produit à l’instant T et les grandes étapes jusqu’à concrétisation de la vision produit qui elle-même découle de la vision de l’entreprise.
Dans son livre, Product Roadmaps: Relaunched, Bruce Mccarthy, utilise l’analogie du GPS pour décrire la Roadmap. Le lieu de départ représente le produit et la destination l’objectif à atteindre. Entre les 2, le voyageur va passer par plusieurs étapes et pour atteindre la destination, plusieurs chemins sont possibles. De plus, cette analogie emphase l’aspect agile, non figé d’une Roadmap. En fonction de travaux, bouchons, etc., le GPS propose de nouveaux itinéraires pour atteindre l’objectif. En fonction de nouvelles informations internes ou externes, la Roadmap se transforme pour continuer à progresser vers l’objectif. Par conséquent, il est important de mettre en avant l’impact et de prendre du recul par rapport aux tâches qui ne sont pas définitives.
Par conséquent, la Roadmap permet :
Pour qu’une Roadmap soit utile et utilisée par les différentes parties prenantes elle doit être compréhensible, visuelle, adaptée en fonction de l’audience, accessible et classée par thématique. De plus, elle doit pouvoir répondre aux questions : à quels types de besoin/ problème nous souhaitons répondre et comment ? Quels sont les objectifs et comment sont-ils liés à nos résultats ?
Tips : pour obtenir une Roadmap actionnable, il est recommandé de la lier aux méthodes d’OKR ou de North Star Metrics.
Afin que la Roadmap soit la plus explicite tout en limitant les informations, il est important de ne pas la surcharger. Par conséquent, les 5 grandes informations primordiales sont :
Prenons un exemple : nous sommes product manager sur un produit dont la vision est de centraliser tous les produits qui respectent la santé et l’environnement et de les rendre accessibles à tous. Nous avons analysé une corrélation entre le temps qu’un utilisateur met à finaliser son inscription et l’action de réaliser une commande. Plus le temps est court, plus les probabilités sont élevées.
Pour le premier semestre notre axe stratégique est de répondre aux besoins exprimés par les utilisateurs “commander les produits sélectionnés dès qu’ils sont dans mon panier sans attendre la validation de mon compte”.
En grandes fonctionnalités on aurait :
Le KPI pour ce semestre est l’augmentation de 10% du nombre de nouveaux utilisateurs qui réalisent une première commande suite à l’ajout de produits dans leur panier.
Dans son livre Inspired, Marty Cagan, met bien en avant le problème qui encourt lorsqu’on ne comprend pas l’intérêt et le rôle de la Roadmap.
en effet, Marty Cagan démontre 2 problèmes à aller trop dans le détail. D’une part, plus de la moitié des idées ne fonctionneront pas car les utilisateurs ne sont pas enclins à cette solution, la solution répond au problème des utilisateurs mais l’effort pour l’utiliser est trop important ou techniquement / financièrement / légalement cela est impossible ou trop complexe à développer. D’autre part, l’idée retenue mettra plusieurs itérations pour atteindre les objectifs espérés. Lister les fonctionnalités et les détails peut être pertinent pour les ingénieurs et développeurs mais pas pour toutes les parties prenantes qui perçoivent la Roadmap comme un engagement. La non réalisation de certains aspects sera facteur de déception, frustration et conflit.
Nombreuses entreprises sous-estiment la Roadmap et la confondent avec le Backlog (outil où retrouver toutes les fonctionnalités plus ou moins détaillées) et le plan de release qui démontre l’exécution du développement de ces fonctionnalités. La Rodmap produit, le Backlog et le Release plan sont 3 outils utilisés à des moment spécifiques de réflexion et d’action. La Roadmap intervient en amont et sert de base de référence lors de doutes ou de modifications internes et/ou externes qui peuvent avoir un impact sur l’évolution du produit (ex : la fermeture des restaurants pour un service de cartes restaurant). Le Backlog découle de la Roadmap en affinant les thèmes / Epics sous forme d'User Stories détaillées qui seront embarquées dans les sprints. Enfin le Plan de Release découle quant à lui du Backlog en listant et détaillant les User Stories présentes dans le Backlog qui seront lancées au moment de la mise en production. Par conséquent, le plan de release est une vision à plus ou moins long terme de ce qui sera livré avec X sprints.
En conclusion, ces 3 outils sont liés et complémentaires, mais chacun apporte des informations différentes. La granularité de l’information est par conséquent différente et n’arrive pas au même moment.
La Roadmap doit refléter ce que les équipes peuvent réaliser pour atteindre un objectif et répondre à des problèmes utilisateurs. Les parties prenantes et dirigeants ont tendance à vouloir que tout rentre dans la Roadmap en fonction de leurs propres préoccupations. Néanmoins, c’est au Product Manager de savoir dire “non” afin de maintenir une cohérence avec les capacités des équipes.
Comme notre environnement, la Roadmap est “vivante”. Elle s’adapte aux priorités de l’entreprise, aux changements externes (légaux, économiques, technologiques, etc.). En fonction de la maturité du produit et de la stabilité du marché, la Roadmap doit être revue tous les 1 à 6 mois au plus tard (même pour un produit mature dans un marché stable). Ainsi, la temporalité de la Roadmap peut prendre différents aspects :
Un des avantages de la Roadmap est de pouvoir être partagée à toutes les parties prenantes et de communiquer à tous les niveaux. Cela permet de collaborer avec les équipes métiers (Marketing, Sales, Support...). En effet, il est primordial de bien communiquer avec les métiers qui sont aussi en contact avec les utilisateurs ou dont une partie de leur mission dépend des évolutions du produit (opération marketing, répondre à un appel d’offres, répondre à la sollicitation d’un client).
De ce fait, la Roadmap doit être en disponible, à chaque nouvelle version ne pas oublier de communiquer (synchrone ou asynchrone) et de faire des points réguliers avec les équipes au besoin.
Exemple, même si vous décidez d’utiliser une Roadmap à 3 niveaux ou intemporelle (court / moyen / long terme), à l’instar d’Intercome, réunir toutes les équipes ayant des dépendances (sales / marketing / tech) pour informer sur quoi l’équipe travaille sur les 3 prochains mois puis confirmer ce qui sera mis en production d’ici 2 semaines permet aux équipes métiers de préparer le travail et de le planifier.
Pour conclure, la Roadmap est le GPS d’un produit qui permet de prendre du recul sur les grandes étapes qui jalonnent le parcours afin d’atteindre la vision produit. Elle est le point de référence qui permet la collaboration des équipes d’une entreprise et avec les parties prenantes internes / externes. Evangéliser la Roadmap est cruciale pour unifier les équipes lors de sa création.
Ce qu’il faut retenir d'une roadmap produit :
Le spécialiste du conseil Product Management fullstack : Strategy, Discovery & Delivery !
