Product Manager n’est pas un job facile. Pour tenir la feuille de la route du produit dont il a la charge, il n’a pas d’autorité particulière sur les différents départements qui vont apporter leur desiderata, ni sur les architectes et les développeurs en charge de concevoir les solutions techniques et de les produire.

Au sein de l’équipe de développement, le Product Manager doit pourtant agir à la manière d’un leader.

Parfois arbitre, parfois diplomate, il doit trouver le consensus le moins imparfait possible entre tous ceux qui ont une légitimité à influencer la vision du produit. Des commerciaux aux clients, de la direction marketing à celle de la technologie.

Le Product Manager n’a pas autorité sur les équipes de développement, mais n’a pas d’autre choix que d’en être tout de même le leader.

La convention la plus répandue est que le Product Manager a la responsabilité de ce qu’est le produit (le quoi) et l’équipe de développement a la responsabilité de comment le produit est construit. La responsabilité du quand est plus variable, mais il est difficile de ne pas la faire reposer sur un tandem entre le Product Manager et l’équipe de développement (au travers de son responsable).

La qualité de la relation du PM avec l’équipe de développement est donc absolument critique pour la société. Elle peut devenir un moteur essentiel de sa réussite, ou agir comme un frein très pénalisant.

Commençons par un petit récit qui illustre bien le rôle du PM et l’importance de sa relation avec l’équipe de développement, et que je me suis permis de piocher dans le très bon livre Inspired de Marty Cagan.

Word 6.1

En 1993 sortait la version 6 de Word, très riche en fonctionnalités. L’équipe technique avait décidé de fusionner le code entre les versions Windows et Mac pour gagner du temps sur les versions ultérieures et pour avoir une commercialisation simultanée des différentes versions.

La version Mac fût un cuisant échec. Extrêmement lente et ne tenant pas compte des spécificités techniques des Macs ou des habitudes de ses utilisateurs. La communauté Apple se fît fortement entendre et accusa Microsoft de vouloir tuer le Mac. Bill Gates demanda à l’équipe de rapidement régler ce problème embarrassant pour l’image de la société.

Entra alors en scène Martina Lauchengco, nouvelle recrue Product Manager, chargée de reprendre le sujet.

Martina travailla avec l’équipe pour faire accepter l’idée que les efforts investis dans la fusion de code entre les versions Windows et Mac sont vains si le produit final n’est pas bon. Et ce, quels que soient les bénéfices apportés par cette fusion.

Elle expliqua que les utilisateurs qui font le choix d’une plateforme différente sont prêts à attendre pour bénéficier d’une expérience différente et recevoir une version du logiciel adaptée à leur machine. 

Sous sa direction, les ingénieurs se concentrèrent alors sur la performance d’exécution et les spécificités des Macs. Des fonctions comme le temps de chargement des polices, beaucoup plus nombreuses à l’époque que sur Windows, furent considérablement améliorées. Le compteur de mots, l’une des fonctionnalités les plus utilisées dans les médias – industrie où le Mac était très répandu, fût recodé et devint même plus performant que son équivalent sous Windows. Les raccourcis claviers auxquels étaient habitués les utilisateurs Mac furent intégrés.

Ces efforts donnèrent lieu à une version 6.1 du logiciel qui fût accompagnée d’un courrier d’excuse. Ce virage permit de corriger le problème d’image, et les utilisateurs Mac se retrouvèrent surtout en possession d’un logiciel vraiment taillé pour leur plateforme, et dont ils pouvaient être fiers.

Lorsque l’équipe technique et le Product Manager travaillent en symbiose, l’entreprise se voit dotée d’un atout exceptionnel.

Cette symbiose dépend d’un certain nombre de facteurs :

La légitimité

Disposer d’une forte, voire incontestable légitimité, évite au PM de se voir opposer certains doutes à ses décisions. Même des ingénieurs expérimentés et bien intentionnés peuvent être enclin, parfois inconsciemment, à challenger quelqu’un dont ils ne sont pas entièrement convaincus qu’il est la bonne personne pour le job.

Premier élément clef pour asseoir cette légitimité : une définition claire et précise du rôle du Product Manager. Tous les collaborateurs de l’entreprise (cela ne concerne pas uniquement l’équipe technique) doivent avoir une bonne compréhension de ce rôle et de son intérêt. Un effort de pédagogie est donc nécessaire lors de l’introduction de ce rôle dans l’organisation, puis lors du processus d’intégration des nouveaux collaborateurs, car tout le monde n’a pas déjà eu la possibilité de travailler avec une organisation qui intègre cette fonction.

Disposer d’un bagage technique suffisant et adapté à ce que les ingénieurs de l’entreprise produisent est quasiment un prérequis. Il ne s’agit pas forcément pour le PM d’être un architecte ou un développeur de formation, mais d’avoir fait les efforts nécessaires pour avoir un niveau d’échange constructif avec l’équipe de développement sur les aspects technologiques. Sans trop s’immiscer dans les décisions d’implémentation, le Product Manager se doit de s’intéresser à la manière dont le produit va être construit, aux conséquences des choix d’architectures importants.

