EasyTech #15 - 10 conseils pour une meilleure relation PM / dév

De l'actionnable, tout de suite, pour une relation 🔥

Salut à toi,

J’espère que tout va bien de ton côté.

Ce week-end j’étais à Bordeaux pour un anniversaire, il a fait très beau c’était génial 🙌 par contre j’ai cassé mes lunettes 😱 Heureusement j’ai pu finalement changer ma monture 😃

Aujourd’hui j’aimerais donner des recommandations très concrètes sur comment interagir avec les développeurs. Je vais utiliser de vraies anecdotes pour que ça soit le plus illustré.

Trois petites histoires pour démarrer

Laisse-moi te raconter trois histoires que j’ai vécues dans 3 contextes différents. Elles illustrent différents aspects de la relation PM / développeur.

Un SaaS de gestion RH

Contexte

→ La boîte

À l’époque je travaillais dans le conseil (chez BearingPoint). On faisait du conseil en “organisation” / management. En gros, on aidait les clients à se transformer notamment en assistant leur digitalisation. C’était génial comme boulot !

Or, on avait pas mal de missions autour des Ressources Humaines pour aider les boîtes à prédire l’évolution de leurs masses RH. Par exemple, j’ai 10% de mes employés qui ont plus de 60 ans ; alors j’aide le client à anticiper que d’ici 5 ans ces 10% seront partis. Donc qu’il faut les remplacer.

Vu qu’on faisait pas mal ce type de missions, on avait décidé de développer un produit pour outiller. Du coup on aurait deux types d’utilisateurs :

• (1) des consultants qui l’utiliseraient en mission pour être plus efficace ;

• (2) des clients qui le donneraient à leurs équipes pour faire ça eux-mêmes.

→ Le produit

Pour simplifier, le produit faisait deux choses :

• Stocker des bases de données RH qu’on pouvait visualiser

• Créer des règles pour modéliser l’évolution de l’organisation / de la base de données RH

→ L’organisation produit

On avait des développeurs internes et moi qui était PO pour ce produit. Il y avait un “directeur de projet” qui pilotait de manière assez resserrée, plusieurs heures par semaine. Puis des sponsors, de plus haut niveau, qu’on voyait tous les 2-3 mois.

Anecdote

📝 Première anecdote : le rituel

Ça faisait 2 ou 3 mois qu’on bossait sur le produit. Il y avait toujours pas mal de bugs, mais globalement ça avançait. Petit à petit. On arrivait plus ou moins à intégrer des bases de données dans l’application. Et on arrivait plus ou moins à créer des règles de calcul pour faire évoluer la base de données.

J’avais une relation extrêmement proche avec le Lead Developer, on l’appellera J. Il était plus âgé que moi. Très patient, très gentil, très sympa. C’était compliqué parce que le sponsor me mettait beaucoup de pression pour mettre en place des nouvelles fonctionnalités. Alors, j’allais souvent le voir pour lui demander “où ça en était”. On était quasi voisins. Mon open space était à 10 mètres du sien. Du coup je faisais le trajet 5 fois par jour pour demander à J où ça en était.

C’était presque un rituel au final :

• J’allais le voir et je lui demandais où ça en était ; souvent il m’expliquait que c’était un peu galère et qu’il était en train de résoudre les derniers problèmes

• Puis en général, quand il réussissait à craquer le truc, trouver la solution. C’est lui qui venait me voir pour que je teste direct la fonctionnalité.

Quand je le voyais arriver de son open space. Lui qui ne venait quasiment jamais alors que moi je venais super souvent. Je savais qu’il venait me donner une bonne nouvelle. Surtout qu’il avait du mal à masquer son sourire.

Souvent on dit que le PM est “responsable” du produit mais quand tu as vécu ce genre de situations. Tu sais à quel point les développeurs mettent du coeur à l’ouvrage et veulent faire le mieux possible. Quand tu as vu ce sourire du dév qui vient te voir direct, alors qu’il pourrait juste attendre 1h avant que tu te déplaces. Tu as compris.

📝 Deuxième anecdote : la démonstration

