Business : Devriez-vous embaucher des chefs de produit ou des chefs de produit pour vos équipes Scrum?

Product Manager vs Product Owner: sur la fausseté des titres de poste de Product Management

Après avoir lu le titre, vous vous demandez peut-être pourquoi je pose une question avec une réponse évidente: Scrum nécessite un Product Owner, vous devez donc embaucher un Product Owner. Duh!

Eh bien, ne serait-ce pas agréable et dandy si les choses étaient aussi simples? Prenons un peu de recul et réfléchissons en posant une question différente mais connexe: qui engagez-vous pour être membre de l’équipe de développement de votre équipe Scrum?

Cela dépend de qui vous avez besoin dans votre équipe Scrum. Il peut s’agir d’un concepteur UX, d’un ingénieur DevOps, d’un ingénieur QA, d’un développeur Full-stack, d’un développeur Back-end ou d’un développeur Front-end.

Vous embauchez quelqu’un avec le bonne connaissance pour remplir le rôle. Que cette personne ait de l’expérience avec Scrum ou ait une certification de développeur Scrum est moins importante que d’avoir les compétences nécessaires pour faire le travail réel. Vous n’embauchez pas pour le rôle dans Scrum, vous embauchez pour le travail qu’ils sont censés faire.

Revenons maintenant au rôle Product Owner. Quel genre de personne a les bonnes connaissances pour assumer ce rôle? Avant de pouvoir répondre à cette question, commençons par la définition de Scrum:

Scrum (n): Un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes, tout en étant productifs et créatifs livrer des produits de la plus haute valeur possible. – Scrum Guide version novembre 2017

L’élément clé est en gras: fournir des produits de la plus haute valeur possible. C’est là qu’intervient le Product Owner. Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement.

Comment le propriétaire du produit fait-il exactement cela? Eh bien, vous êtes seul. Scrum est relativement normatif en ce qui concerne Comment vous construisez quelque chose, la livraison du produit. Scrum aide à construire la bonne chose avec un court délai de mise sur le marché. Scrum fournit peu de conseils pour la construction la bonne chose en dehors de mettre commodément tout cela sur les genoux du propriétaire du produit.

Les propriétaires de produits s’inquiètent de nombreuses facettes de la création de valeur avec un produit comme: que devrions-nous construire et pourquoi? Comment validez-vous si ce que vous avez construit réussit? Comment associez-vous efficacement vos parties prenantes pour maximiser la valeur ajoutée de votre produit?

Scrum ne fournit aucune réponse à ces questions: vous êtes seul. C’est intentionnel parce que Scrum est un cadre de processus et pas un processus. La force (et la faiblesse) de Scrum est que vous devez compléter le cadre pour qu’il réussisse. Utiliser simplement Scrum ne suffit pas pour créer d’excellents produits.

Avoir un examen Sprint où vous montrez votre produit aux parties prenantes et les impliquez dans quoi travailler ensuite, ne garantira pas que vous construisez quelque chose qui offre de la valeur aux utilisateurs et à l’entreprise.

De plus, découvrir quelque chose n’a de valeur qu’après la construction, il est trop tard. Vous devriez essayer d’augmenter vos chances de réussite en apprenant avant de construire ou de construire aussi peu que nécessaire pour maximiser l’apprentissage.

Alors, comment Scrum aide-t-il à s’assurer que vous construisez la bonne chose? Le paragraphe suivant du Scrum Guide explique clairement ce qui motive la livraison de valeur:

Scrum rend clair l’efficacité relative de la gestion de vos produits et techniques de travail afin que vous puissiez améliorer continuellement le produit, l’équipe et l’environnement de travail. – Scrum Guide version novembre 2017

En d’autres termes, la gestion des produits est le moteur qui génère la livraison de valeur. Scrum peut rendre transparente l’efficacité de vos techniques de gestion de produits. L’inspection et l’adaptation vous permettent de perfectionner et d’améliorer ces techniques. Cela n’est possible que si une personne fournit au départ cette expertise en gestion de produits.

L’expert en gestion de produits de Scrum est appelé le Product Owner. Un excellent Product Owner est un solide Product Manager. Vous ne pouvez pas être un bon propriétaire de produit sans comprendre la gestion des produits. Sans suivre les pratiques de gestion des produits, Scrum ne peut pas tenir sa promesse de fournir des produits de la plus haute valeur possible.

