Comment construire une roadmap produit ?

Une tentative de réponse à ce casse-tête de product manager ! 

Au cours des 7 dernières années, à travers plusieurs postes de product manager et projets freelance, j’ai appris énormément en termes de construction de roadmap. C’est l’un des exercices les plus difficiles auxquels on est confronté en tant que product manager. Car il faut faire des sacrifices, et car on est confronté à énormément de pression. En interne, de la part d’autres équipes, mais également en externe, de la part des utilisateurs ou des clients. 

Dans cet article, je tente de donner quelques conseils qui me viennent de mon expérience personnelle mais également de la part d’équipes produit d’entreprises “modèle” dans la sphère produit comme Intercom, Basecamp, Front et Slack.

Qu’est-ce qu’une roadmap produit ?

Une roadmap produit, c’est l’exercice de transformer une liste désordonnée de projets en un résumé priorisé et visuel des priorités de l’équipe produit pour les prochain(e)s semaines/mois/années. Cela permet à l’équipe produit de bâtir un plan d’action et communiquer autour de leur vision concernant l’avenir du produit. 

Il y a deux éléments clés dans la construction d’une roadmap :

1. Prioriser les projets
2. Construire une roadmap visuelle

1. Prioriser les projets

Coût/bénéfice = ROI

Tout est une histoire d’équilibre entre coût et bénéfice

Comme on le sait, une équipe produit & tech a une capacité de développement limitée durant une période définie. Tous les projets ne peuvent pas être réalisés. C’est pourquoi ils doivent être priorisés. Comment ? La méthode de base, c’est d’évaluer le coût et le bénéfice de chaque projet.

Ce faisant, vous pourrez en déduire le ROI (retour sur investissement) de chaque projet et transformer une liste désordonnée en une liste priorisée.

Source : Ruthless Prioritization par The Black Box of Product Management

Mais tout cela reste très conceptuel. Certes, le “time to build” (l’effort de développement) peut être aisément estimé, à condition d’avoir une idée suffisamment aboutie de la solution en question, avec des règles de fonctionnement et des maquettes même simplifiées. Mais comment mesurer rigoureusement la “customer value” ; la valeur que cela apportera à l’utilisateur final ? 

Valeur pour l’entreprise, valeur pour les clients

En réalité, la “customer value” est souvent un mélange entre la “valeur pour l’entreprise” et la “valeur pour les clients”. 

Idéalement, tous les projets devraient figurer dans l’intersection entre les deux zones, mais ce n’est pas toujours le cas…

Certaines entreprises implémentent même des fonctionnalités qui ne génèrent de la valeur que pour elles, mais zéro pour leurs clients. Prenez l’exemple de Ryanair il y a quelques années, avec le parcours utilisateur de son assurance voyage : en tant que client, si vous ne souhaitiez pas souscrire à l’assurance voyage, il fallait sélectionner l’option “Ne m’assurez pas” dans leur liste déroulante du choix du pays…!

A typical example of a UX “dark pattern”

Ceci a généré un tollé auprès de nombreux clients, contribuant à une nette baisse de confiance vis-à-vis de l’avionneur irlandais.

Cette différence entre “valeur pour l’entreprise” et “valeur pour l’utilisateur” est ce qui distingue les équipes produit “centrées sur l’utilisateur” (user-centered) des équipes produit “centrées sur la croissance” (growth-centered) ; termes inspirés de l’article “The 6 Types of Product Teams You’ll be Working in de Ariel Verber.

Une équipe “centrée sur l’utilisateur” place ses utilisateurs au-dessus de tous les KPI de l’entreprise. En fait, la satisfaction des utilisateurs est probablement le KPI numéro 1 dans ces équipes-là. Des exemples d’équipes centrées sur l’utilisateur peuvent être trouvés dans des entreprises comme Duolingo ou Basecamp. 