Pourtant tout ne s’est pas toujours bien passé. Globalement tant qu’on restait dans notre routine et nos rituels ça allait. J’étais habitué à ce que l’application ne marche pas forcément parfaitement.

Je connaissais par coeur les messages d’erreur de l’application et tous les contournements pour réussir à faire fonctionner le produit coûte que coûte. Par exemple, quand on importait le fichier Excel, il y avait souvent des soucis au niveau de l’encodage. Certains caractères spéciaux : accents (é,è,ê) notamment ne marchaient pas bien. J’avais toute une manip pour changer l’encodage directement à la main. Là où ça aurait sûrement été plus efficace de changer direct dans l’outil.

Mais un jour on prévoit une démonstration avec le big chef. Le big sponsor qui avait poussé le projet depuis le début. Pas le sponsor / directeur de projet qui me mettait la pression pour aller voir J dans l’open space.

On se prépare pour la démonstration mais par malchance, on venait de déployer une nouvelle fonctionnalité quelques minutes avant. Résultat : avant ça marchait pas tout le temps tout le temps ; mais là ça marchait carrément plus, il y avait des messages d’erreur dans tous les sens, bref pas ouf.

Sur le moment, tout le monde s’est rendu compte qu’il y avait un problème sauf moi. Le directeur de projet, le big sponsor, le développeur avec lequel je bossais, l’équivalent du CTO etc…

À force j’avais tellement l’habitude qu’il y ait des problèmes, des bugs… que ça semblait normal.

La démo s’est donc très mal passée, et à la fin on a débriefé avec le directeur de projet. On a décidé que j’irai à plein temps dans l’open space avec l’équipe de dév et J, pour voir si ça allait mieux et s’il y avait moins de problèmes.

📝 Troisième anecdote : le brainstorm

Un matin j’arrive comme tous les autres matins et je vais dire bonjour à J. Il n’était pas là pendant 2 jours la semaine dernière parce qu’il était allé à une conférence avec la présentation de plein de start-ups.

C’était peut-être Viva Tech d’ailleurs 🤔 ou une autre conférence dans le genre.

Dès que je lui ai dit bonjour, j’ai vu qu’il avait les yeux qui pétillaient 😍

Il m’a expliqué qu’il avait été assister à plusieurs pitchs de start-ups de la RH tech et que ça lui avait donné plein d’idées :

• Rajouter telle fonctionnalité à tel endroit

• Permettre de monitorer tel KPI RH

• Etc…

J’ai été hyper étonné et agréablement surpris du fait qu’il avait plein plein de suggestions ! OK, toutes n’étaient pas exceptionnelles. Mais c’était impressionnant à quel point il maîtrisait bien aussi les enjeux métier, et à quel point il était heureux d’être force de proposition.

Au final, je crois qu’on n’a jamais mis en place ces fonctionnalités. Mais je n’oublierai la flamme qu’il avait eu pour me proposer ses idées.

Une application pour l’administration

Contexte

→ La boîte

J’étais encore dans le conseil mais cette fois je travaillais pour un client dans le secteur public ! On bossait pour automatiser le traitement de dossiers pour permettre à l’administration d’être plus efficace.

→ Le produit

Comme je disais, l’objectif du produit était d’automatiser un certain nombre de traitements et d’interactions avec des systèmes informatiques.

• Je récupère des informations sur un citoyen

• Je recoupe ces informations avec d’autres bases de données

• Je traite ces informations en fonction de règles métier

On était donc plutôt sur des fonctionnalités “back-office”. Il y avait quelques utilisateurs finaux mais principalement des traitements qui s’effectuaient sans action humaine.

→ L’organisation produit

J’intervenais comme “Product Manager” ou plutôt proxy-Product Manager puisque le “vrai” Product Manager était chez le client donc au sein de l’administration publique.

Deux spécificités à l’organisation produit :

• 1️⃣ on était organisé en agile à l’échelle, en mode SAFe. Du coup en tant que PM, j’avais la responsabilité de superviser 4-5 équipes et pas une seule - d’où le “à l’échelle”.

• 2️⃣ les équipes de développement étaient externalisés et c’était une ESN / SS2I qui fournissait ces ressources. C’est important parce que le pilotage aurait été un poil différent dans un autre contexte plus internalisé.

