Parce que je donne un cours sur la gestion de produit à la Harvard Business School, on me demande régulièrement « Quel est le rôle d’un chef de produit ? ». Le rôle du chef de produit (PM) est souvent qualifié de « PDG du produit ». Je ne suis pas d’accord car, comme le souligne Martin Eriksson, « les chefs de produit n’ont tout simplement pas d’autorité directe sur la plupart des éléments nécessaires au succès de leurs produits – de la recherche sur les utilisateurs et les données au marketing, aux ventes et au support, en passant par la conception et le développement. » Les GP ne sont pas le PDG du produit, et leurs rôles varient considérablement en fonction d’un certain nombre de facteurs. Alors, que devez-vous prendre en compte si vous envisagez d’exercer un rôle de GP ?
Les GP inspirés doivent tenir compte de trois facteurs principaux lorsqu’ils évaluent un rôle : les compétences de base, l’intelligence émotionnelle (QE) et l’adéquation à l’entreprise. Les meilleurs GP avec lesquels j’ai travaillé maîtrisaient les compétences de base, avaient un QE élevé et travaillaient pour l’entreprise qui leur convenait. Au-delà de l’expédition de nouvelles fonctionnalités à une cadence régulière et du maintien de la paix entre l’ingénierie et l’équipe de conception, les meilleurs GP créent des produits avec une forte adoption par les utilisateurs, qui ont une croissance exponentielle des revenus et peut-être même perturbent une industrie.
Compétences de base
Il y a des compétences de base que chaque GP doit avoir – dont beaucoup peuvent commencer en classe – mais la plupart se développent avec l’expérience, de bons modèles et le mentorat. Voici quelques exemples de ces compétences :
- conduite d’entretiens avec les clients et de tests auprès des utilisateurs
- réalisation de sprints de conception
- priorisation des fonctionnalités et planification de la feuille de route
- l’art de l’allocation des ressources (ce n’est pas une science !)
- réaliser des évaluations de marché
- traduire les exigences commerciales en exigences techniques, et vice versa
- modélisation de la tarification et des revenus
- définir et suivre les métriques de succès
Ces compétences fondamentales constituent la base de référence de tout PM, et les meilleurs PM affinent ces compétences au fil des années de définition, d’expédition et d’itération des produits. Ces GP excellent à réfléchir à la façon dont chacune de ces compétences a contribué au succès ou à l’échec de leurs produits et à ajuster continuellement leur approche en fonction des commentaires des clients.
Intelligence émotionnelle
Un bon GP peut connaître les choses à faire et à ne pas faire lors d’un entretien avec un client, mais les meilleurs GP ont la capacité d’éprouver de l’empathie pour les clients lors de cet entretien, sont à l’écoute de leur langage corporel et de leurs émotions, et peuvent sonder astucieusement les points douloureux que le produit ou la fonctionnalité abordera. Un gestionnaire de projet doté d’un QE élevé entretient de solides relations au sein de son organisation et sait comment surmonter les obstacles internes et externes pour livrer un excellent produit. Voici un examen plus approfondi de la façon dont les quatre traits clés du QE, tels que définis par Daniel Goleman, se rapportent au rôle de GP :
Gestion des relations. L’une des caractéristiques les plus importantes d’un grand GP est probablement ses compétences en gestion des relations. En formant des liens authentiques et dignes de confiance avec les parties prenantes internes et externes, les meilleurs GP inspirent les gens et les aident à atteindre leur plein potentiel. La gestion des relations est également essentielle à la réussite des négociations, à la résolution des conflits et à la collaboration avec les autres en vue d’atteindre un objectif commun, ce qui est particulièrement difficile lorsqu’un GP est chargé de concilier les besoins des clients, les équipes d’ingénieurs aux ressources limitées et les objectifs de revenus de l’entreprise. Des relations authentiques et de confiance au sein d’une organisation peuvent conduire à un soutien accru lorsqu’un financement supplémentaire est nécessaire pour un produit ou lorsqu’il faut convaincre un ingénieur d’inclure une correction rapide de bogue dans le prochain sprint. En dehors de l’entreprise, ces compétences peuvent encourager les clients existants à tester une nouvelle fonctionnalité pour obtenir un premier retour d’information ou convaincre un client cible d’essayer le MVP d’un produit encore en mode furtif. Ces compétences relationnelles peuvent également être ce qui fait la différence entre avoir des clients furieux à cause d’un bogue introduit dans le produit et ceux qui disent : » Pas de soucis, nous savons que vous allez corriger cela ! «
Conscience de soi. Les GP doivent avoir conscience d’eux-mêmes afin de rester objectifs et d’éviter de projeter leurs propres préférences sur les utilisateurs de leurs produits. Si un GP est amoureux d’une fonctionnalité parce qu’elle répond à ses propres points de douleur – les GP sont souvent des super-utilisateurs des produits dont ils sont responsables – ils peuvent amener un utilisateur à dire qu’il l’aime aussi, juste pour faire plaisir au GP ( » validation de fonctionnalité faussement positive « ). S’il n’en est pas conscient, un GP peut pousser à donner la priorité à une fonctionnalité qu’il a conçue, même si les entretiens avec les clients et les preuves s’accumulent contre elle. Ce manque de conscience de soi pourrait faire dérailler des priorités plus importantes ou nuire à la relation du GP avec les ingénieurs, qui pourraient perdre confiance en leur GP lorsque la fonctionnalité n’est pas facilement adoptée par les utilisateurs.
L’autogestion. Être un GP peut être incroyablement stressant. Le PDG veut une chose, l’équipe d’ingénieurs une autre, et les clients ont leurs propres opinions sur les priorités des fonctionnalités. La gestion simultanée de délais serrés, d’objectifs de revenus, de demandes du marché, de conflits de priorités et de contraintes de ressources n’est pas pour les âmes sensibles. Si un gestionnaire de projet ne parvient pas à maîtriser ses émotions et à garder son sang-froid sous pression, il peut rapidement perdre la confiance de tous ses interlocuteurs. Les meilleurs GP savent comment faire pression sur les bonnes priorités, de façon urgente mais sans transmettre un sentiment de panique ou de stress. Ces GP savent aussi quand prendre une respiration et s’éloigner pour se ressaisir.
Conscience sociale. Selon Goleman, les compétences associées à la conscience sociale sont l’empathie, la conscience organisationnelle et le service. Les GP doivent comprendre les émotions et les préoccupations des clients concernant leur produit autant qu’ils comprennent les préoccupations de l’équipe de vente sur la façon de vendre ce produit, ou de l’équipe de soutien sur la façon de le soutenir, ou de l’équipe d’ingénierie sur la façon de le construire. Les GP doivent avoir une compréhension profonde du fonctionnement de l’organisation et doivent construire un capital social pour influencer le succès de leur produit, qu’il s’agisse d’obtenir un budget et des effectifs ou de s’assurer les services d’un ingénieur de haut niveau pour travailler sur leur produit. Enfin, la conscience sociale garantit que les meilleurs PM servent leurs clients avec un produit qui répond à leurs tâches à accomplir, ce qui est en fin de compte ce qui conduit à l’adéquation produit-marché.
(Pour en savoir plus sur ce que Paul Jackson a à dire sur le QE et les PM, cliquez ici. Et voici une interview de Sam Lessin, ancien vice-président de la gestion des produits chez Facebook, qui affirme n’avoir » jamais réussi à former l’empathie. « )
Company Fit
Si les meilleurs GP ont des compétences de base bien développées et un QE élevé, cela signifie-t-il qu’ils sont voués au succès, peu importe où ils travaillent ? Pas nécessairement. En fait, prendre ces compétences et traits de personnalité et les appliquer à la bonne entreprise est ce qui garantira finalement le succès.
Je n’ai pas encore vu de description de poste standard pour un chef de produit, car chaque rôle est finalement défini par la taille, le type de produit, le stade, l’industrie et même la culture de l’entreprise. Si vous possédez les compétences de base et le QE élevé nécessaires pour être un PM performant, l’étape suivante consiste à décortiquer les entreprises qui embauchent et ce qu’elles recherchent vraiment.
Voici quelques-uns des domaines clés dans lesquels les entreprises diffèrent dans ce qu’elles attendent d’un PM :
Compétences techniques. Le type de produit, les personnes qui l’utilisent et le type d’entreprise déterminent à quel point un PM doit être technique. Par exemple, Google exige que les MP passent un test de compétences techniques, quel que soit le produit sur lequel ils vont travailler. Si l’entreprise construit un CRM SaaS, il se peut que l’expérience de la mise sur le marché et du cycle de vie des clients soit plus importante que la façon dont le produit est construit. En revanche, s’il s’agit d’un produit de science des données avec des algorithmes d’apprentissage automatique et des API, le rôle peut exiger beaucoup plus de profondeur technique pour comprendre non seulement comment construire le produit mais aussi comment parler de manière crédible avec les clients qui l’utiliseront. Cela dit, une compréhension technique de base de ce qui se trouve sous le capot et une maîtrise des outils utilisés par les chefs de projet sont certainement importantes pour ce rôle, où qu’il soit. Colin Lernell en dit plus sur ces compétences nécessaires ici. Si vous êtes un aspirant GP et que vous craignez de ne pas avoir les compétences techniques de base pour le rôle, vous pourriez envisager de suivre des cours en ligne comme le célèbre cours Introduction à l’informatique (CS50) offert par l’Université Harvard ou l’un des nombreux cours d’introduction et de technologie avancée offerts par la Flatiron School.
Philosophie de l’entreprise au sujet du GP. Chaque entreprise a une philosophie différente concernant le processus de développement de produits et la place des MP dans ce processus. Voici les trois types les plus courants, avec leurs avantages et leurs inconvénients :
- La MP dirige l’ingénierie. Il s’agit d’une approche » à jeter par-dessus le mur « , où les GP recueillent les exigences, rédigent la quintessence du document sur les exigences du produit et le remettent à l’ingénierie pour qu’elle spécifie les exigences techniques. Les organisations contemporaines peuvent réaliser ce processus de manière plus agile et collaborative, mais on s’attend à ce que les GP sachent mieux que quiconque ce dont les clients ont besoin et que l’ingénierie soit là pour les servir.
- Pro : L’ingénierie peut se concentrer sur le codage sans beaucoup de distraction ; cela a tendance à bien fonctionner pour les ateliers de développement Waterfall avec de longs cycles de vie.
- Con : Les ingénieurs perdent de vue la vue d’ensemble et ne développent pas d’empathie pour les clients, ce qui peut conduire à une mauvaise expérience utilisateur. Il y a souvent des tensions malsaines lorsque la dette technique et le travail de » plomberie » doivent être prioritaires par rapport aux besoins des clients.
- L’ingénierie dirige le produit. Les entreprises de produits plus orientés techniquement (cloud, big data, réseau) ont tendance à être axées sur l’ingénierie, où les ingénieurs font progresser la science dans leur domaine et les PM valident les solutions ou créent des points d’accès frontaux (interfaces utilisateur, API) pour exploiter cette nouvelle technologie. Il peut y avoir une relation de collaboration et une boucle de rétroaction entre les clients, les MP et l’ingénierie, mais généralement les MP sont au service de l’ingénierie dans ces entreprises.
- Pro : Une technologie révolutionnaire peut offrir aux clients des choses dont ils ne savaient même pas qu’ils avaient besoin. VMotion chez VMware en a été un excellent exemple. Un ingénieur a pensé que ce serait cool à faire, un PM a trouvé comment le monétiser, et c’est devenu un changeur de jeu d’un milliard de dollars pour l’entreprise.
- Con : Les ingénieurs courent après la nouvelle chose brillante, sur-architecte la solution, ou itère à l’infini, cherchant la perfection avant d’obtenir le feedback des clients. L’apport des PM sur les priorités est ignoré, ce qui inclut parfois les besoins les plus fondamentaux des clients.
- Le partenariat PM-ingénierie. Dans ces cas, il existe un fort yin-yang entre le GP et l’ingénierie, avec une découverte conjointe, une prise de décision et une responsabilité partagée. Les ingénieurs rejoignent les GP dans les entretiens avec les clients, et les GP sont dans les réunions de sprint pour aider à débloquer les tâches ou à clarifier les exigences. Mais les deux rôles respectent la ligne où l’un commence et l’autre s’arrête. Les GP comprennent ce qui est codé mais ne disent pas aux ingénieurs comment coder, et les ingénieurs ont de l’empathie pour les besoins des clients mais laissent la priorisation aux GP.
- Pro : Un processus de priorisation rationalisé qui valorise la dette technique et les projets d’aplomb ; de meilleurs processus de conception menant à une expérience utilisateur plus positive ; des équipes plus performantes avec une amélioration de la vélocité et de la qualité des produits et, généralement, des clients plus heureux.
- Contre : l’innovation révolutionnaire peut ne pas obtenir le feu vert ; le temps de mise sur le marché peut sembler retardé (même si je soutiens que ce qui est publié est bien mieux aligné sur les besoins des clients et plus susceptible de réussir à s’étendre).
Je suis clairement biaisé en faveur du troisième type de philosophie sur la MP (tout comme le capital-risqueur Fred Wilson), car j’ai expérimenté les trois et j’ai trouvé le yin-yang le plus efficace. Mais cela ne veut pas dire que les autres philosophies sont mauvaises – cela dépend vraiment du type de produit que vous construisez, du stade de l’entreprise, etc. Quoi qu’il en soit, lorsque vous envisagez un rôle de PM, la philosophie du PM au sein de l’entreprise pourrait être le facteur décisif sur l’adéquation au rôle.
Stade de l’entreprise. Le rôle du GP dans une startup est beaucoup plus susceptible d’être responsable de » toutes les choses « , alors que dans une entreprise mature, son rôle sera plus distinctement défini. (Le livre Product Leadership de Banfield, Eriksson et Walkingshaw comporte une section beaucoup plus détaillée sur ce sujet.)
- Démarrage. Au-delà de la découverte, de la définition et de l’expédition, les PM peuvent également être responsables de la tarification, du marketing, du support et potentiellement même des ventes du produit. Ces PM s’épanouissent dans un environnement teigneux et sont à l’aise avec l’ambiguïté et les changements fréquents de direction à mesure que l’entreprise travaille à l’adaptation produit-marché et apprend à fonctionner à l’échelle.
- Pro : Les PM sont susceptibles d’être plus impliqués dans la stratégie de l’entreprise, d’être exposés à la haute direction et au conseil d’administration, de pouvoir prendre plus de risques et d’avoir un impact plus important. Ils ont également plus d’influence et d’autorité sur les ressources de l’entreprise.
- Con : Il y a généralement peu ou pas de mentorat, de modèles ou de meilleures pratiques au sein de l’entreprise. (Vous devrez peut-être les rechercher à l’extérieur.) Les budgets sont généralement serrés, et les GP peuvent ne pas avoir l’expérience requise pour réussir certaines des choses qu’ils sont chargés de faire.
- Entreprise mature. Le GP peut avoir une portée plus étroite et avoir des collègues qui s’occupent de la tarification, des stratégies de mise sur le marché, etc. Et ils sont susceptibles de faire partie d’une plus grande équipe de chefs de produit.
- Pro : Les PM sont plus susceptibles d’avoir un mentorat et des modèles de rôle, ainsi que des normes de développement et des meilleures pratiques. Une association étroite avec une équipe d’ingénieurs peut créer des relations solides au fil du temps, ce qui est excellent pour l’impact à long terme et la croissance de la carrière. Et si le produit est adapté au marché, il y a une base de clients établie et une base de performance à partir de laquelle travailler, plutôt que de deviner jusqu’à ce que vous ayez raison.
- Con : Les PM sont moins exposés à la stratégie de l’entreprise et ne sont qu’une des nombreuses voix du client. Ils peuvent se » perdre » dans le système et doivent composer avec davantage de politiques et de budgets serrés.
Relation fondateur/CTO/CEO avec le GP. Surtout dans les entreprises en phase de démarrage, il est important de savoir à quel point le fondateur/CTO/CEO est impliqué dans le processus du produit. S’ils sont profondément impliqués, le rôle du GP peut être davantage un rôle de soutien, pour étoffer leurs idées ou valider les concepts avec les clients, plutôt que de concevoir et de conduire des idées propres. Cela peut être très amusant pour certains GP qui aiment s’associer aux fondateurs et aux cadres supérieurs et collaborer à l’évolution du produit. Mais pour d’autres GP, cela peut être très frustrant s’ils préfèrent s’approprier davantage la direction du produit. Cela peut également être un défi si les fondateurs ou les cadres supérieurs plus techniques préfèrent travailler directement avec les ingénieurs. Les chefs de projet peuvent alors se retrouver à l’écart ou être mis à mal (parfois involontairement), ce qui entraîne non seulement des frustrations personnelles, mais aussi des retards. Lorsque vous envisagez un rôle de GP susceptible de travailler en étroite collaboration avec l’équipe dirigeante fondatrice, assurez-vous de connaître leurs attentes à l’égard de la fonction de GP et décidez si cela correspond à vos intérêts.
Il y a, bien sûr, de nombreux autres facteurs à prendre en compte pour tout rôle, comme le type de produit que vous construisez (B2B, B2C, industrie), les personnes avec lesquelles vous travaillerez, la culture globale de l’entreprise (diversifiée, inclusive, horaires de travail flexibles, culture à distance) et, bien sûr, la rémunération et les avantages. Il existe également de nombreux articles sur l’embauche de chefs de produit pour avoir une idée de ce que recherchent les responsables du recrutement – je recommande tout particulièrement l’article de mon ami Ken Norton intitulé « How to Hire a Product Manager ». Cependant, si vous vous efforcez d’être un excellent chef de produit, tenez compte de tout ce qui précède avant de signer votre prochain contrat. Le développement des compétences de base sera une activité permanente tout au long de votre carrière, et l’utilisation du QE vous garantira une expérience plus positive. Mais l’endroit où vous travaillez, la façon dont ils travaillent et les personnes avec qui vous travaillez et pour qui vous travaillez détermineront en fin de compte votre succès à long terme.
Une version de cet article est d’abord apparue sur le site Web de l’auteur.