Onboarder un PM en 90 jours :
le plan à écrire avant de signer

Chaque fois qu'une entreprise recrute son premier Product Manager, elle met des semaines à trouver le bon profil, mène cinq entretiens, négocie le package, puis le laisse seul le premier lundi avec un accès Slack et un « bon courage ». Le recrutement a été soigné ; l'arrivée, improvisée.

C'est l'erreur la plus coûteuse, parce qu'elle est invisible. Un mauvais recrutement se voit en un mois. Un bon recrutement saboté par une mauvaise intégration met six mois à se voir, et quand il se voit, tout le monde conclut qu'on s'est trompé de personne.

On ne s'est pas trompé de personne. On a sauté le plan.

J'ai déjà décrit comment recruter ce premier PM : le profil, les dix-huit questions, les signaux qui font recruter vite. Mais le recrutement n'est que la moitié du travail. L'autre moitié est un plan de quatre-vingt-dix jours que vous devriez écrire avant de signer, pas improviser une fois la personne arrivée. Voici celui que j'utilise.

1. Pourquoi l'onboarding d'un PM se joue-t-il avant le premier jour ?

Parce que la confiance dont un PM a besoin se gagne ou se perd dans ses premières semaines, sur la base de signaux minuscules. Un développeur qu'on intègre mal perd du temps ; un PM qu'on intègre mal perd sa légitimité. La différence tient à la nature du rôle : un PM n'a presque aucune autorité formelle. Il avance parce que l'organisation lui fait confiance pour arbitrer, pas parce qu'un organigramme lui en donne le droit.

Le piège, c'est que ces signaux sont envoyés par l'organisation bien avant que le PM n'arrive. Si personne n'a décidé à qui il reporte, quels sont les trois sujets qui comptent vraiment, et qui va le protéger le temps qu'il apprenne, alors aucune qualité personnelle ne compensera ce vide. Il passera ses premières semaines à chercher sa place au lieu de comprendre le produit.

D'où la règle que j'applique : l'onboarding d'un PM n'est pas un document qu'on rédige la première semaine, c'est une décision qu'on prend avant de faire l'offre. Si vous ne savez pas écrire le plan des quatre-vingt-dix premiers jours, c'est que vous n'êtes pas encore prêt à recruter.

Un mauvais recrutement se voit en un mois. Un bon recrutement mal intégré met six mois à se voir, et on l'impute toujours à la mauvaise personne.

2. Les trois jalons : observer, proposer, livrer

Le plan tient en une phrase, et je la garde volontairement simple pour qu'elle survive au contact du réel : les trente premiers jours pour observer, les trente suivants pour proposer, les trente derniers pour livrer un premier résultat mesurable.

Ce découpage n'est pas une formule magique, c'est un contrat de patience entre le PM et l'organisation. Il dit au PM : tu as le droit de ne rien livrer pendant un mois, ton travail est de comprendre. Et il dit à l'organisation : ne lui demande pas de résultats avant qu'il ait compris, sinon tu l'obliges à deviner.

La plupart des échecs viennent d'une inversion de ce rythme. On met le PM sur une roadmap à tenir dès la deuxième semaine, avant qu'il ait parlé à un seul utilisateur. Il livre alors vite, et il livre la mauvaise chose, parce qu'un PM qui produit avant d'avoir compris ne fait que donner une forme professionnelle aux hypothèses de ceux qui l'ont recruté.

Les trois sections qui suivent déroulent chaque jalon. Mais aucun des trois ne tient si le travail d'avant le premier jour n'a pas été fait.

3. Avant le premier jour : les quatre accès qui décident de tout

Il y a quatre choses à verrouiller avant que le PM ne pousse la porte. Aucune ne dépend de lui ; toutes dépendent de vous. Ce sont elles qui font qu'un bon PM réussit ou s'épuise.

