Construire ta Roadmap
Correctement réalisée, ta roadmap peut orienter l'ensemble de ta boîte vers la réussite de ses objectifs. 🚀
Hellooo,
Aujourd’hui on s’attaque à un GROS morceau. 🐳
J’ai vu/lu/écouté une dizaine d’articles, de podcasts et de vidéos sur Youtube (13 pour être exacte) concernant la Roadmap et je te synthétise tout.
On va voir comment créer et communiquer sur la roadmap, et quelques tips que j'ai pu trouver durant mes lectures. 🤓
Aussi, je serai aussi super intéressé de savoir comment toi tu créés ta roadmap en commentaire !
Il est possible que l’article soit trop long pour être vu complètement par e-mail. Je te recommande de l’ouvrir sur ton navigateur :
🗺️ Le plan
Qu’est-ce qu’une roadmap et à quoi sert-elle ?
Les différents frameworks pour ta roadmaps
666 Roadmap
Now/Next/Later
Construire ta roadmap basée sur les résultats
Qui va créer la roadmap et quelles sont les étapes de sa création ?
Ta Roadmap d'Initiative
Ta Product Roadmap
Ta release Roadmap
Outcome oriented
Comment planifier ce qui rentre dans ta roadmap produit ?
Les questions à se poser
La dette technique et la sécurité
Présenter ta roadmap
À qui et comment partager ta roadmap ?
L'audience
Le Storytelling
Rester Macro
Les Metrics
Valider/réviser ta roadmap
La Diffusion
Autres tips pour ta Roadmap
Qui l'utilise ?
Les outils pour créer ta roadmap
À quelle fréquence et comment itérer sur ta roadmap ?
Ce qu’il faut éviter sur ta roadmap
Avoir une Roadmap produit et une Roadmap technique
Croire que tout va bien se passer
La feature factory
La Roadmap au gut feeling + solo
Accepter toutes les urgences
Je reviens de Corée et créer une roadmap me fait un peu penser à un voyage.
Tu te demandes quel type de voyage tu veux faire (chiller ou découvrir de nouvelles choses), tu planifies les endroits que tu veux visiter, à quelle date.
Puis tu te demandes comment y aller à pied, en bus, métro, train, à dos de mulet… 🐴
En marchant, tu décides de faire un détour dans cette rue que tu trouves jolie, ce qui change le plan initial et tu dois retirer une destination que tu avais planifiée parce que tu n’as plus le temps. ⌛
Et comme chaque personne a sa façon de planifier ses voyages, chaque entreprise exige un format différent et chaque PM a ses préférences également.
C'est d'ailleurs pourquoi lorsque tu tapes sur Google Images "Product roadmap", tu tombes sur plein de types différents. 😵💫
Second problème, c’est que beaucoup d'équipes produit ne remettent jamais en question la manière de construire leur roadmap.
Pourtant, elles ne la construisent parfois pas correctement, ne l’utilisent pas à bon escient et ne la font pas évoluer.
La roadmap est trop dans les détails, elle est trop micro avec des deadlines à la date près, alors qu’elle devrait être plus haut niveau, découler de la vision produit, et décrire comment un nouveau produit va créer de la valeur pour les utilisateurs et l’entreprise.
Qu’est-ce qu’une roadmap et à quoi elle sert ?
A good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.
— Bruce McCarthy, Founder at Product Culture
Une roadmap produit c'est la visualisation dans le temps des futurs produits en development.
Elle permet de communiquer sur le “why” et le “what” d'un produit.
Une bonne roadmap doit :
Présenter clairement la vision d'un produit, aligne et engage toute l'entreprise sur le court et le long terme. Elle sert de guide pour la création et la mise en œuvre de la stratégie produit et ainsi réduire l’incertitude. 🌟
Permettre d’allouer efficacement le temps et les ressources en communiquant les attentes, les priorités et les releases. 🗓️
Faciliter les discussions sur la priorisation et la communication entre les parties prenantes. 💬
La plupart des products roadmaps se confondent avec le release plan.
La Roadmap = Opportunités, et l’opportunité est considéré comme “done” quand le KPI cible est atteint (chaque opportunité est rattachée aux OKRs).
Release plan = Features, et la feature considéré comme “done” quand elle est livrée.
Une roadmap produit communique visuellement la vision, la stratégie et les objectifs de votre produit d'une manière que tout le monde puisse comprendre et elle unit l'équipe produit derrière un objectif commun.
Elle doit être vivante, tout comme quand tu es amené à changer d'itinéraire pendant ton voyage, il faut accepter que la roadmap puisse aussi évoluer.
Ce que j'entends par vision, stratégie et objectifs :
Vision produit : l'objectif global que vous visez, la raison de la création du produit.
Stratégie produit : votre plan pour donner vie à votre vision du produit. Elle décrit clairement ce que vous visez à atteindre.
Objectifs : des objectifs clairs et mesurables alignés sur les résultats spécifiques que vous vous efforcez d'atteindre pour vos users, votre produit et l’entreprise.
Si tu penses qu’une personne autour de toi pourrait être intéressée par Product Shonen, n’hésite pas à lui transférer cette édition directement par e-mail, ou à cliquer sur le bouton ci-dessous !
Si tu n’es pas encore abonné(e), c’est le moment 👇
Les différents framework pour ta roadmaps
Il a plusieurs façon de créer des roadmaps, ici je t’en présente deux que j’apprécie bien.
666 Roadmap
Dans son article The 666 roadmap, Paul Adams propose 3 timelines de roadmap.
Les 6 prochaines années
Comment est-ce que tu vois le monde en prennant en compte ce que vous aurez changé.
Les 6 prochains mois
Votre plan pour construire des choses qui auront un impact significatif sur votre cheminement vers le changement que vous souhaitez instaurer dans le monde.
Les 6 prochaines semaines
C'est ton plan maintenant, tu sais exactement ce qui va être construit.
Now/Next/Later
Chez Thiga, ils utilisent le framework Now/Next/Later qui fournit un cadre que tout le monde peut comprendre et même aider à exécuter :
Le “Now” couvre le trimestre (les étapes, de directives et d'instructions que nous suivrons pour y arriver).
Le “Next” les deux trimestres suivants (dans quelle direction générale devons-nous nous diriger pour y arriver).
Le “Later” s’inscrit dans un horizon éloigné, où nous voulons être dans 𝓧 année(s).
Et pour construire notre roadmap, on va utiliser sur ce dernier !
Construire ta roadmap basée sur les résultats
Ta roadmap doit refléter les résultats souhaités.
Qui va créer la roadmap et quelles sont les étapes de sa création ?
C’est un travail collaboratif mais c’est souvent PM est responsable de la création de la roadmap dans son périmètre produit.
Voici les étapes de la création d’une roadmap que j’ai retenu :
Connaître la product vision (tu peux t’aider du framework “Product Vision Board” de Roman Pichler).
Définir les OKRs du périmètre de l'équipe.
Collecter des besoins auprès des parties prenantes.
Analyser des feedbacks utilisateurs et données à ta disposition afin d'en extraire des opportunités produit.
Formaliser et prioriser les opportunités prometteuses entre elles avec une méthode de priorisation comme RICE
Faire valider à ton boss et les autres décisionnaires. Leur but est de vérifier la cohérence avec l'alignement de la stratégie produit et de l'entreprise.
Communiquer la roadmap avec les stakeholders
En utilisant le framework Now/Next/Later, on va finalement créer 3 types de roadmap :
La Roadmap d'initiatives (Later) : Objectifs et milestones que ton entreprise souhaite atteindre.
La Roadmap product (Next) : Les produits qui vont aider ta boîte à arriver à ces objectifs.
La roadmap des releases (Now) : Un plan sur quelques mois (pas plus) montrant quand s'attendre à ce que chaque fonctionnalité de votre produit soit lancé (sans date précise).
Ta Roadmap d'Initiative
Pour créer la roadmap d'initiative, il faut comprendre les objectifs et les priorités de l'entreprise. Pour cela tu peux :
Organiser une réunion en 1 to 1 avec toutes les parties prenantes des autres départements (CEO, C-levels, leads...), tu as besoin de leur adhésion.
Demande quels sont leurs objectifs pour cette année
Utilise les OKRs comme cadre pour définir ces objectifs
Dis-leur que tu documenteras et établiras des priorités avec les équipes de direction dans les semaines à venir.
Ajoute ces objectifs dans ton outil pour faire des roadmap comme Notion, Aha, ProductBoard ou Trello (si tu cherches un outil, j’ai fait une liste plus bas).
Maintenant, priorisons en créant ta roadmap avec les initiatives/thèmes :
Prévois du temps avec les leads de chaque équipe (dont produit et tech) pour hiérarchiser les objectifs des prochains mois.
Partage les objectifs et les initiatives qui doivent être priorisés avant la réunion. Assure-toi que tout le monde les comprend pour éviter les mauvaises surprises.
Utilise des techniques de hiérarchisation comme la méthode RICE, la méthode MoSCoW ou encore Kano pour classer et noter les idées (chacune de tes initiatives doit être associée à des OKRs).
Voilà, tu as maintenant ta roadmap d'initiative, on passe à la roadmap produit
Ta Product Roadmap
Pendant tes réunions avec les leads, tu as dû récolter pas mal d'idées de features, de produit.
N’hésite pas aussi à croiser avec ton backlog produit, dans les feedbacks des utilisateurs, ou dans tes outils d’analyse comme ContentSquare, Mixpanel, etc.
Tu trouveras de nouveaux pain points, ça permet de valider grâce à de la data quanti/quali et de hiérarchiser en fonction des objectifs définis dans ta roadmap d’initiative.
Lors de la construction de celle-ci, voici quelques autres points de données qu'il est utile d'inclure :
Liens vers les initiatives/thèmes/objectifs de l'entreprise
Mises à jour des progrès en %
L’impact (élevé, moyen, faible)
Les champions, le propriétaire de l’initiative
Tu peux y trouver des opportunités intéressantes qui sont en accord avec les objectifs de ta boîte.
Ta Release Roadmap
Après avoir détaillé toutes les initiatives avec les produits que tu vas réaliser il est maintenant temps de détailler sous chaque produit les features qui vont intégrer ta release roadmap.
Travaille avec l'équipe de delivery pour décomposer les produits en ensemble de fonctionnalités.
Définis les fonctionnalités du produit : Tu peux dans un premier temps noter toutes les fonctionnalités que tu veux pour ton produit, et encore une fois, utiliser la méthode RICE, MoSCoW ou Kano pour les prioriser.
Enfin, une fois la liste fonctionnalités créé, les fonctionnalités devront être planifiées dans ta roadmap de release en fonction de son poids et du nombre de ressources que tu as dans ton équipe.
Outcome oriented
Dans mon article sur les OKRs, je disais que les OKRs étaient orientés "Outcome" et que la roadmap était orientée "Output".
Je pense que maintenant que la roadmap peut aussi être orientée Outcome si :
Elle découle d'OKRs,
Et si elle n'est pas traitée comme un release plan.
Un peu à la manière des OKRs ce genre roadmap laisse une marge de manœuvre considérable à ton équipe pour concevoir des solutions permettant d'atteindre les résultats souhaités.
Comment planifier ce qui rentre dans ta roadmap produit ?
Les questions à se poser
Afin de maintenir la crédibilité de ta roadmap auprès de tes parties prenantes, la roadmap doit être claire.
Voici quelques questions que tu peux te poser afin de filtrer toutes les demandes :
Est-ce les données en ta possession montre une valeur évidente ? Pas de place au gut feeling et à l'intuition.
Est-ce que ça a réellement une valeur pour l'utilisateur ? Sinon on kill. 🔫
Il y a un porteur du projet dans l'équipe qui en comprend les nuances et est prêt à se battre pour que ce produit existe ?
Est-ce que tu as de la place ? La plupart du temps il faudra faire preuve de pragmatisme et bien prioriser ta roadmap, et lorsque ça ne rentre pas... bin il ne faut pas forcer, il faut faire avec les moyens à ta disposition. 🤷
La dette technique et la sécurité
Garde une place dans ta roadmap pour la sécurité et la dette technique (ça peut être 10%).
Ça n'empêche pas de créer des produits en mode scrappy au début pour le tester sur le marché, mais le deal devrait toujours être : Si ça marche, on prendra le temps de bien le faire, sinon on kill tout pour ne pas laisser du code dégueu.
Parce que 3 ans après, tu te retrouveras avec un monstre où le changement d'un bouton peut créer 5 nouveaux bugs ailleurs. 💩
Si vous ne prenez pas le temps de faire de l'exercice (physique), vous devrez probablement trouver le temps de vous soigner — Robin Sharma
C’est un peu pareil pour le code de ton app.
De plus, si tu n’as pas le temps aujourd’hui, tu n’auras pas plus de temps pour traiter la dette technique ou la sécurité lorsque ton projet sera encore plus gros.
Présenter ta roadmap
Bon, créer ta roadmap ne suffit pas.
Elle doit être partagée et facilement accessible.
À qui et comment partager ta roadmap ?
La roadmap produit peut être présentée à un groupe d'investisseurs, comme à un média ou encore les parties prenantes qui attendent des résultats de ta part pour améliorer leurs propres taff.
Comme d’habitude, cela dépendra de ton entreprise, mais tu devras très certainement le présenter à tes supérieurs pour qu'ils sachent sur quoi tu vas ou pas travailler.
L'audience
Tous n’ont pas besoin du même niveau d'information. C'est pourquoi il faut connaître ton audience, ses motivations ce qui leurs problèmes et anticiper les questions.
Au lieu de diffuser la même version de la roadmap du produit à tout le monde, tu peux crafter des roadmaps produit plus digestes selon tes interlocuteurs.
Prévois aussi un moment avec des décideurs du département pour valider l'alignement avec ses intérêts avant la réunion. Elle sera ainsi plus rassurante pour toi et ça évitera de te retrouver face à une audience totalement sur la défensive. 🛡️
Aussi, partager ta roadmap à tes développeurs, la data, le design permet de les engager dans le "pourquoi" on doit le faire et de les motiver.
Le Storytelling
Donne du contexte, des anecdotes, des sources, des verbatims qui montre que c'est important d'investir du temps sur les sujets que tu présentes.
Tu peux par exemple commencer par la fin et développer ensuite.
Par exemple, si tu t'adresses à ton équipe customer care : “0 call pour des problèmes d'assurance habitation. C'est ce que l'on vise.”
Là tu catches leur attention et tu développes ton plan machiavélique ensuite. 😈
Ajoute aussi de l’Ethos, du Pathos et du Logos.
Rester macro
Le cerveau humain est câblé pour trouver des solutions à des problèmes. C'est en partie ce qui nous a permis de survivre jusqu'à maintenant.
Et c'est pourquoi, la plupart du temps pendant nos meetings sur la roadmap, on a tendance à parler de features (de solutions) qui vont être implémentées.
Essaies de te focaliser sur la stratégie de la boîte et les objectifs (objective-led roadmap).
Pour certains stakeholders, comment tu vas le faire ne devrait pas plus les intéresser du moment que les objectifs seront atteints.
Communiquer sur des solutions c'est prendre le risque de vendre des features qui ne seront peut-être pas les plus efficaces face au problème.
Les Metrics
Tout devrait être mesurable pour pouvoir progresser. 📊
Ça sera aussi plus simple de gagner leurs soutiens, si chaque élément de ta roadmap est lié à l'amélioration d'un KPI.
Valider/réviser ta roadmap
Malheureusement, la plupart du temps, tu ne peux pas décider tout seul de la validation ta roadmap produit.
Une fois créer il faut que tu en parles avec ton manager.
Pour cela, j'ai découvert un template qu'utilise l’équipe de Figma pour faire leur "Roadmap review" que je trouve très pratique. 🔥🔥🔥
Il se décompose en 6 parties :
L’équipe : Liste les parties prenantes qui ont contribué à l'élaboration de ce plan et qui l'exécuteront.
La Reflexion : Invite les participants à faire une lecture silencieuse et à laisser des questions ou des commentaires avec des stickers Figjam. Puis discutez-en.
La Strategie : Parcours la stratégie de ton équipe, en invitant les participants à laisser des questions ou des commentaires avec des stickers Figjam. Puis discutez-en.
La Roadmap : Invite les participants à faire une lecture et à laisser des questions ou des commentaires, puis discutez-en.
Feedbacks & Questions : Permet de voir l'adhésion ou non des collaborateurs et permet de discuter des commentaires et des questions stratégiques.
Les annexes utiles : Ajoute des informations utiles ici.
Si tu veux en savoir plus et mettre en place ce format de review, voici le lien du template : https://www.figma.com/community/file/1116436476720086895
La Diffusion
Une fois ta roadmap validé par tous, ton rôle est de faire en sorte que devs, archis, QAs, designers, le comprennent clairement.
Communique aussi sur les updates, et soit disponible pour répondre à leurs questions.
Deux idées de rituel que tu peux instaurer :
Tous les mois : les PMs échangent les autres départements Sales, Customer Support, Marketing, etc. pour faire le point sur la roadmap, les changements, les features déployées, et celles à venir prochainement.
Toutes les deux semaines : les PMs se réunissent avec l’équipe Tech pour parler des blocages et problèmes qui pourraient impacter les dates de livraison et la roadmap. Tu pourras aussi répondre aux questions et cela te permet de garantir l'alignement et d'économiser beaucoup de temps par la suite.
Une autre astuce est de mettre ta roadmap dans un dossier public afin que tous les membres de ta boîte puissent voir tes priorités.
Autres tips pour ta Roadmap
Qui l'utilise ?
Le C-level : Lorsqu'ils définissent des objectifs stratégiques, ils peuvent utiliser les roadmaps pour s'assurer que toutes les équipes sont alignées sur ces objectifs au fil du temps.
Les Product managers : On est souvent les créateurs de la roadmap, on sait donc ce qui doit être fait pour atteindre les objectifs. On trace le chemin pour y arriver et la roadmap nous aide à communiquer. 🛣️
Les Développeurs : Ils utilisent la roadmap pour suivre les progrès et respecter les délais.
Le Marketing : La roadmap les aide à déterminer le positionnement des produits et à créer des campagnes pertinentes.
Les Sales : La roadmap leur permet de connaître les futures fonctionnalités et de les communiquer aux clients/prospects. Il est possible que les sales communiquent la roadmap interne avec trop de détails comme une release avec une date spécifique aux clients. Peut-être qu'il serait intéressant de créer une roadmap en retirant ce genre d'infos que l'on veut garder uniquement en interne. Concentre-toi sur ce que l'utilisateur pourrait obtenir, ça leur permettra de vendre plus. 💰
Les clients/prospects : Comme les sales, il vaut mieux éviter les dates de déploiement et rester uniquement focus sur les bénéfices qu'il pourra en tirer.
Les outils pour créer ta roadmap
Voici quelques outils qui pourraient t'être utiles pour créer ta roadmap plus facilement afin de mieux communiquer, planifier, partager, visualiser, suivre les évolutions, synchroniser...
À quelle fréquence et comment itérer sur ta roadmap ?
Ce que l’on a livré a-t-il eu l’impact attendu ?
Décide-t-on de poursuivre ou d’arrêter nos efforts sur ce problème ?
Nos enseignements ou l’évolution du marché nous amènent-ils à prioriser de nouveaux sujets ?
Une roadmap ça doit être vivante, elle doit être updatée continu, au moindre changement de contexte.
Après cela dépend de la maturité de ton entreprise :
Les start-up ont beaucoup plus de mal à prédire les besoins futurs et les opportunités pour les produits. Ils doivent rester très agiles et leur roadmap n'ira probablement pas trop loin dans le futur (ou s'ils le font, il faut que tout le monde comprenne que ça risque fortement d'évoluer). 👶
Par contre, les produits bien établis peuvent faire des plans à plus long terme car on a ici une meilleure compréhension des clients et du marché.
Quelques éléments déclencheurs pour la mise à jour de ta roadmap sont :
Une nouvelle initiative qui pop et qui est hyperprioritaire, on doit l'ajouter au quarter actuel ou au prochain
À la revue des OKRs de l’équipe (tous les mois) on se rend compte qu'on prend du retard et il faut réagir rapidement.
On arrive à la fin du trimestre et il faut redéfinir le périmètre du Now, du Next et du Later.
On arrive à la fin du semestre (ou de l’année) et on vient de redéfinir les OKRs de la prochaine période.
Certaines entreprises instaurent chaque vendredi une publication d’un compte rendu des avancements, retards, risques sur chaque feature sur lesquelles les PMs travaillent.
Comme ça tout le monde à une bonne vision globale de la bonne tenue ou non de la roadmap et s'il faut l'ajuster.
La MaJ trimestrielle permet :
D’assurer le focus de l’équipe en la protégeant des re-priorisations trop fréquentes;
Donner suffisamment de temps pour creuser un problème, tester une ou plusieurs opportunités et commencer à mesurer un impact;
Être aligné avec le rythme des autres départements qui ont souvent des objectifs trimestriels.
Ce qu’il faut éviter sur ta roadmap
Avoir une Roadmap produit et une Roadmap technique
Pourquoi faire une distinction alors que les équipes qui vont s'en occuper sont les mêmes ? Cela montre un manque de cohésion entre ces deux équipes. ❤️🩹
Croire que tout va bien se passer
Ta roadmap va quasi inévitablement évoluer.
Il faut que les parties prenantes comprennent qu'elle va changer, mais il faut aussi que de ton côté communiquer régulièrement sur les releases ou les modifications sur un projet.
Ne promettez pas de dates. D'expérience, le développement est imprévisible (un nouveau bug, une dépendance avec une autre feature, du legacy, un dev malade...).
Utilise plutôt des calendriers des échéances comme “Q1”, “octobre 2023”, “2023”.
Si un problème spécifique à un client/utilisateur survient, comment le prioriser ?
Tu peux te poser ces 4 questions :
Qui va en bénéficier ? Est-ce représentatif du marché ?
Est ce une demande rationnelle ?
La complexité est-elle en accord avec le besoin ?
Est-ce sur le long terme ça a du sens pour la boîte ?
Si tu obtiens au moins 3 "oui", c'est que ce n'est probablement pas du tres specifique et que tu peux passer un process de design, verifier, l'estimer, et peut-être updater ta roadmap.
Sinon tu kill. 🔫
La feature factory 🏭
Une erreur fréquente est de délivrer sans mesurer l'impact de ce que l'on a produit.
On est donc dans de l’output, et cela ne motive pas les techs qui se sentiront juste comme des exécutants qui délivrent sans se préoccuper de la valeur apportée. 😞
La Roadmap au gut feeling + solo
Il sera compliqué de faire comprendre tes choix au top management sans données, sans feedbacks utilisateurs. 🔍
De plus, il faut vraiment se forcer à construire cette roadmap en équipe et non tout seul.
L'ensemble des parties prenantes est légitime pour la créer avec toi. 🤜✨🤛
Accepter toutes les urgences
Tu feras face à de multiples urgences mais il faudra savoir dire non. Sinon tu risques de ne pas tenir les délais, de créer de la frustration auprès de ton équipe. 😫
Pour justifier cela, tu peux t'appuyer sur ta roadmap, sur tes OKRs, de la vision de la boîte, ou encore de la donnée quantitative ou qualitative.
Par exemple, si on te remonte un bug :
Est-ce que les utilisateurs peuvent arriver à leur objectif autrement ?
Est-ce que la feature est beaucoup utilisée ?
Est-ce que ça peut avoir un impact sur le business ?
Bref, il faut investiguer avant de dire “oui”.
—
Au final, les différents types de roadmap, c’est un peu comme les différentes vues que tu peux avoir sur Notion. À toi de choisir ce qui te convient le mieux et qui convient le mieux à ton audience.
Selon ton poste et ton entreprise, il est possible que ça ne soit pas toi qui fasse la roadmap d’initiative ou même produit.
Mais rien ne t’empêche de challenger la roadmap.
C’est important car un produit qui échoue est souvent lié à une mauvaise préparation en amont.
La roadmap était peut-être bancale et les développeurs ne l'avaient pas intégré.
Donc que tu te lances dans la création d'une roadmap ou que tu dois challenger une roadmap, prend le temps pour bien la faire, de l'updater et surtout de communiquer. 📣
J’espère que cette édition t’a plu et je suis super intéressé pour connaître le process de création de roadmap dans ta boîte !
Qui le fait, quand, comment ? Dis-moi tout en commentaire. 🤩
Dans la prochaine newsletter, j’améliore mes connaissances dans le Design Thinking !
Bon week-end, 👋
Kevin ❤️
Tu aimes la newsletter Product Shōnen, pourquoi ne pas la partager à tes proches ?