La méthode d'Alan pour faire sa roadmap produit

Chez Alan, la roadmap produit est à l’image de la culture d’entreprise. La licorne française mise en effet sur la transparence et l’autonomie de ses équipes pour bâtir les nouvelles briques de son produit d’assurance santé. Détaillons les coulisses de son processus avec Thomas Rolf, son Chief Product Officer.

⏳ 15 min de lecture pour naviguer avec assurance

✉️ Article issu du Ticket N°86

---

Ce que tu vas apprendre dans cet article sur les roadmaps produit de Alan : 

1- Les 3 intérêts d’une roadmap : priorisation, alignement et communication

2- Ce que contient le Strategy Pack, le doc de référence de la stratégie d’Alan

3- Le framework de roadmap d’Alan, avec les notions de narratif, d’appétit et de thèmes produit

4- La déclinaison des roadmaps au sein de chaque équipe, avec les Crew Quarter Plan

5- Un processus de roadmap est le reflet d’une culture d’entreprise et d’un contexte particulier

6- Incertitude, radicalité, standardisation : 3 difficultés rencontrées

---

Contexte : les chiffres clés d’Alan (septembre 2024)

• 570 employés (les “Alaners”) dont 100 ingés, 25 Data scientists, 20 Product Managers, 20 Product Designers et 20 Operation managers

• + 370 M€ de chiffre d’affaires dans 3 pays (France, Espagne, Belgique)

• 25 000 entreprises clientes (soit + de 530 000 membres)... dont Matignon et l’Assemblée Nationale

• 4 Mds € de valorisation (depuis sa levée de fonds de 173 M€ du 20 septembre dernier) et une rentabilité espérée en 2026
  

Préambule : Les 3 dimensions de la roadmap produit d’Alan

Commençons par rappeler la base : à quoi sert une roadmap produit ? Selon Thomas Rolf, Chief Product Officer (CPO) de l’insurtech, l’outil revêt 3 intérêts majeurs : 

1- Priorisation

Décider des opportunités sur lesquelles Alan veut investir et, en corollaire, celles qui ne vont pas être traitées (souvent une information encore plus pertinente).

2- Alignement

Accorder les opportunités produit avec les objectifs business de la boîte et les besoins des utilisateurs. “C’est un puissant outil d’alignement pour s’assurer que les équipes vont toutes dans la même direction”, précise Thomas.

3- Communication

Diffuser les opportunités et priorités du produit à un instant T, que cela soit aux différentes parties prenantes d’Alan qu’à l’ensemble des équipes produit. “Notre Strategy Pack (NDLR : dont on parle juste après) est la première chose que doit lire une nouvelle recrue, afin d’avoir une vision claire sur la direction que nous prenons”, ajoute-t-il.

Pour Thomas, arrivé en tant que 24e salarié d’Alan il y a 6 ans, après une expérience chez Meta à Londres, l’équipe produit a la responsabilité de clarifier ce qu’est et surtout ce que n’est pas une roadmap.

“La plupart des parties prenantes vont en attendre beaucoup de choses. Par exemple, l’un des risques est de la considérer comme un plan détaillé d'exécution : on va sortir telle fonctionnalité, telle semaine et cela va nécessiter tant de jours / hommes. Cette conception peut s’avérer efficace dans certaines organisations, mais ce n’est pas comme ça que cela marche chez Alan”, admet-il.

Voici plutôt comment l’entreprise, créée en 2016, fonctionne.

1- 1ère étape de la roadmap d'Alan : le Strategy pack

Une roadmap est une boussole… Mais encore faut-il savoir dans quelle direction aller ! C’est tout l’objet du “Strategy pack”, un document de référence synthétique (environ 4 pages) élaboré au cours de chaque dernier trimestre de l’année afin de définir la vision et les priorités stratégiques de l’année. 

Jean-Charles Samuelian, le cofondateur et CEO en pose les premières grandes lignes, puis les responsables des grandes directions de la boîte affinent leur partie.

On y retrouve les éléments suivants : 

• La vision et la mission d’Alan (long terme)
• Les piliers de la stratégie (comment y on arrive)
• Les objectifs business de l’année (notamment le chiffre d’affaires et les marges par segments) - Responsabilité : Chief Financial Officer
• Le plan produit (les grandes opportunités produit) - Responsabilité : Chief Product Officer
• Le plan de Go-to-Market (le lien entre produit et business) - Responsabilité : Chief Revenue Officer

“Côté produit, je travaille avec les leads des équipes Tech, Design, Data, Operations et Assurance pour être bien alignés. Cela donne les grandes directions au produit qui seront ensuite déclinées à l'échelle des équipes”, témoigne Thomas.

