Les étapes à suivre et les conseils de notre expert pour construire une roadmap produit

Qu’est-ce qu’une roadmap produit ?

Par définition, une roadmap produit, c’est la feuille de route du projet. C’est le plan à suivre, la vision stratégique du produit, ce que l’on souhaite faire de lui, plutôt que des objectifs qui doivent impérativement être atteints. Sa fonction est donc de diffuser à tout le monde les objectifs du produit.

Une roadmap produit, ça se construit à court, moyen et long terme.

“ Cependant, attention à la stratégie long terme du produit. En agilité, lorsque l’on parle de long terme, on parle de 1 an maximum. Au-delà, selon moi ça ne sert à rien. De mon expérience, la direction du produit va tellement évoluer entre temps, les échéances se décaler, le plan initial être retravaillé… qu’il est préférable de ne pas vouloir établir une roadmap produit à plus d’un an. “

De plus, la roadmap produit ne doit pas être trop détaillée, c’est une vision macro. Si vous détaillez vraiment toutes les features, toutes les étapes, cela perd de son intérêt. La représentation de la stratégie du produit doit être lisible et s’il y a trop de niveaux de détails, elle ne le sera plus.

Elle doit inclure les informations et données clés suivantes :

Généralement, il faudra entre 1 à 3 mois, selon la complexité du ou des produits, la taille de l’entreprise, l'organisation, la disponibilité des équipes projet pour créer une première version validée de la roadmap produit.

Quelles sont les parties prenantes à intégrer à la construction de sa roadmap produit ?

En tant que Product Manager, tu ne construis pas ta roadmap produit dans ton coin. C’est une grosse erreur de faire ça ! Même si t’es owner sur celle-ci, tu n’as jamais toute la vision du produit : business, stratégique, opérationnelle, métier… Elle se construit impérativement avec toutes les parties prenantes.

Il est nécessaire de s’entretenir avec chacun d’entre eux pour avoir toutes les informations, les besoins et contraintes de chacun. Ce n’est qu’à la suite de ça, que le Product Manager est capable de proposer une première version de la roadmap produit qui pourra être par la suite itérer avec les parties prenantes.

Penses-tu que réaliser un atelier soit indispensable pour construire sa direction produit ?

Oui, c’est essentiel. C’est ce que j’expliquais avant, on peut formuler, en tant que Product Manager, une première version en ayant discuté avec toutes les parties prenantes mais pour la faire évoluer dans le bon sens, il faut forcément faire un atelier.

De mon point de vue, pas forcément des ateliers “by the book”, qui sont peut être trop théoriques. Il est souvent plus pertinent de faire quelque chose de plus informel, en regroupant toutes les parties prenantes autour d’une table et en élaborant une stratégie collaborative. Car si les personnes ne discutent pas, la feuille de route produit ne reflétera pas les objectifs globaux de l’entreprise.

Pour avoir une roadmap bien construite, il faut qu’elle soit validée par tout le monde.

“ En tant que Product Manager, notre rôle est de récupérer les attentes et besoins de tout le monde et de juger de la valeur d’une feature et de son impact sur le produit. Plus la valeur est haute, plus elle sera priorisée. “

Quels frameworks utiliser pour construire une roadmap produit ?

Il existe plusieurs frameworks pour construire et formaliser sa roadmap produit. 

Now-Next-Later

Le premier exemple de framework dont nous allons parler est le Now-Next-Later. Ce framework est utilisé en gestion de produit pour prioriser les évolutions sur 3 axes temporels : le court terme (now), le moyen terme (next) et le long terme (later).

Go-to-Product Roadmap

La Go-to-Product Roadmap est un second outil à disposition pour créer une roadmap produit. Elle permet de visualiser les prochaines grandes étapes de développement de votre produit en termes de fonctionnalités, de livraisons, d’objectifs et de métriques sur une période donnée. Et le top du top ? La Go-to-Product roadmap est très facile à mettre à jour et à adapter en fonction des feedbacks de ses clients et des changements marchés. Cela permet de mieux répondre aux attentes de ses clients et de rester à la pointe de l’innovation !

