Comment les Product Managers perdent-ils la confiance de leur équipe ? La façon dont ils communiquent avec leurs coéquipiers joue un grand rôle.
Une petite histoire
Un Product Manager dit :
“Je pense que nous devrions arrêter d’itérer sur cette fonctionnalité.”
L’équipe est en désaccord. Ils ont examiné les feedbacks des clients et ils ne sont pas très fiers de l’état actuel de cette fonctionnalité. Pour eux, l’interface nécessite encore quelques ajustements et il reste encore quelques améliorations à mener.
Ils ont donc fait part de leurs préoccupations au PM.
Imaginons quatre exemples de réponses du chef de produit :
- #1 – “Ha bon ? A mon sens, rien ne me semble mauvais sur l’interface. C’est tout à fait utilisable ! C’est vrai qu’il n’y a pas de nice to have mais elle est terminée en fonction des critères d’acceptation que nous avons déterminé. Il est temps de passer à autre chose.”
- #2 – “Eh bien, nous nous sommes engagés à terminer cela d’ici la fin du mois, puis à commencer le projet X. Je discutais avec Marvin du marketing, et le projet X attire beaucoup l’attention de Linda, notre PDG, …”
- #3 – “Je ne vois tout simplement pas en quoi ces ajustements et ces améliorations sont la chose la plus importante sur laquelle nous pourrions travailler. Je veux dire, cette fonctionnalité a-t-elle plus de valeur que la fonctionnalité A ? Nos utilisateurs nous supplient de faire A depuis l’année dernière. Quelle est la valeur d’une UX légèrement meilleure ?”
- #4 – “Si vous en avez vraiment l’envie, alors allez-y. Ce qui me mettrait un peu plus à l’aise serait que nous revoyions nos objectifs – ceux que nous avons formalisés ensemble – et que nous nous assurions que ce travail supplémentaire y corresponde. Ensuite, j’aimerai que nous passions quelques minutes à voir les autres travaux qui nous attendent pour voir comment intégrer ce que vous venez de proposer. Je serai d’accord avec tout ce que l’équipe décide de faire, mais je tiens à ce que nous réfléchissions vraiment ensemble à ces choix.”
On analyse ?
Que véhiculent ces réponses ? Passons-les en revue :
- #1 – Le Product Manager semble expliquer à l’équipe (designer, ingénieurs,…) comment faire leur travail.
- # 2 – L’équipe s’est sentie contrainte à cet engagement. Cela ne s’est jamais senti bien. Une estimation s’est soudainement transformée en un engagement difficile. Et quels autres sujets ont été discuté avec Marvin du marketing ? Quelles discussions intéressantes à pu manquer l’équipe ? Et à quoi Linda prête-t-elle attention ? Cela se produit-il dans des réunions auxquelles ils ne participent pas ?
- #3 – Le Product Manager se concentre sur la valeur. C’est plutôt bénéfique mais… un certain nombre de choses clochent ici. La “valeur”, non mesurée, abstraite, marginalise le point de vue de l’équipe. Les clients ont demandé BEAUCOUP de choses, alors pourquoi la fonctionnalité A plus qu’une autre ? De plus la valeur de l’UX est remise en question. Même avec de bonnes intentions, cela ne passera probablement pas très bien.
- #4 – Le Product Manager montre son soutien à ses coéquipiers. Il exprime ses besoins – faire des choix réfléchis – et essaie de s’assurer que l’équipe reste ancrée dans sa mission. Il y a un problème ici ?
Cohérence ? Ou pas.
L’équipe, les ingénieurs, designers, concepteurs qui la compose sont des résolveurs de problèmes (et des explorateurs de problèmes, des penseurs de systèmes et des analystes des coûts/avantages, etc.). Ils peuvent flairer l’incohérence à un kilomètre de distance, même si ce n’est pas leur expertise. Ainsi, même si un designer n’est peut-être pas un “expert en affaires”, il est probablement capable de détecter une stratégie commerciale qui ne correspond pas aux attentes des utilisateurs.
Lorsqu’ils (ingénieurs et concepteurs) ne peuvent pas voir à plusieurs reprises l’intérêt de leur travail ou que les actions du Product Manager sont incohérentes, ou que les explications sont obscures… ils sont susceptibles de commencer à perdre confiance.
Même des choses petites et innocentes peuvent être un déclencheur.
Prenons l’exemple du #2 où le Product Manager a interagi avec des personnes extérieures à l’équipe. C’est bénéfique ! Les interactions sont bénéfiques ! Mais la simple distance, associée à quelques gaffes de communication, peut transformer une chose positive en une chose gênante. L’équipe se sent en dehors de la boucle et se sent moins en contrôle du résultat.
Souvent, le product management soulignera le fait que “les choses vont TRÈS BIEN, nous devons nous concentrer sur les bonnes choses !”
Essayez d’envisager :
- Cela ne signifie pas que vous ne pourriez pas faire mieux
- Cela n’explique pas comment les décisions du Product Manager ou de l’équipe ont contribué à ce succès (peut-être que le succès actuel est le résultat de paris placés il y a des années)
- Ce n’est tout simplement pas une manière très rigoureuse ou cohérente de faire valoir votre point de vue
Tout cela est mieux résumé dans une citation d’un développeur que j’ai pu croiser :
Nous passons toute la journée, tous les jours, responsables de ces fonctionnalités, de ces tickets. Scruté. Notre code doit fonctionner. Le système (QA) essaie littéralement de casser ce que nous faisons. Les gens comptent les « points » de notre vélocité. Lors du daily, on nous dit de nous lever et de rendre des comptes (NDT : bien mauvaise compréhension du dail). Où est maintenant cette même rigueur pour notre Product Manager ? Sur quels critères se basent-ils lorsqu’ils annulent ou contestent la valeur de notre travail ou de nos suggestions ? En fait, quand les choses tournent mal, on nous reproche simplement d’être lents.
Et donc ?
Alors, quel est mon point ?
Tout d’abord, l’évidence. La confiance est tellement importante. Je crois vraiment que nous entrons dans des relations de travail avec une combinaison de confiance pour nos coéquipiers ET le poids collectif des conflits passés. C’est pourquoi vous vous devez de travailler pour augmenter et préserver la confiance dans l’équipe et confronter vos propres stéréotypes à ceux qui vous entourent.
Deuxièmement, les Product Managers doivent être particulièrement conscients de la façon dont leur langage peut être interprété (en particulier lorsqu’eux-mêmes et leurs coéquipiers sont stressés et/ou impatients). C’est pourquoi je pense que les concepteurs et les ingénieurs qui passeront un jour dans ce rôle auront un petit avantage : ils savent comment les choses peuvent se passer. Ils ont été là. Par exemple, ils savent à quel point il peut être embarrassant de se faire relayer des informations de seconde main par des personnes de votre entreprise.
Troisièmement, notez comment la réponse # 4 peut aider pour tirer l’ensemble de l’équipe vers le haut. Vous voulez de la confiance ? Accordez la votre au collectif.