• Un sponsor nommé dans le leadership. Quelqu'un, idéalement un fondateur ou un dirigeant, qui a dit oui à ce recrutement et qui va protéger le PM pendant qu'il apprend. Sans sponsor, le premier conflit de priorisation se tranche contre le PM, et sa légitimité s'effondre.
• Un accès aux données opérationnel dès le premier jour. Pas « on te donnera les accès plus tard » : les tableaux de bord, l'analytique, les retours clients, le support. Un PM qui doit passer par trois personnes pour obtenir un chiffre ne décidera jamais sur des faits.
• Un périmètre écrit, même imparfait. Sur quoi il a la main, sur quoi il n'en a pas, et qui tranche quand ce n'est pas clair. Un périmètre flou n'est pas une liberté offerte au PM, c'est une zone de friction quotidienne avec tout le reste de l'équipe.
• Un chemin direct vers les utilisateurs. Le nom de cinq clients qu'il peut appeler dès la première semaine, sans demander la permission. C'est la ressource la plus rare et la plus précieuse, et c'est presque toujours celle qu'on oublie de préparer.

Si vous ne pouvez pas réunir ces quatre accès, le problème n'est pas le PM : c'est que l'organisation n'est pas prête à en accueillir un. Mieux vaut le savoir avant de signer qu'au bout de trois mois.

4. Jours 1 à 30 : observer sans rien promettre

Le premier mois a un seul objectif, et il est contre-intuitif pour tout le monde : comprendre, sans livrer. C'est la phase la plus difficile à tenir, parce que le PM veut prouver sa valeur et que l'organisation veut un retour sur son investissement. Les deux ont tort au même moment.

Ce que fait un bon PM pendant ces trente jours ressemble beaucoup à un audit produit mené de l'intérieur : il écoute, il cartographie, il note les écarts entre ce que les gens disent et ce que les données montrent. Il parle aux développeurs, au support, aux ventes, et surtout aux utilisateurs. Il ne propose rien encore, parce qu'une proposition faite trop tôt n'est qu'une opinion déguisée.

Quelques règles non négociables pour cette phase :

• Parler à dix utilisateurs avant de toucher au backlog. Pas des personas, de vraies personnes au téléphone. C'est la seule manière de ne pas hériter des certitudes de l'équipe en place.
• Écrire ce qu'on observe, pas ce qu'on compte faire. Un carnet d'étonnement vaut mieux qu'une roadmap prématurée : il garde la trace du regard neuf, qui disparaît en quelques semaines.
• Résister à la première demande « urgente ». Il y en aura une dès la deuxième semaine. Y céder, c'est accepter d'être un exécutant ; la décliner proprement, c'est poser qu'on arbitre sur des faits.

Le rôle de l'organisation ici est simple : tenir bon. Ne pas juger le PM sur sa productivité à court terme alors que son vrai travail est de construire une compréhension que personne d'autre n'a encore.

5. Jours 31 à 60 : proposer, et assumer les arbitrages

Au deuxième mois, le PM a assez compris pour proposer. C'est le moment où il passe d'observateur à acteur, et où sa première vraie compétence devient visible : la priorisation. Non pas la capacité à produire une longue liste, mais celle de défendre un petit nombre de paris et de refuser le reste sans se faire d'ennemis.

Ce que je demande à un PM à ce stade n'est pas une roadmap sur douze mois. C'est une note courte, deux pages au plus, qui dit : voici ce que j'ai compris, voici les trois problèmes qui méritent qu'on s'y attelle, voici celui que je propose de traiter en premier et pourquoi. Cette note est le premier livrable réel du PM, et c'est elle qui transforme son observation en décision.

C'est aussi la phase où se joue sa relation avec les développeurs. Un PM qui arrive en imposant des process se grille ; un PM qui arrive en demandant « qu'est-ce qui vous empêche d'avancer aujourd'hui ? » et qui règle un irritant concret en quinze jours gagne une confiance qui vaut tous les organigrammes. La légitimité d'un PM ne se décrète pas, elle se constate.

6. Jours 61 à 90 : livrer un premier résultat mesurable

Le troisième mois sert à prouver, par un fait et non par un discours, que le PM change quelque chose. Le piège ici est symétrique du premier : après deux mois de patience, la tentation est de viser gros pour marquer les esprits. C'est une erreur. Le premier résultat doit être petit, choisi pour être atteignable en trente jours, et mesurable sans ambiguïté.

Petit ne veut pas dire sans importance. Un bon premier résultat a trois propriétés : il résout un problème que les utilisateurs ressentent vraiment, il est livrable dans la fenêtre, et son effet se voit dans un chiffre que tout le monde comprend. Réduire les allers-retours sur une étape d'inscription, raccourcir un parcours qui faisait fuir les clients, débloquer une fonctionnalité qui attendait depuis des mois faute d'arbitrage : peu importe, pourvu que ce soit net.