Pour que cela soit plus claire, prenons un exemple complété avec BLABLACAR :

Quelles sont tes bonnes pratiques et conseils pour construire une feuille de route produit de qualité ?

Comme je le disais, elle ne doit pas être trop détaillée. Idéalement, les premières étapes à venir seront plus développés, c’est–à-dire que la roadmap produit sera découpée en plus petits jalons. Pour la phase à court terme, nous savons concrètement ce que nous devons faire et quels sont nos objectifs. Nous pouvons donc l’expliquer plus en détails : fonctionnalités à développer en priorité, cotation du nombre de jours de développement, date prévisionnelle de livraison, etc.

Cependant, pour les éléments à plus longue échéance, nous ne rentrons pas dans le détail. Ce sera simplement un nom d'ensemble de features, une macro-estimation. S’il y a plusieurs équipes d'un service, elle peut potentiellement inclure l'équipe par qui ça va être traité pour commencer à dispatcher.

“ Au moment de créer la roadmap produit, ce n’est pas le moment de se poser des questions dites “opérationnelles”. Il faut se les poser au moment où les fonctionnalités arrivent dans la vision court terme. Tu détailleras tout dans le backlog produit. La roadmap produit n’est pas faite pour ça. “

La roadmap produit doit être agile ?

Inévitablement ! Ceux qui pensent qu’une roadmap produit est figée dans le marbre se trompent. Elle ne cesse d’évoluer, c’est un outil vivant. Souvent le board dirigeant pense, à tord, qu’elle n’évoluera pas, que tout ce qui est inscrit dans la roadmap se passera comme prévu. C’est ça aussi qui est challengeant dans la fonction de Product Manager, c’est qu’il est important de bien faire comprendre que ce n’est pas un objectif à tenir absolument mais une direction.

“ Ce n’est pas sain de se dire “cette roadmap ne va pas bouger”. Ça marche bien quand tu construis un immeuble, pas quand tu fais du développement de logiciel ! ”

Quel est ton avis sur les deadlines imposées dans les projets ?

Dans un monde idéal, je te dirais que non, il est préférable de ne pas imposer de deadline. En tout cas, en agile, on évite d’imposer des deadlines sans possibilité d’adapter le scope de la feature. Dans les faits, tu en as et il y en aura toujours. Souvent c’est dicté par le “time-to-market”, sortir la bonne fonctionnalité, au bon moment, ce sont des actions imposées par le business, c’est comme ça. Et puis t’as des features qui peuvent être de tous types, parfois pour des raisons légales et qui doivent aussi sortir rapidement.

Parfois certaines features n’apportent même pas tant de valeur que ça et si elles n’avaient pas été imposées, tu ne les aurais probablement pas mis dans ta roadmap. 

Après, les deadlines fortes et imposées systématiquement c’est compliqué car tu sors du cadre de l’agilité donc ce n’est pas bon. Mais des deadlines il y en aura toujours, tu dois t’en imposer à toi-même, aux équipes et parfois elles te sont imposées. Et c’est normal, il faut être réaliste.

Jusqu’à aujourd’hui, dans toutes mes expériences chez divers clients, on m’a toujours imposé certaines échéances pour des features stratégiques ou légales.
Après l'important c'est de savoir prioriser et de jongler entre les divers besoins et attentes.

Quelles méthodes existent pour apprendre à bien prioriser ?

Les méthodes de priorisation du backlog se ressemblent un peu toutes. Personnellement, ce que je fais et qui marche, c’est que je demande à toutes les personnes qui sont parties prenantes du projet de se retrouver autour d’un atelier pour prioriser ensemble les tâches à venir et les features à développer. Cela permet aussi d'instaurer de la communication entre eux qui sera utile tout au long du projet.