Anecdote

📝 Première anecdote : les PIs plannings

En SAFe, on pilote plusieurs équipes et on organise des séances de planification tous les 3 mois afin de définir le planning pour l’ensemble de ces équipes : on appelle ça les PI plannings (un PI c’est l’équivalent à l’échelle d’un sprint). Ensuite il y aura une planification au niveau de chaque équipe avant de démarrer les “sprints”.

Ces “PI plannings” sont un moment très sympa. Il y a une centaine de personnes regroupée dans un petit espace. Chaque équipe a son coin et travaille sur des fonctionnalités, les découpe et les priorise. En tant que Product Manager, tu te balades pour être sûr que tout se passe bien. Tu incites également les experts métier à venir discuter avec les équipes.

Un moment que j’aimais beaucoup, c’était la fin de cette séance de planification. Chaque équipe présentait son planning pour les 3 mois à venir au Product Manager. Concrètement, un des développeurs détaillait les différents items en expliquant pourquoi certains choix avaient été faits. Si possible en parlant en termes business “on va résoudre tel problème” et non pas en termes solution / techniques “on met en place telle librairie Java”.

J’aimais beaucoup ce moment parce que je challengeais et je demandais pas mal d’explications :

• Pourquoi vous avez découpé comme ça ?

• Pouvez-vous me détailler ce qu’il y a derrière au niveau technique ?

• Pourquoi vous estimez que telle fonctionnalité va prendre xx jours ?

Attention, je ne le faisais pas systématiquement sur chaque fonctionnalité en mode “pinailleur” / pointilleux. En revanche, des aspects me surprenaient, je le faisais. En tant que PM, il faut être vigilant à ne pas donner l’impression de se prendre pour un développeur ou pour un CTO.

Pour autant, poser des questions, demander de détailler, c’est aussi montrer qu’on s’intéresse et valoriser l’expertise du développeur qui explicite les choix.

Ça m’a d’ailleurs toujours permis de renforcer mes relations avec les développeurs.

📝 Deuxième anecdote : les démonstrations de fin de sprint

On déroulait notre planning de 3 mois. Et toutes les 2 semaines on avait un point de passage obligé à la fin des différents sprints qui jalonnaient cette période de 3 mois. En agile, c’est important de se forcer à faire des démonstrations régulièrement à l’utilisateur pour deux raisons :

• 1️⃣ récupérer régulièrement du feedback de celui-ci

• 2️⃣ livrer de la valeur de manière incrémentale

Je me rappelle la fois où un développeur qu’on appellera F a présenté le travail qu’il avait réalisé. C’était une fonctionnalité pas facile. On avait dû faire bosser F, justement parce qu’il était senior et expérimenté. C’était assez crucial de réaliser cette fonctionnalité car pas mal d’autres fonctionnalités en dépendaient.

Deux choses importantes et qui m’ont marquées :

• À la fin de la démonstration de la fonctionnalité par F, tout le monde a applaudi. En vrai, on applaudissait à chaque fois, pour chaque fonctionnalité. Mais là, on ne forçait pas le truc. Il nous avait vraiment sauvé la mise. Je me suis rendu compte à quel point cette célébration était importante. Au fond, on développe pour un utilisateur mais aussi pour l’équipe, pour pas laisser les autres dans la m*rde.

• Une fois que F a fini de présenter la fonctionnalité, c’était aussi mon rôle, en tant que PM, de faire un mini commentaire et/ou de faire des feedbacks pour corriger d’éventuels points. J’ai félicité F, très clairement, très explicitement. En rappelant que c’était une fonctionnalité cruciale et sensible. Et qu’il avait travaillé vite et bien sous pression. Par la suite, j’ai toujours fait très attention à féliciter très vivement les développeurs, en les appelant par leur prénom, en leur disant merci, devant tout le monde. C’est important.

Un réseau social interne

Contexte

→ La boîte

Chez L’Oréal, je développe des outils pour aider les employés.

Ça peut être pour des employés côté “coeur de métier” = construire des produits cosmétiques, les produire à grande échelle et les marketter pour les vendre.

