Dans cet article, ils partagent les raisons de ce changement, les bons et les mauvais côtés et leurs conseils. Découvre leurs retours d’expériences pour t’éclairer sur ce choix de carrière, au plus proche du business et des utilisateurs.

1. C’est quoi le métier de Product Manager ?

En tant que dev, il est de plus en plus courant de travailler au quotidien avec des product managers (PM). Le trio Tech - Produit - Design est en effet aujourd’hui un incontournable des entreprises tech. Mais ce n’est pas pour autant que chacun connaît précisément le rôle des uns et des autres. 

Surtout que le product management est une discipline relativement nouvelle en Europe. Le média francophone Le Ticket, spécialisé sur le sujet, a déniché une des premières offres d’embauches de PM en France qui date… de 2011 ! Il s’agissait d’un poste pour BlaBlaCar, la plateforme de covoiturage. “Je me souviens que c’était inhabituel de recruter sur un poste comme celui-ci, différent de simple Project Manager”  se souvient Frédéric Mazzella, son président fondateur.

Une fonction d’architecte de produits numériques

Depuis, le métier s’est bien développé et formalisé. Voici comment on pourrait le résumer simplement :

L’objectif des product managers est d’avoir un impact sur le comportement des utilisateurs de leur produit, dans l’intérêt de la stratégie de leur organisation.

“Il s'agit de transformer des besoins utilisateurs et des attentes de la société en opportunités pour construire des modèles économiques pérennes”, précise Tanguy Verluise, ex senior PM chez Veepee et TheFork et cofondateur du média Le Ticket.

L’idée forte à retenir : dans la culture produit, on mesure sa réussite en regardant plutôt l’impact généré (= les outcomes) que les projets livrés en tant que tels (= les outputs).

Pour reprendre les propos de Marty Cagan, l’auteur de la bible du product management Inspired, les PM doivent avoir une vue sur 3 dimensions pour créer des produits :

• qui apportent de la valeur (composante business)
• qui sont facilement utilisables (composante design)
• qui sont faisables (composante technique) 

2. Pourquoi vouloir devenir PM quand on est dev ?

Ne dit-on pas que développeur est le plus beau métier du monde ? Il n’empêche, certaines personnes connaissent des frustrations et ont fait de leur passé d’ingé une force pour franchir le pas du monde du produit. Voici certaines raisons entendues :

“Avoir une plus grande influence sur le produit”

Après une formation d’ingénieur à Lyon, Marc Viricel devient développeur mobile. En 2016, il rejoint le fabricant d’objets connectés Withings en tant qu’architecte iOS puis responsable de la partie iOS pendant 3 ans. Un poste qui lui permet d’échanger avec d’autres équipes (design, qualité, product management, etc.) et de se rendre compte que ses intérêts personnels évoluent.

“J’avais la sensation que je pouvais apporter des conseils sur la partie tech mais que mon champ d’action sur l’ensemble du produit était limité. Alors que les enjeux business, comme trouver un product/market fit ou établir une politique tarifaire, me passionnaient de plus en plus”, explique celui qui est devenu Product Manager en mai 2021. 

Un argument qu’a utilisé Frédéric Dermer, ancien senior PM de Critéo et Head of Product de BlaBlaCar, aujourd’hui cofondateur et CPO/CMO de la startup londonienne Fixter, pour convaincre un de ses dev’ de passer au produit : “Pour moi, l’intérêt de devenir PM, c’est de pouvoir augmenter son impact dans la construction de la stratégie et de l’avenir de la boîte”. 

“Le développement était juste un moyen d’arriver à mes fins”
Armand Quainon, Head of Product chez wenabi

Pour Armand Quainon, le déclic se produit quand il est amené à faire du support client et, donc, à être au contact direct des utilisateurs. Cet ancien développeur chez Airbus, aujourd’hui Head of Product de wenabi, comprend qu’il est plus attiré par la réflexion produit que la réalisation technique : “Le développement était juste un moyen d’arriver à mes fins. Mais j’ai pris conscience que ce que je recherchais le plus, c’était de répondre à des besoins”.

“Moins subir les décisions des autres”

Marc Viricel poursuit son raisonnement et découle sur une autre frustration, quoique proche de la précédente : “J’ai eu plusieurs fois le sentiment de ne pas construire les bonnes fonctionnalités. En tant que tech, tu as certes une influence mais rarement le dernier mot”. 

“Je pense que la moitié du code que j’ai écrit dans ma vie n’a jamais été mis en prod’ !”
Matthieu Cutin, Product Manager chez Easyblue

