Travailler avec les chefs de produit, par Sean Goedecke

Travailler avec les chefs de produit, par Sean Goedecke

La relation entre les ingénieurs et la direction produit est plus problématique qu’avec n’importe quel autre service de l’entreprise. Il n’y a ni culture ni langage communs, contrairement à ce qui existe entre ingénieurs, et les règles déterminant « qui a le droit de donner des ordres à qui » ne sont pas aussi claires qu’avec les managers. Les ingénieurs n’ont pas grand-chose en commun avec les services juridiques, de conception ou commerciaux, mais ils n’ont pas non plus besoin d’interagir beaucoup avec ces fonctions. D’après mon expérience, les ingénieurs communiquent avec les chefs de produit presque tous les jours.

Contre la « product mommy » (maman produit)

La pire version de la relation entre le produit et l’ingénierie se présente à peu près ainsi :

Les ingénieurs sont compétents sur le plan technique, mais trop autistes pour qu’on leur fasse entièrement confiance. Ils ont besoin d’une figure parentale à la fois bienveillante et stricte, qui sache communiquer avec les autres parties prenantes de l’organisation (par exemple, en utilisant sans gêne le mot « parties prenantes ») et empêcher les ingénieurs de s’égarer.

Toute cette dynamique déplaisante est parfaitement résumée par le terme populaire de « maman produit ». Je n’aime vraiment, vraiment pas ce terme, ni cette dynamique dans son ensemble. Presque aucune de mes relations avec mes chefs de produit n’a ressemblé à cela, même si j’ai pu l’observer de loin.

Une bonne collaboration avec les chefs de produit peut faire la différence entre la réussite et l’échec au sein d’une entreprise. Pourquoi est-il si difficile d’entretenir de bonnes relations entre l’ingénierie et le produit ? À quoi ressemble une bonne relation ?

Pourquoi est-il si difficile d’instaurer la confiance ?

Les chefs de produit et les ingénieurs possèdent des compétences qui ne se recoupent pratiquement pas. Les chefs de produit ne comprennent pas le travail technique des ingénieurs et ne sont pas en mesure d’en discuter : si un ingénieur donne une raison technique pour expliquer quelque chose, les chefs de produit doivent généralement hausser les épaules et répondre « d’accord, je suppose ». De même, les ingénieurs n’ont pas la même visibilité sur l’organisation que les chefs de produit. En particulier dans les grandes entreprises, c’est le chef de produit qui détient la vérité sur les attentes des utilisateurs et sur les fonctionnalités importantes. Lorsqu’un chef de produit affirme qu’une chose est cruciale, les ingénieurs n’ont généralement d’autre choix que de hausser les épaules et de répondre « d’accord, je suppose ».

Cela exige évidemment beaucoup de confiance. Ce qui l’est un peu moins, c’est que cette confiance est sans cesse trahie par les deux parties. Chaque chef de produit s’est entendu dire des milliers de fois qu’une tâche technique X était techniquement impossible ou aurait des conséquences désastreuses, pour finalement voir cette tâche réalisée sans encombre et avec succès. Chaque ingénieur s’est entendu dire des milliers de fois qu’une exigence X était absolument cruciale et méritait qu’on y consacre des efforts considérables, pour finalement voir cette exigence abandonnée en silence ou modifiée sans aucune excuse.

Bien sûr, il n’y a là aucune malveillance. Les ingénieurs donnent souvent des estimations erronées parce qu’il est impossible d’estimer avec précision, et parfois, les conséquences désastreuses dont ils mettent en garde se produisent réellement (elles sont simplement gérées en coulisses, comme les ingénieurs gèrent bien d’autres types de dysfonctionnements techniques). Les chefs de produit « changent d’avis » parce que ce qui est important dans une grande entreprise technologique change véritablement d’heure en heure, et même les meilleures tentatives visant à ne transmettre à l’équipe d’ingénierie que les priorités les plus fiables peuvent parfois échouer.

Manipulation et mensonges

La conséquence de cette rupture de confiance est que la relation devient très difficile à entretenir. Lorsque vous êtes ingénieur et que vous expliquez quelque chose à votre chef de produit, tout en sachant qu’il ne vous croit pas (alors qu’il n’est lui-même pas en mesure de juger de la question), cela peut être incroyablement frustrant. De même, lorsque vous êtes chef de produit et que vous essayez désespérément d’expliquer à un ingénieur ce que nous devons faire, tout en sachant qu’il hausse les épaules intérieurement, cela doit être insupportable. Ne savent-ils pas que c’est crucial pour l’entreprise ? Vous venez pourtant d’assister à une réunion avec les dirigeants de l’organisation !