Ce document de haut niveau est généralement ajusté côté produit et Go-to-Market tous les 6 mois, à la fin de chaque semestre et… en cas de grosse nouvelle sur le marché. “Ce qui arrive quand même pas mal”, sourit Thomas. Dans ce cas, un processus dédié existe : le Product Strategy Review. Dont nous allons justement parler dans la 2e étape de l’exercice de roadmapping d’Alan.

2- 2e étape de la roadmap d'Alan : la déclinaison de la stratégie en roadmaps pour chaque “Product Area”

Chez Alan, les équipes produit sont réparties en une dizaine de Product Area (l’équivalent des Tribes dans d'autres organisations). 

Ces dernières, responsables d’une partie spécifique du produit, comme leur nom l’indique, sont composées de 5 à 20 personnes (essentiellement ingés mais aussi Product Designers et Product Managers) réparties entre 2 et 6 Crews (l’équivalent des Squads). Alan compte actuellement 9 Product Areas.

Pour donner un exemple concret, la Product Area Claims Management s’occupe de la gestion des remboursements. Elle est composée par exemple d’une Crew contre la fraude ou encore d’une Crew dédiée à l’analyse de documents.

C’est à ce moment et à ce niveau que l’on commence vraiment à parler de roadmap produit. Ou plutôt, de roadmaps produit au pluriel, puisque chaque Product Area doit écrire la sienne à partir du Strategy Pack et de leur contexte (enjeux, données utilisateurs etc.). Comment ?

A) Un template de roadmap produit en 6 parties

Une première version est d’abord écrite par la Core Team de chaque Product Area (4 Alaners senior de différentes communautés produit les plus pertinentes pour l’Area), selon un template similaire, sur 4 pages maximum.

📄Voici le template du Product Quarterly Review d’Alan

1. Apprentissages de l’année précédente

Afin de faire le lien entre le passé et la projection du futur et inscrire la roadmap dans un contexte temporel plus large

2. Le narratif de l’année

Historiquement, Alan utilisait les OKR. Mais, après la lecture de cet article de Reforge, l’équipe a récemment adopté un nouveau concept : les narratifs. L’idée ? Raconter la (petite) histoire de l’Area sur cette année.

“Résumer un objectif d’OKR ou une mission d’équipe en une phrase est souvent un exercice difficile. Cela débouche sur une formulation inspirationnelle pas toujours évidente à comprendre. Avec un narratif, on se libère de cette barrière en énonçant un petit paragraphe de 150 mots max que tout le monde peut se représenter”, explique Thomas Rolf.  

3. Les KPI Business de l’année

L’idée est ici de faire le lien entre la roadmap de la Product Area et les enjeux business de l’entreprise. “On demande aux équipes produit de préciser l’impact qu’elles vont avoir sur nos principaux indicateurs business ”, précise Thomas. Généralement, il est ici question d’indicateurs de réussite à suivre. 

4. Les thèmes de roadmap

Voici le cœur du document : les fameuses opportunités produit qui constitueront autant de sujets de travail pour les Product Areas au cours des prochains mois. Ce qui est sommairement considéré, par simplification, comme la “roadmap” pour les parties prenantes.

📘 On retrouve cette notion de "roadmap à thèmes" dans notre résumé du livre Product Roadmap Relaunched

Chaque thème représente un problème clients ou membres spécifique, une opportunité de marché ou un but stratégique que l’équipe veut traiter. Il doit être présenté, là encore, avec un petit narratif de quelques phrases et correspondre au travail d’au moins une crew sur un trimestre, afin de pouvoir plus facilement les comparer entre eux - ce qui implique parfois de regrouper plusieurs petites initiatives en un seul thème. Sans toutefois rentrer dans le comment.

Alan a aussi introduit un concept de segmentation des thèmes selon trois niveaux de maturité des initiatives produit, afin d’avoir une meilleure visibilité sur le staffing nécessaire des équipes, basé sur cet article de Kent Beck : 

• Explore : investigation sur une nouvelle initiative (= 4 “Alaners” max, cela reste un pari)
• Expand : développement d’un produit existant (7 “Alaners” max)
• Run : maintenir un service existant

Il est aussi recommandé de mentionner ce qui ne sera PAS fait, afin d’éviter toute confusion. 

Enfin, la Product Area est invitée à tirer à gros traits, avec un graphique visuel, les thèmes qu’elle va traiter au cours des deux prochains trimestres, voire, dans la mesure du possible, d’estimer les thèmes du semestre suivant. “Même si on sait bien qu’il y a de fortes chances que cela évolue d’ici là”, atteste Thomas.

5. L’appétit

