10 conseils pour les Product Owners sur la Gestion de Produits en mode Agile

Être un Product Owner en mode agile

Avant de nous plonger dans les conseils sur la gestion de produit dans un environnement Agile, voyons d’abord ce qu’est la gestion de produit Agile ! Dans le framework Scrum, un Product Owner en mode Agile est la seule personne responsable du succès d’un produit et de la maximisation de sa valeur. En général, dans ce framework, seules quelques responsabilités du Product Owner sont décrites (telles que la gestion du Backlog de produit, la maximisation de la valeur et la gestion des parties prenantes).

Outre ces responsabilités, le rôle du Product Owner a également beaucoup à voir avec la gestion du produit ! Ainsi, un Product Owner est une sorte de Product Manager Agile.

Le rôle de Product Owner est totalement différent des rôles traditionnels qui sont connus dans la plupart des organisations. Certains pensent que le Product Owner est une sorte de « chef de projet Agile » ou que le Product Owner est une sorte de  » Business Analyst « , mais il n’en est rien.

Le Product Owner est le véritable propriétaire du produit.

Il ou elle est la seule personne qui est responsable et redevable du succès du produit. L’objectif d’un Product Owner n’est donc pas de « faire des projets », mais de livrer, maintenir et commercialiser le produit !

10 conseils pour les product owner sur la gestion de produits en mode agile

Dans ce post, nous allons évoquer 10 conseils sur la gestion de produit dans un environnement Agile. Consultez également nos autres articles sur les Product Owners, leur rôle et leurs missions.

 

Voici nos 10 conseils pour les Product Owner en mode Agile :

1. Agissez comme un chef de produit et non comme un « gestionnaire de projet Agile »

2. Expliquez à vos parties prenantes pourquoi vous travaillez en mode Agile

3. Soyez “orienté produit” plutôt que « orienté projet ».

4. Se focaliser sur les retours des utilisateurs plutôt que sur la réduction du délai de mise sur le marché

5. Assumer la responsabilité du succès du produit

6. Ne travaillez pas en méthode “Cascade” durant les sprints, focalisez vous sur la mise à disposition de la valeur aux clients/utilisateurs

7. Se focaliser sur l’analyse n’améliore pas forcément le produit

8. L’étude de marché, les ventes et le marketing font partie de vos responsabilités

9. Se concentrer sur l’augmentation de la valeur (résultat final) plutôt que sur l’augmentation de la productivité

10. Soyez un dauphin, pas un sous-marin !

1. Agissez comme un chef de produit et non comme un « gestionnaire de projet Agile »

Un chef de projet est responsable de la gestion des objectifs, des exceptions, des ressources et des rapports (pour ne citer que ces tâches).

En tant que Product Owner, votre rôle ne consiste donc pas à gérer les « ressources » ou les « tâches ». Le cœur de votre métier, c’est d’agir pour maximiser la valeur de votre produit. Pour cela, il faut créer les fonctionnalités qui apportent le plus de valeur aux utilisateurs du produit. Afin de maximiser la valeur de votre produit, vous ne devez donc pas vous focaliser sur la gestion des tâches des membres de l’équipe au quotidien ou encore la progression de l’équipe dans un sprint. Tout cela peut être géré par l’équipe elle-même, de façon autonome.

Ce qui est important pour vous, c’est de maximiser la valeur de votre produit, en collaboration avec les utilisateurs, les clients et les parties prenantes !

2. Expliquez à vos parties prenantes pourquoi vous travaillez en mode Agile

Le travail en mode Agile n’est pas une tendance, ni quelque chose que vous « faites » . C’est un état d’esprit. C’est un ensemble de valeurs et de principes qui vous guident.

exemple de cycle de développement agile

Scrum est un des framework de l’agilité : il est utilisé dans des environnements complexes pour développer et maintenir des produits complexes.

La façon de travailler, les valeurs et les principes que vous souhaitez adopter sont très différents des méthodes de travail traditionnelles. Il en va de même pour la culture et la gouvernance de l’organisation. Les parties prenantes doivent également changer de mode de pensée et de comportement.

Vous devrez donc consacrer du temps à l’accompagnement de vos parties prenantes et à leur expliquer la méthode Agile (en collaboration avec votre Scrum Master ou votre coach Agile).

3. Soyez “orienté produit” plutôt que « orienté projet »