L’outil naturel d’un chef de produit méfiant, c’est la manipulation. Je me souviens encore d’un chef de produit qui a tenté d’obtenir un engagement de mon équipe en nous demandant de faire le tour de la table et de dire tous : « Je m’engage à mener ce travail à bien en deux semaines », après une conversation au cours de laquelle nous avions expliqué les risques qui pourraient allonger les délais. Je suppose que l’idée était que nous travaillerions tous beaucoup plus dur, après avoir prêté un serment sacré ? Des variantes plus subtiles de cette approche consistent à laisser entendre que vous seriez vraiment déçu si ce travail prenait du retard (dans le plus pur style « maman produit »), ou à évoquer vaguement la possibilité d’une récompense abstraite (que le chef de produit n’a pas le pouvoir d’accorder) si le travail est terminé avant la date prévue.

L’outil naturel d’un ingénieur méfiant, ce sont les mensonges. La forme la plus bénigne consiste à exagérer les estimations : par exemple, le conseil classique qui consiste à doubler son estimation et à y ajouter 20 %. J’ai vu des ingénieurs prétendre avoir dû s’occuper de toutes sortes de tâches en grande partie fictives (un exemple courant est « contacter une équipe voisine pour confirmer X ») afin de gagner du temps. Dans le pire des cas, les ingénieurs peuvent même mentir ouvertement en affirmant que le travail a été achevé, puis enregistrer le retour « ça ne fonctionne pas en production » comme un bug.

Une fois que cela commence, il est presque impossible de réparer la relation. Je ne peux pas me résoudre à faire confiance à un chef de produit qui essaie clairement de me manipuler, et je suis sûr qu’un chef de produit ne peut pas faire confiance à un ingénieur qui lui a menti en face par le passé. C’est pourquoi il est si important d’éviter dès le départ de se retrouver dans une mauvaise relation.

Ne vous disputez pas avec le chef de produit

À quoi bon ? S’il est si difficile d’établir une bonne relation de travail avec les chefs de produit, pourquoi ne pas simplement se contenter d’une mauvaise relation ? Les chefs de produit peuvent tout à fait vous anéantir si vous ne faites pas attention.

Les chefs de produit sont presque toujours plus avisés sur le plan politique que les ingénieurs. Cela s’explique en partie par des raisons structurelles : les chefs de produit ont tout simplement davantage d’échanges avec les décideurs de l’entreprise, et entretiennent donc naturellement de meilleures relations avec eux (et sont donc mieux à même de sentir dans quelle direction souffle le vent). C’est aussi en partie un biais de sélection : les ingénieurs peuvent être embauchés même s’ils ont des compétences sociales relativement limitées, car ils sont principalement évalués sur leurs compétences techniques, alors que les compétences sociales constituent un élément essentiel du rôle de chef de produit³.

Si vous êtes en conflit avec un chef de produit, vous perdrez probablement. À moins que vous ne disposiez d’une influence hors du commun, il aura tout simplement bien plus d’occasions que vous de vous discréditer discrètement auprès des cercles influents. Il suffit de quelques remarques du type « Oh, je ne choisirais probablement pas Sean pour ce projet » pour ruiner votre réputation. Si vous êtes ouvertement en conflit avec un chef de produit, les dirigeants de l’entreprise prendront par défaut le parti de ce dernier plutôt que le vôtre. Ils le connaissent probablement mieux, partagent davantage de repères culturels avec lui et seront généralement enclins à interpréter la situation comme « encore un ingénieur qui ne comprend pas comment fonctionne l’organisation ».

Gagner la confiance d’un chef de produit présente d’énormes avantages. Les chefs de produit veulent livrer des produits, et comprennent généralement assez bien tous les obstacles non techniques à la livraison. Si vous souhaitez vous aussi livrer des produits, vous pouvez former une équipe redoutable.

De plus, comme la confiance entre ingénieurs et chefs de produit est si difficile à établir, une fois que vous y êtes, vous y êtes pour de bon. Les chefs de produit choisissent souvent un ou deux ingénieurs comme interlocuteurs privilégiés pour obtenir la « vérité » sur les questions techniques. Si c’est votre cas, vous disposez d’une influence hors du commun au sein de l’organisation, que vous pouvez utiliser pour faire avancer les projets qui vous tiennent à cœur.

Comment instaurer la confiance avec les chefs de produit ?

En tant qu’ingénieur, comment instaurer la confiance avec votre chef de produit ?

La première étape consiste à comprendre leur point de vue. Quand il vous dit que quelque chose est important ou qu’une exigence vient d’arriver, sachez que c’est rarement sa décision. Ce n’est pas lui qui vous mène en bateau, c’est quelqu’un de plus haut placé dans la hiérarchie qui vous mène tous les deux en bateau. Si vous pouvez adopter un état d’esprit complice avec lui, plutôt que contre lui, c’est un bon début. Essayez simplement de demander « Oh là là, d’accord, qu’est-ce qu’on peut faire là-dessus ? » au lieu de vous plaindre.

