Aller au contenu

Qu’est-ce qu’une Roadmap produit ?

Le premier trismestre touche à sa fin, il est temps de retrouver où vous avez rangé votre Roadmap… La Roadmap produit est-elle une source de stress et de conflit dans votre équipe ? Vous n’êtes 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.  

Sommaire

Définition de la Roadmap basée sur les objectifs / problèmes utilisateur

Définition roadmap produit

La Roadmap représente votre 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. 

L’intérêt d'utiliser une roadmap produit

  • Aligner les décideurs sur les prochaines grandes étapes du produit et d’aligner les équipes lorsque le produit est divisé en plusieurs squad.  
  • Représenter de manière visuelle la vision produit, les objectifs chiffrés, les moyens pour les atteindre à un niveau macro ainsi que les risques ;  
  • Prioriser les problèmes auxquels nous souhaitons répondre et se concentrer sur l’outcome et non l’output. 
  • Baser sa réflexion sur les utilisateurs finaux (entreprise user-centric) ou la croissance (entreprise business-centric). Best practice, prioriser les projets qui apportent les 2.  
  • Donner un état d’avancement des différentes initiatives.  
  • Accentuer la collaboration de toute l’équipe pour répondre à l’objectif.  
  • Limiter les erreurs et les ratés suite à un sprint en analysant les causes (sprint douloureux pour toute l’équipe ou inachevé). Prenez le temps de réaliser un ROTI après chaque sprint / release et comprendre ce qui a fonctionné et moins bien fonctionné en mettant en place des actions concrètes pour les prochains. 

Pour qu’une Roadmap soit utile et utilisée par des 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 à 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 ? 

Ce que doit contenir une Roadmap

Afin que la Roadmap soit la plus explicite tout en limitant les informations, il est important de limiter de la surcharger. Par conséquent, les 5 grandes informations primordiales sont :  

  • La vision produit qui doit être affichée en haut de la Roadmap pour la garder en tête et qu’elle soit accessible par tous.  
  • La période sans tomber dans le travers de la charte de GANTT avec des dates, il est important de donner une temporalité vague tout en incluant les dates incompressibles. L’équipe de développeurs ne peut s’accorder sur des dates de lancement au niveau de la Roadmap, car les thèmes listés dans cette dernière sont à un niveau macroscopique.  
  • Les objectifs : les enjeux stratégiques que nous souhaitons atteindre à plus ou moins long terme. Ils doivent être précis et chiffrés 
  • Le contenu est priorisé (MoSCo, RICE, T-sizing) ce qui permet de répondre aux objectifs : présenté sous forme de problèmes / besoins utilisateurs. Il est déconseillé de parler de solution à ce niveau en détaillant les fonctionnalités. Rester à un niveau qui favorise l’idéation, sous forme d’Epic / initiative. Le contenu peut aussi être classé sous forme de zone de travail.  
  • Les KPI’s qui permettront de mesurer le succès des initiatives développées et à quel point elles répondent aux objectifs. 
  • Optionnel : ajouter les risques liés 


Exemple :
nous sommes product manager sur un produit dont la vision est de centraliser tous les produits qui respect 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 :
– Inscription via compte Google

– Inscription via compte Microsoft
…Etc

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.

roadmap produit

Ce que n’est pas une Roadmap

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. 

La roadmap n’est pas une liste de fonctionnalités détaillées.  

En effet, Marty Cagan démontre 2 problèmes à aller trop dans le détail. En premier, plus de la moitié des idées ne fonctionneront 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. En second, 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 utile pour les ingénieurs et développeurs mais pas pour toutes les parties prenantes qui estiment la Roadmap comme un engagement. La non réalisation de certains aspects sera facteur de déception, frustration et conflit.  

La Roadmap n’est pas un Backlog ou un release plan 

Nombreuses entreprises sous-estiment la Roadmap et la confondent avec le Backlog qui est l’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 est en amont et permet une 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 n'est pas irréalisable

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 dirigeant ont tendances à 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. 

La roadmap n'est pas document figé qui n’est pas mis à jour régulièrement

Comme notre environnement, la Roadmap est “vivante”. Elle s’adapte avec les priorités de l’entreprise, les changements externes (légal, économique, technologique, 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 :  

  1. Trimestrielles : en lien avec la méthode OKR  (objectives key results), la Roadmap est revue tous les trimestres. L’aspect trimestriel peut limiter la réactivité et l’itération en se basant sur 4 grandes périodes par an pour prendre du recul sur le produit et où on souhaite arriver.  
  2. Court / moyen / long terme : sous forme d’un Kanban, la Roadmap est moins concrète et plus flexible ce qui facilite l’itération et limite fortement les frustrations, pression de mise en production.  
  3. 3 niveaux : exemple très connu d’Intercome dont la Roadmap est articulée selon la règle des trois 6 : 6 semaines / 6 mois / 6 ans. Avec cette méthode, Intercome ne souhaite pas prédire le marché dans 6 ans mais comment le produit peut influencer le marché. Cette méthode fonctionne autant pour des nouveaux produits (3 semaines / 3 mois / 3 trimestres) que des produits et/ou marchés plus matures (4 mois / 4 trimestres / 4 ans). 

La roadmap n'est pas un document rangé dans un “tiroir”, que tout le monde a oublié et/ou est inaccessible.

 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 disponible, avec des communications régulières lors de nouvelles versions (synchrone ou asynchrone) et doit faire l’objet de points réguliers avec les équipes qui ont besoin.  
Exemple, même si vous décider d’utiliser une Roadmap à 3 niveaux ou intemporelle (court / moyen / long terme), à l’instar de Intercome, réunir toutes les équipes ayant des dépendances (sales / market / tech) pour informer sur quoi l’équipe travaille sur les 3 prochains mois puis confirmer ce qu’il 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 crucial pour unifier les équipes lors de sa création.   

Ce qu’il faut retenir :

  • Une Roadmap est un document vivant et dynamique qui a pour but de représenter comment le produit va atteindre la vision en présentant les grandes étapes.  
  • La Roadmap permet de créer un lien entre la stratégie et l’opérationnel  
  • C’est un document avec des actions, de haut niveau, non détaillées qui est centré sur les problèmes à résoudre et non les solutions ou fonctionnalités 
  • La Roadmap est exprimée en horizon de réalisation et seules les dates incompressibles sont informées  
  • C’est un document qui doit être compréhensible par toutes les parties prenantes internes et externes.