Comment construire votre roadmap produit?

La roadmap produit permet de suivre l’avancement du produit et la destination vers laquelle il tend à se diriger. C’est un document qui permet de prendre du recul et de se fixer un cap. Il présente de manière visuelle les objectifs et la vision du produit et intervient tout au long de la construction du produit.

Une bonne roadmap doit être compréhensible, visuelle, accessible et classée par thématiques afin de rapidement répondre aux interrogations suivantes :

• A quels types de problèmes ou de besoins essayons-nous de répondre et comment ?
• Quel est l’objectif des développements prévus et quand seront-ils mis en place ?
• Comment se rattachent-ils à nos résultats ?

Les objectifs d’une roadmap produit

Une roadmap répond à la fois à des objectifs business, stratégiques, collaboratifs et produit. Ce document doit permettre de :

• Aligner les développements avec la vision de l’entreprise
• Être un outil de communication pour collaborer plus efficacement la vision et la stratégie produit
• Aligner les parties prenantes et donner de la visibilité au management
• Prioriser les problèmes auxquels on veut répondre sur la période
• Donner un état d’avancement indicatif du développement

💡 Tips

Partager et communiquer la roadmap à toute l’entreprise permet d’être certain que tout le monde est aligné sur l’évolution du produit et de récupérer des retours en amont des développements. Il est important que les équipes commerciales et le service client soient informés des fonctionnalités à venir pour les communiquer au client.

Les informations clés d’une roadmap produit

La roadmap produit contient 4 informations principales : la période, les objectifs, le contenu et les métriques. Voici le détail ci-dessous :

• Les étapes intermédiaires de livraison : périodes de temps. Il est déconseillé de mettre des dates précises car le but de la roadmap n’est pas que l’équipe technique s’engage sur des dates de livraison.
• Les objectifs : enjeux stratégiques de cette release
• Le contenu de la release avec les fonctionnalités principales présentées de manière “high level” : on peut parler ici de grandes thématiques ou d’initiatives. Une autre manière est d’utiliser les zones à travailler du produit, par exemple la landing page, la fiche produit, l’écran de paiement...
• Et les KPIs pour mesurer si les objectifs ont été atteints

💡 Tips

• Il est aussi possible d’ajouter les risques, s'ils sont déjà identifiés
• On parle de thématique et non de solution. Si l’on prend pour exemple un site e-commerce, la fonctionnalité “nouvelle page d’accueil” est une solution. Il est préférable de mettre comme problématique “l’optimisation de la conversion”, avec un objectif chiffré. Lorsqu’il faudra réfléchir à la solution, on aura la possibilité d’en trouver plusieurs et donc de choisir la plus efficace et la moins coûteuse, sans être bloqué. Une des potentielles solutions serait d’agrandir le bouton d’inscription sur la page d’accueil ou de le changer de place au lieu de refaire toute la landing page.

Roadmap produit - exemple Airbnb, par Hubvisory

La roadmap n’est pas une liste de fonctionnalités à développer !

“I realize that the fundamental mistake that I was making, that so many Product people make, is that I was confusing a roadmap with a project plan, with a to-do list, with a release plan, with all of the mechanism and the operational details. All of the what and none of the why. A roadmap is not a list of features and dates.” - Bruce McCarthy, Founder @ProductCulture

Comme vu précédemment, définir des thématiques à développer permet de communiquer sur des problèmes utilisateurs sans s’engager sur une solution prédéfinie. Il est plus simple d’identifier la racine du problème, définir des initiatives et prioriser ensuite le périmètre du produit. Cela permet aussi d’intégrer les retours utilisateurs dans le développement du produit. De plus, la roadmap a pour vocation d’évoluer avec le produit.

“Themes are a promise to solve problems, not build features” - Jared Spool

On confond en effet, souvent une roadmap et un release plan :

• Une roadmap permet de soulever les grandes thématiques / problèmes utilisateurs et les objectifs à atteindre
• Un backlog liste les features détaillées pour résoudre ces problèmes
• Un release plan démontre l'exécution du développement de ces features.

Les étapes de construction

Une roadmap se construit de manière itérative. Les étapes suivantes se répètent tout au long du développement afin de la faire évoluer, si nécessaire.

1- Collecter les retours et demandes :

Il est important de récupérer les insights de plusieurs acteurs :

• les utilisateurs finaux
• les parties prenantes internes (investisseur, sponsor du projet,...)
• les équipes métiers (marketing, commerciales, service client…)
• et analyser le marché : tendances, concurrence….

Construction de la roadmap chez IntercomSource : https://www.intercom.com/blog/podcasts/podcast-paul-adams-on-product/#666

“How does your idea support our objectives ?” - Bruce McCarthy, Founder @ProductCulture

💡 Tips