Un sentiment partagé par Matthieu Cutin, développeur plusieurs années pour des agences Web ou à son compte, avant de devenir Product Manager pour Easyblue, un courtier en assurance pour les pros : “Je pense que la moitié du code que j’ai écrit dans ma vie n’a jamais été mis en prod’ ! Combien de fois je savais qu’un projet allait échouer avant de démarrer… D’où cette volonté de quitter cette position d'exécutant pour celle de décideur afin de me rapprocher des utilisateurs et ne pas faire des choses inutiles”.

“Être PM, c’est une manière de prendre en main son destin pour moins se positionner en bout de chaîne”, confirme Frédéric Dermer. Et donc de mieux comprendre le pourquoi de ce que l’on fait.

“Vivre plus d’interactions au quotidien”

David Ronchaud, après plus de 5 ans dans le développement front-end, est devenu PM puis directeur du numérique des agences de voyage Copines de voyage et Les Aventureurs, sur la suggestion de son CTO.

Une décision qu’il ne regrette pas : “La tendance à rester toute la journée devant son ordinateur a toujours été quelque chose qui me gênait dans le dev’”, indique-t-il. Alors que le métier de PM est justement à la croisée de beaucoup de parties prenantes. Ce qui n’est pas sans poser d’autres problèmes, que nous évoquerons plus tard…

“Je prenais moins de plaisir à coder”

Dernière grande raison entendue : une moindre motivation à développer. Tout simplement. “Je me rendais compte que débugger ou gérer la legacy m’intéressait de moins en moins”, concède Thomas Bianchini, fullstack développeur pendant près de 5 ans et, depuis mars 2020, PM chez… talent.io. Deux options s’offraient à lui : devenir tech manager ou product manager. Ce fut donc la deuxième voie : “Moi, ce que j’aime, c’est résoudre des problèmes. Ce que l’on fait aussi en tant que PM, mais d’une autre manière.” 

“Je me rendais compte que débugger ou gérer la legacy m’intéressait de moins en moins”
Thomas Bianchini, Product Manager chez talent.io

Un discours qui ressemble sensiblement à celui de Marc Viricel de Withings : “Ce que j’adorais quand j’étais développeur, c’était prendre un problème et réfléchir à l’architecture technique de sa solution. La création de code derrière me branchait moins…” 

3. On fait quoi concrètement en tant que PM ?

Nous avons vu globalement à quoi correspondait le métier des product managers. Regardons de plus près maintenant ce que cela veut dire au quotidien, de la bouche de ceux qui ont troqué leur casquette tech pour celle du produit.

Thomas Bianchini, de talent.io, parle d’un métier aux deux facettes : 1) rendre les utilisateurs heureux 2) tout en en répondant à des objectifs business. Pour se faire, il effectue 4 activités principales :

1) La discovery

Cette phase consiste à découvrir ce que l’on doit construire, en comprenant bien les besoins des utilisateurs (par exemple en les rencontrant, en leur demandant leurs avis sur des maquettes, en validant des hypothèses etc.) et des parties prenantes. L’intérêt ? Maximiser les chances d’obtenir l’impact recherché, prioriser les sujets sur lesquels travailler… et minimiser le risque de bosser pour du vent ! C’est la composante à plus haute valeur ajoutée du métier.

2) La delivery

C’est la phase de construction et de mise en production de la solution trouvée. Elle correspond grosso modo au rôle de Product Owner dans la méthodologie Scrum et est parfois -à tort- considérée comme l’intégralité du métier de PM. C’est évidemment celle que tu connais le plus en tant que dev, car tu y participes en premier lieu. Mais, maintenant, tu sais que le métier de PM ne se restreint pas qu’à celà !

3) Le lancement d’un produit ou d’une fonctionnalité

On parle ici de product marketing. La réflexion a lieu idéalement au moment de la discovery et avec les équipes commerciales et marketing. L’objectif : réussir le go-to-market, c’est-à-dire faire en sorte que ce qui a été construit rencontre sa cible et… soit véritablement utilisé.

Exemples : travailler avec l’équipe marketing pour établir un plan de communication externe avec les bons messages clés (newsletters, réseaux sociaux, publicité, information supplémentaire au sein du produit, FAQ…), ou bien former en interne les sales et l’équipe relation clients sur les nouvelles fonctionnalités… 

4) L’analyse de la performance

Le product management est un processus itératif qui ne s’arrête pas lors de la mise en production d’une fonctionnalité. Généralement, dès la phase de discovery, les PM définissent un indicateur de succès. Puis, après le lancement, ils ou elles collectent les données avec l’aide des équipes data afin de mesurer le succès du projet. 

Ensuite, on repart sur un nouveau cycle ! La roadmap est un de ses outils de prédilection du PM, dans laquelle il ou elle va planifier les différentes itérations du produit.