Une équipe “centrée sur la croissance” est une équipe pour qui le succès dépend principalement de la maximisation de KPIs de croissance comme l’activation, la rétention, la conversion, mais pas la satisfaction de ses utilisateurs. Des exemples d’équipes centrées sur la croissance peuvent être trouvés dans des entreprises comme LinkedIn ou Booking.com. 

Méthodes de priorisation : l’exemple de RICE

Revenons à notre histoire de priorisation. Nous avons vu que le ROI est la manière fondamentale de prioriser des projets. Mais certaines entreprises ont développé leurs propres méthodes de priorisation. Par exemple, Intercom a créé la méthode “RICE”.

“RICE” signifie “Reach, Impact, Confidence and Effort” (portée, impact, confiance et effort) : 

• Reach (ou portée) : Combien de personnes vont être impactées par cette initiative ? Par exemple, si je travaille sur la fonctionnalité “Evenements” de Facebook (utilisé par 15% des utilisateurs) sur l’application Android (plateforme sur laquelle Facebook compte 500 millions d’utilisateurs), mon Reach est de 75 millions d’utilisateurs).
• Impact : Quel va être l’impact de mon initiative sur chaque utilisateur ? L’idée ici est de choisir un score d’impact défini arbitrairement. Intercom recommande de choisir un intervalle entre 0,25 (pour un impact minime) et 3 (pour un impact maximal) et d’appliquer un coefficient multiplicateur.
• Confidence (ou confiance) : Quel niveau de confiance avez-vous dans vos estimations ? Ceci s’exprime avec un pourcentage de probabilité.
• Effort : Ceci représente l’effort de développement technique. Combien de “mois-hommes” ce projet représente-t-il ? 

Cette méthode peut être intéressante si vous n’avez aucun point de départ. Voici quelques autres idées de critères à prendre en compte lorsque vous priorisez des projets : 

• Est-ce un réel problème utilisateur ? Vous pouvez créer un score, de 0,25 à 3 comme pour le score d’impact, pour définir si votre projet résout un réel problème rencontré par vos utilisateurs ou si c’est purement un projet qui crée de la “valeur pour l’entreprise”
• Alignement avec la vision long terme : Parfois, certains projets “opportunistes”, qui ne sont pas nécessairement alignés avec la vision long terme de l’entreprise, doivent être tout de même priorisés par la force des choses.
• Concurrence : A quel point ce projet permet-il à votre entreprise de se différencier de la concurrence ? Dans des industries très compétitives, ceci peut être un critère très important à prendre en compte. 

Un dernier mot sur la priorisation : Il n’y a pas de recette miracle. Le plus important est d’itérer régulièrement, jusqu’à ce que vous trouviez votre propre méthode de priorisation ; celle qui correspond à votre produit, à votre industrie, à vos indicateurs et à vos valeurs. 

2. Construire une roadmap visuelle

Le product manager montre la voie…

Une fois que vous avez priorisé vos projets, vous pouvez commencer à communiquer votre roadmap auprès des personnes intéressées (votre équipe, le reste de votre entreprise, vos partenaires, vos clients). 

À ce stade, vous serez probablement confronté à ce type de fichier :

Une liste de projets priorisée pour la roadmap de l’application Yelp sur iOS (extrait d’un de case study utilisé dans le cadre d’un entretien pour un poste de product manager il y a quelques années)

Personne, à part vous peut-être, ne prendra plaisir à lire cette feuille Excel fastidieuse. La prochaine étape est donc de transformer cette liste de projets en un document visuellement attractif. 

Quel format choisir ?

Mon conseil numéro 1 est d’éviter de construire un diagramme de GANTT. 

C’est une source inépuisable de maux de tête, ce n’est jamais à jour, et les prévisions ne sont jamais respectées.

Un document de roadmap que nous utilisions il y a quelques années lorsque j’étais product manager chez BlaBlaCar

