Product Owner

Scrum est un cadre de travail agile permettant aux équipes de développer des produits et de les adapter progressivement. Dans ce cadre, le Product Owner (PO) est responsable de maximiser la valeur du produit issu du travail de l’équipe. Il porte l’objectif produit et répond de la bonne gestion du Product Backlog, la liste ordonnée du travail à réaliser. Son rôle consiste à rendre les priorités compréhensibles et à relier les développements aux besoins des utilisateurs.

Cette responsabilité dépasse la rédaction de demandes. Le PO doit expliquer pourquoi une fonctionnalité mérite d’être développée et comment elle contribue à l’objectif poursuivi. Il échange avec les parties prenantes, clarifie les éléments du backlog et rend leur ordre visible. Dans les pratiques produit décrites par le référentiel EQL, il s’appuie aussi sur sa connaissance du métier et les retours utilisateurs pour faire évoluer ses choix.

Les modalités d’exercice dépendent de l’organisation. Avant un recrutement, précisez qui définit les objectifs du produit, quelles décisions le PO peut prendre et à qui il rend compte. Son intitulé ne suffit pas à connaître son autonomie ni son rattachement. Une responsabilité de priorisation doit correspondre à une possibilité réelle de décider entre des demandes concurrentes.

Product Owner, Product Manager et développeurs : qui fait quoi ?

Dans le cadre Scrum, les responsabilités se répartissent ainsi :

• Le Product Owner porte l’objectif produit et définit l’ordre du backlog. Il rend les besoins et les choix accessibles à l’équipe.
• Les développeurs choisissent le travail du Sprint en échangeant avec le PO. Ils sont responsables de son estimation et de la manière de le réaliser.

Le Product Manager travaille sur l’orientation et les priorités du produit. Ce rôle n’est pas défini par ce cadre de travail. Si les deux rôles coexistent, clarifiez leur partage de décisions sans présumer que le PO se limite à l’exécution.

Le PO influence donc les choix par la compréhension du besoin et des compromis. Cette responsabilité ne lui confère pas, à elle seule, une autorité hiérarchique sur les développeurs.

L’enjeu est de consacrer le travail de l’équipe à des besoins qui comptent pour les utilisateurs et pour le produit. Un backlog peut être détaillé sans rendre ce choix compréhensible. Si les raisons d’une priorité restent implicites, les parties prenantes disposent de peu d’éléments pour discuter une demande ou comprendre son report. Ce manque de transparence peut conduire à des décisions qui réduisent la valeur du produit.

Pour le dirigeant, une question structurante est donc celle du pouvoir de décision accordé au PO. Demander à une personne de répondre des priorités tout en laissant chaque interlocuteur les modifier séparément crée une contradiction à résoudre. Le cadrage du poste doit préciser comment les demandes arrivent, comment elles sont discutées et qui tranche leur ordre. Selon le Scrum Guide, le document de référence qui définit ce cadre de travail, la responsabilité de Product Owner revient à une seule personne, même si elle représente les besoins de nombreux interlocuteurs.

Un autre enjeu concerne la qualité de la compréhension du problème. Une demande formulée comme une solution peut encore nécessiter des échanges sur les utilisateurs concernés et le résultat attendu. L’analyse des parcours et les retours d’usage aident à réexaminer ce que l’équipe doit développer. La valeur attendue reste une hypothèse à confronter aux résultats, sans indicateur universel applicable à tous les produits.

Exemple fictif : une équipe hésite entre ajouter un filtre et simplifier un formulaire. Le PO commence par préciser les difficultés rencontrées par les utilisateurs. Il discute ensuite de la valeur attendue et des contraintes avec l’équipe, puis explique la priorité retenue. Les retours après livraison peuvent conduire à revoir ce choix.

Enfin, la revue du travail réalisé doit permettre des adaptations. La revue de Sprint, appelée Sprint Review, réunit l’équipe et les parties prenantes pour examiner les résultats et les adaptations à apporter au produit. La réduire à une démonstration prive cette séance de sa fonction de travail collectif sur la suite du produit.

• Formuler et communiquer l’objectif produit pour donner un sens commun aux décisions de l’équipe.
• Comprendre les besoins des utilisateurs et préciser les résultats attendus avec les parties prenantes.
• Clarifier les éléments du backlog afin de rendre le travail envisagé compréhensible.
• Ordonner les fonctionnalités selon leur valeur attendue et le contexte du produit.
• Rendre le backlog visible et expliquer les priorités aux interlocuteurs concernés.
• Discuter les compromis avec les développeurs en respectant leur responsabilité sur les estimations et la réalisation.
• Analyser les retours utilisateurs pour ajuster les choix produit.
• Contribuer à l’examen des résultats en Sprint Review et aux adaptations du backlog.

Plusieurs parcours peuvent préparer au métier de Product Owner. L’analyse métier et l’assistance à maîtrise d’ouvrage apportent des acquis utiles pour comprendre un besoin, formaliser une demande et dialoguer avec les interlocuteurs d’un projet. Le passage vers le rôle de PO suppose aussi d’acquérir les principes agiles et leur mise en œuvre. Si le poste s’exerce dans une équipe qui utilise Scrum, une expérience en AMOA ne suffit pas, à elle seule, à démontrer la maîtrise des responsabilités du Product Owner dans ce cadre.