L’appétit, notion venant directement de la méthodologie Shape-up, correspond au temps que l’équipe souhaite consacrer à un sujet. À l’inverse d’une estimation (qui donne un temps de conception envisagé), l’appétit fixe l’ambition comme variable d’ajustement d’un projet.

L’approche est donc inversée : au lieu de se dire “combien de temps va durer ce projet ?”, la question devient “combien de temps ai-je envie d’investir sur ce projet ?”. Sous-entendu, “Je vais ajuster l’ambition pour que cela rentre dans le temps dans cet appétit”.

Concrètement, elle indique le nombre de personnes dont elle va avoir besoin pour accomplir sa roadmap, par métier (Ingés, Design, Product Manager, Data, Ops, Assurance, Product Content, Product Marketing Manager).

Les équipes sont invitées à indiquer l’appétit de base ainsi qu’un appétit augmenté. C’est-à-dire : que feraient-elles en plus dans la roadmap avec des ressources supplémentaires et ce que cela impliquerait en termes de business KPI ?

Conséquence : un ajustement des équipes peut se produire tous les 6 mois chez Alan, en fonction des projets actés dans la roadmap. Autrement dit, les crews ont une durée de vie fixe mais renouvelable.

“Notre organisation est au service de notre stratégie”, précise Thomas.

6. Les annexes

Enfin, en annexes de ce document, la Product Area peut ajouter différentes informations : 

• Le rappel du périmètre produit de l’Area (les interfaces et Jobs-to-be-done principaux dont elle est responsable en l’occurrence)

• L’identification de dépendances avec d’autres Product Areas

• Les risques majeurs de ne pas réussir à livrer cette roadmap

• Les actions liées à la dette technique et à l’augmentation de la qualité produit

Actuellement, la roadmap est établie tous les 6 mois chez Alan. “On s’est rendu compte que planifier à un horizon d’un an ne servait pas à grand-chose car notre monde change assez vite”, confirme Thomas Rolf.

Sachant que se déroule un Product Quarterly Review à la fin de chaque trimestre. L’occasion de faire le point sur ce qui a été réalisé et d’ajuster à la marge si nécessaire.

B) Un document affiné par itérations successives

Voilà, à ce stade, chaque Product Area a proposé sa roadmap, rédigé sur un Google Doc. Que se passe-t-il ensuite ?

Place au ping-pong ! Les Product Community Leads d’Alan (Thomas pour le produit et ses équivalents côté ingé, design, data et ops) et parfois les parties prenantes business, selon les Product Areas, vont challenger les roadmaps, pendant une semaine.

Histoire de proposer un cheminement cohérent pour l’ensemble des équipes produit, voir s’il convient d’ajouter du monde dans une équipe ou, au contraire, ralentir les investissements pour se concentrer sur d’autres priorités… Bref, endosser la responsabilité de la roadmap produit globale à l'échelle des 6 prochains mois. 

“Pour arbitrer les décisions les plus complexes, on fait remonter à Jean-Charles, le CEO ainsi qu’au Chief Financial Officer”, ajoute Thomas.

Au bout de ce processus, les Product Areas ont leur feuille de route sur le semestre. En avant Guingamp !

C) Une communication à l’échelle de l’entreprise

Alan dispose d’une culture de l’écrit très atypique. Au sein de l’insurtech, quasiment pas de réunion ! Tout se fait par discussion asynchrone à même les documents. Dit autrement : toutes les décisions se prennent à l’écrit. Naturellement, tout est disponible en ligne de manière assez transparente. 

Il en va ainsi des roadmaps de 2 à 3 pages des Product Area qui sont accessibles librement en interne. “Je m’occupe généralement de faire un petit récap’ par écrit et en vidéo sur Loom à mesure que l’on avance”, complète Thomas.

D) Le Product Strategy Review, le rituel de modification de la roadmap en cours de route

Et que se passe-t-il si, durant les 6 mois, des éléments impromptus interviennent et remettent en cause la teneur de la roadmap d’une Product Area ? Réponse : une Product Strategy Review est organisée.

Ce mécanisme permet de “changer le contrat entre Alan et une Product Area”, expose Thomas. Il précise :

“S’il se produit une grande nouvelle qui a un impact sur le succès d’une initiative ou l’émergence d’une opportunité significative qu’on n’avait pas anticipée, cette instance permet de refaire le point sur l’attribution en ressources des équipes”.

Une manière de rester agile face au caractère potentiellement figé d’une roadmap.

C’est par exemple au cours d’un Product Strategy Review qu’a été prise la décision stratégique (radicale) d’arrêter l’application Alan Baby, dont nous avions raconté l’histoire dans ce podcast d’Épique.

