Comment bien construire une roadmap produit ? Les bonnes pratiques de notre expert

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

Dans cette interview, Sébastien nous partage ses bonnes pratiques et convictions pour réaliser une roadmap produit alignée avec les enjeux, objectifs et besoins de tous les acteurs du projet. Il nous dévoile les étapes à suivre pour créer une roadmap lisible visuellement et compréhensible par tous.

Selon ta propre définition, 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. “

Selon moi, 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 :

  • Vision Produit

  • Date de lancement ou période du projet

  • Contenu du projet avec les principales fonctionnalités et thématiques

  • Objectifs et enjeux stratégiques du produit

  • Livrables attendus

  • Bonus : les indicateurs à utiliser pour mesurer la réussite des idées développées

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

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 l'étape à 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. “



Quels sont les acteurs importants à intégrer à la construction de sa roadmap produit ?

En tant que Product Manager (PM), 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 ni toutes les données du produit : business, stratégique, opérationnelle, métier, ressources… Sa création est faite impérativement avec les acteurs stratégique de l'équipe.

Dans ceux-ci, tu as généralement, les managers ou le dirigeant qui sont les sponsors et porteurs de la stratégie business, le Lead Développeur qui a la connaissance technique des ressources interne et le métier et/ou les utilisateurs qui vont utiliser ton produit.

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

 

Penses-tu que réaliser un atelier soit une étape indispensable pour créer sa direction produit ?

Oui, c’est essentiel. C’est ce que j’expliquais avant, on peut formuler, en tant que PM, 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. Car sans avoir communiquer tous ensemble, je ne peux pas définir les priorités.

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 toute l'équipe. Les actions à mettre en place doivent être lisibles. Et Les priorités définies en accord avec tous les acteurs.

“ 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 pour l'utilisateur, de son objectif et de son impact sur le produit. Plus la valeur est haute, plus elle sera priorisée dans la roadmap produit. “

 

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 ! ”

Envie d’aller plus loin dans la conception de votre roadmap produit ?

Retrouvez tous nos REX et conseils dans notre livre blanc sur l’organisation produit : de la start-up à la scale-up

Téléchargez notre livre blanc

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 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 features 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 tu préconises 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 roadmap, 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 roadmap 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

Envie d’être accompagné dans la création et le pilotage de votre roadmap produit ?

Organisons un échange !

Demander un rendez-vous

Découvrez d’autres articles autour du Product Discovery & Product Management