Ce premier résultat n'a pas vraiment pour but d'améliorer le produit, même s'il le fait. Son but est d'installer une boucle : le PM observe, propose, livre, mesure, puis recommence. Une fois cette boucle visible, l'organisation cesse de se demander si le recrutement était le bon. Elle a la preuve sous les yeux.

7. Les erreurs qui tuent un bon PM, et comment les éviter

La plupart des intégrations ratées ne le sont pas à cause du PM. Elles le sont à cause de schémas d'organisation qui reviennent si souvent qu'on peut les lister. Les voici, avec leur antidote.

• Le mettre sur une roadmap dès la semaine deux. C'est exiger une décision avant la compréhension. Antidote : protéger la phase d'observation comme un livrable à part entière.
• Le laisser sans sponsor. Au premier arbitrage contesté, un PM sans protecteur perd, et une défaite précoce est très difficile à rattraper. Antidote : nommer le sponsor avant l'arrivée, pas après le premier conflit.
• Le juger sur son activité. Compter ses tickets ou ses réunions, c'est mesurer le bruit, pas le travail. Antidote : convenir dès le départ que le résultat des quatre-vingt-dix jours est une boucle qui tourne, pas un volume produit.
• Confondre un PM avec un chef de projet. Si on attend de lui qu'il exécute des décisions prises ailleurs, on a recruté un exécutant et gaspillé un PM. Antidote : lui laisser le « quoi » et le « pourquoi », pas seulement le « quand ».
• Ne pas préparer le retrait de celui qui tenait le rôle avant lui. Souvent un fondateur portait la casquette produit. S'il ne lâche rien, le PM reste un assistant. Antidote : décider explicitement ce que le fondateur délègue, et s'y tenir.

Chacune de ces erreurs a la même racine : traiter l'onboarding comme une formalité administrative plutôt que comme la seconde moitié d'une décision de recrutement. Le plan de quatre-vingt-dix jours est précisément ce qui empêche d'y retomber.

Ce qu'il faut vraiment retenir

Recruter un PM et l'intégrer sont deux moitiés de la même décision. La première se prépare avec des entretiens ; la seconde, avec un plan écrit avant de signer. Sans ce plan, même le bon candidat échoue, et l'organisation en tire la mauvaise leçon.

• Écrivez le plan avant l'offre : si vous ne savez pas décrire les quatre-vingt-dix premiers jours, vous n'êtes pas prêt à recruter.
• Verrouillez les quatre accès : un sponsor nommé, des données dès le premier jour, un périmètre écrit, un chemin direct vers les utilisateurs.
• Tenez le rythme observer, proposer, livrer : trente jours pour comprendre, trente pour proposer, trente pour un premier résultat mesurable.
• Protégez la phase d'observation : un PM qui livre avant d'avoir compris livre vite la mauvaise chose.
• Visez petit pour le premier résultat : le but n'est pas l'exploit, c'est d'installer une boucle visible.

Un bon onboarding ne rend pas bon un PM médiocre. Mais un mauvais onboarding rend un bon PM invisible, puis suspect, puis partant. Le plan des quatre-vingt-dix jours coûte une après-midi à écrire. Ne pas l'écrire coûte six mois et un recrutement.

À lire aussi

• Recruter son premier PM : la grille de 18 questions à poser, la première moitié de la décision : comment choisir la personne que ce plan va intégrer.
• Pourquoi votre audit produit ne change rien (et comment y remédier), parce que les trente premiers jours d'un PM sont un audit mené de l'intérieur.
• L'art de dire non à une demande de fonctionnalité, la méthode à transmettre au PM avant qu'il ait à assumer ses premiers arbitrages.

Dans les organisations que j'accompagne, l'arrivée d'un PM se passe presque toujours bien quand le plan existe, et presque toujours mal quand on l'improvise. Ce n'est pas une question de talent individuel, c'est une question de préparation collective. Co-construire ce plan, cadrer les quatre accès et sécuriser les quatre-vingt-dix premiers jours est typiquement une mission de conseil courte qui évite une erreur longue, et vous pouvez lire ce qu'en disent les équipes que j'ai accompagnées.