Un product manager tient trois choses à la fois. Il comprend les utilisateurs par la discovery, fixe avec la direction des objectifs mesurables, et travaille avec le design et les développeurs pour livrer ce qui fera bouger ces objectifs. Selon l'organisation, il a ou non un product owner à côté de lui. Les intitulés varient aussi : chef de produit digital, product lead, senior product manager. Les offres récentes insistent sur la discovery continue, la mesure de l'impact après le lancement et l'autonomie dans les données.
Le métier se raconte facilement. Beaucoup de candidats citent les bons cadres (OKR, RICE, North Star) et décrivent une roadmap réussie. Ce qui fait la différence, ce sont les détails d'une décision : quel problème, quelle preuve, quel indicateur, quel résultat, et ce qui a été arrêté. Un PM confirmé a déjà retiré une fonctionnalité, défendu un non devant la direction et lu un test qui ne donnait rien.
Les questions portent sur ses derniers produits, avec des chiffres. Le PDF contient 30 questions sur six axes, un cas de 20 minutes sur une application de prise de rendez-vous et une grille de 1 à 4.
Les méthodes et outils qu'un product manager cite
Discovery produit
L'ensemble des pratiques qui servent à comprendre les utilisateurs et à valider une idée avant de la développer : entretiens, observation, prototypes, tests d'utilisabilité. Pratiquée en continu, elle occupe une part de chaque semaine et pas seulement le début d'un projet.
Opportunity solution tree
Une façon de relier un objectif mesurable aux problèmes observés chez les utilisateurs, puis aux solutions et aux tests qui les valident. Popularisée par Teresa Torres. Elle aide à ne pas s'attacher à la première idée.
North Star et indicateurs produit
Un indicateur principal qui traduit la valeur reçue par les utilisateurs, décliné en indicateurs sur lesquels l'équipe agit : activation, fréquence d'usage, rétention par cohorte, conversion. Des indicateurs de garde évitent d'améliorer un chiffre en dégradant un autre.
OKR
Objectives and key results : un objectif qualitatif et quelques résultats mesurables par trimestre. Beaucoup d'équipes produit les utilisent pour relier leur travail à la stratégie. Des résultats formulés en fonctionnalités livrées sont un signe de mauvaise pratique.
Priorisation (RICE, coût du retard)
Des méthodes pour comparer des sujets différents. RICE note la portée, l'impact, la confiance et l'effort. Le coût du retard estime ce que l'on perd à attendre. Elles servent à discuter, et ne remplacent pas le jugement.
Test A/B et feature flags
Le test A/B compare deux versions sur des groupes d'utilisateurs tirés au hasard. Les feature flags permettent d'ouvrir une fonctionnalité progressivement et de la couper vite. Un PM sait préparer un test et accepter qu'il ne montre rien.
Analytics produit et SQL
Amplitude, Mixpanel ou un outil équivalent pour suivre les parcours, les entonnoirs et les cohortes, et un peu de SQL pour répondre seul à une question simple. Le plan de marquage, défini avec les développeurs et l'analyste, conditionne la fiabilité de tout le reste.
PRD et outils de cadrage
Le product requirements document décrit le problème, l'objectif, le périmètre et les questions ouvertes avant le démarrage d'un sujet. Il vit dans Notion, Confluence ou un outil équivalent, à côté des maquettes Figma et du backlog Jira ou Linear.
Le poste change avec le produit et l'organisation. Chez un éditeur SaaS B2B, le PM parle beaucoup aux clients et aux ventes, avec peu de trafic pour tester. Sur un produit grand public, il s'appuie davantage sur les données et les tests A/B. Dans une grande organisation, il travaille souvent avec un product owner et passe plus de temps à aligner les parties prenantes. Les cabinets de conseil en produit placent aussi des PM en mission. Le niveau se lit à la taille des décisions : un junior porte une fonctionnalité, un senior un domaine ou un objectif, un lead plusieurs équipes et leur cohérence.
Les compétences attendues d'un product manager
- Discovery et compréhension des problèmes
- Stratégie et roadmap par objectifs
- Choix et lecture des indicateurs
- Expérimentation et décision
- Cadrage avec design et engineering
- Lancement et parties prenantes
Cinq questions pour un entretien de product manager
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un gros client demande une fonctionnalité précise et menace de partir. Comment traitez-vous la demande ?
Une bonne réponseLa personne cherche le problème derrière la solution demandée : ce que le client essaie de faire, à quelle fréquence, ce que cela lui coûte aujourd'hui. Elle vérifie si d'autres clients ont le même problème (tickets, entretiens, données d'usage) et chiffre l'enjeu commercial avec les ventes. Elle peut proposer une autre réponse que la fonctionnalité demandée, ou un engagement limité, et dit clairement au client ce qui sera fait et quand.
Signal d'alertePromettre la fonctionnalité telle quelle pour garder le client, ou la refuser sans chercher le problème. Une réponse qui ne parle jamais des autres clients.
Question 2 · junior à confirmé
Comment préparez-vous et menez-vous un entretien utilisateur de discovery ?
Une bonne réponseUn objectif d'apprentissage écrit, un recrutement de participants qui correspondent au segment visé, des questions ouvertes sur des situations passées (« racontez la dernière fois que… ») et pas sur des intentions futures. Pas de démonstration de la solution au début. Des notes partagées avec le designer et un développeur présents si possible, puis une synthèse par problème observé et par fréquence.
Signal d'alerte« Je leur demande s'ils utiliseraient la fonctionnalité. » Des questions fermées, une démonstration en ouverture, ou des entretiens menés seul et jamais partagés.
Question 3 · senior
Le comité de direction vous demande la roadmap des douze prochains mois. Que présentez-vous ?
Une bonne réponseDes objectifs et des problèmes à résoudre plutôt qu'une liste de fonctionnalités datées, organisés par horizon (en cours, prochain, plus tard), avec le lien vers les objectifs de l'entreprise et les indicateurs attendus. Les engagements fermes sont distingués des pistes. La personne explique ce qui a été écarté et pourquoi, et comment la roadmap sera revue.
Signal d'alerteUn diagramme de Gantt de fonctionnalités datées sur douze mois, ou au contraire aucune visibilité sous prétexte d'agilité.
Question 4 · confirmé
Quel indicateur principal choisissez-vous pour votre produit, et comment le reliez-vous au travail de l'équipe ?
Une bonne réponseUn indicateur qui traduit la valeur reçue par l'utilisateur et anticipe le revenu (par exemple le nombre de comptes qui accomplissent l'action principale chaque semaine), puis des indicateurs intermédiaires sur lesquels l'équipe peut agir à court terme : activation, fréquence d'usage, rétention par cohorte. La personne ajoute des indicateurs de garde pour ne pas dégrader autre chose.
Signal d'alerteLe chiffre d'affaires ou le nombre d'inscrits comme seul indicateur, ou une liste de vingt indicateurs sans hiérarchie.
Question 5 · confirmé
Un test A/B sur une nouvelle page d'inscription ne montre aucune différence significative après quatre semaines. L'équipe veut la garder quand même. Que décidez-vous ?
Une bonne réponseLa personne vérifie d'abord que le test pouvait détecter l'effet visé (taille d'échantillon, effet minimal fixé avant le lancement) et que les indicateurs de garde ne se sont pas dégradés. Sans différence et sans dégradation, garder la nouvelle version peut se défendre pour d'autres raisons (maintenance, cohérence), à condition de le dire. Elle ne présente pas le résultat comme un gain.
Signal d'alerteProlonger le test jusqu'à ce qu'il devienne significatif, ou annoncer une amélioration que les données ne montrent pas.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Product manager : les questions fréquentes
Product manager ou product owner : deux personnes ou une seule ?
Cela dépend de la taille et du rythme. Dans beaucoup d'éditeurs, une seule personne fait les deux, de la discovery au backlog. Dans les grandes organisations, le PM porte la stratégie et les objectifs, le PO la traduction en backlog et le travail quotidien avec l'équipe. Pour un PM qui fera aussi le travail de PO, l'entretien ajoute un exercice de découpage et de rédaction de stories.
Un product manager doit-il savoir coder ou écrire du SQL ?
Coder n'est pas demandé sur la plupart des postes, sauf pour un PM technique ou plateforme. Lire des données, oui : explorer seul un outil d'analytics produit et écrire une requête SQL simple évite d'attendre un analyste pour chaque question. La personne explique comment elle a vérifié elle-même l'impact de sa dernière fonctionnalité, et quelle requête ou quel graphique elle a utilisé.
Quel cas pratique pour un candidat product manager ?
Un cas proche du produit, à traiter en direct en vingt à trente minutes : un objectif, quelques données, un problème remonté par les clients. On regarde s'il pose des questions avant de proposer des solutions, s'il choisit un indicateur et s'il dit ce qu'il ne ferait pas. Un devoir de plusieurs jours à la maison pénalise les candidats en poste sans rien apprendre d'utile en retour.
Comment vérifier qu'un product manager sait lire des chiffres ?
Pas au sens d'un exercice de code. Un test technique utile pour ce poste porte sur les données : un tableau de cohortes à lire, un résultat de test A/B à interpréter, un indicateur qui chute à expliquer. Dix minutes suffisent pour voir si la personne raisonne sur des chiffres ou se contente de commenter un graphique.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
