Questions d'entretien Chef de produit

Je m'appuie sur une combinaison de frameworks selon le contexte. Pour les produits en phase de démarrage, j'utilise souvent RICE (Portée, Impact, Confiance, Effort) pour créer un système de notation partagé. Pour les produits plus matures, j'ajoute une couche d'alignement stratégique : est-ce que cette fonctionnalité fait avancer une métrique clé ? J'organise aussi des syncs réguliers avec les parties prenantes pour faire remonter les conflits de priorité tôt, et je maintiens une liste documentée des sujets reportés. L'objectif n'est pas seulement de choisir l'élément le mieux noté, mais de séquencer le travail pour que les fondations débloquent la valeur future. Je réévalue les priorités à chaque sprint.

Je commence par m'aligner sur le résultat que le produit doit produire, pas seulement les livrables. Je travaille avec les parties prenantes pour convenir d'une métrique principale et deux ou trois métriques secondaires avant de construire quoi que ce soit. Pour une fonctionnalité de croissance, cela pourrait être le taux d'activation et la rétention à 30 jours. Pour une fonctionnalité de monétisation, le taux de conversion et le revenu moyen par utilisateur. Je définis aussi une contre-métrique pour détecter les effets secondaires non souhaités : par exemple, surveiller le volume de tickets support quand on simplifie l'onboarding. Après le lancement, je réalise une revue structurée à 30 et 90 jours et partage les apprentissages avec l'équipe.

Je vois mon rôle comme celui de créer les conditions pour que les ingénieurs et les designers fassent leur meilleur travail. J'implique les deux disciplines le plus tôt possible, idéalement dès la phase de définition du problème. Avec les designers, je me concentre sur une compréhension partagée du problème utilisateur avant d'aborder les solutions. Avec les ingénieurs, je privilégie la transparence sur le "pourquoi" de chaque initiative et je sollicite activement leur avis sur les compromis de périmètre. Je tiens un sync hebdomadaire pour lever les blocages et une rétrospective bimensuelle pour améliorer notre processus. Je donne aussi aux ingénieurs une visibilité sur les retours utilisateurs et les métriques.

L'IA fait désormais partie de plusieurs étapes de mon travail. Pour la recherche utilisateur, je l'utilise pour analyser les transcriptions d'interviews à grande échelle : je peux identifier des patterns sur dix sessions en quelques minutes, ce qui aurait pris des heures manuellement. Pour la rédaction de specs, je fournis des points clés à un modèle et j'obtiens un premier jet de PRD structuré que j'édite ensuite en profondeur. Cela m'amène à 40% du chemin en quelques minutes. Pour la communication avec les parties prenantes, j'utilise l'IA pour reformuler des concepts techniques pour des interlocuteurs non techniques et pour vérifier si ma formulation d'un problème est claire. Les domaines où je ne me fie pas encore à l'IA sont les décisions de priorisation et les arbitrages finaux : la question de ce qu'il faut construire et pourquoi nécessite le contexte complet du business, de l'équipe et des utilisateurs, que le modèle n'a pas. Je traite l'IA comme un accélérateur pour le travail structurel, pas comme un substitut au jugement.

Dans mon entreprise précédente, nous devions décider si nous devions refondre notre flux d'onboarding. Les données montraient un fort taux d'abandon à l'étape trois, mais nous ne savions pas pourquoi. Nous avions deux semaines avant un gel de l'engineering. J'ai réalisé cinq interviews utilisateurs rapides et un test d'utilisabilité non modéré pour obtenir des insights directionnels. Les interviews ont révélé que les utilisateurs étaient confus par une demande de permission non expliquée. Plutôt qu'une refonte complète, j'ai proposé une correction ciblée : ajouter un écran explicatif avant la demande de permission. Nous l'avons livré en trois jours. L'abandon à l'étape trois a baissé de 22 % en deux semaines.

Notre PDG voulait ajouter une fonctionnalité de partage social, sur la base des retours de deux clients importants. J'ai analysé nos données et constaté que moins de 4 % des utilisateurs avaient utilisé notre fonction de partage existante. J'ai préparé un court document montrant les données d'usage, le coût engineering estimé et trois alternatives d'utilisation de cette capacité qui répondaient mieux à notre objectif de rétention. J'ai présenté cela comme une question de priorisation, pas un désaccord, et proposé de mener une expérimentation légère pour valider la demande. Le PDG a accepté de reporter la fonctionnalité et approuvé un spike de deux semaines pour tester un mécanisme de partage plus simple.

J'ai piloté un module de reporting B2B construit sur trois mois. Le lancement a enregistré une faible adoption : moins de 10 % du segment cible l'a utilisé dans les 60 premiers jours. Dans le post-mortem, nous avons identifié deux causes principales. D'abord, nous avions validé le problème avec les acheteurs mais pas avec les utilisateurs finaux, qui avaient des workflows très différents. Ensuite, nous avions sous-estimé le coût de migration depuis les outils tableur déjà en place. J'ai appris à distinguer la validation acheteur de la validation utilisateur et introduit le framework "jobs to be done" dans notre discovery, ce qui a amélioré les taux d'adoption des lancements suivants.

Je traite les données comme une entrée parmi d'autres, aux côtés de la recherche qualitative. Ma boîte à outils inclut l'analytics événementiel (Mixpanel, Amplitude), SQL pour les requêtes ad hoc, et l'A/B testing. Avant toute expérience, j'écris une hypothèse sous la forme "si nous faisons X, nous anticipons Y parce que Z", je définis la métrique principale et l'effet minimum détectable, et je calcule la taille d'échantillon nécessaire. Après l'expérience, j'analyse les résultats complets incluant les métriques secondaires et les ventilations par segment. Je distingue soigneusement la significativité statistique de la significativité pratique : un gain de 2 % qui ne justifie pas le coût de maintenance n'est pas une victoire.

Je construis les roadmaps autour des résultats, pas des fonctionnalités. Je pars de la stratégie de l'entreprise et des OKRs du trimestre, puis j'identifie les deux ou trois problèmes dont la résolution ferait avancer ces métriques. Chaque élément correspond à une formulation de problème, une hypothèse et une métrique de succès. J'utilise une structure "maintenant, prochainement, plus tard" pour garder l'équipe concentrée sur le court terme tout en maintenant la visibilité sur la direction. Je partage une version de la roadmap avec les parties prenantes clés chaque mois et la mets à jour dès que les priorités stratégiques évoluent.

Je commence par le problème, pas la solution. La première section couvre le problème utilisateur, les preuves qui l'étayent et le business case. Ensuite, je définis les objectifs et les non-objectifs explicites : cette dernière section est souvent la plus utile car elle prévient le scope creep. J'inclus des user stories au format "en tant que [utilisateur], je veux [action] afin de [résultat]" et des critères d'acceptation testables. J'ajoute une section sur les questions ouvertes avec des responsables et des échéances, puis une section sur les risques techniques, UX et business. Je fais relire le PRD par l'engineering et le design avant de le finaliser.