Posture du Product Manager, résister à l’ingérence

Vous êtes Product Manager et vous vous interrogez sur votre posture au sein de votre équipe : voici deux bonnes nouvelles pour vous. La première, c’est que c’est normal. Le rôle de PM est un subtil équilibre entre tendances contradictoires : technique, mais pas trop : savoir être leader, mais ne pas devenir tyran ; installer des bonnes pratiques, tout en laissant votre Scrum Master faire son travail. La deuxième bonne nouvelle c’est que cet article se propose de vous aider à éviter quelques écueils qui peuvent nuire à l’exercice de votre fonction. Plus précisément, il est ici question des situations où vous serez tenté de vous substituer au rôle de vos collègues, lorsque certaines conditions sont réunies : un Scrum Master inexistant, des développeurs qui n’inspirent pas confiance, un manager qui ne vous convient pas… les quelques exemples qui suivent sont à éviter soigneusement.

Les raisons qui conduisent à l’ingérence

Voici une liste non exhaustive des raisons qui vous poussent à déborder de votre rôle de Product Manager.

Vous avez envie de vous substituer à votre Scrum Master

• Pour de bonnes ou de mauvaises raisons, vous avez perdu confiance en votre SM
• Le SM de votre équipe a un autre rôle dans l’équipe ou l’entreprise qui l’empêche de se consacrer suffisamment à sa fonction de SM
• Vous n’avez pas de SM.
• Vous venez d’être certifié PM, vous êtes donc plein de convictions sur la manière dont votre SM devrait aider votre équipe.
• Vous avez déjà été SM d’une équipe, et vous avez du mal à accepter qu’une autre personne puisse jouer ce rôle différemment de vous.
• Vous avez une affinité pour les fonctions de coach, les aspects organisation ou “process” au sein d’une équipe et avez donc envie de vous impliquer dans les tâches associées.

Manager votre équipe vous démange

• Vous ressentez une baisse de motivation, de cohésion voire de discipline dans l’équipe
• Votre entreprise en est à sa 3e réorganisation du trimestre. Votre équipe est impactée par le flou organisationnel ambiant.
• Le manager de votre équipe vient de partir, son successeur arrive dans 4 mois.
• Vos sponsors vous ont fait comprendre qu’ils attendaient que vous délivriez plus, et plus vite ; vous voyez arriver la fin de l’année, et votre roadmap a beaucoup glissé
• La vélocité de l’équipe ne vous satisfait pas.
• Vos développeurs font des horaires qui vous scandalisent, et passent leur temps devant leur ordinateur à battre des records de 2048.
• Vous êtes le capitaine de votre équipe de Curling : vous vous sentez naturellement l’âme d’un meneur d’hommes et vous avez plein d’idées pour améliorer la situation dans l’équipe.
• Vous vous verriez bien à la tête de l’équipe Produit l’année prochaine ; prouver à votre hiérarchie (ou à vous-même) que vous savez prendre en main une équipe ne peut pas vous nuire.

Vous avez très envie de prendre le lead technique

• Votre équipe apprécie votre aptitude à aborder les sujets techniques car cela fluidifie vos échanges. Cette sensation vous grise et vous donne envie de prendre une place croissante dans les décisions techniques.
• Vous avez une précédente expérience en tant que développeur et la magie créatrice du code, ça vous manque.
• Vous mesurez votre dette technique (c’est bien), et vous constatez qu’elle augmente depuis 3 sprints. Votre confiance en vos développeurs s’est émoussée.
• Vous venez de reprendre le rôle de PM dans une équipe préexistante. Vous héritez d’un backlog, mais aussi d’un lot de bugs, d’une architecture vétuste et de frameworks démodés. Vous sentez qu’il faut agir pour améliorer cela.
• Votre personnalité de “control freak” vous pousse à vous immiscer dans les choix techniques que font vos développeurs.
• Votre équipe expérimente de nouvelles méthodes de travail ou de nouveaux frameworks ; vous êtes tentés d’intervenir pour accélérer la courbe d’apprentissage de vos développeurs.

Faire le travail des autres comporte des risques

Si vous vous laissez aller à ce type d’ingérence, vous risquez de voir se mettre en place des mécanismes nuisibles à la dynamique collective. En effet, en endossant un rôle qui dépasse celui que vous êtes censé avoir, vous amènerez vos coéquipiers à adopter des positionnements qui peuvent dégrader différents facteurs de réussite collective : organisation, relations entre coéquipiers, et en définitive performances de l’équipe.

Déresponsabiliser votre équipe

Si vous prenez une place excessive dans votre équipe, une des réactions possibles de vos collègues va consister à accepter la situation et vous céder du terrain. Prenons l’exemple du PM avec une casquette de manager d'équipe ; vous cumulez les rôles de leader et de manager qui vont vous projeter “au-dessus” de votre équipe. Rien de tel pour endommager la proactivité des développeurs : initiative, force de proposition, voire motivation peuvent être écrasés par le rôle dominant que vous jouez. Et c’est un cercle vicieux qui peut s’installer : votre équipe vous laisse de plus en plus de terrain, que vous cherchez à occuper ; à la longue, vous pourrez vous épuiser à porter votre équipe à bout de bras, voire vous exaspérer du manque de volonté qui s’y est installé.

Propager la défiance dans le groupe