Il est plus simple pour les autres équipes et vos clients de lire une roadmap sous un format kanban, avec une colonne par statut de projet. La “Roadmap for Developers” de Slack Platform est un bon exemple. 

La “Roadmap for Developers” de Slack Platform est un tableau Trello ouvert au public

Si vous souhaitez construire une roadmap simple et facilement lisible, je vous conseille d’utiliser Trello ou Notion.

Le casse-tête des “deadlines”

Mon conseil numéro 2 est d’éviter, autant que possible, d’imposer des deadlines, ou dates de lancement. Ou alors, imposer des deadlines, mais permettre au périmètre (“scope”) du projet de changer au cours du temps. 

Dans le développement informatique, les expressions de besoin (“requirements”) changent régulièrement et il y a généralement de nombreux imprévus au fil du développement, ce qui rend le fait d’anticiper une date de lancement très difficile. 

Plus d’informations à ce sujet dans l’excellent article “Runnings in Circles” du blog Signal V. Noise

Par exemple, dans son tableau public Trello “Front Product Roadmap”, Front affiche publiquement les projets actuellement en cours de développement, mais n’affiche aucune deadline. Tous les projets en cours de développement apparaissent au sein de la colonne “Coming Soon”.

Bien sur, le fait de ne pas annoncer de dates de lancement peut poser quelques problèmes aux équipes qui en dépendent dans leur travail au quotidien. Je pense par exemple aux équipes commerciales, marketing et communication. 

Pour pallier à ce problème et pour permettre aux équipes produit/tech et sales/marketing de travailler en harmonie, Intercom a trouvé un compromis. Lorsque j’ai participé à la conférence Intercom Tour à Paris en 2017, Paul Adams, le VP Product d’Intercom, a détaillé la manière dont ils gèrent les deadlines en interne. 

Chaque trimestre, les équipes produit et tech communiquent au reste de l’entreprise une liste de projets sur lesquels ils comptent travailler durant le trimestre, sans annoncer de date de lancement. Les dates de lancement ne sont annoncées que 2 semaines en avance, lorsque les équipes produit et tech sont certaines à 99% que le projet va être livré. Ceci donne un minimum d’information aux équipes sales et marketing, qui dépendent énormément des dates de lancement des nouvelles fonctionnalités pour établir des relations de long terme avec leurs prospects et clients. 

Problèmes vs. fonctionnalités

Durant ce talk, Paul Adams a parlé d’une autre idée intéressante : l’importance de créer des roadmaps orientées “problèmes”, plutot que des roadmaps orientées “features”. 

Paul Adams on Twitter: “Roadmaps that contain problems to solve are better than roadmaps with lists of features to build. Sadly the latter is more common.”

Pourquoi est-ce si important ? Car entre le moment où une équipe produit commence à s’attaquer à un problème et celui où une solution est effectivement livrée en production, des dizaines de fonctionnalités différentes peuvent être considérées comme pertinentes pour résoudre le problème en question. A travers de la recherche utilisateur, en raison de contraintes techniques ou de la stratégie de l’entreprise, l’équipe produit va itérer jusqu’à ce que tout le monde tombe d’accord sur la bonne solution. C’est pourquoi le fait d’annoncer une fonctionnalité bien définie en amont, durant la communication de votre roadmap, pourrait s’avérer déceptif pour vos parties intéressées si cette fonctionnalité venait à changer.

En résumé, voici mes conseils pour construire une roadmap produit :

• Priorisez vos projets, en évaluant les couts et bénéfices (pour vos utilisateurs et pour l’entreprise). Inspirez-vous de méthodes de priorisation comme RICE. Et surtout, mettez au point votre propre méthode de priorisation !
• Construisez une roadmap visuelle. Evitez les diagrammes de GANTT. Autant que possible, évitez d’imposer des deadlines. Utilisez des outils comme Trello et Notion. 

Bon courage dans la construction de votre roadmap ! 

Découvrez également sur Tribes