3- 3e étape de la roadmap d'Alan : Les plans trimestriels à l’échelle des Crews

Une fois les roadmaps validées, il existe encore une étape afin d’affiner le travail de chacun et chacune des Alaners. Petit rappel : les Product Areas, l’équivalent des Tribes, comprennent parfois plusieurs équipes en leur sein. Des crews.

Les roadmaps sont l'outil des Product Areas. Mais encore faut-il les transposer à l'échelon plus granulaire des crews. Alan n’appelle pas cela des roadmaps mais des plans trimestriels de crew (Crew Quarter Plan). Cela résume ce que l’équipe compte accomplir dans le trimestre.

📄Voici le template des Crew Quarter Plan d’Alan

A) Un document Notion en 3 temps principaux

Ces documents sont renseignés cette fois dans Notion et chaque responsable de crew doit suivre plus ou moins le même enchaînement.

1. Le narratif

Comme précédemment, il s’agit de “raconter” en 200 mots max ce que l’équipe ambitionne de réaliser au cours du trimestre. Notamment en expliquant en quoi c’est important pour les membres et le business (en lien avec les KPI de la Product Area) mais également pourquoi le faire maintenant.

2) Les objectifs et engagements

Cette partie ressemble étroitement aux OKR. Il s’agit du pendant du narratif en prouvant en quoi le Crew a progressé au cours de ce trimestre.

L’objectif tient en une ligne tandis que les engagements correspondent à des mesures de succès (idéalement des indicateurs basés sur des outcomes qui peuvent être suivis toutes les semaines, comme un taux de conversion par exemple). Pour des produits moins matures, il est plutôt demandé d’indiquer des jalons chiffrés.

3) Les tâches

Enfin, les Crews doivent indiquer les grandes actions qu’elles comptent mener pour chaque objectif. Il faut savoir qu’Alan fonctionne non pas en sprint de 2 semaines mais en cycles de 6 semaines, sur le modèle de Shape Up. 

Il ne s’agit donc pas d’entrer avec précision dans chacune des tâches effectuées (ce qui s’apparenterait un peu à du flicage) mais plutôt de donner une estimation de l’allocation du temps de l’équipe entre le shipping, la mesure d’impact, le framing ou le making, pour reprendre les termes de la documentation d’Alan.

Aussi, les équipes peuvent préciser ce qu’elles ne vont pas faire pour informer les autres équipes produit.

Un fonctionnement qui s’inspire directement du framework NCT (Narrative, Commitments, Tasks) de Reforge.

En résumé, voici donc à quoi ressemble un trimestre complet chez Alan :

B) Comment faire le lien entre stratégie d’entreprise et retours terrain ?

Toute la complexité d’une roadmap produit est d’arriver à faire coïncider une stratégie globale sur plusieurs années avec des enjeux du quotidien remontés par les utilisateurs ou les parties prenantes. Comment Alan réussit à gérer ce subtil équilibre ? “C’est toute la magie du Product Management… et ce n’est clairement pas facile”, convient Thomas.

Pour lui, un élément de la réponse tient au fait d’avoir déjà une organisation en trio sur 3 niveaux hiérarchiques (on parle d’orga fractale chez Alan) : le produit, le design et la tech (auquel on peut ajouter Ops, data et assurance) sont décisionnaires à l’échelle du leadership, des Product Areas et des Crews. Une façon d’avoir d’emblée une diversité de perspectives.

Aussi, la collecte des insights du terrain a été méthodiquement formalisée chez Alan. La licorne utilise par exemple l’outil Harvestr pour agréger ces derniers, notamment via les Product Marketing Managers ou les Product Specialists, une fonction hybride nouvelle entre le produit et le service clients, qui se chargent de faire remonter des tendances marquantes.

Enfin, il s’agit de la fonction même de Product Manager de jongler entre la compréhension du terrain et de la vision plus macro !

4- La roadmap produit chez Alan : un processus spécifique… et en évolution permanente

Avant de dérouler le mécanisme de création des roadmaps chez Alan, dont nous venons à l’instant d’énumérer les étapes, Thomas avait souhaité faire deux mises en garde : 

A) Un processus de roadmap est très dépendant de la culture d’une entreprise

“Il s’agit du reflet de la façon dont sont prises les décisions au sein de la boîte”, précise-t-il.

En l'occurrence, comme on l’a évoqué, Alan dispose d’une culture assez atypique et difficilement transposable. 

On a évoqué la culture de l’écrit et de l’asynchrone. On pourrait aussi parler de la transparence extrême liée à la notion de responsabilité décentralisée (decentralized ownership qui se rapproche des valeurs défendues dans Empowered de Marty Cagan).