Les PM sont parfois surnommés les “CEO du produit”. Nuançons un peu cela. “Ils sont responsables d’un périmètre mais restent guidés par la vision et la stratégie de l’entreprise. Ce ne sont pas des magiciens qui arrivent subitement avec des idées de génie pour tout révolutionner”, relativise Jean Lebrument, cofondateur, Chief Product Officer et ex CTO de la plateforme de freelance Brigad. 

Autrement dit : c’est un métier qui nécessite d’échanger avec des personnes très différentes en interne (marketing, sales, stratégie, design, tech, finance, legal etc.) comme en externe (utilisateurs finaux, clients, partenaires...) pour concevoir les solutions les plus appropriées.

4. Comment on fait pour devenir PM quand on vient du dev’ ?

Comme tu le vois, la connaissance technique n’est qu’une partie du rôle de PM. Certain·es n’ont d’ailleurs jamais écrit une ligne de code de leur vie. Voyons donc quelles compétences il convient de développer quand on vient du monde du développement, et comment y arriver.

Les trois soft skills clés à acquérir : communication / leadership / empathie

“Les qualités de communication sont déjà très importantes pour un dev’, mais là, il faut apprendre à adapter son discours avec plein de populations différentes,” affirme Thomas Bianchini. “J’ajouterai même le côté “leadership””, renchérit Frédéric Dermer. 

“On joue un rôle de facilitateur entre toutes les parties prenantes.”
Marc Viricel, Product Manager chez Withings

Ce que confirme Marc Viricel : “On joue un rôle de facilitateur entre toutes les parties prenantes. Il faut sans cesse aller chercher les infos proactivement”. Ce qui sous-entend d’acquérir des bases en marketing, en design ou en fonctionnement d’un modèle économique, afin de pouvoir comprendre et participer aux discussions.

N’oublions pas non plus la question de l’autorité, pour faire avancer efficacement les projets : “Savoir dire non est vraiment la clé d’un bon travail de priorisation. Mais ce n’est pas toujours facile, notamment devant ses fondateurs…” précise David Ronchaud. Ce dernier ajoute aussi l’empathie, qualité requise pour le travail de design et de réponse aux besoins des utilisateurs. Même si tu l’as normalement en tant que développeur/développeuse... quand tu travailles sans PM !

Se mettre dans la posture avant de jouer ce rôle

Pour monter en compétence, il est possible de faire appel à des ressources externes (cf point suivant) et/ou de sortir de sa zone de confort et d’apprendre sur le tas ! En commençant par des petites initiatives.

“Quand il y avait des démos, des présentations orales ou des groupes de réflexion sur la stratégie de l’entreprise, je faisais régulièrement partie des volontaires, indique ainsi Thomas Bianchini. “Souvent, on officialise un rôle avec un poste. Il faut prouver au préalable qu’on peut mériter cette confiance”, ajoute Marc Viricel, qui se souvient avoir commencé à prendre plus de décisions produit, pour sortir de son étiquette de “bon en tech, moins en design ou en business”. Selon lui, il faut justement montrer que l’on peut aussi être en mesure d’avoir des convictions sur d’autres domaines.

D’ailleurs, lui comme Thomas Bianchini ont commencé leur nouveau rôle sur un produit technique, qui demandait une bonne connaissance des API ou en documentation technique. Une bonne porte d’entrée selon eux pour une transition en douceur.

Quelques ressources essentielles

Il y a la pratique… mais aussi la théorie. Voici une liste loin d’être exhaustive pour approfondir tes connaissance du product management :

En anglais :

• Les newsletters Silicon Valley Product Group et Lenny’s newsletter 
• Le compte Twitter de Shreyas Doshi
• Les formations de Udemy, Reforge, Product School, Product Institute
• La conférence Mind The Product
• Les livres Inspired de Marty Cagan et Empowered de Marty Cagan and Chris Jones

En français :

• La communauté : French Produit
• Les podcast : Product Squad - Clef de Voûte - Product Tape - Épique
• Les newsletters : Le Ticket - Product Inbox - Thiga
• Les formations : Noé - Maestro - Open Classrooms

Les conférences : La Product Conf - School of Product

5. C’est quoi les avantages d’être PM avec un background tech ?

On vient de voir qu’il faut se renforcer sur certains pans pour passer au produit. Mais ce n’est pas pour autant que l’on repart de zéro quand on a été développeur ou développeuse par le passé ! Petit aperçu des atouts à faire valoir dans une équipe produit.

Des échanges fluides avec les ingénieurs