Les formations en gestion de produit constituent une autre voie. Le référentiel Product manager d’OpenClassrooms vise notamment les emplois de Product Owner et utilise des projets et des soutenances pour évaluer les acquis. Ces travaux peuvent montrer comment un candidat analyse un problème et explique une décision. Ils ne doivent pas être confondus avec une responsabilité déjà exercée dans une organisation.

Un parcours d’ingénieur peut également apporter une compréhension du logiciel, de la gestion de projet et des indicateurs. Le travail pluridisciplinaire aide à dialoguer avec les développeurs et les designers. Pour le recrutement, recherchez une culture technique adaptée au produit, sans faire d’un passé de développeur une condition automatique.

L’expérience attendue gagne à être exprimée en responsabilités. Distinguez un candidat qui a clarifié des demandes avec un accompagnement d’un candidat qui a assumé des arbitrages et révisé ses priorités après des retours utilisateurs. La difficulté du produit, les interlocuteurs et l’autonomie prévue doivent guider ce choix. Ces parcours sont des voies possibles vers le métier, sans constituer des prérequis obligatoires.

GetPro s’appuie sur une grille de critères, avec une modalité d’évaluation définie pour chacun. Les entretiens approfondissent les compétences par des questions ouvertes et des exemples concrets. Les prises de références permettent de compléter les observations recueillies sur les compétences et les points à approfondir.

Les étapes ci-dessous sont des conseils pour appliquer ce cadre à un poste de Product Owner. Adaptez-les au produit, à l’autonomie attendue et aux interlocuteurs du futur Product Owner.

1. Définissez une grille liée aux décisions du poste

Retenez des critères observables : compréhension des utilisateurs, clarté du backlog, priorisation, analyse des retours et communication des choix. Précisez les décisions que le candidat devra prendre seul et celles pour lesquelles il sera accompagné.

Associez chaque critère à une situation réelle du poste. Si les demandes viennent de plusieurs services, donnez davantage de place à l’explication des compromis. Si le produit impose des contraintes techniques, prévoyez un échange avec les développeurs.

Un profil pertinent relie ses compétences au travail attendu. Soyez prudent face à une présentation qui accumule des noms de méthodes sans expliquer leur utilité dans ce contexte.

2. Faites raconter une décision passée

Demandez au candidat de décrire une priorité qu’il a défendue, les informations disponibles et les autres options envisagées. Faites préciser sa contribution personnelle et les personnes associées à la décision.

Examinez, lorsque le partage est possible, un exemple anonymisé de backlog ou de demande formalisée. Cherchez le lien entre le besoin utilisateur, le travail retenu et le résultat attendu.

Invitez ensuite le candidat à expliquer les retours obtenus et les changements qu’ils ont entraînés. Une réponse solide distingue ce qui était attendu de ce qui a été observé. Une alerte apparaît si la seule réussite citée est la livraison, sans explication de son utilité.

3. Proposez un cas de priorisation proche du produit

Exemple fictif : soumettez deux demandes concurrentes concernant un formulaire et un filtre de recherche, avec des informations incomplètes sur leurs utilisateurs.

Demandez au candidat quelles précisions il chercherait avant de décider. Invitez-le à proposer un ordre de travail et à expliquer ce qui pourrait lui faire changer d’avis.

Poursuivez en faisant clarifier une demande pour les développeurs. Une user story assortie de critères d’acceptation peut servir de support, sans imposer ce format à tous les candidats.

Appréciez la cohérence du raisonnement et les limites reconnues. Ne récompensez pas seulement l’application d’une formule de priorisation. Un score calculé sans justification des hypothèses mérite d’être discuté.

4. Examinez le dialogue avec l’équipe

Demandez comment le candidat réagit à une estimation différente de ses attentes ou à une demande urgente d’une partie prenante. Faites préciser ce qu’il décide et ce qu’il laisse aux développeurs.

Si votre équipe utilise Scrum, vérifiez que le candidat respecte la responsabilité des développeurs sur les estimations et les choix de réalisation. Un candidat qui impose les tâches techniques par autorité confond son rôle de priorisation avec les choix de réalisation qui appartiennent aux développeurs.

Observez également sa capacité à reformuler un désaccord et à expliquer un report. Si le poste comporte du management hiérarchique, évaluez cette responsabilité séparément, sans la déduire du seul titre de PO.

5. Croisez les observations avant de conclure

Associez une personne capable d’apprécier les décisions produit et un interlocuteur technique pour les contraintes de réalisation. Si cette expertise manque en interne, faites intervenir un évaluateur expérimenté dans le contexte concerné.

Lors d’une prise de références convenue avec le candidat, cherchez à préciser son autonomie et sa contribution aux décisions évoquées. Rapprochez ces éléments des observations recueillies, sans demander à une référence de remplacer l’évaluation.

Concluez sur les responsabilités que la personne peut assumer et sur l’accompagnement nécessaire. Un désaccord entre évaluateurs doit conduire à expliciter les critères et les faits observés.