3 niveaux d'autonomie dans le Product Management
Auteur : Roman Pichler
Source : 3 empowerment levels in Product Management
Date : 19/02/2024
Traducteur : Fabrice Aimetti
Date : 20/02/2024
Traduction :
Le fait de disposer d'une certaine autonomie peut faire toute la différence dans la réalisation d'un travail de qualité. Malheureusement, tous les Product Managers ne disposent pas de l'autorité dont ils ont besoin. Ce constat n'est pourtant pas nouveau, et il ne suffit pas de souhaiter plus de pouvoir. Dans cet article, j'explique ce que signifie réellement l'autonomisation dans le domaine du Product Management. Je vous aide à déterminer votre degré d'autonomie et je vous donne des conseils spécifiques pour le renforcer.
Introduction
Pour aborder la question de l`autonomisation dans le Product Management, il me semble utile de distinguer trois niveaux principaux d`autorité de prise de décision : le Product Delivery, le Product Discovery et le Product Strategy, comme le montre le modèle de la figure 1[1].
Figure 1 : Un modèle d'autonomisation pour les personnes et les équipes chargées des produits.
Notes
- [1] Le modèle de la figure 1 tire parti de la distinction entre stratégie, discovery et delivery décrite dans le livre de Marty Cagan Inspired, 2e édition. Notez que le modèle définit l'autonomisation comme le fait de disposer de l'autorité décisionnelle nécessaire et d'avoir l'ownership du produit ou du moins de certains de ses aspects.
- [2] J'utilise le terme fonctionnalité (feature) pour faire référence à une capacité du produit, par exemple, les commentaires sur cet article.
- [3] Dans un processus agile basé sur Scrum, le travail de "project management" est effectué dans Scrum en collaboration par le "product Owner" et l'équipe de développement, cette dernière prenant en charge la majeure partie du travail. Dans le cadre de mise à l'échelle SAFe, cependant, le Product Owner SAFe dispose d'un niveau d'autonomie 1, pour autant que je puisse en juger.
- [4] Marty Cagan appelle les équipes qui n'ont pas d'autnomisation de niveau 2 des "feature teams".
- [5] Je poursuis en disant : "Mais cela ne signifie pas que vous devez créer la stratégie et la roadmap tout seul, remettre vos plans finis aux parties prenantes et aux équipes de développement, et attendre d'eux qu'ils les mettent en œuvre. Quelle que soit la qualité de votre stratégie produit et de votre roadmap, elles n'ont aucune valeur si les parties prenantes et les équipes de développement n'y adhèrent pas. Vous devez donc les impliquer dans la création et la mise à jour des plans, de préférence sous la forme d'ateliers collaboratifs". Strategize, 2e édition, p. 20.
- [6] Le pouvoir de référence et le pouvoir d'expertise ont été décrits pour la première fois par French et Raven dans leur article intitulé The Basis of Social Power (Les fondements du pouvoir social). Ils sont également appelés pouvoir personnel pour les distinguer du pouvoir hiérarchique, qui découle d'une position dans l'organigramme. Pour plus d'informations, voir également mon article intitulé "Decoding Product Leadership" (""Décoder le leadership produit).
- [7] Si vous avez des coachs qualifiés dans votre organisation, demandez-leur de vous soutenir. Un Scrum Master, par exemple, est censé s'attaquer aux obstacles organisationnels et contribuer à apporter les changements nécessaires pour mettre en place une méthode de travail efficace. Il s'agit notamment d'accroître l'autonomie des personnes chargées du produit.