Valentin Ménard, Lead PM chez ManoMano, la licorne d’achat en ligne de matériels d’outillage et de jardinage, vient de publier une série de trois articles qui va faire un bien fou aux PM qui souffrent du syndrôme Marty Cagan. À savoir qui sont frustré·es de ne pas pouvoir appliquer les principes théoriques de la littérature produit dans leur orga. Entrevue salvatrice en guise d’éloge du pragmatisme business dans le produit.

⌛ 11 minutes de lecture

Article issu du Ticket n°056

 

Salut Valentin, peux-tu nous raconter ce qui t’a motivé à écrire cette série d’articles ?


Valentin Ménard : Pour rappeler le contexte, quand je suis arrivé chez BlaBlaCar, ma vraie première expérience de PM, je n’avais suivi aucun cursus produit. Je sortais d’une école de commerce, j’avais fait le Wagon et créé une boîte en mettant pas mal les mains dans le code et le design. On m’avait alors dit que je savais discuter avec les techs, que j’avais des compétences en design et en business, donc que j’allais comprendre ce métier qui était à la croisée de ces disciplines.


Avec du recul, et jusqu’à très récemment, j’ai toujours baigné dans le flou autour de ce rôle, en me reposant sur de grands principes. Un peu comme si un joueur de tennis ne connaissait pas les règles pour gagner un point. Il essaie juste de faire de beaux coups droits, des beaux revers etc.


Après BlaBlaCar, j’ai rejoint Clustree, une startup B2B qui travaillait avec de grands groupes sur des enjeux de mobilité interne. Et c’est là où je me suis pris une claque.

 

C’est-à-dire ?


V. M. : Pour la première fois, j’étais challengé dans mes principes produit. Je devais défendre des choses qui m’avaient toujours paru couler de source. Par exemple, on me disait : “Vous êtes mignon avec vos itérations mais c’est un enfer pour les clients qui doivent réapprendre le produit en permanence”. Ou encore : “C’est quoi ta légitimité à trouver des solutions alors que tu es là depuis 6 mois et que nos clients font ce métier depuis 15 ans”.


Clairement, il fallait mettre de l’eau dans son vin et adapter ses dogmes à la réalité du terrain. C’est sûrement là où j’ai le plus appris, même si je le vivais avec une grande culpabilité : ces personnes m’empêchaient de “bien faire du produit” et je complexais de m’éloigner de la vision de Marty Cagan. J’ai alors décidé de rejoindre une boîte qui semblait avoir réussi à appliquer concrètement ces grands principes : ManoMano.

Et alors ?

V. M. : Quatre mois après mon arrivée, en février 2021, je me suis rendu compte que ces principes et cette zone grise sur la conception du rôle de PM généraient ici aussi des dissensions avec les équipes business. Ces dernières ont commencé à pousser pour avoir moins de rigidités par rapport à ces pratiques produit by the book. Cela a créé de la frustration côté PM mais, j’avais vu que l’herbe n’était pas forcément plus verte ailleurs.

Donc je me suis dit : arrête de te dire que ce n’est pas normal et profite d’être dans une boîte qui va te permettre de comprendre quels sont les nœuds entre la théorie et la pratique, plutôt que de fuir en quête d’une situation parfaite qui n’existe pas. Chez ManoMano, il y a en effet une forte maturité produit et des gens au business très pragmatiques, donc une vraie possibilité d’échange à haut niveau.

Je me suis donc lancé dans une démarche personnelle qui est devenue, progressivement, un projet d’entreprise : mener une vaste investigation pour clarifier le rôle de PM. Depuis plus d’un an, j’y ai passé entre 30 min et 1h chaque jour. Après 60 interviews, moitié côté produit et moitié côté business, et une quinzaine de présentations auprès des différentes équipes jusqu’au C-level, j’ai abouti à une vision partagée de tous et officielle de ce qu’est le produit chez ManoMano.

En résumé, tu trouvais qu’il y avait une dissonance trop forte entre la théorie produit et la pratique en entreprise avec des parties prenantes qui trouvent les PM trop rigides.

