Le premier recrutement de PM dans une organisation est souvent le plus risqué. Pas parce que les candidats sont mauvais — mais parce que l'organisation ne sait pas exactement ce qu'elle cherche, et que personne en interne n'est vraiment qualifié pour évaluer le candidat.
Le résultat classique : on recrute un "chef de projet" qu'on appelle PM. Ou un PM senior issu d'une grande tech qui ne sait pas fonctionner sans équipe structurée. Ou un profil très technique qui confond backlog et sprint backlog, et qui passe ses journées à écrire des tickets au lieu de parler aux utilisateurs.
Six mois plus tard, tout le monde est déçu. Et personne ne comprend vraiment pourquoi.
Ce que vous cherchez vraiment
Avant les questions, il faut être honnête sur ce que le rôle exige dans votre contexte spécifique. Un premier PM dans une startup de 15 personnes n'est pas le même profil qu'un PM dans une scale-up de 80.
Dans une petite structure, votre premier PM doit être capable de :
- Fonctionner dans le flou sans processus établis, sans stack d'outils mature, et souvent sans données fiables
- Faire avancer sans autorité formelle — les devs ne lui reportent pas, et les décisions finales appartiennent souvent aux fondateurs
- Livrer vite — pas dans 6 mois avec une roadmap parfaite, mais dans 4 semaines avec un scope réduit et des compromis assumés
- Apprendre des utilisateurs directement — pas via des études de marché commanditées, mais en décrochant son téléphone
Ce profil-là est rare. Et il ne ressemble pas toujours au PM que les GAFAM forment.
Ce que vous ne cherchez pas
Autant être direct sur les mauvaises pistes :
- Un MBA avec une belle présentation sur la stratégie produit mais aucune expérience de livraison
- Un "PM certifié" dont la seule certification a été obtenue en 2 jours de formation
- Un profil qui n'a jamais dit non à un stakeholder et ne sait pas l'expliquer
- Quelqu'un qui confond "avoir une opinion sur le produit" avec "faire du product management"
- Un candidat qui ne peut pas vous citer une décision difficile qu'il a prise, avec ses conséquences réelles
La grille en 6 dimensions × 3 questions
Voici les 18 questions que j'utilise, organisées par dimension. Chaque dimension teste une compétence critique. Pour chaque question, je cherche des réponses ancrées dans des expériences réelles — pas des frameworks théoriques.
Product thinking
- Racontez-moi une fois où vous avez découvert que vos utilisateurs voulaient autre chose que ce qu'ils vous demandaient. Comment vous l'avez découvert, et qu'est-ce que vous avez fait ?
- Comment décidez-vous qu'un problème mérite d'être résolu par le produit plutôt que par un process ou une formation ?
- Quel est le produit que vous admirez le plus en ce moment, et pourquoi il résout bien son problème ?
Priorisation
- Racontez-moi une fois où vous avez dit non à une demande d'un stakeholder important. Comment vous l'avez formulé, et quelle a été sa réaction ?
- Comment gérez-vous un backlog quand tout le monde prétend que sa demande est urgente et prioritaire ?
- Donnez-moi un exemple de fonctionnalité que vous avez décidé de ne pas faire, et expliquez-moi le raisonnement.
Stakeholder management
- Racontez-moi une situation où vous n'étiez pas d'accord avec votre hiérarchie sur une décision produit. Comment vous l'avez géré ?
- Comment vous assurez-vous que les équipes Engineering et Design avancent dans la même direction sans passer votre temps en réunion ?
- Vous avez un stakeholder qui contourne systématiquement le processus de priorisation. Que faites-vous ?
Data & mesure
- Comment décidez-vous que vous avez assez de données pour prendre une décision, et que vous n'avez pas besoin d'en collecter plus ?
- Racontez-moi une fois où les données vous ont dit une chose et votre intuition une autre. Qu'avez-vous fait ?
- Quelle est la métrique la plus importante que vous avez suivie dans votre dernier rôle, et pourquoi vous avez choisi celle-là ?
Delivery
- Racontez-moi le dernier projet que vous avez livré en retard. Quelle était la cause racine, et qu'auriez-vous fait différemment ?
- Comment définissez-vous "terminé" pour une fonctionnalité ? Qu'est-ce qui doit être vrai pour que vous puissiez dire que c'est livré ?
- Vous êtes en fin de sprint et il devient clair que le sprint goal ne sera pas atteint. Que faites-vous, dans quel ordre, et avec qui ?
Équipe & confiance
- Comment construisez-vous la confiance avec une équipe de développeurs qui vous voit arriver comme "quelqu'un qui va créer de la bureaucratie" ?
- Racontez-moi une fois où vous avez pris une mauvaise décision qui a impacté votre équipe. Comment vous l'avez géré après ?
- Si je demandais aux développeurs avec qui vous avez travaillé ce qu'ils pensent de vous, que me diraient-ils — les bons points et les points à améliorer ?
Les 5 red flags qui éliminent d'office
- Aucune réponse ancrée dans du concret. Si toutes les réponses sont théoriques ou génériques ("en général, je..."), le candidat manque d'expérience réelle ou cache quelque chose.
- Pas de décision difficile dans son historique. Un PM qui n'a jamais dit non à un stakeholder important n'a pas encore fait du product management.
- Le crédit, jamais l'erreur. Si le candidat prend crédit de tous les succès mais n'a jamais rien à voir avec les échecs, méfiance.
- Il parle de lui-même, pas des utilisateurs. Demandez-lui de décrire un utilisateur de son dernier produit. S'il décrit une persona PowerPoint et non une vraie personne qu'il a rencontrée, problème.
- Il n'a pas de questions. Un bon PM est curieux par nature. S'il n'a rien à vous demander sur votre produit, vos utilisateurs ou vos défis, il n'est pas assez investi.
Les 3 green flags rares qui font recruter vite
- Il a une opinion sur votre produit. Pas une critique polie — une vraie perspective, construite, avec des exemples et une logique. Ça montre qu'il a fait le travail avant l'entretien.
- Il vous dit ce qu'il ne sait pas faire. La conscience de ses propres limites est un signe de maturité. Un candidat qui prétend tout maîtriser est un signal d'alarme.
- Il vous a challengé sur une de vos hypothèses. Pas de façon agressive, mais avec curiosité et rigueur. C'est exactement ce que vous voulez dans votre équipe.
L'onboarding des 90 premiers jours
Le recrutement est la moitié du travail. L'autre moitié, c'est l'onboarding. La plupart des échecs du premier PM ne surviennent pas à cause du mauvais candidat — mais à cause d'un onboarding qui le laisse seul face à une organisation qu'il ne comprend pas encore.
Les 30 premiers jours : observer. Les 30 suivants : proposer. Les 30 derniers : livrer un premier résultat mesurable.
Ce rythme n'est pas une formule magique. C'est un signal envoyé à l'organisation : donnez-lui le temps de comprendre avant d'exiger des résultats. Un PM qui livre trop vite au début livre souvent la mauvaise chose.
Ce qui tue les premiers PM en onboarding :
- Être mis sur une roadmap à tenir dès la semaine 2 sans avoir parlé à un seul utilisateur
- N'avoir aucun accès aux données ou devoir passer par 3 personnes pour obtenir un chiffre
- Ne pas avoir de sponsor clair dans le leadership — quelqu'un qui le protège pendant qu'il apprend
- Être jugé sur sa productivité court terme alors que son vrai travail est de construire une compréhension profonde du produit et des utilisateurs
Est-ce que vous avez un leadership sponsor clairement désigné ? Est-ce que vous avez un accès data minimal opérationnel ? Est-ce que les fondateurs sont prêts à lâcher des décisions produit ? Si les trois réponses ne sont pas "oui", le PM va souffrir — peu importe son niveau.
Recruter son premier PM est une décision qui va façonner la culture produit de votre organisation pour les années à venir. Prenez le temps de bien le faire. Les 18 questions ci-dessus ne garantissent pas le bon choix — elles augmentent vos chances de ne pas faire le mauvais.
Et si vous n'êtes pas sûr de savoir évaluer les réponses : faites-vous accompagner. C'est exactement le genre de situation où une heure avec quelqu'un qui a recruté des PM peut vous éviter 6 mois d'erreur.
Vous recrutez votre premier PM ?
Je peux co-construire la fiche de poste, participer aux entretiens ou structurer l'onboarding. Une mission courte, un impact long.
Discutons-en →