Qu’est-ce qu’une roadmap produit
Lorsque l’on démarre un projet de développement web ou mobile, on est par nature dans l’incertitude. La roadmap produit permet de donner une direction malgré cette incertitude. Concrètement, c’est une représentation visuelle et chronologique des étapes clefs de développement d’un produit. Elle porte la vision et la direction d’un produit, à la fois sur le court et le long terme.
Le GPS est une bonne analogie pour décrire le principe de la roadmap produit, comme le fait remarquer Bruce McCarthy dans Product Roadmaps: Relaunched. Entre le point de départ (le produit) et la destination (l’objectif à atteindre), nous pouvons passer par plusieurs étapes. Pour lier ces étapes, le GPS choisit un itinéraire, parmi différentes possibilités. Cependant, au cours de notre voyage, nous risquons de rencontrer des aléas (des embouteillages, des travaux…). Le GPS propose alors de nouveaux itinéraires permettant d’atteindre l’objectif. Cette analogie est particulièrement parlante, car elle témoigne du caractère évolutif (et non figé) d’une roadmap. Une roadmap doit en effet tenir compte des aléas du projet (complexité technologique non anticipée, redéfinition du besoin suite à de nouvelles informations…), et ce notamment en méthodologie agile.
5 étapes pour créer sa roadmap produit
1. Définir le cadre et la raison d’être du projet
Avant de créer votre roadmap produit, il faut s’assurer de savoir pourquoi (et pour qui) vous construisez ce produit. Il vous faut donc clarifier la raison d’être de votre produit en identifiant :
Le besoin ou le problème que vous souhaitez résoudre grâce à votre produit ;
Les utilisateurs concernés par ce besoin ou ce problème. Ils peuvent être de plusieurs types, et si c’est le cas, nous vous conseillons de les catégoriser ;
La manière dont vous répondez à ce besoin (votre proposition de valeur) ;
Les caractéristiques et éventuelles contraintes du marché concerné ;
Vos concurrents et votre différenciation par rapport à ces concurrents
Cette raison d’être doit rester votre étoile du Nord tout au long du projet, et notamment lors de la construction de votre roadmap. Elle doit également vous permettre de définir les objectifs de votre projet.
2. L’idéation
La deuxième étape est la phase d’idéation. Elle consiste à émettre de nombreuses idées de fonctionnalités, en stimulant la créativité. Les idées peuvent ensuite être catégorisées sous différents thèmes, qui seront les “epics” de votre roadmap.
Nous vous conseillons d’effectuer cette phase d’idéation en équipe, afin de valoriser les perceptions et les informations de chacun. L’idéation en équipe conduit généralement à des idées plus abouties, car chaque membre peut construire sur les idées des autres. Une phase d’idéation doit toujours être suivie d’une phase de tri.
Lorsque votre roadmap sera construite, nous vous conseillons de la partager avec vos équipes. En effet, dans une entreprise, chaque métier a ses objectifs propres. Ces objectifs peuvent parfois être divergents et créer des conflits d’intérêts au sein de l’entreprise. Par exemple, la fonction vente peut, afin de maximiser le chiffre d’affaires, vendre un projet à l’étranger alors que l’application n’est pas disponible dans la langue et la devise considérées.
3. La priorisation de votre roadmap produit
Le backlog
À l’issue de la phase d’idéation, vous disposez d’une liste de fonctionnalités non priorisées. Elles doivent être traduites en “user stories”. Une “user story” est généralement exprimée sous la forme suivante : “En tant que [type d’utilisateur], je peux [fonctionnalité] afin de [objectif].
Les “user stories” sont ensuite réparties sous des “epics”, qui peuvent correspondre aux thèmes définis lors de la phase d’idéation ou à des sous-catégories de ces mêmes thèmes. Cette liste finale d’user stories est appelée product backlog.
Comment prioriser votre backlog ?
Il existe plusieurs méthodes de priorisation du backlog. Nous vous conseillons d’utiliser celle qui vous convient le mieux, voire de créer un mélange de celles-ci.
La matrice impact / faisabilité consiste à prioriser les fonctionnalités en fonction de leur impact sur les utilisateurs de votre produit et des efforts à fournir pour les développer. Chez Galadrim, nous affectons des valeurs numériques à chaque fonctionnalité, afin de noter son impact et sa faisabilité. Nous utilisons pour ce faire la suite de Fibonacci, dans l’objectif de refléter la croissance de l’incertitude sur l’estimation, qui va de pair avec la complexité de la tâche estimée.
La méthode RICE est similaire mais prend en compte davantage de paramètres. Elle consiste à calculer un score de priorité, basé sur la portée (la fonctionnalité bénéficie-t-elle à de nombreux utilisateurs ?), l’impact, la confiance (y-a-t-il des risques ? des inconnues ?) et l’effort.
Le planning poker est une méthode de priorisation collaborative où chaque membre de l'équipe attribue une estimation en points à chaque tâche du backlog, basée sur la complexité perçue de la réalisation. En réunissant les différentes estimations, l'équipe peut discuter et converger vers un consensus sur la priorité des éléments du backlog. Cette méthode favorise l'engagement collectif et offre une vision plus holistique de la complexité des tâches.
Les user stories priorisées peuvent ensuite être organisées au sein d’un tableau Kanban, sous forme de cartes. Ce tableau permet de facilement visualiser toutes les tâches à accomplir pendant les différentes phases de développement, ainsi que leur état d’avancement. La méthode Kanban consiste à associer chaque colonne du tableau à une phase du développement, de la conception à la mise en production (en passant par la réalisation, la mise en pré-production, le recettage…) et à déplacer les cartes au sein de ces colonnes en fonction de leur statut.
4. Définir des objectifs et les mesurer
Après avoir priorisé les fonctionnalités à développer et avoir estimé leur temps de développement, il convient de les diviser en sprints de développement. Un sprint correspond à une unité de temps fixe durant laquelle une équipe de développement travaille sur un ensemble défini de tâches qui permettent de réaliser un ou des objectifs du projet. Une caractéristique clef de la méthode Kanban est de limiter les travaux en cours (Work In Progress), afin d’assurer que l’équipe se concentre sur les tâches les plus cruciales.
Les objectifs doivent être SMART (Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis). Il est conseillé de définir des KPIs associés à ces objectifs. Les KPIs permettent ainsi de mesurer les résultats obtenus de manière régulière. En comparant ces résultats aux objectifs chiffrés, vous pourrez mieux définir vos prochains objectifs, et adapter votre roadmap en conséquence.
Par exemple, si votre objectif est d’augmenter la rétention des utilisateurs, un KPI à suivre peut être le nombre de Daily Active User et/ou leur temps moyen de session.
5. Rendre votre roadmap évolutive
Comme précisé en introduction, une roadmap n’est pas figée. Elle doit refléter la réalité changeante des projets de développement web et mobile. Adapter régulièrement votre roadmap permet de rester réactif et d'assurer que votre produit évolue en harmonie avec les besoins fluctuants de vos utilisateurs et les objectifs stratégiques de votre entreprise. Faites preuve de flexibilité tout en suivant le fil conducteur qu’est la raison d’être de votre produit !