Ce que les chefs de produit et les propriétaires de produits devraient avoir en commun:

• Les deux devraient être des experts en gestion de produits.

Quelles sont les différences?

• Product Manager est le terme agnostique pour quelqu’un qui maximise la valeur pour les clients et l’entreprise en utilisant leur connaissance de la gestion des produits.
• Le Product Owner est ce que Scrum appelle le Product Manager, et le Product Owner a bien plus de responsabilités que le Product Manager moyen qui ne travaille pas avec Scrum.

Pourquoi le chef de produit a-t-il plus de responsabilités que le chef de produit moyen? La gestion des produits reconnaît généralement les niveaux d’ancienneté suivants:

• Chef de produit – Responsable de plus d’un produit.
• VP de produit – Responsable d’un seul produit.
• Chef de produit senior – Responsable d’une ou plusieurs équipes travaillant sur un seul produit. Coaching possible d’autres chefs de produit.
• Chef de produit – Responsable d’une seule équipe travaillant sur un seul produit, souvent sous la direction d’un chef de produit principal.

Dans Scrum, il n’y a qu’un seul propriétaire de produit pour un produit entier. Scrum ne permet pas de répartir cette responsabilité sur plusieurs personnes. Cela signifie que le rôle Scrum Product Owner est égal au Chief Product Officer ou VP of Product dans le monde de la gestion des produits. Les chefs de produit senior ou les chefs de produit ne sont pas propriétaires de produit, sauf s’ils n’ont pas de couche de gestion au-dessus d’eux.

Dans Scrum, le Product Owner est censé être actif sur tout le spectre de la gestion des produits:

• Vision
• Stratégie
• Feuille de route
• Découverte
• Delivery (In Scrum: tout ce qui se passe pendant le Sprint pour aider l’équipe de développement à fournir de la valeur).
• Validation

Scrum s’appuie fortement sur des équipes auto-organisées pour faire fonctionner le rôle de Product Owner. Des équipes auto-organisées mettent à disposition un Product Owner pour des activités autres que la livraison. Si un Product Owner doit être trop impliqué dans l’exécution, alors il n’aura pas suffisamment de temps pour couvrir les autres facettes de la gestion des produits. Il sera impossible d’accorder une attention suffisante aux activités de niveau supérieur telles que l’élaboration de la vision, de la stratégie et de la feuille de route du produit.

Il s’agit d’un problème courant car de nombreuses entreprises travaillent avec Scrum de telle sorte que le travail du propriétaire du produit consiste à garder les équipes Scrum pour garantir que les fonctionnalités sont livrées à temps. C’est la mauvaise approche car avec Scrum, c’est le travail du Scrum Master de construire une équipe auto-organisée qui a le moins besoin possible du Product Owner pour apporter de la valeur pendant le Sprint. Malheureusement, cela échoue souvent et, par conséquent, le produit souffre parce que le propriétaire du produit est simplement occupé à exécuter les équipes Scrum au lieu de regarder la vue d’ensemble du produit.

Pour contourner ce problème, les entreprises introduisent un nouveau rôle pour contourner le problème réel: le chef de produit. Le Product Owner s’assure que l’équipe continue à livrer et travaille efficacement à l’intérieur de la bulle Sprint. Tout ce qui est en dehors du Sprint est couvert par le chef de produit. Le chef de produit est généralement face externe aux clients et parties prenantes, le chef de produit est face interne à l’équipe Scrum.

La dichotomie chef de produit – propriétaire de produit est une solution à un problème, mais d’après mon expérience, elle présente sa propre multitude de problèmes qui aggravent la guérison plutôt que la maladie:

• Gaspillage et perte d’informations dus aux transferts du chef de produit au chef de produit, conduisant à des solutions qui ne résolvent pas le problème prévu du client.
• Le manque de compréhension par les clients et les entreprises du propriétaire du produit peut conduire à de mauvaises décisions ad-hoc pendant le Sprint, entraînant des retouches inutiles ou des fonctionnalités ne fournissant pas de valeur.
• Les propriétaires de produits peuvent se désengager. Le rôle de Product Owner est effectivement réduit à celui de maître de ticket, baby-sitter et scribe. Ce n’est certainement pas ainsi que Scrum entend que le rôle de Product Owner soit.
• Il y a souvent un désaccord entre les chefs de produit et les propriétaires de produit sur la direction du produit, ce qui conduit à des frictions et à des décisions de sprint qui ne correspondent pas à la situation dans son ensemble.

