Gabriel Jubert (Sphères) : “Une roadmap produit, c’est comme le Vendée Globe”

Gabriel Jubert exerce le métier de “Business designer” au sein du bureau de design et d’innovation, Sphères. En gros, son job, c’est de concevoir des business. De créer de la valeur et trouver comment la capter. Dans ce cadre, cet ancien PM de Veepee est amené à être mentor de sessions de roadmaps de certaines boîtes. Entrevue en mode prise de recul et de hauteur sur le sujet. Prends ton ciré Saint James, il nous emmène en mer.

Alors, déjà, peux-tu nous donner ta définition d’une roadmap produit ?

Gabriel Jubert : Pour moi, c’est la trajectoire simplifiée d’un produit, pour atteindre un objectif, en fonction de tes capacités actuelles et futures.

Cette notion de capacité est importante car tes moyens ne seront peut-être pas les mêmes dans 3 mois ou dans 6 mois, si tu lèves des fonds par exemple. En fait, pour être plus imagé, je dirais qu’une roadmap, c’est comme le Vendée Globe !

Tiens… On est curieux d’entendre l’explication de ton parallèle.

G.J. : Dans le Vendée Globe, les skippers ont un un objectif hyper clair : faire le tour du monde en solitaire, sans escale et sans assistance. 

Pendant la course, ils vont devoir définir la meilleure trajectoire, bord après bord, en prenant en considération l’environnement (les vents, les courants, les glaces etc), les contraintes humaines, technologiques (tu n’auras pas les mêmes trajectoires si ton bateau est équipé de foils ou non) ou réglementaires (au Vendée Globe, tu n’as pas le droit aux escales, dans le produit, tu as la RGPD par exemple). 

On a aussi tendance à oublier la casse. Tu peux démâter, déchirer tes voiles… Ce qui peut s’assimiler à de la dette technique. Tu as voulu aller trop vite, tu le paies et, à un moment, il faut que tu le répares. 

Vois-tu d’autres analogies ?

G.J. : Oui, un tour du monde, comme une roadmap, demande de prendre de la hauteur. Tu vas devoir te projeter au-delà de ton bateau et savoir anticiper où les décisions que tu vas prendre vont t’emmener.

L’absence d’aide au routage est aussi intéressante. Les skippers reçoivent tous les jours des données météos brutes et c’est à eux/elles de les interpréter.

C’est pareil pour les PM qui doivent prendre des décisions en fonction des inputs d’affaires ou des utilisateurs. Sachant que les concurrents auront peut-être une autre interprétation et prendront un cap différent.

Et bien merci pour cette métaphore filée inattendue ! Si nous revenons sur notre sujet de façon plus terre à terre, quelles sont les erreurs fréquentes que tu vois chez les startups que tu accompagnes, en termes de conception de roadmap ?

G.J. : Il y en a deux qui me viennent en tête :

1) La confusion entre une roadmap et une liste de fonctionnalités

Une fonctionnalité n’est pas, pour moi, l’input (= l’entrant) de ta roadmap. Ce sont au mieux des output (= des résultats) et encore, tu n’es pas obligé d’en avoir à la sortie de ta roadmap. En fait, tu peux vite partir dans une foire à la fonctionnalités, alors qu’il faut toujours revenir à l’objectif que tu veux atteindre et les leviers que tu veux activer, en fonction du contexte dans lequel tu te trouves. 

2) L’autre écueil, c’est de rentrer parfois dans trop de dogmatisme.

En mode : « On a fait une roadmap, il faut qu’on s’y tienne ». Alors que ça doit être, au contraire, quelque chose d’organique, qui doit vivre. Une bonne roadmap, c’est quelque chose que tu vas pouvoir ajuster. Ce qui ne veut pas dire que tu dois tout jeter toutes les 30 secondes. Pour reprendre l’analogie de la voile, tu as un cap mais tu vas l’ajuster au fur et à mesure. Car tu n’avais pas vu mais tu as une dépression qui arrive.

Il ne faut surtout pas se dire : “C’est bon, on sait quoi faire”. Et c’est parfois exacerbé dans les grands groupes car la prise de décision est tellement longue, le temps de convaincre toutes les parties prenantes, qu’une fois qu’elle est validée, tu dois la dérouler coûte que coûte et peu importe ce qui arrive. 

Franchement, peut-on vivre sans roadmap ? Ce qui revient à se poser la question de son utilité au final…

G.J. : C’est en effet un exercice qui peut-être chiant à faire ou à animer. Mais il me paraît essentiel. Pour plusieurs raisons.

D’abord, c’est une aventure humaine. C’est une super façon de poser ta vision produit et de donner du sens aux équipes. Tu n’es pas juste là pour pisser de la fonctionnalité. Dans une startup où tout va très vite et où tu ne sors pas la tête de l’eau, tu peux vite perdre le sens de ce que tu fais. “OK, j’ai sorti la 10e version optimisée de telle fonctionnalité… mais pourquoi en fait ?” D’ailleurs, si tu n’as pas de vision produit, tu ne peux pas avoir de roadmap.

Cela aide aussi les équipes de vente et de support à se projeter dans leurs futures ventes du produit.

Enfin, cela donne de la visibilité aux investisseurs internes ou externes. Ces derniers n’investissent pas sur des fonctionnalités mais sur des impacts. C’est une façon de leur indiquer que l’équipe essaie de cracker (= résoudre) les bonnes choses. 

Quelles différences vois-tu, dans cet exercice, entre une startup, une scale-up et une grande entreprise ?

G.J. : Ce que je vais dire va paraître peut-être un peu réducteur mais j’assume le trait. La différence principale que je vois, c’est tout simplement le nombre de personnes à impliquer.

Dans une startup, il y a un énorme enjeu de vitesse d’exécution et de focus. Mais le gros atout, c’est l’accès direct au/à la CEO / CTO voire aux utilisateurs. Ton choix peut donc être hyper rapide. Un point important que j’ajoute ici : si tu n’as pas encore trouvé ton product market fit (= adéquation produit / marché), ton sujet, ce n’est pas la roadmap : c’est de trouver ton product market fit !

Dans une scale-up, le nombre de parties prenantes à impliquer est plus important mais, comme on reste dans le numérique, le produit reste normalement au centre culturellement.

Pour les grands groupes, tu ajoutes une contrainte supplémentaire : le produit est généralement une composante du modèle économique, mais pas le cœur. Avec tout l’enjeu de la culture produit numérique que cela pose.

On a parlé, dans notre dossier sur les roadmaps collaboratives, du rapport à des personnes externes au produit, que cela soit des salariés ou des utilisateurs. Vois-tu cela comme du parasitage ou au contraire une ouverture d’esprit bénéfique ?

G.J. : Il faut bien voir qu’à un moment, tu n’as plus le choix d’embarquer du monde. La question principale qui se pose, c’est l’accès aux personnes.

Après, personnellement, si on a accès à ses utilisateurs par exemple, je préfère aller à leur rencontre pour comprendre leur problème plutôt que de les faire voter sur des fonctionnalités. Trouver des solutions à leur problème, c’est notre taf. Par contre, s’assurer qu’on travaille sur le bon problème, c’est là qu’est l’enjeu.