La deuxième étape consiste à avoir raison, très souvent. C’est un principe de leadership d’Amazon qui peut paraître ridicule, mais qui s’avère tout à fait juste. J’ai écrit davantage à ce sujet, mais (aussi injuste que cela puisse paraître), vous devez vraiment avoir raison la plupart du temps si vous voulez instaurer une relation de confiance avec un chef de produit. Lorsque vous dites qu’une fonctionnalité sera livrée, elle doit l’être ; lorsque vous dites que quelque chose est impossible, cela ne doit pas se produire quelques jours ou semaines plus tard. Il n’y a pas de mal à se tromper de temps en temps, mais vous devez établir une habitude consistant à leur fournir des informations techniques utiles et correctes.

La troisième étape consiste à les laisser prendre les décisions stratégiques la plupart du temps. Si vous attendez d’eux qu’ils fassent confiance à vos décisions techniques, vous devez leur accorder la même confiance lorsqu’il s’agit de naviguer au sein de l’organisation. Ne les discréditez pas publiquement lors des réunions ; exprimez vos préoccupations en privé. S’ils affirment que quelque chose est important et que vous n’en êtes pas tout à fait sûr, faites au moins comme si c’était le cas. Acceptez le fait qu’ils se trompent parfois, tout comme vous vous trompez parfois sur des questions techniques.

La quatrième étape consiste à avoir de la chance. Il arrive parfois que votre chef de produit soit tout simplement un bon à rien. Vous ne pouvez pas établir de relation de confiance avec une personne incompétente : vous n’avez aucune raison de lui faire confiance, et elle n’est pas en mesure de vous accorder sa confiance de manière constructive. Travailler au sein de grandes entreprises implique d’accepter le fait que certains de vos collègues seront plus compétents que d’autres, et de trouver des moyens de collaborer avec (ou de contourner) ceux qui compliquent le travail au lieu de le faciliter.

Les chefs de produit « techniques »

De nombreux chefs de produit ont d’abord été ingénieurs. Si votre chef de produit est technique, cela vous met-il à l’abri de ces problèmes ? Absolument pas !

Vous n’aurez probablement pas beaucoup de choix quant aux chefs de produit avec lesquels vous travaillerez, mais sachez qu’avoir été ingénieur est un point négatif, et non positif. Aucun chef de produit ne peut jamais être suffisamment technique pour que cela ait de l’importance, car il ne travaille pas sur le code : même s’il était ingénieur à temps plein, il n’aurait pas le temps d’acquérir la connaissance spécifique du système dont il aurait besoin pour participer réellement aux discussions techniques. Il vaut donc mieux avoir un chef de produit qui sait qu’il n’est pas technique plutôt qu’un chef de produit qui croit à tort qu’il pourrait l’être.

Le pire scénario est celui d’un ancien ingénieur devenu chef de produit qui se croit suffisamment technique pour détecter quand les ingénieurs lui mentent. Ce genre de paranoïa est un piège dans lequel les chefs de produit « techniques » tombent facilement, en particulier lorsqu’ils n’ont pas dans leur équipe d’ingénieur de confiance sur lequel s’appuyer. Si vous avez affaire à l’un d’entre eux, préparez-vous à passer beaucoup de temps à expliquer pourquoi vous ne pouvez pas « simplement » faire certaines choses (et préparez-vous à ce que ces explications ne soient pas crues).

Conclusion

Dans le pire des cas, la relation avec un chef de produit s’apparente à une famille malsaine : elle est marquée par la condescendance, la manipulation émotionnelle, les mensonges et la méfiance. Ce n’est pas parce que les chefs de produit sont de mauvaises personnes ! C’est parce que la structure même de la relation engendre des conflits. Les deux parties doivent prendre des engagements (concernant le système technique ou les objectifs de l’organisation) qui sont (a) souvent erronés, et que (b) l’autre partie est incapable de vérifier de manière indépendante. Pour éviter ce piège, les deux parties doivent faire preuve de générosité, être disposées à se faire confiance mutuellement dans leurs domaines d’expertise, et surtout, être compétentes.

Source : Working with product managers

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Réussir à « faire avancer les choses » dans les grandes entreprises technologiques, par Sean Goedecke

Les microservices sont un coût que votre startup ne peut probablement pas se permettre, par Oleg Pustovit

Pourquoi vous ne devriez pas supprimer des fonctionnalités : Lettre d'amour d'un développeur au code « impopulaire », par Kush Creates