Questions d'entretien Directeur produit

Je pars de la stratégie globale de l'entreprise et je détermine la place de chaque ligne de produit : lesquelles portent la croissance, lesquelles défendent une base de revenus existante, et lesquelles sont des paris encore en cours de validation. Ce cadrage change ce à quoi ressemble le succès pour chaque ligne, donc je n'applique pas les mêmes attentes de croissance à une ligne mature et à une ligne vieille de deux ans. Je mène un cycle de planification structuré deux fois par an avec chaque responsable de ligne, où nous convenons d'une stratégie d'une page couvrant le marché cible, la métrique la plus importante, et les compromis que nous choisissons explicitement de ne pas faire. Je confronte ensuite ces stratégies entre elles pour repérer les conflits de ressources avant de présenter quoi que ce soit au PDG. Dans mon poste précédent, ce processus a révélé que deux lignes construisaient discrètement une automatisation de flux de travail similaire, ce qui nous a conduits à consolider l'effort dans une capacité de plateforme partagée plutôt que de dupliquer les dépenses d'ingénierie, libérant environ quatre mois-ingénieur par trimestre.

Je dimensionne l'équipe en fonction de l'ampleur des problèmes à résoudre, pas d'un ratio fixe par rapport au nombre d'ingénieurs, même si j'utilise ce ratio comme vérification de cohérence une fois l'équipe suffisamment grande. Je regroupe les chefs de produit autour de problèmes utilisateurs ou business cohérents plutôt qu'autour de fonctionnalités individuelles, car une propriété au niveau des fonctionnalités se fragmente trop vite à mesure que le produit grandit et provoque des réorganisations constantes. Quand j'ai hérité d'une équipe de neuf chefs de produit organisée par fonctionnalités individuelles sans responsable clair au-dessus, je l'ai regroupée en trois pôles, chacun portant un parcours client complet avec un chef de produit référent responsable des résultats de son pôle, et me rapportant directement. Cela m'a donné trois personnes que je pouvais développer en futurs leaders produit plutôt que neuf rapports directs que je pouvais à peine coacher correctement. Je revois la structure environ une fois par an, en lien avec le cycle de planification stratégique, plutôt que de réorganiser de façon réactive à chaque nouvelle priorité.

J'apporte au conseil un nombre restreint d'éléments à chaque cycle : l'avancement des paris stratégiques convenus la fois précédente, les métriques de santé du portefeuille produit dans son ensemble, et une demande claire, qu'il s'agisse de budget, d'une décision de recrutement, ou d'un arbitrage pour lequel j'ai besoin d'un soutien visible. J'évite de détailler le conseil au niveau des fonctionnalités, car ce n'est pas leur niveau d'attention et cela noie la décision qu'ils doivent réellement prendre. Je suis direct sur ce qui ne fonctionne pas. Quand un membre du conseil a demandé pourquoi une initiative majeure avait six mois de retard sur son plan initial, j'ai détaillé la décision de ressources précise à l'origine du retard et ce que nous avons changé en conséquence, plutôt que de reformuler le retard en changement de périmètre après coup. Ce type de transparence est ce qui permet d'obtenir la confiance nécessaire pour faire approuver un investissement la fois suivante.

Je pars de la question de savoir à quel point la capacité est réellement différenciante commercialement pour nous, pas de son intérêt technique à construire. Si une capacité n'est pas un motif de choix pour nos clients, je privilégie l'achat ou le partenariat, sauf si le coût d'intégration et le risque fournisseur dans la durée dépassent le coût de construction, que je modélise sur trois ans et non sur la seule première année. J'implique tôt la direction de l'ingénierie et la finance dans cette décision, car le coût de construction est presque toujours sous-estimé côté produit, et le coût réel inclut la charge de maintenance continue, pas seulement l'estimation du premier sprint. Quand nous avions besoin d'une capacité de détection de fraude, j'ai mené une évaluation structurée face à trois fournisseurs et une estimation de construction interne, et j'ai choisi le partenariat malgré une équipe interne qui voulait construire, car le modèle du fournisseur était entraîné sur un jeu de données que nous ne pouvions jamais reproduire en interne, et le coût de changement en cas d'erreur était faible. Dix-huit mois plus tard, cette décision a libéré un pôle entier pour travailler sur une fonctionnalité réellement différenciante.

Nous avions une ligne de produit qui incarnait la vision originale du fondateur et conservait un petit groupe de partisans internes vocaux, mais elle stagnait sous les 5 % du chiffre d'affaires depuis deux ans tout en consommant près de 20 % de la capacité d'ingénierie. J'ai construit le dossier lentement plutôt que d'annoncer une décision : j'ai extrait l'économie unitaire, interrogé la poignée de clients qui en dépendaient encore, et modélisé ce que cette capacité d'ingénierie pourrait accomplir si elle était redirigée vers nos deux lignes de croissance. J'ai présenté l'analyse au fondateur en privé avant toute discussion plus large, car je voulais qu'il entende le raisonnement directement de moi plutôt que par une annonce générale. Nous avons convenu d'arrêter tout nouvel investissement, de continuer à soutenir les clients existants jusqu'à la fin de leurs contrats, et de redéployer l'équipe sur deux trimestres plutôt que du jour au lendemain. Ce n'était pas une décision propre ni rapide, mais le chiffre d'affaires des deux lignes ayant reçu la capacité libérée a crû de 30 % l'année suivante, et le fondateur m'a dit plus tard qu'il avait apprécié que je lui présente le dossier avant que la décision ne soit finale, pas après.

