🇬🇧 Click here to access the English version of this post
Chers CTO et tech leaders,
Dans toute entreprise technologique, l’une des relations les plus importantes est celle qui unit les équipes product et engineering. En général, les product managers passent leur temps à parler aux utilisateurs et à analyser leur marché pour identifier de nouveaux problèmes. Ils conçoivent ensuite des solutions que les ingénieurs vont coder et intégrer au produit afin que les clients puissent les utiliser.
Comme dans la plupart des relations, la première phase ressemble toujours à une lune de miel. Product managers et ingénieurs passent tout leur temps ensemble, côte à côte. Quand les premiers expriment une idée, elle est presque immédiatement poussée en production par les seconds. La communication est fluide, presque télépathique. Mais, à mesure que l’organisation grandit, la relation change.
Les product managers deviennent de plus en plus frustrés car le développement de nouvelles fonctionnalités prend toujours plus de temps. De leur côté, les ingénieurs s’agacent face à des demandes qu’ils jugent incohérentes ou face à un manque de compréhension de la complexité de leur travail. La communication se tend. Mais comme dans toute relation, rien n’est inéluctable. L’article qui suit résume les cinq dysfonctions les plus courantes qui peuvent apparaître dans une équipe product engineering — et comment les éviter dans votre entreprise.
1/ Too much inventory
La plus grande différence entre un product manager et un ingénieur, c’est que les ingénieurs sont contraints par des limites physiques : la complexité du problème à résoudre, le temps nécessaire pour coder une solution, ou encore le nombre de ressources disponibles pour développer de nouvelles fonctionnalités. Les product managers, eux, sont principalement limités par leur créativité. Résultat : dans un système product–engineering, la quantité de spécifications produit en entrée est virtuellement illimitée, alors que les ressources pour les développer sont limitées — ce qui crée un inventaire sans fin de nouvelles fonctionnalités à coder.
Augmenter le nombre de ressources côté engineering permettrait probablement de résoudre ce problème. Mais recruter et onboarder de nouveaux ingénieurs est coûteux, et cela ne ferait qu’amplifier la créativité des product managers (la fameuse loi de Parkinson). Une solution consiste donc à limiter virtuellement le flux de nouvelles fonctionnalités via une méthodologie de spécification plus stricte (comme le Amazon 6-pager) ou un processus de priorisation plus rigoureux.
2/ Le téléphone arabe
Dans le jeu du téléphone arabe, chaque joueur répète à l’oreille du suivant le message qu’il vient d’entendre, jusqu’à ce que le message revienne au premier joueur. L’objectif est de transmettre l’information sans l’altérer, mais l’amusement vient justement du fait qu’elle change légèrement à chaque étape, jusqu’à devenir une phrase complètement différente. De la même manière, certaines fonctionnalités finissent par n’avoir plus grand-chose à voir avec l’idée initiale.
Ce scénario, lorsqu’il se répète, survient souvent quand les ingénieurs sont peu, voire pas du tout, impliqués dans la conception produit. À mesure que l’entreprise grandit, la séparation entre product et engineering s’accentue, et les individus se retrouvent cantonnés à créer ou exécuter des tickets.
Une bonne façon de résoudre ce problème consiste à mettre en place des “feature teams” autonomes, où product managers et ingénieurs travaillent ensemble à concevoir des solutions pour résoudre les problèmes des utilisateurs. Même sans aller jusque-là, il est toujours bénéfique que les ingénieurs soient eux-mêmes utilisateurs du produit qu’ils construisent (dans le cas d’un produit grand public), ou qu’ils interagissent directement avec des clients (dans le cas d’un produit B2B). C’est dommage que tant d’ingénieurs ne rencontrent jamais les personnes qui utilisent, au quotidien, le logiciel qu’ils développent.
3/ « Ça, c’est facile à faire »
Avez-vous déjà vécu cette situation où vous devez développer une fonctionnalité extrêmement complexe, et où votre interlocuteur côté product (ou business) ne comprend tout simplement pas pourquoi cela prend autant de temps ? Malheureusement, cette incapacité à se mettre à la place des ingénieurs est courante dans les organisations où les profils business et product n’ont pas de formation technique. Ne voyant que la partie visible (souvent le front-end ) ils ne peuvent pas imaginer ce qu’il faut mettre en place pour que la fonctionnalité fonctionne réellement. Résultat : frustration côté ingénieurs et ralentissement du système.
Idéalement, les product managers devraient avoir une formation technique, ou au moins un minimum d’expérience en code, pour mieux comprendre la complexité inhérente à l’ingénierie. Les ingénieurs, de leur côté, gagneraient à mieux communiquer sur les difficultés liées au développement d’une fonctionnalité, en précisant les points bloquants (algorithmes, bases de données, dépendances système, APIs complexes, etc.) et leur niveau de complexité.
Il est également essentiel d’instaurer un système de confiance entre product managers et ingénieurs. Dans de nombreuses entreprises, les tensions sont constantes autour des estimations : les premiers accusant les seconds de gonfler les délais pour travailler moins, et les seconds reprochant aux premiers de survendre aux clients sans anticiper la charge. Le modèle du Betting Table de Basecamp est une manière de résoudre ce problème : les ingénieurs s’engagent à livrer les fonctionnalités prévues pendant un cycle de développement (6 semaines chez Basecamp), à condition que les product managers s’engagent à ne pas introduire de nouvelles demandes ni de changements pendant ce cycle.
4/ Désalignement des objectifs
À mesure que les entreprises grandissent, il est courant de créer des départements séparés pour le product et pour l’engineering, avec des C-levels, des Heads et des managers intermédiaires chargés de fixer des objectifs et de diriger les équipes. Dans certains cas, quand ces départements s’éloignent trop, leurs objectifs peuvent devenir conflictuels, voire antagonistes. Par exemple, des tensions apparaissent si l’objectif de l’équipe product est de livrer toujours plus de nouvelles fonctionnalités alors que l’objectif de l’équipe engineering est de se concentrer sur la qualité de la plateforme (après plusieurs pannes récentes). Ces conflits s’exacerbent encore si les managers utilisent des KPIs différents pour mesurer l’efficacité de leurs équipes.
La meilleure façon d’aligner les équipes product et engineering est de revenir à l’objectif fondamental d’une organisation software : livrer le plus de valeur possible aux utilisateurs, le plus rapidement possible avec le plus haut niveau de qualité. Le seul indicateur qui compte vraiment, indépendamment de la taille des départements, est donc le temps qu’il faut pour passer d’une idée validée à un feedback utilisateur positif. Dans un précédent article, j’ai introduit la métrique TPUF (Time to Positive User Feedback), qui permet aux product managers comme aux ingénieurs de se concentrer sur le même objectif : la satisfaction client.
Plus le TPUF est faible, plus l’entreprise est performante, car le feedback positif des utilisateurs a un impact direct sur la croissance et la rentabilité. Si le TPUF n’est pas suffisamment bas, cela peut venir soit des product managers qui ne passent pas assez de temps à analyser leur marché, soit des délais engineering trop longs. Quand product et engineering suivent la même métrique, cela crée un sentiment d’unité dans l’entreprise et permet d’éviter bien des conflits.
5/ Que des nouvelles fonctionnalités
Enfin, un dysfonctionnement classique dans la relation product–engineering est la pression pour ne construire que de nouvelles fonctionnalités, sans que les ingénieurs passent ne serait-ce qu’une heure sur la roadmap technique. Cette situation est normale pour une startup en tout début de vie, qui cherche encore son product-market fit. Mais une fois ce stade franchi, beaucoup d’entreprises oublient qu’elles ont accumulé de la dette technique… et qu’il faudra bien la rembourser.
En ingénierie comme en finance, si vous accumulez trop de dettes, vous finissez par faire faillite. Lorsqu’une entreprise néglige sa roadmap technique, elle sacrifie inévitablement la vitesse de long terme au profit de la vitesse de court terme. Car le raccourci d’aujourd’hui devient toujours le blocage de demain. Les équipes engineering avisées veillent donc à traiter la dette technique le plus tôt possible dans l’histoire de l’entreprise — mais par petites touches. Un grand projet de réécriture sur plusieurs mois a peu de chances d’être priorisé face à des fonctionnalités génératrices de revenus, mais des mises à jour plus petites et fréquentes seront beaucoup plus faciles à faire passer.
Pour y arriver, les entreprises adoptent différentes approches : certaines ne distinguent pas la roadmap produit de la roadmap technique et utilisent un seul processus de priorisation pour décider quels projets entrent dans un cycle de développement. D’autres réservent arbitrairement un pourcentage de temps aux projets techniques. D’autres encore consacrent des journées ou des moments spécifiques du cycle uniquement à ces projets. À chaque équipe de trouver le modèle qui fonctionne le mieux pour elle.
Reconstruire une relation saine entre Product et Engineering
La relation entre product et engineering est l’un des piliers de toute entreprise technologique. Mais comme toute relation, elle peut se fragiliser avec le temps. Les cinq dysfonctions que nous avons passées en revue apparaissent souvent quand l’organisation grandit, quand la pression du marché s’intensifie, ou simplement quand la communication se dégrade.
La bonne nouvelle, c’est que ces dysfonctions ne sont pas une fatalité. Les leaders qui en ont conscience peuvent mettre en place des pratiques simples pour les éviter : limiter le flux de spécifications produit, impliquer les ingénieurs dès la conception, instaurer un climat de confiance autour des estimations, aligner les équipes sur une métrique commune comme le TPUF, et réserver du temps à la dette technique.
Au final, la relation entre product et engineering n’est pas seulement une mécanique d’exécution : c’est une véritable alliance. Quand elle fonctionne bien, elle permet de livrer plus de valeur, plus vite, et avec moins de frictions. Quand elle dysfonctionne, elle devient un frein invisible à la croissance.
C'est donc aux leaders des différentes organisations de transformer ces tensions en une collaboration saine et durable. Car le succès ne vient pas de la victoire d’un camp sur l’autre, mais de la force de leur partenariat.