Il est important de déceler derrière chaque demande, le réel besoin ou la problématique. Si on repart sur notre exemple précédent, une partie prenante en interne demande de refaire la page d’accueil, c’est une solution. Le besoin ou la problématique pourrait être, dans ce cas, d’augmenter la conversion. Il peut donc y avoir d’autres solutions que de refaire la page d’accueil pour répondre à cette problématique.

Le Product Manager doit challenger chaque demande. Une méthode simple à mettre en place est la “règle des 5 pourquoi” : demander pourquoi après chaque réponse de la personne. Cela permet de mieux cibler et comprendre le fond du besoin.

2- Définir des objectifs et se fixer des résultats :

Se concentrer d’abord sur les objectifs de l’entreprise ainsi que la vision produit pour en déduire, ensuite, des objectifs produits.

Les objectifs répondent à la question “où allons-nous?”, tandis que les résultats répondent à “comment y allons-nous?”.

3- Prioriser :

De la même manière qu’un backlog doit être priorisé, la roadmap, même si elle a une vision high level, doit être classée par thèmes et objectifs et surtout être priorisée. Pour cela, il est important de mettre en comparaison la valeur business, la valeur utilisateur et l’effort nécessaire pour réaliser la fonctionnalité.

💡 Tips

Attention, comme vu précédemment, on parle ici de thématiques / initiatives et non de fonctionnalités. Pour connaître l’effort technique nécessaire sans rentrer dans la solution, on peut faire une estimation macro ou alors se baser seulement sur la valeur métier et la valeur utilisateur. Une fois les solutions identifiées, une seconde phase de priorisation aura lieu avec l’effort technique pour challenger la priorisation précédente.

Une des techniques très utilisées est de suivre le parcours utilisateur en réfléchissant avec une logique de Minimum Viable Product (MVP) : que puis-je réaliser qui est vraiment nécessaire afin que mon produit fonctionne et réponde au besoin utilisateur ?

Il existe de nombreuses méthodes de priorisation à réaliser sous forme d’ateliers avec les parties prenantes :

• Taille de tee shirt (XS, S, M, L, XL)
• Moscow (Must have, Should Have, Could Have)
• RICE (Reach, Impact, Confidence, Effort)
• ...etc.

Dans la partie suivante, vous pourrez retrouver les différents types d’ateliers couramment utilisés pour réfléchir au contenu et à la priorisation de la roadmap.

4- Mesurer :

Mesurer les résultats obtenus, les comparer à ceux attendus, et récupérer de nouveaux inputs pour itérer et modifier la roadmap.

Les ateliers les plus utilisés pour créer la roadmap

Afin de faciliter la création de cette roadmap, voici 2 ateliers très utilisés et facile à mettre en place. Ils peuvent aussi être faits l’un après l’autre.

L’impact Mapping :

Pour se concentrer sur les objectifs et définir les moyens à mettre en place pour y répondre.

Impact Mapping

L'Impact Mapping est rapide à mettre en oeuvre et facile à faire en groupe. Cette technique de planification stratégique propose de définir le ou les objectifs, les acteurs qui peuvent y contribuer, les impacts attendus sur ses acteurs et enfin les fonctionnalités qui répondent à ces impacts.

Si nous continuons avec l’exemple d’Airbnb, voici un impact mapping que nous pourrions réaliser :

Impact Map - exemple Airbnb par Hubvisory

Pour plus d’infos sur l'Impact Mapping ici : https://hubvisory.com/blog/comment-organiser-des-ateliers-d-impact-mapping/

Le Story Mapping :

Le Story Mapping permet de définir le parcours utilisateur nominal et ensuite prioriser les grandes fonctionnalités.

Story Mapping

Cet atelier consiste à lister les fonctionnalités importantes du produit en les ordonnant selon le parcours le plus basique et fréquent de l’utilisateur et ensuite à les trier par priorité 1, 2… Cela permet de dégager rapidement les premières releases à regrouper par objectifs.

Mise à jour et planification de la roadmap produit

Il est important de mettre sa roadmap régulièrement à jour car les priorités de l’entreprise et des utilisateurs évoluent. La concurrence et les technologies changent aussi très vite. Il est donc nécessaire de s’adapter. La roadmap produit n’est pas gravée dans le marbre, c’est un document qui évolue avec le produit.

Différents types de planification et de revue de roadmap

• En fonction du marché et de la maturité du produit

Mise à jour de la roadmap produit

• Par releases : “Go Product Roadmap” de Roman Pichler

Chez Hubvisory, on utilise très souvent et on conseille ce type de roadmap à nos clients. Elle permet d’identifier clairement les priorités actuelles que l’équipe cherche à résoudre, et les idées potentielles dans un futur proche.

Schéma Go Product Roadmap Hubvisory

• Modèle au trimestre

Les objectifs de l’entreprise sont revus tous les trimestres afin de pouvoir revoir les objectifs du produit et donc la roadmap. Cela permet de s’adapter rapidement à la stratégie de l’entreprise. Ce modèle intervient souvent suite à la mise en place de la méthodologie OKR (Objectives Key Results).