“Clairement, je n’ai pas à adapter mon langage et je n’ai pas peur d’être ultra technique pour expliquer des contraintes de perf’ ou de base de données, par exemple, quand je parle avec les développeurs”, lance d’emblée Thomas Bianchini. Un avantage indéniable pour commencer dans le métier car, au début, c’est surtout sur la partie delivery qu’est attendu et évalué un PM. “Je sais ce qu’ils attendent dans la manière de rédiger des user stories, en termes de rigueur et de niveau de détails, pour l’avoir moi-même vécu,” détaille Matthieu Cutin. 

“En tant qu’ancien dév, je sais ce qu’ils attendent dans la manière de rédiger des user stories”
Matthieu Cutin, Product Manager chez Easyblue

Un bagage qui permet aussi de prendre plus rapidement des décisions techniques. “L’avantage, c’est que je sais quand il s’agit juste d’un “if” ou si la fonctionnalité sera plus complexe à construire”, poursuit ce dernier. Même si ce biais du “comment je l’aurais fait si j’avais été à leur place ?” est à double tranchant : “Cela peut être un frein à la créativité et nous faire oublier que notre rôle est moins de faire du beau code que de répondre aux besoins des utilisateurs”, nuance Thomas Bianchini.

Une bonne vision technique globale

Pour Frédéric Dermer, la diversité et la complémentarité des profils est le propre d’une bonne équipe produit. D’ailleurs, c’est ce qui a joué dans le recrutement de sa nouvelle PM, une ancienne développeuse. “C’est beaucoup plus courant dans la Silicon Valley d’avoir des anciens tech aux postes de PM”, constate-t-il.

En Europe, cette couleur tech est plus rare au produit. Mais elle permet de mieux prendre en compte certaines complexités d’architecture technique ou liées à la maintenance du code existant par exemple. “Dans mon équipe, j’ai des backgrounds design, business, tech… Il faut que cela puisse refléter les différentes facettes de ton produit”, estime Jean Lebrument.

6. Et les inconvénients de cette nouvelle vie de PM ?

Pour que le portrait soit plus réaliste qu’idyllique, ne cachons pas certains désagréments du métier de PM.

Accepter de ne plus “faire”

C’est LE point qui revient le plus dans la bouche des personnes interviewées. “Je ne peux plus mettre en oeuvre les solutions moi-même. Il faut que je l’explique en mettant tout le monde dans la boucle”, regrette parfois Matthieu Cutin… même s’il avoue prendre plus de plaisir aujourd’hui lors des phases de discovery. “Cela manque de ne pas pouvoir tester son idée directement”, confirme Armand Quainon.

“Tout est prêt, tu as tout en tête.. mais tu vas le confier à d’autres alors que tu aurais vraiment trop aimé le coder pour voir comment cela se goupille dans les détails. Il faut accepter…”, partage de son côté Thomas Bianchini. “On a cette sensation d’artisan qui fait quelque chose de ses mains quand on est développeur. Ce concept de création concrète est plus flou en tant que PM, comme on met en orchestre d’autres personnes”, résume Marc Viricel. “Même si, moi, je continue à coder en freelance à côté, pour le plaisir”, atteste David Ronchaud.

Plus d’interruptions

Autre point négatif : “Tu ne peux plus rester dans ta bulle ! Tu es dérangé tout le temps quand tu es PM”, assure ce David. Ce qu’a aussi constaté Thomas Bianchini. Quand il était dev’, il pouvait se prévoir de longues sessions de programmation. “J’avais 2 réunions par semaine alors qu’aujourd’hui, cela représente la moitié de mon temps !”, estime-t-il. La rançon d’avoir plus d’interactions avec les autres équipes. “Le problème également, c’est que tout le monde dans la boîte a un avis assez fort sur le produit. Il faut bien faire ses devoirs pour faire comprendre que c’est un métier à part entière”, conclut Jean Lebrument.

Un marché du travail (un peu) moins dynamique

Le métier de développeur/développeuse offre en général une rémunération supérieure, même si les écarts ont tendance à se gommer au fur et mesure de la progression dans la hiérarchie.

Notre dernière étude des salaires présentait même des niveaux de rémunération médians supérieurs pour les Product Managers. Dans tous les cas, le salaire semble sensiblement égal entre les deux rôles.

Il est par contre très clair qu’il y a moins d’offres d’emploi pour des postes de PM que pour des développeurs/développeuses. “J’avais 2 propositions de poste par semaine avant. C’est plus calme depuis que je suis PM”, confie un des interviewés.

Le job de product manager reste malgré tout très attractif et demandé. La preuve : aucune des personnes que nous avons interrogées n’envisage un retour au code !

‍

‍