Enfin, pour une légitimité indiscutable, le reste de l’équipe doit constater que le PM a la confiance du porteur de la stratégie et de la vision produit. Selon l’organisation il peut s’agit d’un Directeur Produit, d’un Directeur Marketing ou un poste équivalent. Ou comme c’est souvent le cas dans les premières phases d’une startup, directement le CEO.

La confiance

La légitimité est un socle nécessaire, mais c’est vraiment la confiance mutuelle entre le PM et l’équipe de développement qui va servir de carburant à une relation de travail constructive et saine. 

Pas de surprise, mais on ne le dit jamais assez : cette confiance passe par la transparence et une constante communication.  Et cela commence par la confiance établie entre le PM et le Responsable des Développements (RD, VP Engineering, CTO ou un autre titre équivalent dans l’entreprise). Celle-ci donnera le ton pour la relation globale entre les deux fonctions, et il est de la responsabilité de ces deux responsables de maintenir une relation constructive entre eux.

Les architectes et les développeurs doivent pouvoir s’approprier le rationnel derrière la feuille de route construite par le PM. Cette appropriation alimente la motivation et la stimulation qui les rendent créatifs, efficaces et ingénieux. Sans cela, ils seront moins enclins à donner le meilleur d’eux-mêmes. Le PM doit donc prendre le temps d’expliquer les raisonnements derrière les différents choix, et leur intérêt pour le projet de l’entreprise. Le Responsable des Développements doit contribuer lui aussi à l’appropriation de ces choix, particulièrement lorsqu’ils appellent certains sacrifices comme une accumulation de dette technique pour une fonctionnalité urgente.

A l’inverse, il doit prendre le temps d’écouter et de s’approprier les propositions et les impératifs que l’équipe technique peut soumettre à la roadmap. Il y a bien sûr les contraintes d’architecture : sécurité, refactoring, rattrapage de dette technique, etc. Mais les ingénieurs sont aussi bien placés pour trouver des fonctionnalités intéressantes à faible coût technique, soumettre de nouvelles technologies au potentiel fonctionnel intéressant, ou tout simplement avoir de bonnes idées !

Il n’y a pas de PM ou d’ingénieur parfait et il pourra toujours y avoir des frustrations entre un développement qui prend beaucoup plus de temps que prévu, qui termine en impasse, des idées de l’équipe technique qui ne sont pas adoptées ou le design inabouti de certaines fonctionnalités. Là encore, une bonne communication et une confiance établie en amont sauront absorber ce type d’écueil. 

Par ailleurs, les situations de crise sont de bonnes occasions de tester la confiance établie, mais aussi de la renforcer. Incident de production, perte d’un appel d’offre, peu importe la nature de la crise. Charge au PM et au RD de piloter la réponse collective à l’incident pour ne pas perdre de temps à chercher des fautifs et rester constructif.

Une opposition constructive

Lorsque le PM dispose d’une légitimité réelle et d’une confiance mutuelle solide avec l’équipe technique, la roadmap peut alors bénéficier dans sa construction de la tension qui résulte de l’opposition entre les objectifs et les points de vue des deux parties.

Le Responsable des Développements et son équipe doivent défendre des bastions importants pour la pérennité opérationnelle du projet sur le long terme comme la prise en compte de la sécurité dans la conception de l’architecture ou la refacto de code pour racheter de la dette technique.

Le Product Manager doit œuvrer pour améliorer l’expérience utilisateur et faire du produit un leader de son marché. Dans le cas d’un modèle B2B, il doit construire les fonctionnalités permettant à l’équipe commerciale de gagner des appels d’offre. Il apporte constamment des contraintes de temps et des défis de faisabilité technique.

Ces objectifs respectifs tirent les efforts dans des directions parfois diamétralement opposée. Les ambitions fonctionnelles, la faisabilité technique, les contraintes de temps, la pression du business, la pérennité de l’architecture guident les échanges des deux équipes. Il s’agit de trouver un équilibre des forces, un compromis au milieu d’arguments contradictoires tous légitimes.

Mais il s’agit aussi d’utiliser ces contradictions et ces oppositions comme leviers pour innover, prendre des risques, mettre à mal la tactique pour la revisiter et l’améliorer. Lorsque le Product Manager et l’équipe technique ont pris l’habitude de travailler ensemble, ils développent un instinct des limites à ne pas dépasser dans leurs résistances et un sens des opportunités à saisir pour faire avancer un sujet important pour eux.

En conclusion

La relation entre un Product Manager et l’équipe de développement est une alchimie délicate à composer. Le dirigeant de la société ne doit pas en sous-estimer l’importance et rester attentif à tout signal de discorde ou de déséquilibre.

Pour qu’un Product Manager puisse réellement apporter ce dont a besoin l’entreprise, les développeurs et leur responsable doivent agir en véritable partenaire. Ils oeuvrent de concert avec le PM pour soutenir la stratégie de l’entreprise, savent acceptent des sacrifices techniques lorsqu’ils sont en confiance et apportent leur contribution au produit par des challenges constructifs et leur capacité d’innovation.