Parfois ça peut également être sur des aspects plus transversaux, pour renforcer l’efficacité d’une expertise.

→ Le Produit

C’est le cas de ce produit. L’objectif était d’améliorer l’efficacité des projets incluant de la Data Science en créant une plateforme pour partager des bonnes pratiques, des retours d’expérience et des exemples de modèles sur étagère.

Donc c’est une sorte de plateforme de “knowledge management” (partage de la connaissance).

→ L’organisation produit

Je bosse dessus en tant que PM avec une équipe composée de data scientists, data ingénieurs et développeurs d’une boîte de prestataires. Il y a également un Product Owner issu de cette boîte.

On fonctionne en agile avec des démos régulières mais sans forcément se prendre trop la tête sur “est-ce que c’est du Scrum / Kanban / Shape Up ?”.

Anecdote

💡 Première anecdote : un pilotage light

Pour développer ce produit, mon implication auprès des développeurs était plus limitée. En particulier, j’échangeais surtout avec le PO.

C’était la conséquence de deux choses :

• D’abord je bossais sur d’autres sujets en parallèle. Je devais avoir autour de 33% de mon temps alloué au produit. Donc je n’avais pas suffisamment de temps pour porter en tant que PM l’ensemble du développement du produit.

• En plus, il y avait un PO qui me complétait très bien et effectuait un pilotage plus opérationnel. Je ne sais pas si le terme PO était adapté pour lui, ni si PM l’était pour moi. Toujours est-il que lui était à 100% auprès des dévs, à suivre l’avancement des dévs. Et que moi j’étais en second rideau mais avec des échanges réguliers avec lui.

Ce genre de fonctionnement peut un peu étonner. Notamment c’est pas forcément qu’on le présenterait dans la littérature (on préfèrerait sûrement avoir 1 PM interne qui suive tout à 100% ; des développeurs internes si possible ; pas un doublon PO / PM…) Mais franchement ça marchait bien :

• Au niveau technique, on n’avait pas trop de soucis pour tout construire. L’application était pas trop complexe. Globalement ça revenait à créer une sorte de Medium pour que des gens puissent créer des articles sur certains sujets. Et il y a pas mal de briques “low-code” sur étagère pour faire ça rapidement.

• En outre, j’avais une visibilité suffisante grâce aux réunions qu’on avait. Toutes les 2 semaines on avait un point de pilotage global avec l’équipe ; c’était un mix entre 1️⃣ une démonstration ; 2️⃣ une rétro ; 3️⃣ un point d’avancement

En revanche, attention avec ce type de fonctionnement :

• Déjà on a moins de proximité avec les dévs. C’est un peu automatique. Ça veut dire que potentiellement on n’a pas l’intimité que j’avais dans les premières anecdotes avec J. Ce n’est pas un problème en soi quand tout va bien. En revanche quand les choses se corsent, le fait de ne pas avoir investi dans la relation peut faire que les problèmes deviennent plus durs à résoudre.

• De même, quand c’est toi le PM “interne” et qui porte le budget, il faut être carré et savoir bien suivre l’avancement. Ça veut pas dire fliquer ou être désagrébable ou micromanager. Mais ça signifie qu’il faut être conscient du fait que la visibilité est moins bonne à 33% qu’à 100%. Donc s’organiser pour récupérer les éléments structurants.

💡 Deuxième anecdote : un déploiement douloureux

Le travail sur le produit avançait bien ! Et comme évoqué, j’avais plutôt une bonne visibilité. Pourtant attention, la release “finale” et l’ouverture aux utilisateurs arrivaient. Avant, on avait déjà des utilisateurs, mais un petit volume. En plus, on avait peu communiqué autour de l’appli.

J’étais assez serein car quand j’utilisais l’appli je trouvais ça plutôt clean. On déployait quasi tout le temps en production. Donc je savais ce que verraient les utilisateurs finaux : ce que je voyais moi tous les jours sur mon ordi. Et c’était OK pour moi.