Par définition, un projet est quelque chose qui se termine. Un projet est une organisation temporaire qui est créé afin de remplir un objectif spécifique, dans une période de temps et un budget donnés.

Or, le cœur de métier du Product Owner, c’est la livraison du produit. Par conséquent, le développement du produit ne se termine pas tant que le produit existe. C’est le contraire pour le projet, qui se termine dès la mise sur le marché du produit.

Mesurer la réussite d’un projet et mesurer la réussite d’un projet, c’est différent. Un projet est généralement réussi lorsque l’objectif convenu au départ a été rempli à temps et dans le respect du budget. En revanche, un produit est réussi lorsqu’il est adopté, utilisé et apprécié par ses utilisateurs.

4. Se focaliser sur les retours des utilisateurs, plutôt que sur la réduction du délai de mise sur le marché

Beaucoup de personnes et d’organisations se concentrent sur la réduction du délai de mise à disposition du projet ou du produit sur le marché. Bien sûr, c’est très important de raccourcir ce délai car c’est un indicateur qui signifie que vous êtes en mesure de livrer des produits à vos clients plus rapidement.

Or, en tant que Product Owner, votre objectif principal est de maximiser la valeur pour vos clients. Livrer plus vite et réussir cette prouesse plus souvent semble être une bonne chose au premier abord. Cependant, se concentrer sur cet indicateur en priorité se fait souvent au détriment du temps alloué à l’étude des retours des utilisateurs. Étant donné qu’il n’est pas possible de déterminer la valeur à l’avance, car ce sont vos clients et vos utilisateurs qui déterminent si quelque chose a de la valeur ou non, il est impossible d’avoir des retours sur leurs intérêts. En fonction de leur utilisation du produit et de leurs commentaires, vous apprendrez à distinguer ce qui a de la valeur et ce qui n’en a pas.

Collecter des informations sur les utilisateurs est très important. Mais, faire des sacrifices sur cet aspect au profit de la réduction du temps de mise sur le marché peut donc avoir des conséquences néfastes. Donc, le temps alloué aux retours des utilisateurs est plus intéressant car il permet de déterminer les points importants pour les utilisateurs et d’éviter la perte de valeur du produit et/ou du projet, et c’est pour cette raison qu’il faut savoir le prioriser face à la réduction du délai de mise sur le marché.

5. Assumer la responsabilité du succès du produit

Un grand nombre de Product Owners sont seulement en charge de certaines parties d’un système, ou qui sont des « proxy Product Owners » (qui gèrent le Product Backlog pour le compte de quelqu’un d’autre qui, souvent, n’est pas disponible).

Or, le Product Owner en mode agile doit se charger non seulement du Backlog mais également du système complet (délais, qualité et coût). Cela signifie que le Product Owner est responsable de la performance finale du produit.

6. Ne travaillez pas en méthode “Cascade” (Waterfall) durant les sprints, focalisez vous sur la mise à disposition de la valeur aux clients/utilisateurs

Il n’est pas rare de voir beaucoup de Product Owner qui font du Scrum dans le cadre d’un projet. De plus, une grande partie de ces Product Owner découpent les systèmes en couches (front-end, back-end, middleware, hardware, etc.), or, c’est pourtant une spécificité propre à la méthode en Cascade (Waterfall).

Agile ou en Cascade

Cela ne vous aidera pas à maximiser la valeur. De plus, ça n’est pas cohérent avec la méthodologie Agile. Par exemple, une architecture complète ne contient aucune valeur pour l’utilisateur. En revanche, une solution de bout en bout (end-to-end) d’une fonctionnalité a de la valeur pour l’utilisateur ! C’est pour cette raison qu’il ne faut pas livrer une solution système dans un Sprint, mais plutôt une fonctionnalité de bout en bout.

En outre, il existe des exemples dans lesquels des équipes créent la conception pendant un Sprint, développent dans le Sprint suivant, testent dans le Sprint d’après et livrent finalement à un utilisateur dans le quatrième Sprint. Cela signifie que vous n’apportez aucune valeur ajoutée aux utilisateurs avant le quatrième Sprint… et c’est contradictoire avec la méthodologie Agile dans un framework Scrum.

Essayez de réduire la taille des éléments du Backlog de produit, afin de pouvoir livrer une fonctionnalité de bout en bout en un seul Sprint !

7. Se focaliser sur l’analyse n’améliore pas forcément le produit