Chacun avec des post-its, ils vont noter de 0 à 10 l’importance de chacune des features demandées selon l’apport de valeur et l'objectif pour le business et l’utilisateur. Les décisions prises doivent être collégiales et tout le monde doit être d’accord.

Les équipes techniques estiment l'effort et le coût de développement pour chacune des tâches, ce qui permet de faire un ratio entre coût de développement VS valeur business pour l’entreprise. Tu peux ensuite hiérarchiser plus facilement les tickets à prioriser de manière objective.

Évidemment il y aura des allers-retours, des personnes qui ne seront pas d’accord avec la priorisation des fonctionnalités dans la roadmap mais en ayant en tête ce rapport coût de développement VS valeur business, tu es mieux armé pour prioriser les tâches du service, en connaître l'impact et argumenter.

Pour pouvoir bien prioriser, je conseille aussi d'avoir un support lisible et visuel. Cela apporte plus de clarté pour tout le monde.

Quels outils utiliser pour construire une roadmap produit visuelle ?

Il existe de nombreux outils, modèles de roadmap produit, du gratuit au payant. Personnellement je n'utilise pas ce type de modèles, je ne trouve pas ça utile dans la mise en place.

Je suis plutôt partisan du modèle 100% personnalisable, un bon tableau blanc collaboratif comme par exemple FigJam fait très bien le travail. Tu peux mettre les informations importantes, faire en sorte que le modèle de board soit visuellement attrayant, l’outil est collaboratif donc tout le monde peut modifier ou faire des propositions et ça suffit très bien. C'est un document de communication et de collaboration efficace auprès des équipes.

Considères-tu la construction d’une roadmap comme l’un des exercices les plus difficiles auxquels sont confrontés les Product Managers ? 

Sans l’ombre d’un doute. La roadmap produit c’est vraiment LA responsabilité du PM, si tu rates ta feuille de route, tu peux complètement rater ton produit. À la fois c’est l’exercice le plus dur mais c’est également le plus intéressant du projet. Parce que c’est toi qui donnes la direction au produit, qui vas prendre les initiatives et décider de la suite du projet. C’est forcément gratifiant.

Conclusion : la mise en place d'une roadmap produit, tout le monde peut le faire ?

Je pense que pour faire une roadmap il faut des compétences méthodologiques mais il faut surtout s’entourer d’une équipe qui connaît tous les aspects du projet et du produit. Et je pense que c’est là où il est important d’avoir une certaine humilité côté Product Manager. Car, en tant que PM, tu es techniquement compétent sur le produit, tu sais ce qu’il vaut mais tu n’auras pas forcément les connaissances sur les opportunités. C'est un document stratégique important, il vaut mieux ne pas se louper.

Un CEO qui connaît bien son produit, ses potentiels clients, le marché sur lequel il se lance et qui est accompagné de personnes ayant une bonne méthodologie et des connaissances en stratégie produit, serait capable de créer une roadmap.

Cependant, dans 90% des cas, le CEO n'est pas entouré et va donc construire sa roadmap seul dans son coin. Du coup, celle-ci n’aura que sa perspective projet à lui. Alors que le principe même d’une feuille de route c’est qu’elle ne reflète pas la vision d’une personne mais la vision globale de l’entreprise sur son produit.

C’est l’erreur la plus courante. Pour bien construire sa roadmap produit il est essentiel qu’elle soit collaborative, construite avec la bonne méthodologie et validée par tous les acteurs de l’entreprise. On évite les prises d'initiatives qui pourraient avoir des impacts négatifs sur votre produit. 

Sébastien BESSOUDO
Product Manager
@Eleven Labs

Sébastien est issu d’une formation universitaire en Psychologie et Ergonomie
et après une expérience de Scrum Master, il a décidé de s’orienter vers le product ownership
et la gestion de produit. Après presque 6 ans d’expérience dans des équipes agiles,
il est aujourd’hui Product Manager chez Eleven Labs.