Si vous mordez sur le rôle d’un collègue par manque de confiance dans ses capacités, il est assez naturel que vous déclenchiez par symétrie une défiance de sa part. Votre positionnement peut être vécu comme une mise en danger de sa raison d’être dans l’équipe, et déclencher chez lui une réaction d’opposition, voire d’hostilité. L’effet miroir peut aussi naturellement pousser vos coéquipiers à chercher à vous montrer que vous avez des choses à vous reprocher dans vos fonctions de PM. Les impacts se ressentent au quotidien : discussions bloquées, mise en doute excessive des choix et avis exprimés, conflits, manque général d’adhésion à la vision que vous proposez, dégradation de l’esprit d’équipe. Ce genre de rapport peut également se propager dans l’équipe voire aboutir à la création de clans en son sein. Cet engrenage aura tendance à se renforcer, car les situations conflictuelles poussent les acteurs à camper sur leurs positions et à refermer le dialogue.

Les conséquences sont particulièrement palpables pour les rôles de Scrum Master ou de développeur, car ils sont à l’intérieur même de l’équipe et affectent très directement le travail produit, et les relations entre coéquipiers.

L’enfer est pavé de bonnes intentions

Pour les raisons exposées plus haut, vous avez pensé que vous seriez plus à même de faire un travail qui n’est pas censé être le vôtre. Restons lucide : rien n’est moins sûr. La remarque peut paraître évidente, mais il n’est pas inutile de la garder à l’esprit. Car si par-dessus le marché vous vous avérez être un piètre Scrum Master, un développeur incompétent ou un mauvais manager, vous aggravez la situation initiale ; c’est dommage, vous avez consacré une énergie considérable en pensant la corriger ! Au passage, vous avez lourdement endommagé la confiance que votre équipe vous accorde, or être PM dans une équipe où on n’est pas légitime est un long chemin de croix.

Quelques conseils pour garantir une équipe saine

Les situations décrites plus haut peuvent être déclinées avec votre responsable QA, votre spécialiste Product Designer, et en fin de compte tous les interlocuteurs dont vous avez besoin pour alimenter la construction de votre produit. Les causes et conséquences associées ne sont pas exhaustives, et sont volontairement décrites de manière caricaturale. Mais il n’est pas impossible que vous en ayez déjà rencontré certaines.

Mais maintenant, vous n’avez plus d’excuses : vous pouvez repérer ces situations, et même les éviter ou y remédier avec les quelques principes qui suivent.

Être humble

Globalement, ne perdez pas de vue qu’on attend de vous que vous fassiez le travail pour lequel vous avez été recruté, et pas celui de vos collègues. C’est probablement là que vous êtes le plus utile. N’oubliez pas de vous dire qu’il en est de même pour vos collaborateurs. L’humilité est une des grandes vertus nécessaires à l’agilité, parce que l’amélioration continue passe par l’aptitude à détecter et accepter ce qui doit être amélioré.

Ne pas ajouter du chaos au chaos

Tenter de faire le travail d’un collègue implique très probablement de négliger le sien, au risque d’aggraver les dysfonctionnements. Analogie footballistique : prenez une équipe de foot composée de très bons joueurs, mais qui ne se font pas confiance : chacun va jouer sur le poste du voisin. Le résultat ? une défense pleine de trous, et une attaque désorganisée.

Faire confiance à ses collègues

Ce conseil, simple en apparence, découle des deux précédents. Accepter ses propres limites et garder en tête que les performances de l’équipe viendront d’un collectif qui cherche en permanence à s’améliorer devraient vous pousser à vous reposer sur les compétences des collègues. Si vous doutez des aptitudes de votre coéquipier, concentrez-vous sur sa capacité à les améliorer, et mobilisez votre équipe pour cela. La confiance, ça soude un groupe et ça responsabilise les personnes. En plus, ça limite la pousse des cheveux blancs et c’est une expérience humaine très agréable.

Communiquer  Communiquer et … Communiquer !

Eh oui, un grand classique pour s’améliorer individuellement et collectivement, c’est d’être transparent, bienveillant, et de maintenir le dialogue en permanence. Ce conseil dépasse tellement le cadre de cet article qu’il n’est pas utile d’en dire davantage. De nombreuses choses ont été dites sur la question, voici un article sur l'équipe Agile et la communication. Profitez de vos rétros pour poser sur la table les points de douleurs qui empoisonnent vraiment la vie de votre équipe (voir ici une idée de rétrospective Star Wars).

Miser sur les qualités qui font un bon PM

Votre posture en tant que PM est essentielle pour le bon avancement du produit. Si vous vous sentez frustré par des problèmes qui échappent à votre zone d’action, concentrez-vous sur les qualités fédératrices que vous pouvez apporter à l’équipe en tant que PM. Légitimité sur votre sujet et votre vision, capacité à trancher, disponibilité sont des leviers considérables pour faire converger les énergies et donc proposer une saine relation avec vos développeurs. L’exemplarité de votre travail pourrait mettre en avant certaines défaillances de l'équipe et créer une émulation positive par l'exemple qui tirerait tout le monde vers le haut.

Pour finir, gardons en tête que respecter le rôle de vos voisins ne doit pas vous empêcher d’être force de proposition sur des domaines où vous pensez être pertinent, même s’ils s’écartent un peu du cœur de métier de PM. Vous avez une expérience et des connaissances personnelles : faites-en profiter votre équipe !

Retrouvez de nombreux autres conseils sur le positionnement du PM et ses relations avec son équipe dans nos précédents articles :

• Product Manager – développeurs : Je t’aime moi non plus?
• Product Manager : Adoptez la bonne posture
• Product Manager & Product Designer : Comment travailler ensemble ?

Et pour en savoir plus : télécharger notre livre Les Clés du Product Management