V. M. : En fait, il y a tellement de principes dans le produit qu’il est très facile de se sentir nul et d’éprouver de la culpabilité à se dire qu’on est en train de devenir project manager. D’autant que beaucoup de ces principes proviennent de visions idéalisées du métier du PM, écrites par des PMs, et qui créent des frictions dès qu’on les met en pratique dans une entreprise. C’est en discutant avec les équipes business que j’ai ouvert les yeux sur cette réalité.

Et puis en faisant les entretiens, je me suis rendu compte qu’il y avait aussi beaucoup de frustrations qui provenaient d’incompréhensions de surface alors qu’au fond on visait le même objectif.

Je donne un exemple. Lors d’une interview, un PM me raconte une situation où il a la sensation de se faire imposer une solution par le business, et qu’il se retrouve dans une posture de simple exécutant. Plus tard, j’interroge la partie prenante côté business qui me relate la scène comme il l’a vécue : il fait au PM un schéma d’une idée de solution … et se rend compte un mois plus tard que c’est exactement ce qui sort en prod’. Il ajoute : “C’est quoi dans ce cas la valeur ajoutée du produit ?”  

Quelles sont les frustrations qui sont ressorties de tes entretiens avec le business ?

V. M. : J’en vois trois principales.

La première, c’est la rigidité de nos pratiques. Notamment sur le fait que tout doit passer par une discovery avec des interviews utilisateurs. On m’a dit par exemple : ça fait 20 ans qu’on fait du e-commerce, à un moment donné, il faut nous faire confiance et ne pas perdre trois mois à réinventer la roue ! Je balaie devant ma porte : quand j’ai lancé le cross sell sur Mano Mano, je me suis lancé dans une phase de recherche utilisateurs pour vérifier que ça répondait bien à un besoin. J’aurais pu être plus pragmatique et m’épargner ce temps : si tous les autres sites de e-commerce, sans exception, mettent des produits complémentaires en avant, ce n’est pas pour rien !

La deuxième, c’est de refuser de s’engager sur des échéances. Certes, la discovery est un exercice incertain durant lequel on va apprendre plein de choses en chemin. Mais il faut comprendre que les équipes sales ou marketing ont leur propres contraintes qui nécessitent d’anticiper nos avancées.

Enfin, on remarque que quand une personne a le pouvoir de trancher, elle finit par moins écouter les autres (NDLR : ce que la science confirme, cf TTSO). Même si les PM sont censé·es prendre les avis de tout le monde, les interlocuteurs business trouvaient – à juste titre – ne pas être suffisamment écoutés.

Ce qui est drôle, c’est que, pendant un trimestre, on a donné ce pouvoir de trancher aux équipes business et il s’est passé le même problème à l’inverse. Désormais, personne n’a le pouvoir absolu de trancher : c’est le quatuor produit / tech / design / business qui doit se mettre d’accord ! Ce qui pousse à plus écouter, faire plus d’effort pour convaincre et crée un vrai esprit d’équipe.

Finalement, n’était-ce pas libérateur pour les PM ? Car c’est difficile de devoir constamment être assertif pour imposer ses avis et ses principes…

V. M. : Je dirais que tout est une question d’équilibre. Cela me fait penser à une publication sur Reddit (effacée depuis) d’un PM qui disait qu’il était tombé amoureux du produit en lisant Marty Cagan et Teresa Torres mais que ses parties prenantes voulaient juste qu’ils livrent des fonctionnalités. Alors, il a arrêté de se battre et est aujourd’hui bien plus heureux, moins stressé et touche ses 200K en jouant le jeu corpo. En concluant que 97% des boîtes ne comprennent pas ou s’en foutent du product management.

Sauf que c’est un piège, autant pour l’entreprise qui n’a pas l’impact qu’elle peut avoir que pour l’individu qui n’a pas un job très nourrissant. C’est la raison d’être du 2e article : quels sont les combats où mettre mon énergie ? Autrement dit, quels sont les 3 principes vraiment importants et ceux qui sont secondaires, afin d’arrêter ce complexe permanent de ne pas être dans les règles de l’art.

Et le 3e article, avec le framework PULSE, c’est un accompagnement sur le chemin des meilleures pratiques pour ne pas abandonner en cours de route.

Justement, tu peux revenir sur ces 3 principes et nous dire pourquoi tu les as choisis dans ton 2e article ?

V. M. : J’aurais pu appeler cet article “a pragmatic definition of PM”. En fait, il s’agit de définir les clés minimum pour réussir à bien répondre à sa mission.

 