De manière générale, je vous conseille au max de privilégier ce genre de fonctionnement où on n’accumule pas plein de développements et de fonctionnalités sur un environnement avant la production. Essayez de déployer au fur et à mesure, progressivement sur l’environnement de production auquel les utilisateurs pourraient potentiellement avoir accès.

Bref, j’étais assez confiant et pas très inquiet. Problème : 2 heures avant le déploiement, le Tech Lead qu’on appellera TL m’envoie un message. Il me dit “ça marche pas, certains scénarios n’ont pas été testés et ont l’air de bugger, il faut repousser”. Je checke et effectivement, ces scénarios ne fonctionnaient pas ! J’avais pas repéré ça parce que c’était des use cases un peu pointus… pas le genre de manip’ que j’imaginais. Mais TL, ça le dérangeait. Donc il voulait qu’on repousse la relase histoire d’avoir fini tous les tests.

Bon autant dire que j’étais pas trop ravi. Au final, on a discuté, on a décidé qu’on allait se débrouiller pour déployer quand même et clairement expliquer que ces scénarios un peu pointus n’étaient pas encore full opérationnels.

J’ai tiré pas mal d’enseignements de ça :

→ 1️⃣ Dans ce genre de situations, il faut vraiment que ça soit très grave pour ne pas déployer. Le genre de situation comme la démo avec le sponsor dans l’anecdote plus haut. Sinon franchement allez-y, poussez en production et montrez aux utilisateurs. Ils vous feront des feedbacks, vous vous améliorerez. Et si vous ratez ce lancement, vous pourrez toujours refaire un lancement réussi 3 mois plus tard.

→ 2️⃣ Attention de bien échanger régulièrement avec les dévs, avec TL. Il faut être au courant de leurs attentes, de leurs lignes rouges etc… Le fait que je n’aie pas eu en visibilité ce point d’attention de TL était lié au fait que mon pilotage était light. Mais ça n’est pas une excuse comme je l’ai dit. J’aurais dû être vigilant et investir du temps pour mieux capter les enjeux de TL.

Au fond, ça ne m’aurait pas trop dérangé de décaler le déploiement si ça avait été justifié. Mais la discussion avec TL était compliquée. Le moment était stressant. Donc j’aurais préféré qu’on discute de tout ça plus en amont, dans un autre contexte.

Bref, ne sous-estimez jamais le risque de ne pas assez communiquer.

---

---

Pourquoi une bonne relation PM / développeur est compliqué et important

Des mondes différents

Plusieurs éléments expliquent pourquoi cette relation peut être compliquée.

Premièrement, la culture française

En France les développeurs ne sont pas assez valorisés. C’est étonnant parce que les études d’ingénieurs par exemple, sont très bien vues. Et un boulot de développeur est un boulot d’ingénieur. En revanche, le statut social d’un développeur ne suit pas le prestige des études d’ingénieurs et du boulot d’ingénieur. C’est dommage.

Deuxièmement, la vision développeur = exécutant

On a trop tendance à faire une analogie entre un développeur et l’exécutant dans des métiers manuels. Le PM serait l’architecte ou le chef de chantier. Le développeur lui serait l’ouvrier qui assemble des briques. Et de cette analogie découle un jugement de valeur avec 1️⃣ un lien hiérarchique implicite entre PM et développeur ; 2️⃣ un travail du développeur qui serait jugé moins poussé intellectuellement.

Troisièmement, la complexité sous-estimée du développement logiciel

Sur la forme, on a vu que l’analogie développeur = exécutant est désagréable à vivre pour les principaux intéressés. Sur le fond, cette analogie est trompeuse. Le développeur n’est pas un exécutant. En tout cas, ce n’est pas du tout la bonne manière pour bosser efficacement avec lui. Il faut responsabiliser le développeur, s’appuyer sur son expertise et lui donner de la marge de manoeuvre pour résoudre des problèmes complexes.

Quatrièmement, une incompréhension de la technique

Les profils non-tech, PMs ou sponsors, manquent de compréhension des enjeux techniques. Évidemment, ça n’est pas leur métier. La plupart des PMs n’ont jamais écrit de lignes de code. Donc forcément, délicat de se projeter dans ces activités. Pour autant, il faut au maximum faire preuve d’empathie vis à vis des développeurs, surtout quand on ne saisit pas dans le détail l’enjeu de leur travail.

