Le quotidien d'un product manager, au-delà de la fiche de poste
Sur le papier, le product manager décide de ce que l'équipe construit et dans quel ordre. Dans les faits, le métier tient en une série d'arbitrages, presque toujours sans lien hiérarchique avec celles et ceux qui font le travail : les développeurs ne lui rendent pas compte, les designers non plus, et l'équipe commerciale encore moins. Tout passe par la clarté, la conviction et la confiance.
On parle aussi de chef de produit, surtout dans l'industrie, où le terme recouvre parfois un rôle proche du marketing. Les situations qui reviennent, elles, se ressemblent d'une entreprise à l'autre :
- un client important réclame une fonctionnalité que l'équipe commerciale a presque promise, et il faut dire si elle entre dans la feuille de route, quand, et pourquoi ;
- des entretiens avec des utilisateurs montrent que le problème n'est pas celui qu'on croyait, et le grand projet du trimestre doit changer de direction ;
- l'équipe technique annonce que la solution prévue prendra trois fois plus de temps qu'espéré, et il faut une version plus modeste qui garde l'essentiel ;
- la direction veut une date, l'équipe veut du temps pour réduire sa dette technique, le support veut qu'on corrige ce qui remplit sa boîte : tout le monde a raison, et il n'y a qu'une équipe.
Bon ou excellent : où se fait vraiment la différence
Un bon product manager livre ce qui était prévu. La feuille de route tient, les besoins sont bien rédigés, et personne ne se demande sur quoi travailler ensuite. C'est déjà beaucoup.
Un excellent product manager se juge à autre chose : à ce qui a changé pour les utilisateurs. Ses collègues le décrivent rarement en parlant de livraisons. Ils racontent une décision difficile qu'il ou elle a su faire accepter, un projet arrêté avant qu'il n'avale un trimestre de plus, une réunion où le vrai problème est enfin apparu. Les différences ressemblent souvent à ceci :
- Le bon transmet les demandes ; l'excellent remonte au problème qui se cache derrière, et revient parfois avec une solution plus simple que celle qu'on lui réclamait.
- Le bon dit non poliment ; l'excellent dit non avec des raisons que la personne déçue peut répéter telles quelles à son propre responsable.
- Le bon suit ce qui a été livré ; l'excellent vérifie, quelques semaines plus tard, si les usages ont changé, et le dit franchement quand ce n'est pas le cas.
- Le bon rédige des spécifications complètes ; l'excellent explique si bien le pourquoi que l'équipe prend seule les petites décisions.
Les compétences qui se voient, et celles qu'on remarque après coup
Certaines qualités sautent aux yeux dès la première réunion : la clarté à l'oral, l'aisance face à la direction, l'art de résumer en trois phrases un débat de vingt minutes. Elles comptent, mais ce sont aussi les plus faciles à jouer pendant une heure d'entretien.
D'autres ne se voient que de l'intérieur de l'équipe, et ce sont elles qui font la réputation d'un product manager. Un CV peut dire que vous avez lancé un produit ; seul un collègue peut raconter comment.
- La curiosité pour le travail des autres : comprendre assez la technique pour poser la bonne question à une développeuse, sans décider à sa place.
- L'écoute des utilisateurs, y compris quand ils disent ce qu'on n'a pas envie d'entendre, et la discipline de ne pas orienter les questions en entretien.
- La mémoire des décisions : savoir pourquoi une option a été écartée six mois plus tôt, et l'avoir écrit là où l'équipe peut le retrouver.
- Le sens du détail sur ce que l'utilisateur rencontre vraiment : un message d'erreur, un cas limite, un écran que personne n'avait dessiné.
- L'honnêteté sur les résultats, surtout quand l'idée qui n'a pas marché était la sienne.
Les erreurs fréquentes, même avec de l'expérience
La plupart de ces erreurs ne viennent pas d'un manque de compétences, mais de la pente naturelle du poste : sous pression, il est tentant de tout accepter, de tout spécifier, ou de se réfugier dans les outils. Les product managers qu'on recommande avec le plus d'enthousiasme ne sont pas ceux qui ne les ont jamais commises, mais ceux qui les ont repérées et ont changé leur façon de travailler.
- Devenir un guichet : inscrire les demandes de chacun dans la liste des sujets à traiter sans jamais les relier à un objectif. L'équipe livre beaucoup, et rien ne change vraiment.
- S'attacher à sa propre solution, et lire les entretiens avec les utilisateurs comme une confirmation.
- Écrire des spécifications si détaillées que développeurs et designers n'ont plus aucune marge pour proposer mieux.
- Confondre une date et un résultat : fêter la mise en production, puis ne jamais regarder ce qu'elle a changé.
- Oublier celles et ceux qui n'étaient pas dans la salle : le support ou l'équipe commerciale découvrent la nouveauté le jour du lancement.
Ce que regarde un recruteur chez un product manager
Les CV de product managers se ressemblent souvent : des produits lancés, des équipes accompagnées, des méthodes citées. La personne qui recrute cherche donc ce qu'on écrit mal soi-même, et sur ces points la parole des autres pèse plus que la vôtre. C'est aussi ce qu'une prise de références cherche à confirmer : notre guide sur les questions posées à vos références détaille ce que vos contacts risquent d'entendre.
Si vous avez réuni des recommandations sur Take Your Skills, mettez le lien de votre profil sur votre CV ou joignez le PDF à votre candidature : le recruteur lit ce que développeurs, designers et clients ont écrit sur vous, sous leur nom, avant le premier entretien. À partir des recommandations publiques, Take Your Skills rédige aussi un portrait professionnel, en français et en anglais, qui fait ressortir les compétences les plus citées et ce qui vous distingue.
Voici ce qu'un recruteur cherche en général :
- des arbitrages racontés : ce qui a été choisi, ce qui a été écarté, et pourquoi ;
- la relation avec l'équipe technique et la conception, souvent testée par une question sur un désaccord ;
- la façon de mesurer : quels signaux ont été suivis, et ce qui a été fait quand ils ne bougeaient pas ;
- la capacité à parler d'un échec sans en rejeter la faute sur d'autres.
Quels profils de personnalité s'épanouissent dans ce métier ?
Aucun profil n'est fait pour devenir product manager, et aucun n'en est exclu. Certaines dispositions naturelles aident pourtant dans des moments précis du métier. Le test de personnalité au travail de Take Your Skills décrit seize profils à partir d'une quarantaine de situations concrètes ; en voici quelques-uns dont les forces rejoignent ce que le poste demande.
Le Stratège pense plusieurs coups à l'avance et donne à l'équipe une trajectoire qui tient face aux urgences. C'est exactement ce qu'on attend d'une feuille de route : qu'elle ne se réécrive pas chaque fois qu'un client s'impatiente.
Le Clarificateur démêle ce qui est confus et repère la faille d'un raisonnement avant qu'elle ne coûte cher. Face aux demandes floues et aux hypothèses fragiles, c'est la personne qui demande « qu'est-ce qui nous fait croire ça ? » avant que la première ligne de code soit écrite.
Le Fédérateur rassemble des personnes différentes autour d'un but commun. Un product manager n'ayant pas d'autorité sur celles et ceux qui construisent le produit, réunir ingénierie, conception, ventes et support derrière une même priorité est le cœur du travail.
D'autres profils réussissent autrement. Le Gardien, qui prend soin des personnes comme des détails et remarque ce qui échappe aux autres, n'est pas celui qu'on imagine d'emblée à la tête d'un produit. Il apporte pourtant ce qui manque souvent : l'attention au cas limite, à l'utilisateur oublié, au collègue du support qui aurait sinon appris la nouveauté le dernier. Chaque profil peut exceller dans ce métier, à sa manière ; le test sert à connaître vos forces naturelles, et à savoir sur qui vous appuyer pour le reste.
Qui solliciter, et comment demander
Le métier se joue à la rencontre de plusieurs équipes, et vos recommandations devraient le montrer : une seule voix, même celle de votre responsable, ne raconte qu'une partie de votre travail. Demandez juste après un lancement ou une étape franchie, quand les souvenirs sont frais, et nommez la situation à laquelle vous pensez, la refonte du parcours d'inscription par exemple, pour que la personne sache de quoi parler. Notre guide pour demander une recommandation propose des modèles de messages.
Sur Take Your Skills, le bouton « Demander une recommandation » de votre profil vous donne un lien à envoyer par e-mail ou par message. Beaucoup de développeurs n'aiment pas écrire un long texte en partant de rien : l'assistant les aide en posant une question à la fois sur des situations concrètes vécues avec vous, puis propose un texte qu'ils relisent et modifient avant de le publier. Leurs réponses ne sont jamais publiées, et ils peuvent écrire sans lui.
Visez des regards différents :
- une développeuse ou un responsable technique, sur la clarté des besoins et votre façon de traiter les contraintes techniques ;
- une ou un designer, sur la place laissée à l'exploration et la manière dont vous défendiez l'utilisateur ;
- une personne de l'équipe commerciale ou du support, sur votre capacité à dire non sans abîmer la relation ;
- votre directrice ou directeur produit, sur vos arbitrages et votre vision d'ensemble ;
- un product manager débutant que vous avez accompagné, pour parler de transmission.
Huit exemples de recommandations pour un product manager
Ces exemples sont faits pour être adaptés. Remplacez les éléments entre crochets, et ajoutez surtout un détail que personne d'autre ne connaît : c'est lui qui rend une recommandation crédible.
- D'une responsable technique : « Sur [projet], ce qui m'a frappée chez [Prénom], c'est la qualité des questions avant chaque développement : pourquoi, pour qui, et ce qu'on accepte de ne pas faire. Quand la solution prévue s'est avérée trop lourde, [Prénom] a appelé deux clients dans l'après-midi et nous a proposé dès le lendemain une version plus simple qui gardait l'essentiel. Je recommande [Prénom] à toute équipe qui veut comprendre ce qu'elle construit. »
- D'un designer : « [Prénom] m'a toujours laissé le temps d'explorer avant de figer quoi que ce soit. Sur [projet], c'est [Prénom] qui a eu le courage de dire en comité de direction que notre première idée ne répondait pas au vrai problème. Le parcours finalement lancé est bien plus simple, et les demandes au support sur ce sujet ont nettement baissé. »
- D'un directeur commercial : « [Prénom] m'a dit non plus d'une fois, mais jamais sans explication, et toujours avec une autre solution à présenter au client. Quand [client] a réclamé [fonctionnalité], [Prénom] l'a appelé pour comprendre son vrai besoin, et notre proposition l'a satisfait sans détourner l'équipe de ses priorités. Avec [Prénom], on sait exactement ce qu'on peut promettre. »
- D'une responsable du support : « Avec [Prénom], le support n'a jamais découvert une nouveauté le jour de sa sortie : nous avions les écrans, les réponses aux questions à venir et une personne à appeler. [Prénom] lisait aussi chaque semaine notre synthèse des difficultés clients, et en a tiré plusieurs corrections qui ont vraiment soulagé nos utilisateurs. »
- D'un client : « [Prénom] nous a proposé de participer à des entretiens peu après notre arrivée sur [produit]. J'ai rarement vu quelqu'un écouter avec autant d'attention, sans chercher à défendre son produit. Plusieurs de nos remarques se sont retrouvées dans les versions suivantes, et [Prénom] nous a prévenus personnellement à chaque fois. »
- D'une directrice produit : « J'ai confié à [Prénom] notre produit le plus délicat, avec beaucoup de parties prenantes et des attentes contradictoires. [Prénom] a construit une feuille de route que tout le monde pouvait suivre, a proposé de retirer [fonctionnalité] qui coûtait plus qu'elle ne rapportait, et l'a expliqué aux équipes concernées sans laisser d'amertume. »
- D'un analyste de données : « [Prénom] posait toujours la question qui dérange en premier : comment saura-t-on si ça marche ? Quand les résultats de [projet] ont déçu, [Prénom] les a présentés tels quels à la direction, avec une proposition pour la suite. Cette honnêteté a donné confiance à toute l'équipe. »
- D'une product manager accompagnée à ses débuts : « [Prénom] m'a appris le métier sans jamais me donner de réponse toute faite. À chaque arbitrage revenait la même question : qu'est-ce qu'on cherche à changer pour l'utilisateur ? J'ai mené mon premier lancement seule, avec [Prénom] disponible en retrait, puis nous avons repris ensemble ce qui n'avait pas marché. Je fais aujourd'hui la même chose avec les nouveaux venus. »