Questions d'entretien Product Owner, avec réponses

Je considère le backlog comme un document vivant qui reflète les priorités actuelles, pas une liste de souhaits. J'utilise une combinaison de valeur business, d'impact utilisateur, de dépendances techniques et d'effort pour classer les éléments. Pour la priorisation courante, j'applique le WSJF (Weighted Shortest Job First) ou une matrice valeur/effort simplifiée selon la maturité de l'équipe. J'organise une session de refinement hebdomadaire avec l'équipe pour estimer, clarifier et affiner les éléments afin que le haut du backlog soit toujours prêt pour le sprint. Je maintiens aussi une distinction claire entre les dix premiers éléments (détaillés et estimés) et le reste (volontairement léger jusqu'à ce qu'ils remontent). Les parties prenantes peuvent voir le backlog mais comprennent que la position reflète la réflexion actuelle, pas un engagement sur une date.

Je rédige les user stories au format standard : "En tant que [persona], je veux [action] afin de [résultat]." Le persona doit être précis, pas un "utilisateur" générique, car des personas vagues mènent à des stories vagues. Les critères d'acceptation suivent la structure Given/When/Then : "Étant donné [contexte], quand [action], alors [résultat attendu]." J'ajoute aussi les cas négatifs (ce qui ne doit pas se produire) et les cas limites pertinents. Avant qu'une story entre en sprint, je la revois avec au moins un développeur et un designer pour confirmer qu'elle est sans ambiguïté et testable. Une story qu'on ne peut pas tester n'est pas prête. Je traite les critères d'acceptation comme un contrat entre l'équipe et les parties prenantes, pas comme une documentation rédigée après coup.

Je commence par rendre le conflit visible plutôt que de l'absorber en silence. Je réunis les parties prenantes concernées, leur montre l'ordre actuel des priorités du backlog et explique le compromis : traiter cette demande signifie repousser l'autre. J'utilise les données autant que possible pour rendre la conversation objective. Quand deux priorités sont véritablement égales, j'escalade vers le responsable de la stratégie produit avec une recommandation claire et un bref raisonnement. Je documente chaque décision de priorité et le raisonnement qui la sous-tend pour garder une trace quand les priorités changent à nouveau. L'objectif est de rendre les compromis explicites et partagés, pas d'être celui qui dit non au nom de l'entreprise sans que personne ne comprenne pourquoi.

Un directeur commercial dans mon ancienne entreprise voulait qu'on développe une fonction d'export personnalisée pour un seul prospect enterprise. Cette fonctionnalité n'était pas dans notre roadmap et aurait nécessité deux semaines de travail d'ingénierie. J'ai extrait les données sur les demandes similaires dans notre file de support et constaté que moins de 3 % des utilisateurs avaient jamais demandé une fonctionnalité comparable. J'ai préparé un document d'une page montrant le coût d'opportunité : les mêmes deux semaines pouvaient finaliser un correctif de performance qui touchait 40 % des utilisateurs actifs. J'ai présenté les deux options au directeur commercial et proposé une voie intermédiaire : un export CSV léger réalisable en trois jours qui répondrait au besoin essentiel du prospect sans le développement complet. Le directeur a accepté. Le prospect a converti. Je trouve que "non" passe mieux quand il est accompagné d'une alternative.

Nous étions en plein sprint quand un concurrent a lancé une fonctionnalité sur laquelle notre équipe commerciale perdait des deals. Je n'avais pas de données sur le nombre de deals affectés et pas le temps pour un cycle de découverte complet. J'ai mené deux appels de 30 minutes avec des commerciaux ayant récemment perdu des deals et examiné les cinq derniers rapports de deals perdus dans notre CRM. Cela m'a donné suffisamment de signal directionnel pour dé-prioriser une story de moindre valeur et insérer un spike pour cadrer la réponse concurrentielle. J'ai été clair avec l'équipe : c'était une investigation à durée limitée, pas une fonctionnalité engagée. Le spike a duré trois jours et nous avons décidé de développer une version minimale. Elle a permis de conclure deux deals le mois suivant.

Lors d'un sprint nous nous étions engagés sur cinq stories et n'en avons livré que deux. La cause principale était une dépendance à une API tierce que l'équipe supposait stable, mais qui a changé ses exigences d'authentification en plein sprint. J'ai mené une rétrospective rapide centrée sur le risque de dépendance : nous ne l'avions pas signalé lors du sprint planning car nous le jugions peu probable. Nous avons ajouté une étape de "vérification des dépendances" à notre Définition de Prêt : toute story touchant un service externe requiert confirmation de la stabilité de l'intégration avant d'entrer en sprint. Les quatre sprints suivants ont tous atteint leurs engagements. La leçon que j'en ai tirée : une Définition de Prêt incomplète est l'une des causes cachées les plus fréquentes d'échec de sprint.

Je suis deux niveaux. Au niveau livraison, je regarde la vélocité, le taux de completion des stories et si les critères d'acceptation ont été respectés sans retravail. Ce sont des indicateurs retardés de la santé de l'équipe. Au niveau résultat, je suis la métrique que le sprint devait faire bouger : taux d'activation, réduction du taux d'erreur, adoption de fonctionnalités. Je fixe un objectif pour chaque release avant qu'elle soit livrée et revois les chiffres réels à 30 jours. Si nous avons livré toutes les stories mais que la métrique n'a pas bougé, c'est un échec de découverte, pas un succès de livraison. Je partage les deux niveaux avec les parties prenantes lors d'une revue mensuelle pour que la conversation porte sur les résultats, pas seulement sur le respect des délais.

Pendant un sprint, je cherche à être disponible sans être intrusif. J'assiste au stand-up quotidien et écoute les blocages qui ont une dimension produit : exigences peu claires, cas limites manquants ou décisions de parties prenantes en attente. Je vise à répondre à ces problèmes le jour même. J'évite de modifier les stories en plein sprint sauf raison critique, car les changements de milieu de sprint détruisent la dynamique et la confiance. Si l'équipe découvre qu'une story est plus grande qu'estimée, je travaille avec le Scrum Master pour décider si on réduit le périmètre pour atteindre l'objectif du sprint ou si on signale le risque à la sprint review. Je fais aussi des points de suivi en milieu de sprint sur les stories en cours pour détecter les malentendus tôt.

Je sépare intentionnellement la planification interne de la communication externe. En interne, je travaille avec une roadmap trimestrielle "maintenant, ensuite, plus tard" qui relie chaque initiative à un objectif business. Avec les parties prenantes, je partage une version centrée sur les objectifs et les thèmes plutôt que sur des fonctionnalités ou des dates précises, car les engagements détaillés sur des fonctionnalités faits des mois à l'avance se révèlent presque toujours inexacts. Je partage des fenêtres de release spécifiques pour les éléments ayant des dépendances externes, comme une campagne commerciale ou un engagement contractuel, mais je les signale comme à haute certitude. Je tiens une revue mensuelle de la roadmap avec les parties prenantes clés pour revisiter les priorités et maintenir les attentes à jour.