Quand on s'est penché sur le sujet de notre futur article avec Marion, on a évidemment évoqué la relation entre PMs et développeurs.euses! Après le business et le design, la thématique clignotait devant nos yeux 😎!
Mais on sait également, que c'est l'une des plus traitées jusqu'à présent, et on ne compte plus les ressources qui nous parle de cette relation si importante et pourtant si souvent complexe - voire compliquée.
Qui n'a pas entendu parlé dans sa carrière - ou vécu d'ailleurs - une des ces situations ?
👉🏽 Le PM trop directif qui impose son idée sans chercher à discuter avec son équipe tech 🤨
👉🏽 Le dev un peu trop "gaga" du challenge technique, qui va transformer une fonctionnalité complexe en refonte complète de l'appli 😅.
👉🏽 Le PM qu'on ne voit jamais car il passe sa journée en réunion 😩
👉🏽 ou encore le dev qui manque cruellement de force de proposition...
Bref, on a une liste longue comme le bras 🤯
Comme d'habitude, on a souhaité laisser le sujet entre les mains de nos invités, ceux qui vivent ce binôme (ou trinôme, n'oublions pas nos ami.e.s designers.euses) au quotidien et qui donc en parleront bien mieux que nous.
Merci donc à ...
🎤 Diane Mergui - Product Manager
🎤 Romain Gauthier - Product Manager @Jahia
🎤 Mathieu Breton - CTO @Swan
🎤 Benoît Lemoine - Lead tech @Décathlon Canada
L'objectif ici n'est pas d'identifier un.e ou des responsables, mais de s'inspirer des très bonnes pratiques qui existent pour les partager, et ainsi éviter à d'autres de tomber dans le piège de la caricature de la relation !
Et pour démarrer, voici quelques conseils d'ami.e.s pour poser les bases saines d'une belle collaboration - oui, on est vraiment sympas chez Pachamama (si si dites le 😉)!
1. Devient le (meilleur) ami des devs !
La collaboration se travaille dès les premières minutes.
Et ça cher.e ami.e PM qui nous lit, il ne faut SURTOUT pas l'oublier!
Les écueils à éviter quand tu arrives dans une nouvelle boîte? 🔥
Premièrement, démarrez par une vraie phase d'observation! Si vous arrivez dans une équipe qui fonctionne, avant de changer les choses, posez vous la question du "coût/bénéfice"!
Et pour cela, partagez avec les techs, appuyez vous sur les leads s'il y en a! Mais abandonnez vos croyances et laissez vous guider dans votre nouvel environnement avec l'esprit ouvert ! Au pire vous en ressortirez avec de vrais éléments à défendre, au mieux, vous en serez enrichi !
Ah le syndrome du PM omnipotent! Non ce n'est pas un mythe, il existe bel et bien...
N'oubliez pas, c'est une collaboration dans laquelle il n'y a pas de liens hiérarchiques. Trouvez votre positionnement mais ne les traitez pas comme "votre équipe tech", ça passe très mal croyez nous !
Il faut aussi savoir créer un vrai lien de confiance avec l'équipe de devs avec qui on collabore - avoir une bonne écoute sur leurs feedbacks notamment car ils ont parfois des supers insights- tout en gardant la tête froide pour bien les mesurer et les évaluer!
Romain quant à lui, nous explique qu'il faut surtout accepter l'incertitude quand on est PM. Et oui, c'est contre intuitif on le sait! Mais donner une deadline aux devs en croisant les doigts pour qu'ils la tiennent est pour le coup carrément contre productif.
Le mieux? Faire un plan bien sur, en parlez avec eux, tout en acceptant que l'incertitude en fasse partie !
De plus, appuyez vous sur les process ! Ils sont là pour ça. Et s'il n'y en a pas, construisez les avec les développeurs. Commencez par des choses simples, en mode itératif, pour montrer qu'il y a un peu de contrôle et en profiter pour partager "les outcomes" des activités discovery dont ils peuvent être parfois loin!
Cela vous permettra de créer de vrais liens avec certains et surtout vous permettra de mieux prévenir les erreurs qu'il y a toujours.
Romain nous le dit : "Les erreurs des PMs se payent très chères!"
Enfin, Diane Mergui nous partage un gros écueil qu'elle a souvent expérimenté:
Pour cela, pas de recette magique: il faut poser des questions! Elles ne sont jamais "bêtes", et n'oubliez pas que vous aiderez toujours au moins une autre personne dans la pièce en dehors de vous même!
2. Arrêtons d'opposer Produit et tech systématiquement !
Oui, ça se travaille au niveau culturel d'une entreprise, dans les valeurs incarnées, les paroles, la manière de travailler vraiment ensemble!
D'ailleurs, nous profitons de ce billet pour faire passer un petit message aux head of engineering et autres CTO qui nous lisent: vous aussi avez un rôle à jouer pour que la relation fonctionne !
Et une des clés réside dans le fait d'arrêter de sur protéger les développeurs. Oui on le sait, c'est dur de les recruter, et vous avez raison de les chouchouter ...un peu! Mais cela engendre de la dé-responsabilisation côté tech - surtout chez les plus juniors et les moins matures - et à la fin, il y a toujours quelqu'un qui paie. Et c'est souvent le PM.
Franchement, cette réplique est irrésistible! 😂 Merci à Benoît Lemoine de nous avoir parlé sans détours!
Pour être plus précise, Benoît nous explique surtout qu'on peut difficilement reprocher à un développeur de ne pas faire d'extra-mile.
"Tout dépend du profil que t'embauche, son niveau d'implication et sa maturité."
Mais cher.e ami.e , Benoît te conseille aussi autre chose : si tu veux t'ouvrir vers d'autres horizons, il faut savoir s'investir un peu plus pour évoluer, et essayer de dédier du temps à son équipe pour faire autre chose que du code. Sinon tu stagnes.
Les meilleures expériences de collaboration sont souvent celles qu'on mérite et qu'on co-construit!
Ayez des bonnes pratiques, des bons rituels dans vos process.
Pour évitez le piège de la dé-responsabilisation technique sur le produit, il y a plein de choses à mettre en place.
L'écriture des stories est un bon exemple de co-construction.
"La relecture d'une story avec le tech lead est hyper importante pour que les questions arrivent en amont et pas quand tu bosses dessus " nous explique Diane.
On nous l'a beaucoup dit: beaucoup de PMs ne savent pas comment bien collaborer avec les devs en dehors d'une histoire de ticket Jira 🤓.
Et pourtant, non, ce n'est pas une fatalité!
Un des points les plus critiques se situe souvent au niveau de la discovery.
Or, impliquer les ingés dans la définition de la solution le plus tôt possible peut vraiment être une super idée. Quand un.e développeur.euse n'est pas convaincu.e par une fonctionnalité, s'il ou elle est un peu intéressé.e par l'idée, l'emmener en entretien utilisateur peut-être une vraie solution pour qu'il.elle revienne avec l'esprit ouvert et des idées plein la tête!
Romain nous le dit par expérience:
Diane ajoute: "Il existe des devs qui ont vraiment envie d'être intégré à la Discovery, notamment en user interviews. J'aime les inviter quand on est en train de drafter la solution avec les designers.euses, il y a une vraie émulation !"
Et c'est vrai. Il suffit de trouver un ou une dev qui va aimer le faire. Et cela nous amène à un autre sujet important:
"Apprenez à connaître l'équipe et les personnes qui la composent ! Vous y trouverez des alliés!"
Les développeurs.euses sont tous différents. Cela peut paraitre évident, mais beaucoup d'articles en font un groupe homogène, ce n'est évidemment pas le cas, nous précise Romain.
Deux points sont particulièrement importants :
👉🏽leur source de motivation : plutôt "tech driven" ou "people driven". Les dévs plutôt tech driven seront motivés par les challenges techniques, l'inconnu, l'innovation. Ceux qui sont "people driven" seront motivés par le fait de résoudre un problème pour quelqu'un. Embarquer les devs "people driven" dans les interviews clients peut vraiment multiplier leur productivité!
👉🏽leur réaction aux interruptions : pour certains, plusieurs interruptions dans une même journée peuvent ruiner beaucoup d'efforts. Pour d'autres, le problème sera beaucoup moins important. Il peut même être une source de motivation si les interruptions concernent le sujet en cours et que le dev a besoin d'échanger sur ce problème en question.
Diane quant à elle, nous raconte que ses meilleures expériences de collaboration étaient avec développeurs pro-actifs, qui anticipaient ses actions et faisaient de l'extra mile.
3. Faites entrer les devs dans votre monde produit!
Un bon dev peut-il devenir un mini PM?
On a posé la question car on sait que dans certaines boîtes, il y a un vrai partage de responsabilités sur le produit à tel point que parfois, PMs, lead tech, designers peuvent être interchangeables ponctuellement comme chez Payfit!
"Complètement! s'exclame Mathieu. Surtout en front!"
Chez Swan, certaines personnes sont hyper pugnaces avec l'équipe produit ! Ils ou elles sont capables de challenger fortement le produit - d'ailleurs quand on recrute un PM, on cherche souvent un background tech pour encaisser ça!
Diane est aussi d'accord. Selon elle, tout le monde peut devenir PM pour peu qu'on ait du sens commun, la capacité à synthétiser l'information pour la retranscrire à un panel de gens différents.
Pour Romain , c'est possible mais il faut leur laisser la place et l'opportunité de le faire. Et ça se joue dès la rédaction des users stories.
Benoit quant à lui, nuance sa réponse. Selon lui, tout dépend du niveau de risque mais c'est plus simple dans le B2C, car dans un produit B2B, la pression du client est plus forte :
"Tu fais ce qu'on te demande et le plus vite possible".
Pour résumer, nous vous invitons à ne pas considérer cette collaboration comme fatalement vouée à être un sac de noeuds pas fun...Ressortez la qualité première d'un bon PM qui est, à notre sens chez Pachamama, l'empathie.
Vous êtes le chef d'orchestre de votre produit ! Faites participez tous les corps d'instrument en prenant soin de prendre en compte les particularités de chacun : deux violons peuvent surement paraître identiques à première vue, vous seriez surpris de voir à quel point la musique qui en sort est différente ! 😉
