Définition : qu'est-ce que la product roadmap ?
La roadmap est un outil pour planifier et prioriser les projets à la fréquence d’un trimestre. Dans beaucoup de start-up / scale-up, la langue utilisée sera souvent l’anglais : on parle de quarter. En tant que PM, vous travaillerez donc sur la roadmap tous les trimestres. Certaines boîtes travaillent sur leur roadmap toutes les 6 semaines ou 6 mois, mais c’est plus rare.
La roadmap est donc la liste des initiatives prioritaires du prochain trimestre. Chacun des projets est appelé EPIC dans les terminologies agiles.
Avant de rentrer dans le détail de la roadmap, il est important de rappeler les différents niveaux de granularité sur lesquels travaille un.e Product Manager. Chaque niveau correspond à une plage de temps.
Il y a 5 étapes en entonnoir, de la vision aux user stories :
- Product vision, sur le long terme (5 ans)
- La stratégie produit, comment met-on en place cette vision cette année
- La roadmap qui révèle les projets du trimestre
- Les sprints, d’une à deux semaines pour décomposer la roadmap
- Les user stories pour délivrer les fonctionnalités
La différence Vision, Stratégie & Roadmap
- La vision détermine où on veut aller
- La stratégie définit comment on veut y aller
- La roadmap clarifie les projets à mettre en oeuvre pour atteindre cette stratégie
Pourquoi la product roadmap est-elle importante ?
Il y a énormément d’idées reçues sur le rôle de la roadmap. Pour commencer, voici ce que la roadmap n’est pas :
- Ce n’est pas un planning par semaine de votre trimestre.
- Le but n’est pas de déterminer des dates de livraison de vos fonctionnalités : la roadmap n’est pas un outil de project management.
- La roadmap contient une liste restreinte d’initiatives prioritaires : ce n’est pas un backlog avec une longue liste de fonctionnalités.
C’est un outil important car :
- Toutes les équipes seront alignées sur les priorités de l’entreprise, et la bande passante de développement accordée à chaque initiative
- La roadmap est un outil de communication pour la stratégie produit
- Elle responsabilise les équipes Tech/Produit et donne des objectifs
Qui est responsable de la roadmap ?
La responsabilité de définir la roadmap dépend des types d’entreprises et de la culture dans cette entreprise :
- Certaines start-up ont une culture Top-down, où les priorités sont déterminées par le top management.
- D’autres entreprises ont une culture Bottom-up, où les squads ont plus d’impact sur la définition de leur roadmap.
C’est une très bonne question à poser en entretien : “qui est responsable de définir la roadmap ?”. Cela vous permettra de mieux comprendre votre futur rôle en tant que Product Manager.
Comme on le voit dans l’entonnoir au début de cet article, la roadmap va dépendre de la stratégie produit pour l’année : quels sont les objectifs clés que l’on souhaite atteindre sur les 12 prochains mois ? Cette stratégie produit va être généralement définie par le leadership de l’entreprise :
- Quels sont les objectifs pour l’année prochaine ? (Ex : Monétisation, Conversion, NPS ?)
- Quelles ressources seront allouées à chacun de ces objectifs. (C'est-à-dire : combien de squads vont travailler sur cet objectif ?)
Dans une entreprise qui a plutôt une culture “bottom-up”, c’est le.la Product Manager qui va déterminer la roadmap pour sa squad. Pour les grosses entreprises, un découpage est fait par tribe, qui est un regroupement de 3-4 squads avec un.e Lead PM à la tête de la tribe.
Dans ce cas, le.la Product Manager définit sa roadmap et le.la Lead PM s’assure de la cohérence de la roadmap avec le reste de la tribe.
C’est un exercice qui doit inclure les équipe business et les équipes tech.
"Roadmap is not about collaboration, about inclusion." Marty Cagan
Généralement, roadmap est revu par le.la Head of Product/ CPO.
Comment construire une roadmap produit ?
Pour construire une roadmap Produit, vous pouvez suivre ce framework :
- Récupérer les inputs
- Les retours des utilisateurs
- Le feedback interne de vos collègues (Customer Success, Sales, Account Manager…)
- La data
- Filtrer et dire non : “acid test”
En tant que PM, vous devrez dire non à 80% des demandes car elles ne sont pas faisables ou alignées à la vision de l’entreprise. Pour y répondre, on utilise l’acid test, framework développé par Intercom. L’idée est simple - si la réponse à une des questions est non, alors il ne faut pas développer cette feature.
Question 1 : Est-ce que cette idée va dans le sens de votre vision Produit ?
Question 2 : Est-ce qu’elle impactera beaucoup d’utilisateurs ?
Question 3 : Est-ce que l’on a la capacité en interne de développer cette fonctionnalité ?
Question 4 : Cette idée améliore-t-elle des metrics business ?
- Estimation de l’impact
Ici, vous devez être au clair sur les objectifs business que vous souhaitez impacter. Quels sont vos objectifs ? Est-ce que vous souhaitez améliorer des KPI de conversion ? De rétention ?
Une fois que vous êtes au clair, vous pouvez estimer l’impact des projets candidats sur vos KPI. Ici, ce sont des analyses date qui permettront d’avoir une idée de l’impact d’un projet sur votre metric principale.
- Estimation du temps de développement
Vous travaillerez main dans la main avec votre Lead dev pour cette partie. Ce n’est pas le rôle d’un.e PM d’estimer le temps de développement de chaque feature. Pour l’estimer, vous pouvez utiliser la technique du T-Shirt sizing (XS, S, M, L, XL).
- Prioriser.
Il y a plusieurs méthodes de priorisation possibles. Ici, vous pouvez utiliser la méthode RICE (ou RICE Scoring Model).
Reach - Impact - Confidence - Effort
Noé a fait un webinar sur le RICE, il est disponible ci-dessous.
- Appliquer les contraintes : dépendances et capacité d’équipe
Certaines contraintes doivent être prises en compte dans la définition de votre roadmap. Il y a deux contraintes principales à considérer :
- Les dépendances : parfois, vous aurez un projet prioritaire qui nécessite l’intervention préalable d’une autre équipe. Dans ce cas, vous devrez probablement décaler ce projet au trimestre suivant.
- La capacité de votre équipe : il peut arriver qu’un projet nécessite une expertise que vous n’avez pas dans l’équipe - par exemple un développeur spécialisé Paiement. Vous devrez donc vous synchroniser avec une autre équipe pour que cette personne puisse venir dans la squad le temps du projet : cela peut aussi repousser la mise en place du projet.
- Inclusion et alignement des équipes
Le process de roadmap implique d’inclure les parties prenantes (notamment les équipes business, et l’équipe Exec). Vous devez inclure ces équipes tout au long de ce processus mais une fois que vous aurez établi les priorités, il faudra faire un dernier point d’alignement pour acter ces priorités.
- Faire évoluer la roadmap au gré du trimestre
Certains projets qui ne sont pas forcément prioritaires d’un point de vue business peuvent être ajoutés à votre roadmap, comme le RGPD ou des projets de sécurité si vous avez été victime de cyberattaque.
Quels sont les différents types de roadmap ? Exemple de product roadmap
Dans une roadmap, vous allez présenter les features retenues comme prioritaires pour les 3 prochains mois. Vous n’aurez pas le même niveau de précision en fonction de la personne à qui vous présentez : il y a différents frameworks pour présenter la roadmap.
Roadmap investisseur. Ex : Front
Pour les investisseurs, votre roadmap sera large. Vous ne rentrerez pas dans les détails des features.
Roadmap publique. Ex : Slack
Certaines entreprises choisissent de partager leur roadmap en public, pour leurs utilisateurs ou leurs prospects. C’est le cas de Slack (roadmap pour leur Developer platform ci-dessous) :
Contrairement à la roadmap investisseur, les utilisateurs connaîtront en détail vos prochains projets. Pas de date limite, simplement des plages de temps (court, moyen et long terme) pour donner une dimension de temps, sans s’engager sur une date auprès des utilisateurs. Ensuite, released permet de montrer aux utilisateurs les features déjà délivrées.
Roadmap interne : présentation
Vous présentez votre roadmap à toute l’entreprise. Cette roadmap doit être plus détaillée pour que les équipes comprennent mieux le Produit. Idéalement, chaque Product Manager présente sa roadmap en compagnie de son.sa Lead Dev. Le format est davantage une présentation des grandes priorités du trimestre.
Attention une roadmap n’est pas un backlog !
Comment bien estimer le temps de développement ?
Ce n’est pas votre rôle en tant que Product Manager d’estimer le temps de développement. La plupart des PM n’ont pas de background tech. L’estimation est un art difficile, l’objectif est plutôt de se tromper le moins possible mais il y aura toujours des imprévus. C’est le rôle de votre équipe tech et surtout de la lead dev qui est owner de cette estimation.
Voici quelques conseils néanmoins :
- Découper vos fonctionnalités, en “tranches” pouvant être développées de manière indépendante. Ce découpage, avec le.la lead dev, permet d’affiner davantage l’estimation du temps de développement.
- Inclure l’équipe tech dans la discovery, notamment en les invitant à des interviews utilisateurs. Le fait de comprendre les problèmes à résoudre permet de mieux concevoir la stack technique de vos fonctionnalités et donc, d’optimiser le temps de développement.
- Suivre chaque semaine l’avancée des projets pour tirer la sonnette d’alarme et ajuster le cas échéant.
- Être clair sur les priorités. Vous devrez souvent déprioriser certaines fonctionnalités en cas de retard. Vous devez être clair sur ce qu’il faut couper dans ce cas. Pour cela, le framework MoSCoW permet de définir les priorités en 4 catégories : Must have, Should have, Could have, Won’t have)
- Le micro-management ne sert à rien pour mieux estimer le temps de développement. Cela va simplement déresponsabiliser les développeurs et faire perdre du temps à tout le monde.
- Imposer des deadlines n’est pas la solution.
- Prévoir un temps dédié au rollout. C’est un processus qui prend du temps et les équipes ont tendance à l’oublier.
- La PM doit clarifier les objectifs du sprint pour la livraison: objectif primaire, objectifs secondaires
Comment présenter sa roadmap ?
A toute la boîte
Lorsque vous présentez la roadmap à l’entreprise, il est important de revenir sur le trimestre précédent :
- Quels sont les objectifs atteints ou non ?
- Prendre le temps de célébrer les projets livrés au trimestre précédent : les équipes ont souvent tendance à foncer tête baissée sur le trimestre suivant, sans célébrer ce qui a été accompli les 3 derniers mois !
Également, il faut expliquer les grandes priorités du trimestre suivant avec les grands projets à attaquer (sans rentrer dans les spécifications), équipe par équipe.
Enfin, ce n’est pas le moment de donner de deadline. On donne simplement un ordre de priorité.
A son équipe (squad)
Pour l’équipe, vous devez rentrer plus dans le détail : pourquoi on veut améliorer cette partie, quelle metric veut-on améliorer, quels sont les problèmes identifiés… Évidemment, votre équipe ne doit pas découvrir ces sujets pendant la présentation. Vous les aurez tenus dans la boucle durant le trimestre précédent et cette présentation sert plutôt à officialiser les priorités et lancer le quarter.
La roadmap dépend de l’organisation : découpage du produit ou objectif stratégique ?
Il y a 2 manières d’organiser les équipes Produit et Tech, par découpage fonctionnel (ex : Meta), et par objectif stratégique (ex : Spotify).
L’organisation par objectif stratégique est la plus utilisée dans les start-up. Quelle que soit l’orga, théoriquement, toutes les squads doivent être autonomes en termes de compétences tech mobile, backend et frontend.
A noter : les équipes infrastructure sont souvent indépendantes et ont leur propre roadmap.
L’organisation de votre roadmap dépendra forcément de l’organisation produit de votre équipe.
Quels sont les meilleurs outils pour gérer une roadmap produit ?
Beaucoup de Product Managers utilisent des outils classiques pour construire leur roadmap (Google Slides, Google spreadsheets et Trello). Néanmoins, des outils dédiés apparaissent comme Aha, ProductBoard et ProdPad.
Template de roadmap produit
La meilleure organisation se fait par colonne. Le plus simple est le mieux.
Attention : La roadmap n’est pas un outil de planning par semaine.
Entretien : quelles sont les questions sur la roadmap produit ?
Lorsque vous passerez des entretiens de recrutement sur la roadmap, il peut vous arriver d’avoir des questions sur la roadmap. Voici les principales questions :
- Questions de priorisation : comment prioriserais-tu entre A et B ?
- Comment ferais-tu un re-design du newsfeed Facebook ?
- Quels sont les éléments à prendre en compte pour construire la roadmap ?
Pour les questions 1 et 2, l’objectif est de savoir que vous connaissez les principes de priorisation comme le RICE et que vous savez les utiliser.
Comment bien faire évoluer une roadmap produit ?
La roadmap est un outil vivant qui évolue au fil du trimestre. Vous devez la tenir à jour en prenant en compte l’avancée des projets. Pour cela, la vue en colonne est utile car vous pouvez facilement mettre à jour l’avancée des projets.
Comment créer une roadmap pour plusieurs produits ?
Si vous avez plusieurs produits, chaque produit doit avoir sa roadmap dédiée.