• Now / Next / Later ou Court / Moyen / Long Terme

Ce modèle est moins concret ce qui permet donc de prendre plus de recul et pouvoir mieux itérer.

• La roadmap 666 : 6 ans, 6 mois et 6 semaines

Ce modèle est utilisé chez Intercom. Il permet d’avoir une vision long terme, moyen terme et court terme. La vision long terme sur 6 ans permet de se projeter dans le futur pour guider le produit. D’après Intercom, il ne s’agit pas de réfléchir à comment sera le marché dans 6 ans mais comment mon produit va influencer le marché dans 6 ans. En quoi le marché sera-t-il différent grâce à mon produit ?

Pour en savoir plus : interview de Paul Adams (VP Product) et l'article sur le blog d’Intercom

Controverses du modèle classique par trimestres

Il existe des controverses sur les modèles classique des roadmap, notamment celui des trimestres. La roadmap est mise à jour trimestriellement donc il y a une perte de réactivité car la remise en question des objectifs et de la vision produit arrive une seule fois par trimestre.

“Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.” David Cancel, CEO, Drift.

La règle du 3-3-3

Un autre modèle intéressant est de s’engager sur ces 3 niveaux, qui sont plus rapprochés et permettent de prendre plus de recul tout en gardant des temporalités proches :

• 3 mois
• 3 trimestres
• 3 ans

Ou pour les start-ups très jeunes :

• 3 semaines
• 3 mois
• 3 trimestres

Quels outils pour gérer sa roadmap produit ?

Il existe beaucoup d’outils différents: Trello, Go Product Roadmap, Product Board, Excel, Powerpoint, Confluence, etc…

💡 Tips

Utiliser celui qui convient le mieux ainsi qu’à ton organisation. Si tu as beaucoup de parties prenantes, il est intéressant d’avoir un outil dynamique, en ligne qui peut être diffusé rapidement et facilement.

Ci-dessous un exemple détaillé de Roadmap avec Trello. On y retrouve :

• La temporalité (court, moyen et long terme)
• Les zones du produit qui vont être impactées
• Le scope de la thématique / problématique à résoudre
• L’objectif stratégique de cette fonctionnalité

Roadmap produit type TrelloSource : https://productmanagement.confabulatory.net/category/roadmap-management/

Une pratique intéressante :

Certaines start-ups ont décidé de rendre leur roadmap publique afin que les utilisateurs aient de la visibilité sur la sortie des prochaines fonctionnalités. Cela permet aussi de communiquer sur la direction et stratégie produit de l’entreprise. Certaines invitent même les utilisateurs à voter et proposer de nouvelles idées.

Voici 2 exemples d’entreprises :

• Slack
• Front app
• Changelog (release plan)

Slack a une roadmap Near term, Mid Term et Long Term : cela leur permet de ne pas s’engager sur des dates précises tout en donnant de la visibilité. Front met aussi à disposition les dernières fonctionnalités sorties et sur quoi ils travaillent au jour le jour. Les utilisateurs peuvent envoyer par email les fonctionnalités qui les intéressent qui seront ajoutées à la colonne “Ideas & Requests”.

La startup Station a même mis en place une plateforme sur laquelle on peut y retrouver une section bugs, idées de nouvelles fonctionnalités, retours UX & design, release notes, roadmap produit, etc…

Roadmap produit publique de la startup StationSource

Communiquer en interne, au sein de l’entreprise est aussi nécessaire. Ce document doit donc être tenu à jour régulièrement pour pouvoir le communiquer et que les équipes s’y réfèrent. Une communication mensuelle au minimum est nécessaire.

Les erreurs à éviter

Pour conclure, voici ci-dessous les erreurs fréquentes et communes qu’on retrouve dans les entreprises. Le Product Manager a la responsabilité de veiller à ne pas reproduire les actions ci-dessous :

• Aller dans le détail et passer trop de temps à la réaliser : c’est un outil stratégique avec une vision “high level” pour guider les équipes, qui va évoluer dans le temps.
• Un document figé : la roadmap doit être ajustée et modifiée régulièrement en fonction des retours utilisateurs et des parties prenantes.
• Une liste de fonctionnalités : la roadmap produit doit montrer la stratégie et le chemin pour y arriver et non les solutions.
• Communiquer plusieurs versions différentes : la roadmap évolue dans le temps mais une seule version doit être communiquée à toute l’entreprise.
• Faire une roadmap non réalisable sous la pression des parties prenantes et du management : ce point est le plus répandu dans les entreprises qui ont tendance à avoir des roadmaps trop ambitieuses et intenables. Il est conseillé de fournir un horizon réalisable et cohérent. Il faut savoir dire non pour ne pas se retrouver en porte-à-faux plus tard.