Le rôle de product manager a gagné en popularité dans l’industrie tech ces dernières années. Alors que de plus en plus d’entreprises ajoutent des PM à leurs organigrammes, il y a encore beaucoup d’expérimentation avec les configurations d’équipe pour trouver le meilleur alignement possible entre produit et engineering. Ces deux fonctions travaillent maintenant plus étroitement que jamais, et bien que cela soit considéré comme la recette pour des équipes performantes, beaucoup d’entreprises ont encore du mal à atteindre de bons niveaux de collaboration.
Les stratégies pour y parvenir sont bien couvertes sur le site web de Martin Fowler. Dans cet article, je me concentrerai davantage sur la perspective de l’ingénieur et sur nos attentes envers un bon product manager.
Ce qu’il ne faut pas attendre#
En tant qu’ingénieur moi-même, j’ai observé des frictions venant des deux côtés, mais aussi quelques partenariats productifs. Bien qu’on puisse argumenter que l’équipe ou l’organisation peut influencer le résultat, cela dépend surtout de la volonté de chaque fonction à collaborer avec l’autre.
Faisons un exercice et réfléchissons à ces attentes à l’envers. Je crois que le rôle de PM en est encore à ses débuts, et à cause de cela, il prend différentes formes, surtout dans les entreprises moins matures qui commencent à construire leurs stratégies de développement produit.
Excel Manager#
Un as des macros et un maître dans le reporting des progrès lors du steering hebdomadaire. Le projet entier ressemble à une œuvre d’art géométrique avec des barres empilées les unes sur les autres. L’excel manager se soucie très peu du cycle de vie du produit et dépensera tous ses jetons pour faire s’engager les développeurs sur ces deadlines.
Featuriste#
Spécialiste top en recherche de marché à 360 degrés. Elle sait tout sur Steve Jobs et l’histoire de l’iPod, se soucie du cycle de vie du produit, mais ne peut pas se permettre de perdre du temps à construire des stratégies parce que “Les détails comptent, ça vaut le coup d’attendre pour bien faire”.
Programmeur à la Retraite#
Mécontent de l’idée d’être un code monkey pour toujours, elle a abandonné l’engineering à la recherche du bonheur et du succès. Regardant avec regret la vie qu’elle a laissée derrière elle, le programmeur à la retraite est un bon allié et est prêt à gérer les attentes de la direction.
La Main du Roi#
Pourquoi partager ses idées quand on est tous là pour servir un but plus grand ? Comme un filtre passe-tout, la main du roi ne prend aucun risque que des doigts pointent dans sa direction. Elle n’est que la messagère.
L’Idée Centrale du Product Management#
Ce que les stéréotypes ci-dessus ont en commun (intentionnellement), c’est qu’ils délèguent tous les décisions business à la couche de direction, ce qui, je pense, est le plus grand changeur de jeu concernant le rôle de product manager. Plus que le design ou l’implémentation, le PM est responsable de l’ensemble du cycle de vie du produit, de l’idée à l’implémentation en passant par le feedback client et la performance sur le marché.
Les équipes les plus réussies dans lesquelles j’ai travaillé sont celles où le PM est présent, parfois même sous la même ligne hiérarchique. PM & EM: Rules of engagement établit 3 règles fondamentales : Confiance, responsabilité conjointe et ownership séparé.
Embarquer l’Équipe dans le Business#
Une des choses qui m’a toujours dérangé, c’est le peu que les ingénieurs savent sur les produits qu’ils construisent. Surprise ou non, il est possible de travailler toute une vie sans savoir qui utilise le logiciel que vous construisez et combien d’argent il génère. Des discussions récurrentes avec l’équipe sur la performance du produit sont un moyen puissant de favoriser l’innovation et maintenir les niveaux de motivation élevés.
Une Roadmap pour les Gouverner Toutes#
Construire une roadmap technique tout en travaillant dans une équipe produit a été l’une des expériences les plus contre-productives que j’ai eues. S’il est important de garder une trace de la dette technique qui doit être payée, si le produit n’adhère pas, l’expérience me dit que ces tâches ne seront jamais implémentées.
Un bon PM est capable de comprendre le coût de ne pas payer la dette technique et l’inclura dans la stratégie produit.
Dates Cibles, Pas Deadlines#
Si vous voulez stresser un ingénieur, demandez-lui un ETA ou de s’engager sur une deadline fixée par la direction. Construire un logiciel sous pression ne cause que du tort au business car cela forcera les gens à faire plus d’erreurs.
Bien qu’il ne soit pas non plus acceptable que les ingénieurs soient libres de gaspiller de grandes quantités de temps, le PM devrait être assez flexible pour permettre à la date cible de bouger ou au scope d’être réduit.
Remarques Finales#
Ce que devrait être le PM parfait est encore une question ouverte, mais il est clair que si produit et engineering travaillent à construire un partenariat efficace, les résultats peuvent être bien plus productifs. Du point de vue d’un ingénieur, le PM idéal n’est pas un stakeholder mais un pair, un peu comme le CEO d’une petite startup au sein de l’entreprise plus large.