Cinquièmement, la réticence des dévs à montrer leur quotidien

Tout n’est pas de la faute des profils non tech. Souvent j’ai observé des profils tech qui demandaient “qu’on les laisse tranquille”. Ça se traduit par le fait de ne pas vouloir trop expliquer leur travail et ses enjeux aux PMs / sponsors. Je pense que c’est aussi une réaction aux éléments vus plus haut. “Vous ne faites pas d’efforts, pourquoi j’en ferais moi ?” C’est compréhensible mais ça renforce le manque de communication et ses conséquences négatives.

Des mondes différents… qu’il faut réconcilier

Ça va sans dire, on a besoin de relations saines entre les profils tech et les profils non-tech au sein de nos équipes.

Raison 1 : Le besoin d’applications de qualité

Quand on parle de qualité pour un logiciel, ça renvoie à deux éléments : 1️⃣ le fait d’apporter de la valeur à l’utilisateur final ; 2️⃣ le fait de ne pas avoir trop de bugs, d’avoir de bonnes performances, bref d’avoir une application bien conçue.

Or on s’en doute, les développeurs ont un impact direct sur cette “qualité technique”. Ce sont eux qui rédigent les lignes de code qui composent l’application et s’assurent qu’elles répondent aux bons besoins métier.

Aussi, plus la relation est dégradée avec les développeurs, plus on a le risque que cette qualité soit moins élevée.

Raison 2 : Une bonne ambiance d’équipe

Pas possible de développer un logiciel tout seul dans son coin. C’est juste trop complexe. On a besoin de trop d’expertise. C’est donc un travail d’équipe, avec plusieurs disciplines. Et quand on travaille en équipe, c’est toujours plus efficace quand l’ambiance est bonne. Ça paraît évident en le disant. Mais ne négligez jamais l’impact d’une mauvaise ambiance d’équipe sur la qualité de ce qui est produit par celle-ci.

Raison 3 : La créativité des développeurs

Marty Cagan, le pape des PMs, estime que “50% des idées produit doivent venir des ingénieurs / développeurs”. L’anecdote avec J plus haut le montre bien. Les dévs ont des idées pour les produits, ils sont créatifs. Est-ce que toutes ces idées sont bonnes ? Non évidemment. Mais est-ce que toutes les miennes sont bonnes ? Non plus.

S’agissant des idées, plus on en a, mieux c’est. De la quantité vient la qualité. Un point c’est tout.

Raison 4 : Répartir plus efficacement la charge

Le quotidien d’un PM est intense. Beaucoup de réunions, pas mal de pression. Il faut s’organiser efficacement. Et réussir à ne pas faire des tâches qui n’ont pas d’intérêt ou valeur ajoutée. Dans cet objectif, valoriser les développeurs et les responsabiliser n’a que des avantages. Par exemple, si tu dois préparer une restitution à un sponsor, propose à un développeur d’effectuer une partie de la présentation sur le travail qu’il a fait. Ça le met en avant et ça te fait moins de travail. Win / Win.

Raison 5 : Des mauvaises priorisations

Enfin, c’est important côté PM de bien s’assurer 1️⃣ que les développeurs ont tous les éléments en tête s’agissant du backlog et des priorités. Et 2️⃣ que les développeurs ont leur mot à dire pour influencer ces priorités ! Comme vu au dessus, les dévs ont leur mot à dire sur les aspects fonctionnels et techniques. Inversement, s’ils ne sont pas suffisamment impliqués, on risque de prendre de mauvaises décisions.

---

Dix conseils actionnables

#1 Brainstormer tous ensemble

Au niveau business, métier, il faut inclure tout le monde dans la réflexion et dans les brainstormings.

• Déjà parce que plus les opinions sont diversifiées autour de la table, plus on a de chance d’avoir des idées innovantes

• Ensuite parce que les développeurs ont d’autres manières de voir les choses, d’autres approches, ce qui rend ces discussions d’autant plus riches

💪 Actions