Lorsque les équipes Scrum nécessitent beaucoup d’attention pendant le sprint du propriétaire du produit, c’est le problème que vous devez résoudre. D’après mon expérience, le Product Owner ne devrait passer qu’environ 20% de son temps avec son équipe Scrum. Sinon, le rôle ne sera pas mis à l’échelle lorsque vous devrez gérer plusieurs équipes Scrum.

C’est le but de Scrum d’aider à livrer des produits de la plus haute valeur possible. C’est le travail du propriétaire du produit de s’assurer que tout le monde comprend bien comment y parvenir sans avoir à compter constamment sur la présence du propriétaire du produit.

En tant que Product Owner, j’encourage les équipes Scrum avec lesquelles je travaille à prendre des décisions pendant le Sprint sans m’impliquer. Si je reçois une question, je pose souvent des questions de suivi pour les amener à la bonne réponse.

S’ils ne sont pas en mesure de fournir une réponse, je passe un peu plus de temps à expliquer le contexte pour fournir les connaissances qui manquent éventuellement. Puis après avoir expliqué un peu plus, je continue à poser des questions jusqu’à ce qu’ils arrivent à la bonne conclusion (ou à une meilleure que la mienne!). Suivre cette approche augmente les chances qu’ils prennent la bonne décision sans m’impliquer la prochaine fois.

Alors maintenant, pour revenir à la question initiale: une équipe Scrum est-elle mieux avec un chef de produit ou un propriétaire de produit?

Vous devez employer une personne possédant la bonne expertise: un expert en gestion de produits. Peu importe si leur ancien poste était propriétaire de produit ou chef de produit, il importe quels domaines de la gestion de produits ils connaissent. Avoir de l’expérience avec Scrum est moins important, surtout parce qu’il y a un Scrum Master disponible pour les coacher dans le domaine de Scrum si nécessaire.

Cependant, avec Scrum étant si populaire, il est de plus en plus rare de trouver un bon chef de produit qui n’a pas d’expérience avec Scrum. Voyant à quel point Scrum se développe, c’est une question de temps jusqu’à ce que les chefs de produit qui manquent d’expérience Scrum commencent à lever les sourcils pendant les entretiens.

Quand quelqu’un dit qu’il est chef de produit ou propriétaire de produit, vous ne pouvez pas simplement conclure en fonction de son titre de l’expérience qu’il possède en matière de gestion de produit. Certains chefs de produit ont plus de responsabilités que les chefs de produit, mais cela peut aussi être l’inverse: les chefs de produit qui ont plus de responsabilités qu’un chef de produit.

Cela explique pourquoi il y a tant de confusion autour des deux rôles. Je m’attends à ce que cette confusion ne soit pas résolue, quel que soit le nombre d’articles qui seront écrits. Les titres de poste de Product Manager et Product Owner sont trompeurs. La façon dont le rôle est rempli diffère d’une entreprise à l’autre.

Comme pour toute location que vous faites: un titre ne raconte jamais toute l’histoire, l’expérience réelle sur le tas le fait. Ce n’est qu’en posant les bonnes questions que vous pourrez découvrir si vous avez confiance que la personne est capable de faire le travail pour lequel vous souhaitez l’embaucher. Ce Product Owner n’est-il qu’un poussoir de tickets qui ne parle jamais aux clients? Ou est-ce quelqu’un qui comprend le métier de la gestion des produits et passe la plupart du temps à parler aux clients, à comprendre l’entreprise, à mener des expériences et à rechercher le marché?

Malheureusement, les gens aspirent souvent à des titres, car c’est un moyen facile de tirer des conclusions sur quelqu’un sans avoir à dépenser beaucoup d’efforts cognitifs. Regardez au-delà du titre et concentrez-vous sur l’expérience de la personne avec qui vous parlez. Surtout en ce qui concerne les titres de poste de gestion de produits tels que chef de produit et propriétaire de produit.

Regarder au-delà du titre du poste est beaucoup plus difficile, mais il fournira bien plus de signaux et d’informations qu’un tas de lettres.

Remerciement spécial à Olaf Molenveld pour avoir suggéré d’écrire cet article.

Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?