La direction commerciale voulait que nous nous engagions sur un ensemble de fonctionnalités sur mesure pour un grand prospect, en avançant que cela permettrait de conclure un contrat représentant une part significative de l'objectif du trimestre. Je m'y suis opposé car ces fonctionnalités ne servaient aucun autre segment de clientèle et auraient consommé un trimestre de la capacité de notre équipe plateforme. Plutôt que de simplement refuser, j'ai demandé aux commerciaux de m'apporter la valeur réelle du contrat et la probabilité de signature, et j'ai modélisé ce que dire oui nous coûterait par rapport à la roadmap engagée pour le reste de la base de clients. Nous avons convenu d'un sous-ensemble plus restreint de la demande, qui avait aussi une applicabilité plus large, et les commerciaux ont accepté un cycle de vente plus long sur ce compte plutôt que le développement sur mesure complet. Le contrat a été signé quatre mois plus tard que ce que les commerciaux souhaitaient initialement, mais les fonctionnalités de compromis ont été livrées à toute la base de clients et adoptées par 40 % des comptes en deux trimestres, ce que les commerciaux ont ensuite cité comme ayant aidé à conclure deux autres contrats que je n'avais pas anticipés.

J'avais une cheffe de produit analytiquement solide mais qui peinait constamment à embarquer l'engineering et le design avec elle ; ses spécifications étaient techniquement correctes, mais elle prenait des décisions unilatérales qui laissaient les deux équipes se sentir ignorées, et l'adoption de ses fonctionnalités en pâtissait. Je lui ai donné un retour direct et précis, appuyé sur des incidents réels plutôt qu'une impression générale, et nous avons convenu d'un plan de 90 jours avec des comportements concrets à changer, notamment coécrire les deux prochaines spécifications avec son ingénieur référent plutôt que seule. J'ai fait un point tous les quinze jours plutôt que d'attendre la fin du plan, car je voulais détecter tôt tout écart. Elle a réellement progressé sur le processus collaboratif, mais le schéma sous-jacent de décisions unilatérales sur les enjeux à fort risque a persisté, donc à la fin des 90 jours, j'ai décidé de la faire évoluer vers une voie de contributrice individuelle sur un périmètre produit plus restreint et moins critique plutôt que de continuer à diriger une équipe, ce qu'elle a d'abord trouvé difficile mais m'a dit plus tard avoir été la bonne décision pour sa carrière.

Je considère la capacité d'ingénierie comme un pool unique et partagé que j'alloue à l'ensemble du portefeuille, pas comme des équipes fixes que chaque responsable de ligne pourrait revendiquer comme siennes. Chaque trimestre, je mène un exercice de classement forcé entre les responsables de ligne de produit, où chacun apporte ses demandes prioritaires avec une estimation explicite des semaines d'ingénierie nécessaires et le résultat attendu si elles sont financées. Je prends ensuite moi-même la décision d'allocation plutôt que de la laisser revenir par défaut à celui qui argumente le plus fort, car c'est le vrai rôle du poste. Je protège un pourcentage fixe, généralement autour de 15 %, pour le travail de plateforme et de dette technique, quelle que soit la pression produit d'un trimestre donné, car j'ai vu ce qui se passe deux ans plus tard quand cela est déprioritisé à chaque cycle. Quand deux lignes avaient besoin des mêmes compétences d'ingénierie spécialisées l'an dernier, j'ai réuni les deux responsables et le directeur de l'ingénierie dans une même pièce pour négocier une séquence échelonnée plutôt que chacun me présentant un dossier isolé, ce qui a révélé une dépendance qu'aucun des deux n'avait signalée seul.

Je garde les deux budgets visiblement séparés plutôt que de laisser le travail de plateforme s'absorber silencieusement dans les délais des fonctionnalités, car s'il n'est pas nommé comme une ligne à part entière, il perd toujours quand une échéance se resserre. Je vise généralement une répartition approximative, ajustée selon la maturité de chaque ligne de produit, et je présente explicitement cette répartition au PDG afin que l'investissement plateforme soit une décision prise au grand jour plutôt qu'un défaut que je dois défendre après coup. Quand nous devions migrer un composant d'infrastructure central qui consommerait une vraie capacité sans production de fonctionnalité visible pendant deux trimestres, je l'ai présenté au comité de direction non pas comme un confort technique mais comme une contrainte directe sur notre capacité à tenir les engagements de roadmap de l'année suivante, avec une liste précise des fonctionnalités qui seraient nettement plus lentes ou impossibles sans cela. Ce cadrage l'a fait financer sans opposition, car j'ai relié l'investissement à des résultats commerciaux plutôt que de demander à l'entreprise de faire confiance au seul jugement de l'ingénierie.

Je suis un tableau de bord restreint au niveau du portefeuille, en complément des métriques individuelles que chaque pôle possède : la prévisibilité globale de la roadmap, c'est-à-dire le pourcentage d'initiatives engagées réellement livrées dans le trimestre prévu, la rétention des chefs de produit et le taux de promotion interne, les frictions de dépendance entre équipes remontées via une enquête trimestrielle avec l'engineering et le design, et la répartition entre travail réactif et travail stratégique dans chaque pôle. Les métriques d'un seul produit peuvent paraître saines alors que l'organisation sous-jacente s'effrite, par exemple un pôle qui atteint ses chiffres en travaillant à un rythme intenable ou en sautant la phase de discovery, et le tableau de bord est conçu pour détecter cela avant que cela ne se traduise par de l'attrition ou un chef de produit référent épuisé. Quand la prévisibilité de la roadmap a chuté fortement deux trimestres de suite, j'ai creusé et constaté que nous sous-estimions systématiquement le travail de dépendance entre pôles, ce qui m'a conduit à ajouter une étape de cartographie des dépendances à la planification, corrigeant le schéma en deux cycles.