⇒ Organiser toutes les 2 semaines des sessions de brainstorming

⇒ Créer une “boîte à idées” dans laquelle, chacun note les idées produit (qu’on peut vider toutes les 2 semaines à la réunion)

#2 Créer un lien utilisateur / développeur

En tant que PM, on a tendance à vouloir garder à son niveau la relation avec l’utilisateur. Pour des raisons qui partent d’un bon sentiment :

• On a peur qu’utilisateurs et dévs ne se comprennent pas bien

• On a le sentiment que c’est notre responsabilité

Pourtant, il y a tout à gagner à créer ce genre de liens :

• 1️⃣ ça libère du temps pour le Product Manager (c’était la raison 4 sur répartir la charge)

• 2️⃣ ça réduit le risque d’incompréhensions et de quiproquos en réduisant le nombre d’intermédiaires

• 3️⃣ ça permet à chacun de monter en compétences, utilisateur sur la tech, développeur sur le métier

💪 Actions

⇒ Organiser des sessions de “shadowing” (où on observe l’utilisateur interagir avec l’application) avec les développeurs

⇒ Créer des rendez-vous toutes les 2 semaines avec un groupe de quelques utilisateurs qui donnent des feedbacks aux développeurs. Sans PM.

#3 Valoriser et mettre en avant ses collègues

De la même manière que le PM a parfois le sentiment de devoir contrôler à son niveau la relation avec l’utilisateur, le PM a parfois le sentiment de devoir gérer la communication vis à vis des chefs et sponsors. Forcément, il est plus habitué à ça ! Et les développeurs eux-mêmes ne sont pas toujours motivés pour se plier à ce genre d’exercice.

N’hésitez pas à justement forcer ce genre de situations, tout le monde y gagne, surtout les développeurs que ça permet de valoriser en les mettant “dans la lumière”.

💪 Actions

⇒ Applaudir et féliciter de manière très explicite à la fin des démos, comme je le racontais dans l’anecdote au-dessus

⇒ Inclure systématiquement dans les grandes présentations, une partie présentée par les ingés (dévs, data scientists etc…)

#4 Se challenger de manière constructive

Des deux côtés, il faut qu’il y ait des échanges constructifs et du débat.

Côté dév : c’est important également de challenger les décisions et choix des PMs. Est-ce que tel écran ne peut pas être amélioré ? Pourquoi avoir privilégié telle fonctionnalité plutôt qu’une autre ? Ce sont des avis précieux. Pas d’auto-censure !

Côté PM : c’est pertinent de demander des précisions, des explications et d’essayer de comprendre un peu mieux ce qu’il se passe sous le capot. C’est important ! Et 95% des développeurs seront très heureux d’expliquer tout ça.

💪 Actions

⇒ Créer un rendez-vous toutes les 2 semaines ou tous les mois avec 1 développeurs qui explicite les enjeux techniques de ce sur quoi il a travaillé

⇒ Inclure dans toutes les docs de spécifications / user stories, une partie “commentaire dév” pour les inciter à prendre la parole

#5 Être coéquipier

C’est important de ne jamais oublier ça. C’est le sens du mot “équipe” dans “équipe Produit”. Comme une équipe de football ou de sports collectifs. Chacun a son rôle à jouer. Mais parfois, on fait face à des aléas et tout ne se passe comme prévu. C’est pas grave. On gagne ensemble ; on perd ensemble.

💪 Actions

⇒ Rappeler l’implication de toute l’équipe, notamment des ingénieurs, lors des événements “solennels” (keynote, grosse release)

⇒ Quand ça va mal, ne jamais mettre en cause une personne de l’équipe

#6 Rappeler l’importance de chaque expertise

Pour construire des produits on a besoin de différentes spécialités. Tech, business, UX, produit… Ça va même plus loin. Je pense que la réussite d’un produit dépend du bon équilibre entre ces expertises.

Pour autant, on peut oublier tout ça avec le rythme des développements et le boulot à accomplir. Donc il faut faire attention à bien toujours se rappeler ces éléments, à la fois dans le travail quotidien de l’équipe, à la fois dans la communication vis-à-vis des sponsors.

