Dans le cadre de notre fonction de Product Manager, une partie non-négligeable de notre rôle pourrait se résumer en ces quelques mots : “Créer des liens”. Des liens entre les équipes marketing et les problématiques techniques, entre les équipes techniques et les contraintes métiers… Mais c’est avant tout établir des connexions entre des personnes : de divers services, de divers backgrounds. A commencer par les développeurs de notre propre équipe.
Dans la plupart des équipes dont j’ai fait partie ou que j’ai pu observer, l’état de la relation et la qualité de la communication entre PM et développeurs m’a toujours semblé être un excellent indicateur de la “santé” de l’équipe. On ne peut que déplorer les cas, où les développeurs ont l’impression de subir les choix du PM ; et ceux où un PM se sent prisonnier d’une équipe de développeurs remettant en cause tous ses choix.
Un Product Manager, des développeurs, une seule équipe
Il ne faut jamais oublier que le Product Manager est un membre de l’équipe à part entière et à ce titre les difficultés techniques auxquelles font face les développeurs sont ses difficultés, et le PM se doit d’être compréhensif et actif dans la résolution de ces problèmes.
Parler la même langue
Le langage est aussi un élément important, même sans avoir de background technique, il est important qu’un PM soit en mesure de suivre dans les grandes lignes un débat technique entre les devs de son équipe. La compréhension et l’utilisation du vocabulaire technique approprié fera sentir à vos coéquipiers que vous montrez de l'intérêt pour leurs problématiques techniques. Dans la mesure de ses connaissances techniques, il est important pour un PM de manifester une réelle curiosité pour l’environnement technologique des développeurs afin de démontrer son implication au reste de l’équipe.
Rassembler l’équipe
Pour souder l’équipe, il ne faut pas négliger aussi le fait de savourer ensemble les réussites. Toujours dans l’esprit “d’établir des liens”, une des fonctions du Product Manager dans l’équipe est aussi de faire partager à l’équipe les compliments et remarques positives (ou négatives) qu’il est susceptible de recevoir des stakeholders ou de tout autre personne sur la qualité du produit, la vélocité de la mise en production d’une fonctionnalité… Ces feedbacks doivent être transmis à l’équipe systématiquement et le plus rapidement possible, il est très important pour le PM de faire en sorte que toute son équipe soit sur un même niveau d’information. Ces petits mots peuvent paraître anodins mais c’est cela qui permet à l’équipe de se rassembler autour d’objectifs et d’avancer ensemble. Un déjeuner ou une petite sortie d’équipe de temps à autre est aussi tout à fait indiqué. :)
S’appuyer sur l’équipe pour concevoir
Dans une équipe où l’on partage les bons et les mauvais moments, de l’empathie mutuelle va se créer, les développeurs deviendront alors vos meilleurs alliés dans la réflexion autour de votre produit. Communiquer avec les développeurs sur vos stories à venir de manière fluide et en amont des cérémonies “officielles” pourra vous permettre de faire émerger une problématique ou une incohérence dans une de vos user-stories. Ces discussions avant le backlog refinement ou la planification pourront ainsi vous faire gagner un temps précieux.
De plus, il ne faut jamais négliger la plue-value fonctionnelle que peut vous amener une bonne communication avec les développeurs. Ils baignent dans le produit à longueur de journée, au moins autant que vous, et sont donc à même d’apporter des réflexions constructives sur l’évolution du produit. Lors des refinements ou lors des discussions plus “off”, je n’hésite jamais à demander l’avis de l’équipe sur une feature, un design, ou à leur exposer mes doutes, cela donne très souvent lieu à des réflexions très constructives et la fonctionnalité en ressort plus aboutie.
Ces discussions ont aussi pour effet bénéfique de générer une sensibilité pour le produit de la part de l’ensemble de l’équipe, mais c’est aussi une marque de confiance du PM envers son équipe que d’aborder ce genre de sujet avec les développeurs.
Établir une relation de confiance
Vous devez avoir confiance en vos coéquipiers tout comme ils doivent avoir confiance en vous. Ils comprendront et accepteront alors beaucoup mieux votre priorisation et votre vision.
Ne pas isoler l’équipe des réalités
Tout comme les développeurs se doivent de communiquer sur les contraintes techniques qui peuvent vous impacter (remboursement de la dette technique, installation d’un nouvel outil...), il est essentiel que vos coéquipiers développeurs aient conscience de vos contraintes fonctionnelles (deadlines, interlocuteurs...), ce sont autant d’informations qui aideront l’équipe à comprendre vos choix, vos priorisations.
De plus, il est très important de ne pas isoler l’équipe du “monde réel”, les développeurs ne travaillent pas pour vous, ils travaillent pour un produit, pour des utilisateurs. Il est donc essentiel que le PM le fasse ressentir à son équipe en donnant toujours du contexte métier, marketing, utilisateur aux développements priorisés.
Donner du sens à leur travail ne rendra que meilleure la qualité de leurs développements ! Intégrez vos développeurs dès la phase de Stratégie, ainsi que dans vos activités de Discovery : il est recommandé de créer des interactions directes entre les développeurs et les différentes parties prenantes, voire même les utilisateurs.
Un développeur qui participe à des interviews, à des brainstorms, à des ateliers de priorisation, à des tests de prototypes... comprendra d'autant mieux les choix qui ont été faits et saura les défendre après du reste de l'équipe.
Emmener l’équipe avec soi
La confiance que vous porteront vos développeurs sera aussi fortement liée à votre capacité à rester rigoureux et stable dans la gestion de votre produit. Les développeurs sauront accepter vos choix s’ils savent que ce sont les vôtres, qu’ils sont justifiés et fruits d’une réelle réflexion. Il est compliqué de demander à une équipe de suivre un PM sur un chemin qu’il ne maîtrise pas où il n’a pas toutes les cartes en main et où la direction change à chaque nouveau sprint de développement.
Cet élément est aussi à mettre en lien avec la protection de l’équipe qui est une des fonctions du PM. Un PM “influençable” et n’avançant pas sur une stratégie claire aura tendance à accepter trop de demandes parasites, ou à changer de priorisation trop souvent, ce qui peut avoir pour effet de le décrédibiliser auprès de l’équipe.
Vous devez montrer aux développeurs que vous avancez sur une voie claire et cohérente, cela passe par de la communication, de l’organisation, avoir un backlog clair, commencer à aborder les sujets avec l’équipe le plus tôt possible.
Un leader, mais pas un chef
À aucun moment le PM n’est le chef des développeurs, c’est ce qui rend le challenge d’arriver à fédérer une équipe autour d’une vision d’autant plus difficile et intéressant. Le bon PM devrait chercher à être un leader et par définition, à convaincre par d’autres moyens que celui de la classique hiérarchie. Sa vision doit être claire, partagée mais aussi challengeable, et c’est ce point qui en fera quelque chose qui n’est pas imposé et que chacun peut s’approprier. Le PM doit avoir la détermination de mener à bien sa stratégie mais doit aussi avoir l’écoute nécessaire pour prendre en compte toutes les remarques afin d’intégrer celles qu’il jugera pertinentes.
Il doit être à la base d’une réelle collaboration avec les développeurs où chacun apporte ses compétences au service d’un objectif commun. Aucun membre de l’équipe n'obéit aux ordres d’un autre, mais chacun doit tâcher de mettre son expertise au service du produit. Et c’est en communiquant et en écoutant ses coéquipiers que le PM arrivera à libérer la force de proposition de chacun d’entre eux. C’est en étant à la fois le rassembleur et le porteur d’objectifs co-construits par l’équipe que le PM peut s’imposer comme un leader.
En conclusion
Le mot d’ordre de cette relation développeur-PM est donc la confiance, mais aussi le partage : des difficultés, des objectifs… Votre roadmap et vos contraintes Produit ne doivent avoir aucun secret pour les développeurs, et il est important que les développeurs souscrivent à la vision Produit, dont vous êtes le garant mais que chacun doit s'approprier.
Pour arriver à cela, l’implication des développeurs dans l’établissement de la roadmap produit est crucial, en terme d’estimation de la charge, de faisabilité, d’ordonnancement et aussi tout simplement en terme de cohérence produit. Par exemple dans le cadre d’un atelier de co-création de roadmap “Buy A Feature”, il est assez aisé de faire participer l’équipe aussi bien dans la préparation de l’atelier que dans l’atelier en lui-même afin que les développeurs aient un réel rôle dans la construction de la roadmap.
Au delà du travail opérationnel lié au produit, la fonction de Product Manager impose aussi de faire face à un challenge humain. De part sa position centrale, il doit convaincre sans imposer, être à l’écoute tout en gardant ses convictions…
C’est un des principes même de l’agilité de mettre l’humain au centre des processus et il est donc fort logique que cette composante relationnelle ait une grande importance dans le quotidien du Product Manager. Négliger cet aspect de la fonction reviendrait à ne pas exploiter le plein potentiel de son équipe, et ainsi se priver d’une force de frappe supplémentaire dans l’amélioration de votre produit.
Pour aller plus loin : Télécharge notre livre Les Clés du Product Management
