Au cours de la dernière année, j’ai travaillé avec des centaines de chefs de produit dans des dizaines d’entreprises, et il y a eu une question qui a sonné comme un battement de tambour persistant: “Quelle est la différence entre le rôle d’un chef de produit et d’un chef de produit?».
Face à cette question, j’hésitais, car d’une entreprise à l’autre il y a un million de choses qui peuvent affecter les rôles; le produit, la structure organisationnelle plus large, le processus de développement de produits, les différences culturelles, les différences régionales dans les titres couramment utilisés, la liste continue.
Sur les conseils de mon collègue Martin Eriksson, je retourne maintenant la question à celui qui pose la question, et je lui propose deux questions à considérer, à savoir: «Qu’essayez-vous de corriger?» Et / ou «Quels résultats recherchez-vous? atteindre?”. Il est logique qu’avant de chercher à imposer un rôle nouveau ou différent, vous devez avoir une compréhension claire de ce qui se passe actuellement.
À un niveau élevé, il y a deux seaux de travail. La première consiste à définir la vision stratégique et l’alignement continu du produit avec le reste de l’organisation. Le deuxième ensemble met en œuvre, suit et rend compte des progrès. D’après mon expérience, un rôle gère les éléments de ces deux compartiments. Dans Scrum, cette personne est appelée propriétaire du produit. Dans Agile, cette personne s’appelle le chef de produit. En général, lorsque l’on se réfère à ces responsabilités, les deux rôles sont complètement interchangeables.
La complexité est introduite lorsque les organisations ajoutent une couche de surveillance hiérarchique, alias la couche qui est ultimement responsable de la prise de décisions sur la vision du produit. Lorsque je travaillais chez Pivotal Labs, une boutique Agile, nous nous sommes référés à notre client sponsor en tant que propriétaire du produit. Ils pourraient également être désignés comme le propriétaire de l’entreprise ou plus généralement comme la partie prenante clé. Dans les organisations qui implémentent Scrum, cela devient confus parce que le propriétaire du produit gère le backlog, mais n’a pas le dernier mot, donc un chef de produit est inséré. Vous voyez le hic?
Mind the Product Training travaille actuellement sur un projet qui illustre ce point. Malgré le fait que je suis chef de produit numérique depuis huit ans, je ne suis pas chef de produit chez Mind The Product – je suis le directeur des produits de formation. Ma mission principale est la conception de services pour nos programmes de formation. Pourtant, il existe plusieurs produits numériques dont la formation a besoin pour que le service fonctionne correctement et je n’ai pas le temps de gérer ces projets et de fournir notre service.
Entrez Christopher Massey, chef de produit Mind The Product (donc méta). Il est responsable de la planification et de la livraison de tous les produits numériques de Mind the Product, y compris notre site Web et nos outils d’administration. Notre programme de formation a dépassé sa phase de test, et nous pouvons maintenant nous concentrer sur le perfectionnement de nos interactions numériques et de nos points de contact. J’ai donc appelé à une réunion avec le produit (Chris), le marketing (la brillante Amy Roberts) et moi-même. Nous avons élaboré un bon plan pour aller de l’avant avec nos pages de formation nécessaires. Chris sera le chef de produit et je serai le propriétaire du produit.
Alors déballons un peu ça. Pourquoi Chris est le chef de produit dans ce scénario? En termes simples, c’est son titre actuel, mais plus étroitement, il gérera la décomposition de la vision en histoires réalisables et s’assurera que l’équipe de livraison comprend l’intention, la valeur et la priorité. Chris gérera le «comment» du produit. Mon rôle en tant que propriétaire de produit sera de maintenir les objectifs et la vision de la formation afin que les produits numériques puissent être correctement guidés. Je posséderai le «pourquoi» du produit, car j’ai passé les 12 derniers mois à le comprendre. À d’autres moments, pour d’autres produits, Chris portera en fait ces deux chapeaux parce qu’il aura fait le travail pour créer la vision du produit, et il est autorisé par Mind the Product à le faire. Dans ces cas, il n’est pas nécessaire d’avoir un propriétaire de produit.
Mon point de vue dans la présentation de ce scénario est que les titres ne sont pas aussi importants que la compréhension des résultats que vous souhaitez atteindre et des faiblesses de votre structure et de votre processus actuels.
Voici quelques questions que vous pourriez poser à votre équipe, pas nécessairement pour imposer un rôle nouveau ou différent, mais pour comprendre si votre rôle produit est habilité et soutenu de manière appropriée pour livrer le produit.
- Qui fait quoi actuellement en ce moment?
- Qu’essayez-vous de corriger en premier? Seconde?
- Quels sont les principaux défis des acteurs clés?
- Qui détient les informations dont vous avez besoin?
- Pensez-vous que vous avez un accès clair aux informations dont vous avez besoin?
- Quel est votre processus pour prendre des décisions?
- La procédure actuelle est-elle claire? La propriété est-elle claire? Votre peuple est-il habilité?
- L’alignement et le signalement sont-ils un problème? Pourquoi?
- À quoi ressemble le succès?
Si vous obtenez des réponses à ces questions via des entretiens individuels avec les parties concernées, vous pourrez au moins mieux comprendre ce qui se passe dans votre équipe. Ensuite, je recommanderais une rétrospective collaborative encadrée autour de l’amélioration du processus, axée sur la création de points d’action avec des responsabilités assignées aux individus. Cela deviendrait alors votre «test bêta» pour changer les rôles.
J’aimerais avoir de vos nouvelles. Avez-vous des propriétaires de produits? Chefs de produit? Comment ça marche pour toi?