💪 Actions

⇒ Inclure systématiquement une revue business, tech, UX pour chaque fonctionnalité structurante

⇒ Ré-expliquer brièvement les enjeux de l’équilibre entre les expertises dans les réunions importantes

#7 Communiquer beaucoup

Dès que j’arrive dans un nouvel environnement ou que je commence à bosser avec des développeurs, je dis clairement les choses en amont “j’aime bosser comme ci comme ça. Et toi ?” Je pense que c’est une très bonne habitude au début d’une nouvelle relation de travail :

• D’abord parce que ça permet de bien comprendre ce que l’autre attend de nous

• Ensuite parce que ça montre que ces sujets sont importants et qu’on peut (et doit) en parler

💪 Actions

⇒ Se poser régulièrement, tous les 6 mois, pour identifier précisément ce qu’on aime et ce qu’on aime moins en termes d’échange

⇒ Mettre en place la routine évoquée au-dessus au début de chaque nouveau produit ou de chaque nouvelle relation

#8 Être très clair sur les priorités

En tant que PM, on a une responsabilité très importante sur la vision à long terme et les priorités à plus court terme. Si ces choses ne sont pas claires, alors tout n’ira pas dans la bonne direction.

Attention, ne négligez jamais l’importance de rappeler ces éléments fréquemment. La pédagogie c’est l’art de la répétition.

C’est d’ailleurs autant important de récupérer les feedbacks de tout le monde sur l’ordre des priorités et l’ajout d’éventuels éléments à cette vision.

💪 Actions

⇒ Identifier une réunion toutes les 2 semaines (démonstration, sprint planning) et rappeler au démarrage de cette réunion la vision long terme du produit et les prios

⇒ Dans la lignée des brainstorms (conseil #1), organiser des sessions de priorisation et de travail de la vision, avec tout le monde

#9 Garder de la marge

Les développeurs ont besoin d’avoir un environnement de travail sain avec du temps laissé pour innover et tester de nouvelles choses. Ça ne peut pas être efficace si les équipes techniques bossent 12h par jour, 5 jours sur 5.

De ta posture de Product Manager, tu as la capacité d’influencer sur le niveau de pression que subissent les équipes tech. Prends garde de bien maintenir des soupapes et des marges de manoeuvre suffisantes, en continu.

💪 Actions

⇒ Mettre en place des sessions type “hackathon” pour tester des solutions innovantes régulièrement (j’en parle dans mon édition #14 sur le DevOps)

⇒ Aborder très régulièrement la question de la charge des dévs, individuellement et collectivement, par exemple en rétrospective chaque sprint

#10 Construire de vraies relations

Car oui, ça reste toujours des humaines qui interagissent au final !

Je pense que ça arrive comme une conséquence de tous les autres points. Mais il faut bien se mettre dans la tête qu’une relation PM / dév efficace, c’est d’abord des personnes qui doivent bien s’entendre.

Concrètement : tu dois être proche de tes collègues ingénieurs / tech. Tu dois tout faire pour bien t’entendre avec eux. Et si ça n’est pas le cas, bien comprendre d’où vient le problème car ça nuira à l’efficacité de ton équipe.

💪 Actions

⇒ Quand quelqu’un arrive, prévoir des meetings de “rencontre”, 1h avec chaque personne de l’équipe

⇒ Organiser des moments informels pour aller un peu plus loin que juste une relation professionnelle superficielle

---

Tu décides du prochain sujet ?

---

Et sur la longueur 🤔

Conclusion

On se retrouve la semaine prochaine pour le prochain numéro !

Merci :

• De m'avoir lu 🙏

• À ceux qui ont répondu à mon sondage de mercredi dernier

• Et qui se sont portés volontaires pour relire ma formation (ici si ça t’intéresse)

Si tu es trop impatient pour attendre, tu peux :

• M’envoyer tes conseils pour une relation saine dev / PM par mail ou par message LinkedIn 💪

• M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪

• Partager la newsletter à des personnes susceptibles d'être intéressées 💪

• Liker cette édition si tu l’as bien aimée 🫶 💪

Bon courage pour la semaine 😃

Victor