Beaucoup d’équipes ont l’habitude de travailler dans le cadre de projets. Les projets sont d’excellents moyens de travailler dans des environnements compliqués mais cela n’est pas forcément le cas dans des environnements complexes  (modèle Cynefin).

Dans les environnements complexes, vous avez besoin d’une approche empirique, comme le propose le cadre Scrum. Dans les environnements compliqués, les problèmes ont une relation typique de cause à effet.

Par conséquent, une analyse plus poussée en amont se traduira par une meilleure solution à la fin. Cependant, dans les environnements complexes, les problèmes peuvent avoir de nombreuses causes et donc, de nombreux effets. Cela signifie que la meilleure approche n’est pas d’analyser davantage.

La meilleure approche dans les environnements complexes est de faire un premier pas (agir), puis d’observer ce qui se passe (analyser) et enfin de réagir aux nouvelles données recueillies (répondre). Pour les Product Owner, cette approche vous permettra de comprendre et d’accepter que le monde est imprévisible. Cette approche est capitale car elle vous pousse à réaliser plus d’expériences, de tests, de versions différentes et à recueillir les commentaires du marché !

8. L’étude de marché, les ventes et le marketing font partie de vos responsabilités

Beaucoup de Product Owner en mode Agile se limitent à être responsables d’un système, ou d’une partie d’un système. Cependant, cela n’englobe pas l’idée d’un Product Owner qui est un propriétaire réel d’un produit, au sens littéral du terme. L’idée d’un Product Owner étant un entrepreneur (ce qui est le plus haut niveau de maturité du Product Owner). Un Product Owner entrepreneur, quelqu’un qui est finalement responsable du succès du Produit, est également responsable des études de marché, des ventes, du marketing… Ces aspects ne doivent surtout pas être négligés car ils jouent un rôle déterminant dans le projet.

9. Se concentrer sur l’augmentation de la valeur (résultat final) plutôt que sur l’augmentation de la productivité

Une très grande majorité de Product Owner en mode Agile se concentrent sur l’augmentation de la productivité de leur(s) équipe(s) et cela peut nuire au produit et/ou au projet. La mesure de la productivité d’une équipe est basée sur une technique d’estimation relative. En d’autres termes, cela signifie que les scénarios ont une valeur relative. Il est extrêmement facile pour les équipes de doubler leur productivité et si vous leur demandez de le faire. Or, cela peut avoir un impact négatif sur le résultat final.

Créer de la valeur en priorité

La création de valeur est donc un indicateur plus important que l’augmentation de la productivité. Nous vous conseillons de mesurer la valeur délivrée par l’équipe, mesurer l’impact des nouvelles livraisons sur les KPI de vos produits et mesurer la satisfaction du client/de l’utilisateur pour maximiser l’impact positif sur votre produit et/ou projet.

10. Soyez un dauphin, pas un sous-marin !

Notre dernier conseil sur la gestion de produit agile est de rester à la surface de l’eau (comme un dauphin). Un dauphin ne va sous l’eau que pour une courte période de temps et remonte à la surface, autrement dit, un dauphin reste visible.

Cette métaphore a pour but de vous montrer que dans les environnements complexes et dans le développement de produits complexes, vous devez rester visible pendant tout le projet et pour toutes les parties prenantes. Donc, vous devez obtenir un retour d’information des clients et des utilisateurs dès le début et régulièrement. 

De nombreux Product Owner en mode Agile sont cependant tentés de rester sous l’eau trop longtemps, comme un sous-marin, c’est-à-dire passer plus de temps sur le produit et par conséquent, se focaliser sur le produit. L’intention est louable : rendre le produit « parfait » pour les clients et utilisateurs finaux. Cependant, passer plus de temps sur le produit aura seulement pour effet d’améliorer votre productivité, au détriment d’autres aspects du projet.

Rester visible et donc obtenir des retour d’informations réguliers et constants seront beaucoup plus utiles pour maximiser la valeur de votre produit, et pour la réussite du projet et/ou du produit sur le long terme.

Nous espérons que vous avez beaucoup apprécié nos 10 conseils pour les Product Owner en mode Agile !

Si vous voulez en savoir plus sur le sujet, n’hésitez pas à consulter nos autres articles sur le sujet :

Vous êtes intéressés par des services de consulting et d’accompagnement dans vos projets Agile ?