Au cours des trois dernières décennies, sur 10 emplois à plein temps et 150 clients de conseil, j’ai dirigé des équipes produit 18 fois (principalement en tant que VP intérimaire) et aidé une autre douzaine d’entreprises choisir leur chef de produit. Cela peut être le record pour quiconque autre que les professionnels de la recherche. Voici quelques schémas que j’ai constatés lors de la sélection de chefs de produit performants.
Modes de défaillance qui surviennent souvent:
- Les équipes exécutives ne savent pas ce que font les chefs de produit ou veulent quelqu’un qui «rendra le développement plus efficace»
- Ils ne valorisent pas l’expérience diriger des équipes de gestion de produits. Au lieu de cela, ils surpondèrent la connaissance technique étroite ou le segment de marché
- Chaque service souhaite embaucher à son image. Les directeurs des ventes veulent plus de chefs de produit. les directeurs de développement veulent plus de chefs de produit d’ingénierie; les équipes marketing veulent un marketeur dans l’habillement produit… aucun candidat ne réussit à rejoindre tous les groupes.
Déballons.
Qu’est-ce qu’il y a dans un nom?
Premièrement, j’observe que les titres et les rôles des produits varient énormément d’une entreprise à l’autre: il n’ya pas de cohérence même au sein d’un segment. Notre premier combat est donc de savoir comment appeler ce rôle. Définissons soigneusement un «chef de produit» comme quelqu’un qui supervise directement une équipe de chefs de produits y compris l’embauche, les affectations de travail, le mentorat et la résolution des différends entre produits. Dans votre entreprise, ils peuvent être appelés Chief Product Officer, VP Product, Director of Product Management ou Group Product Lead. Les chefs de produit peuvent également gérer les concepteurs, les propriétaires de produits, les opérations de produits et les analystes commerciaux ou les spécialistes du marketing occasionnels.
J’exclus spécifiquement les rôles qui sont principalement la gestion du développement: VP Engineering, CTO, CIO, Director of Development, Engineering Manager, Project Office ou Agile Transformation Leader. Si vous supervisez 52 développeurs et 4 chefs de produit, votre attention se porte principalement sur les problèmes d’ingénierie plutôt que sur les problèmes de produits.
Et de nombreux dirigeants n’ont jamais vu une bonne gestion des produits. Ils proviennent de groupes de services professionnels – ce qui est tout contrats sur mesure et gestion de projet. Ou les sociétés non logicielles – où l’informatique est pressée comme un centre de coûts au lieu de devenir le principal centre de profit de l’entreprise. Ou ils jouent créateur-créateur-de-goût-de-produit-instable-à temps partiel – où les développeurs prennent les commandes directement du PDG, secoués par un flux constant de nouvelles interruptions et de changements de priorités. Ou ils ont vécu des transformations agiles échouées de la cascade à l’échec – où travaillent des propriétaires de produits étroitement définis usines de fonctionnalités pour mettre en œuvre des projets mal envisagés pour les dirigeants d’entreprise non techniques.
Il n’est pas étonnant que les gens soient confus, frustrés et ne parviennent pas à obtenir le leadership produit dont ils ont besoin. Nous passons notre temps à nous disputer sur les titres ou à ressasser des échecs à l’échelle de l’organisation.
À mon humble avis, l’expérience de leadership produit est essentielle pour les chefs de produit
Lors de l’embauche d’un CFO (alias Head of Finance), il pose des questions sur l’expérience antérieure de la gestion des équipes de trésorerie, de paie et de comptes clients. Les directeurs financiers s’assurent que les employés sont payés et que les cadres ne sont pas en prison, de sorte que les nouveaux employés sont des embauches risquées.
Lorsqu’ils recherchent un vice-président de l’ingénierie, ils recherchent quelqu’un qui a créé de nombreux logiciels et géré des équipes de développement. «Je pense qu’écrire un logiciel serait amusant» n’est pas un argument de vente fort.
Lorsqu’ils envisagent d’embaucher des VP Marketing, ils insistent sur le positionnement, la messagerie, les entonnoirs de prospects qualifiés, l’engagement dans les médias sociaux et la stratégie marketing globale. Les directeurs marketing savent que le marketing ne se limite pas à la refonte des logos ou des e-mails de test A / B.
Pourtant, d’une manière ou d’une autre, cette pensée se perd dans les descriptions de poste et les entretiens avec les chefs de produit. Je me retrouve à insister à plusieurs reprises sur la nécessité d’une expérience produit fondamentale pour tout responsable produit. (Questions: “Avez-vous déjà eu une équipe de chefs de produit relevant directement de vous? Combien / combien de temps?” “Quel est votre modèle d’organisation préféré pour les responsables de produits?” “Parlez-moi des produits ou services que vous gérez personnellement…”)
Sans une stratégie de recrutement claire et des critères précis, les enquêteurs choisissent naturellement les candidats qui leur ressemblent le plus. Les enquêteurs commerciaux recherchent une expérience sur le terrain et un soutien pour les «offres spéciales»; les développeurs font des exercices de codage; les équipes de support jaillissent des chefs de produit qui disent qu’ils donneront la priorité à chaque rapport de bogue; les gens de la finance veulent savoir que nous pouvons estimer le retour sur investissement au niveau des fonctionnalités à neuf décimales.
J’évite cela en [1] mettre l’expérience antérieure de leadership produit au au sommet des qualifications du candidat, [2] amincir le reste de la description du poste, [3] demander à chaque membre de l’équipe d’entrevue de lire la description de poste, puis [4] attribuer à chaque intervieweur un domaine à explorer avec tous les candidats. Cela nous donne une base de comparaison.
«Nous voulons un chef de produit qui poussera l’ingénierie plus loin»
De nombreux PDG me disent que leur vice-président de la gestion des produits devrait en quelque sorte rendre le processus de développement plus efficace. Cela vient d’un malentendu sur la façon dont les gens du produit et de l’ingénierie travaillent ensemble, et d’une confusion fondamentale entre «plus rapide» et valeur réelle pour le client.
Les équipes de développement ne travaillent pas pour la gestion des produits: elles relèvent d’un vice-président de l’ingénierie ou d’un autre responsable du développement. Et ils font la plupart de leurs choix de processus / d’outillage. (Les chefs de produit peuvent avoir de fortes opinions sur Scrum vs Kanban vs XP; ou Jira vs Asana vs Pivotal Tracker; ou Selenium vs LambdaTest vs Ranorex; ou la planification du poker vs sortes de serpent.) Mais les développeurs peuvent choisir. Nos suggestions ne sont que des suggestions. Nous ne pouvons pas faire l’équipe d’ingénierie fait ce que nous demandons, nous ne pouvons que leur donner envie fais le.
La plus grande contribution du produit à l’efficacité du développement est la réduction des interruptions au milieu du sprint et la réduction de la priorité des 92% + des demandes qui ne sont pas aussi importantes que les 8% critiques que nous allons commencer puis terminer. C’est contre-intuitif pour les dirigeants de mise sur le marché, mais plus nous surchargons le développement, moins nous livrons au total. Chaque engagement client surprise (“BigCorp a besoin de X et ce ne sera pas difficile, alors nous l’avons inscrit dans le contrat”) signifie moins de temps pour nos projets stratégiques convenus et moins dévouement de nos développeurs. Les objectifs étendus et les concours peuvent motiver les équipes de vente, mais surtout les équipes de développement découragées.
Ainsi, les chefs de produit augmentent la productivité et global livraison en repoussant presque toutes les demandes bien intentionnées. (Les demandeurs individuels ne voient pas le modèle, mais nous recevons 10, 20 ou 50 nouvelles demandes chaque jour, chacune émanant d’une personne qui doit être notre nouvelle priorité n ° 1.)
Et un chef de produit doit gracieusement prendre la critique politique du reste de l’équipe de direction, sachant que chaque groupe fonctionnel veut plus d’attention de l’ingénierie.
“Notre produit est super complexe, nous avons donc besoin d’un expert en la matière”
J’entends cela partout, des produits d’apprentissage automatique au CRM en passant par les systèmes de gestion hospitalière, les outils de conception, le commerce électronique, les applications de rencontres et la sécurité du réseau. Et je ne l’achète presque jamais.
Je vois un grand fossé entre les produits B2C et B2B / entreprise, et donc leurs chefs de produits. La plupart des produits B2C ont des ordres de grandeur plus d’utilisateurs, des cycles de vente considérablement plus courts / plus simples, et aucun client unique avec un pouvoir d’achat suffisant pour nous tenir en otage. L’acheteur a tendance à être l’utilisateur et les histoires de valeur ne sont pas transmises au directeur financier pour examen. Nous apportons différents outils et réflexions commerciales aux produits grand public par rapport aux produits d’entreprise. Mon parti pris est donc de rechercher une expérience B2B / entreprise pour les entreprises B2B.
Mais à l’intérieur de cela, j’observe que les chefs de produit chevronnés peuvent apprendre la plupart de ce dont ils ont besoin en un à deux mois. Les PM de l’entreposage de données peuvent se mettre au courant de la sécurité du réseau; Les gens de CAO / FAO peuvent saisir rapidement les systèmes ERP; les vétérans des systèmes comptables peuvent passer aux systèmes de suivi des RH et des candidats.
En tant que chef de produit, il se peut que je doive pousser mon équipe à quitter le bureau (virtuel). Ce premier mois ne peut pas être consacré exclusivement à des artefacts agiles tournés vers l’intérieur ou à des analyses techniques. Au moins la moitié de leur temps doit être expérimentant directement marchés / utilisateurs / concurrents / pipelines de vente / ROI côté client et rentabilité côté entreprise / problèmes de support / défis d’intégration / écosystèmes. Parce que ce que nous pensons importe peu à moins que cela ne reflète ce qui se passe réellement sur le marché Les bons chefs de produit font confiance au marché sur leurs idées préconçues; les bons chefs de produit insistent sur découverte directe constante du client.
Si votre produit est si compliqué qu’un chef de produit ne peut pas l’apprendre en 8 semaines, vous aurez un énorme problème à faire en sorte que les prospects le comprennent, l’achètent, l’utilisent et montrent leur succès.
Voici ce que j’ai vu lorsque nous avons placé un expert non spécialisé dans le domaine du produit en tant que chef de produit:
- Ils se concentrent sur les utilisateurs expérimentés et les nouvelles fonctionnalités complexes. Ils savent comment cela doit fonctionner. Ils ont “Été le client.” Malheureusement, cela manque ce que 95% de ce que vivent les utilisateurs réels: intégration difficile, flux de travail compliqués, connaissances supposées, messages inutiles ou peu clairs, sauf pour d’autres experts. Souvent, j’entends blâmer / humilier les utilisateurs pour leur stupidité.
- Comme ce sont des experts, il est moins urgent de faire de véritables découvertes et validations. Les marchés changent, des concurrents émergent, de nouveaux problèmes apparaissent, les choix techniques évoluent – ce que nos experts ignorent. Ils connaissent déjà la bonne réponse, donc pas besoin de confirmer. “Laissez-moi vous expliquer à nouveau pourquoi les clients ne veulent vraiment pas ce qu’ils demandent.”
- Souvent, nos experts en la matière sont issus d’une expérience utilisateur de longue date. «J’ai dirigé des systèmes d’analyse des patients à la Cleveland Clinic pendant 12 ans. Je sais de quoi les hôpitaux ont besoin. Leur point de vue a tendance à être ancien, rigide, ancré dans une configuration unique. Cela sape également une compétence de base en matière de gestion de produit: segmenter de manière créative un marché pour trouver un sous-ensemble qui a besoin de nous, nous éloigner des segments où nous sommes mal placés.
Les chefs de produit doivent apporter une soif de connaissances: ce qui se passe réellement à chaque étape, du besoin du client à l’idéation d’un nouveau produit en passant par les choix techniques pour conduire la génération à la vente initiale au renouvellement pour l’utilisateur désabonné. Et les chefs de produit doivent les pousser-pousser-pousser rafraîchir constamment leurs observations.
“La hiérarchisation ne fait que mettre notre stratégie dans une feuille de calcul”
Il m’est rare de trouver une entreprise dont la stratégie est suffisamment spécifique et exploitable pour prioriser le travail produit. Parfois, c’est parce qu’ils ont emprunté des OKR simplistes hors du commun; parfois, ils «ciblent» tous les acheteurs et utilisateurs possibles; Parfois, les objectifs ne sont qu’un résumé des objectifs du service dans un fouillis de 60 éléments de tâches et de projets. La plupart n’ont pas une liste précise de ce que nous sommes ne pas va poursuivre.
Face à une longue liste de 6, 13 ou 27 objectifs stratégiques, il est très difficile de prioriser quoi que ce soit. La plupart de notre arriéré soutiendra un objectif ou un autre. Et chaque service demandeur appelle le seul objectif qui correspond à son article.
Et chaque département veut tout l’effort de développement. Le support vit avec les bogues des clients toute la journée, nous attend donc tous nos efforts pour résoudre les problèmes P1 / P2. Les ventes génèrent tous nos revenus et supposent que 100% de chaque sprint est destiné à aider à conclure des transactions importantes. Customer Success nourrit les nouveaux clients grâce à l’intégration: l’intégration et la conversion de données devraient donc couvrir presque tous nos cycles d’ingénierie. Les fondateurs non techniques voient trop d’améliorations progressives et pas assez d’innovation. La conformité veut garder nos cadres hors de prison et considère donc chaque élément réglementaire comme la plus haute priorité. L’ingénierie souffre d’une dette architecturale et d’outils imparfaits, elle souhaite donc consacrer au moins 80% de son énergie au refactoring.
Notez que chaque groupe fonctionnel a un ensemble différent de critères, métriques, justifications, histoires de valeur. Celles-ci ne sont pas faciles à comparer et à changer de jour en jour en fonction des clients faisant partie de l’échantillon d’aujourd’hui. Il s’agit donc d’un mélange d’analyse pure et de logrolling politique interne. Je n’ai jamais trouvé de feuille de calcul qui reflète la complexité.
Ce qui signifie que nous avons besoin d’un chef de produit doté de grandes capacités de négociation, d’une profonde empathie et d’une épine dorsale en acier. Rester sur la stratégie tout en échangeant des chevaux avec d’autres cadres (sans se faire virer) est une compétence subtile développée au fil des ans. De plus, nous avons besoin de notre chef de produit pour responsabiliser les chefs de produit individuels: chacun doit équilibrer les intérêts internes concurrents tout en offrant un produit gagnant sur le marché que de nombreux clients paieront. Les non-produits pensent que c’est facile; Des chefs de produit chevronnés ont passé une partie de la journée à rendre ce look facile.
Octet sonore
Tout comme nous nous attendons à ce que les directeurs des ventes, de l’ingénierie et des finances aient de l’expérience dans la gestion d’organisations de vente, d’ingénierie et de finance, nous devrions rechercher des chefs de produit qui ont de l’expérience dans la gestion d’équipes de produits.
Cela inclut le temps passé en tant que chef de produit, puis une expérience au niveau du leader: stratégie au niveau du portefeuille, brillante collaboration interfonctionnelle, embauche / mentorat de nouveaux produits et égalisation exceptionnelle pour apaiser les pairs exécutifs qui n’obtiennent jamais autant que Ils veulent. Il vaut mieux embaucher un vétéran du produit que quelqu’un qui pense que ce sera une partie de plaisir.