1. Un·e leader sans pouvoir

Les PM proposent mais n’imposent pas. Ce sont des chefs d’orchestre de personnes qui ont plus de connaissances qu’eux dans chacune de leur verticale.

2. Commencer par les plus gros risques

Ce qui va de pair avec le besoin de travailler en équipes autonomes capables de prendre des décisions, et ajuster rapidement le cap au fur et à mesure de leurs apprentissages.

3. L’équilibre business – utilisateur

Ce qui rejoint un des mythes que j’indique dans le 1er article : on considère souvent que la dimension utilisateur est la plus importante. Mais ce n’est pas le cas. La dimension business l’est tout autant. Un produit qui ne répond pas aux besoins business de l’entreprise est tout autant un échec qu’un produit qui n’est pas utilisé par les utilisateurs.

Un dernier mot sur le Framework PULSE dont tu parles dans le dernier article. Peux-tu nous dire comment les PM peuvent l’utiliser concrètement et si cela s’adapte à tous les types de boîtes ?

V. M. : Je pense qu’il peut s’appliquer à tout le monde, du 1er PM en startup à une scale-up comme ManoMano en passant par un grand groupe, quelle que soit la maturité produit de l’organisation.

Ensuite, il faut le lire de façon chronologique, comme si c’était ton onboarding dans une nouvelle équipe. L’idée est d’arriver à améliorer les pratiques produit tout en consolidant le lien avec le business. Et pour ça, le chemin, c’est d’apporter de la valeur dès ton arrivée. Généralement, ta première tâche, c’est de résoudre le problème de backlog de fonctionnalités qui s’entassent. C’est ça qu’il faut gérer plutôt que de chercher d’emblée à mettre en place les meilleures pratiques produits.

C’est pour ça que je recommande un chemin en 5 étapes. Dont la première étape est de fluidifier le passage des idées business vers la tech, sans bug, en temps et en heure. Tu es clairement en mode delivery team et project management, mais tu apportes déjà de la valeur.

L’important maintenant est de ne pas se contenter de cette étape 1. Ce framework vise à montrer qu’il est possible d’extraire beaucoup plus de valeur d’un·e PM, ce dont n’ont pas toujours conscience les parties prenantes. 

Justement, comment se déclinent les étapes suivantes ?

V. M. : Ensuite, la 2e étape, c’est d’arriver à identifier les besoins derrière les solutions que l’on te pousse et trouver les solutions les plus adaptées. C’est une grosse partie de ce qu’on appelle souvent la discovery. Mais rapidement, tu vas te demander si tu travailles sur les besoins les plus importants.

D’où la 3e étape, celle de la priorisation. Tu collectes les besoins de l’ensemble de tes parties prenantes, et à l’aide d’une north star metric claire, tu alignes tout le monde sur les sujets qui ont le plus de potentiel. À ce stade, tu es capable de délivrer le plus de valeur par rapport aux enjeux qu’on a désormais tous en tête en interne. Mais ils ne reflètent pas toute la réalité.

Pour aller plus loin, il convient d’élargir notre spectre, en creusant plus en profondeur les besoins des utilisateurs, et en faire émerger de nouvelles opportunités. Il s’agit de la 4e étape.

La dernière, c’est se permettre d’être plus ambitieux. Tant que tu réfléchis trimestre par trimestre, tu te brides inconsciemment. Là, tu te poses la question : si on avait 2 ans devant nous, qu’est-ce qu’on aimerait bien créer ? Une fois que tu peux y répondre, tu peux trouver un équilibre dans tes roadmaps entre du stratégique et du tactique.

Il ne faut pas oublier une chose : in fine, notre rôle, c’est quand même de shiper des fonctionnalités ! Pour avoir de l’impact, bien sûr. Mais c’est notre moyen d’action. C’est comme si tu disais à un humoriste, ton rôle, ce n’est pas de faire des blagues, c’est que les gens se sentent mieux. OK… mais en faisant des blagues quand même ! C’est ce qui fait notre différence en tant que PM. Tout le monde dans l’entreprise cherche à avoir de l’impact et nous, on en a en ajoutant (ou retirant) des fonctionnalités dans le produit. Et plus on prendra ce recul, plus on sera capable d’avoir de l’impact.