Un sujet qui a été soulevé à plusieurs reprises récemment lors de mes sessions de coaching de chefs de produit: combien déléguer aux chefs de produit (contributeur individuel) de nos équipes – y compris différentes façons de développer les compétences produit et d’équilibrer l’autonomisation personnelle et les bons résultats. Autrement dit, si vous dirigez une équipe de 4, 11 ou 23 chefs de produit, vous avez beaucoup à faire qui est différent de leur travail direct vous devrez donc déléguer la prise de décision ainsi que l’exécution. Cela signifie planifier un mentorat nuancé. Déballons…
Quel est notre objectif de délégation?
Différents cadres ont différents POV, donc je devrais partager mon parti pris. Mon objectif déclaré en tant que chef de produit est de déléguer autant de travail de gestion de produit directe que possible à mon équipe, à la fois opérationnel et stratégique, afin que je puisse faire le travail d’organisation et de processus pour rendre mon équipe globale plus de succès. Si mes tâches essentielles sont l’embauche, le mentorat, l’alignement des stratégies, la construction collaboration interfonctionnelle, conduite sensée OKRs/ objectifs, faire du lobbying auprès de l’équipe de direction pour plus de talents côté développement, et préempter le prochain escalade des ventes d’entreprise alors je ne peux pas aussi deviner chacune de mes personnes ou faire leur travail pour elles. Nous devons développer suffisamment de confiance et de compétences et d’expérience pratique pour que je passe de «faire» à «montrer» à «critiquer» à «inspecter le cas échéant».
Mais nous avons besoin de bons résultats, pas seulement de moins de travail pour moi. Donc, mettre cela dans le langage des résultats, une délégation réussie signifie que mes chefs de produits font des choix défendables, même si ces choix ne sont pas exactement ceux que j’aurais pu faire. Il s’agit de créer une certaine autorité pour qu’ils appliquent leur bon jugement – plutôt que «j’aurais fait cela légèrement différemment, alors laissez-moi être le décideur final sur tout».
La composition de votre équipe guidera les décisions de délégation:
- Un groupe de novices avec un enthousiasme sans bornes mais une expérience produit limitée a tendance à se concentrer sur les activités transactionnelles (billets, histoires, backlogs, présentations) mais sera faible sur la stratégie, déballant les demandes des clients mal conçues et le marchandage politique de chevaux. Vous passerez donc plus de temps à «faire» et «montrer» et à les aider à faire correspondre leur travail transactionnel aux résultats réels. Prévoyez deux heures par semaine et par personne pendant quelques trimestres pour partager ce que vous savez et critiquer les artefacts du produit.
- Si votre équipe est majoritairement chefs de produit chevronnés, ils apportent des cicatrices de bataille et des modèles mentaux et une expérience avec différentes approches et des salaires plus élevés. Mais ils peuvent être trop biaisés en faveur de «qui n’ont pas fonctionné dans la société X» ou vouloir que les PM subalternes reprennent leur travail transactionnel. Attendez-vous à passer du temps à juger les membres de l’équipe senior qui font chacun pression pour que leur produit soit le plus important et le mieux financé.
Si vous avez du personnel avec experts en la matière qui sont nouveaux dans le produit, vous devrez probablement les coacher “Les utilisateurs intelligents ne commettront pas cette erreur” et “Pas besoin d’entretiens avec les utilisateurs finaux, car je sais exactement ce que devrait contenir le produit” et “Permettez-moi de montrer à chaque client individuellement comment configurer cela.” J’ai du mal à convaincre les experts que leur propre expérience personnelle côté utilisateur n’est pas universellement vraie.
Ma préférence va à une équipe mixte de personnes âgées et juniors, avec un expert en matière de nouveaux produits très occasionnel.
Mais nous pouvons également trier la délégation en fonction des tâches et des activités. Quelles activités sont adaptées pour «vous montrer une fois et vous êtes prêt à partir» et lesquelles sont complexes, moins fréquentes ou ont des implications profondes? Lorsque vous planifiez un programme de coaching pour votre équipe (ce que j’encourage!), Réfléchissez aux domaines de produits qu’ils trouveront faciles à apprendre et aux endroits où vous aurez besoin d’un mentorat continu ou intensif. Voici trois catégories:
[1] Travail contextuel fréquent, transactionnel et au niveau de l’équipe
Certains travaux sur les produits se déroulent presque en continu et dépendent de connaissances approfondies au niveau de l’équipe. La planification de sprint, la rédaction d’histoires / la création de billets, les critères d’acceptation et la hiérarchisation fine peuvent sembler génériques de l’extérieurmais non. Je peux voir qu’une histoire d’utilisateur est grammaticalement correcte («En tant que chef de produit, je veux créer des fonctionnalités intéressantes pour que les utilisateurs finaux me comblent d’éloges et d’invitations à dîner»), mais en tant que non-participant, il me manque les spécificités infinies pour savoir si l’histoire est «juste». Les chefs de produit et leurs équipes de développement disposent de raccourcis, de noms de code et de compromis difficiles. Les longues discussions se résumaient à de courtes phrases. Compréhension partagée implicite. Des dizaines de conversations clients capturées en une seule phrase.
Je peux expliquer à quelqu’un comment équilibrer de manière générique les investissements techniques ou mesurer le succès, mais je manque de détails et de contexte pour bien faire les choses en fonction de leur situation spécifique. Le coaching ici s’appuie fortement sur «dites-moi plus sur la façon dont vous avez décidé X» et «avez-vous pensé aux résultats stratégiques si Y» plutôt que de «déplacer l’élément n ° 4 avant le n ° 3 dans votre carnet de commandes».
Mon test d’acceptation pour la délégation du travail contextuel au niveau de l’équipe est “Est-ce que je fais suffisamment confiance à mon chef de produit et à mon équipe de développement pour prendre les bonnes décisions et me pousser quand ils ont besoin d’aide?”
[2] Compromis du portefeuille stratégique et initiatives d’entreprise
Certains choix de produits couvrent plusieurs équipes ou produits. Les PM de mon groupe peuvent manquer de visibilité ou de contexte dans les grands problèmes, et favoriseront naturellement leur propre travail d’équipe. Les initiatives descendantes sont considérées comme une intrusion; L’UX et l’architecture technique communes ne correspondent pas exactement à ce que n’importe quelle équipe peut choisir. (“Une API partagée est géniale, mais faisons-le comme le souhaitent mes développeurs.” “La correction de ce bogue de sécurité à chaud est un support multilingue beaucoup plus important à l’échelle de l’entreprise.”)
La délégation et le coaching dans ces domaines sont donc un mélange de compétences, d’alignement stratégique et de visibilité plus large au niveau du portefeuille. En tant que chefs de produit, nous pourrions obliger toutes nos équipes à travailler davantage sur l’évolutivité qu’elles ne le souhaiteraient. Ou harmonisez les références / numéros de pièces pour faciliter la commande. Ou négociez des définitions de données communes pour les profils clients.
Les leaders jouent ici un double rôle: faire pression pour des choix spécifiques sur des questions importantes tout en aidant nos chefs de produits à prendre de meilleures décisions partagées sans nous.
Mon test d’acceptation pour le bon montant de délégation au niveau du portefeuille est «Faisons-nous des progrès raisonnables sur les initiatives inter-équipes tout en maintenant une autonomie adéquate au niveau de l’équipe?» Trop de pression descendante transforme chaque équipe en preneurs de commandes sans pouvoir; une hiérarchisation ascendante pure encourage les éléments de produit non liés ou incohérents.
[3] Travail subtil, peu fréquent et complexe
Certains problèmes de produits apparaissent rarement – à des années d’intervalle. Par exemple, la refacturation / reconditionnement d’une gamme complète de produits est rare: certains chefs de produit ne peuvent le faire qu’une seule fois dans leur carrière. De même formellement retirer un produit. Ou cartographiez une migration complète du site vers le cloud. Ceux-ci ont tendance à être compliqués, remplis de défis pour les clients, politiquement sensibles, chargés de communication et difficiles à dérouler si les choses tournent mal.
Il est donc probable qu’aucun membre de votre équipe produit n’ait poussé les clients qui adoptent tard à remplacer un produit ancien mais toujours utilisé par un remplacement nouveau mais suspect. Ou repositionné un portefeuille entier pour un segment de marché différent. En tant que chef de produit, vous devrez peut-être jouer un rôle très actif dans la formulation du problème, le choix de modèles mentaux, la persuasion des parties prenantes, la rédaction de contenu ou de communications et le ralliement d’autres groupes fonctionnels pour soutenir ce travail.
Si vous n’avez pas vécu cette bataille vous-même, envisagez une expertise extérieure à court terme. Existe-t-il un spécialiste de la découverte de produits, des prix, des OKR, de la sécurité du système ou de l’analyse des gains / pertes qui pourrait vous guider, vous et votre équipe, vers un résultat positif?
Les critères d’acceptation peuvent être «Est-ce que quelqu’un de mon équipe a déjà résolu ce problème? Puis-je les accompagner moi-même? Ou avons-nous besoin d’un spécialiste?
Entraîneurs-joueurs
De nombreux chefs de produit sont «joueurs-entraîneurs:»Superviser formellement les autres membres de l’équipe produit tout en étant directement responsable d’un élément spécifique du portefeuille. Il s’agit généralement d’un rôle de transition: à mesure que l’entreprise se développe ou que nos équipes deviennent plus expérimentées, ce rôle devrait passer à un poste de leadership uniquement. OMI, la combinaison joueur / entraîneur est très difficile à bien faire, avec une tendance à se concentrer sur le travail urgent à accomplir au lieu d’embaucher / encadrer / organiser une équipe qui nous sort de cette impasse. En d’autres termes, j’encourage fortement les gens à décider s’ils veulent devenir chef de produit ou chef de produit et se remplacer dans l’autre poste.
Leaders de produit qui sont nouveaux dans le produit
Tout cela nécessite une compréhension détaillée de ce que les chefs de produit doivent faire, comment ils se développent et leurs conflits quotidiens inévitables avec les parties prenantes internes. Nous ne pouvons pas “faire” ou “montrer” ou “critiquer” ou “inspecter” bien si nous n’avons pas fait de travail direct sur les produits nous-mêmes. Ce qui signifie que c’est un énorme défi pour les cadres d’autres domaines fonctionnels qui choisissent pour la première fois la gestion des produits. Il est difficile de guider les chefs de produit nouvellement créés sans expérience directe de leurs défis spécifiques.
De la même manière, l’enseignement de la vente de solutions aux vendeurs implique une connaissance approfondie des ventes. Et le mentorat de développeurs de logiciels sur l’architecture technique requiert une réelle expérience en ingénierie. Et les vraies transformations agiles ont besoin de vétérans agiles endurcis pour mener l’autonomisation et le changement organisationnel plutôt que de «simplement devenir agiles» en suivant mécaniquement un livre de mêlée et en collant de nouveaux processus au-dessus des modèles de commandement et de contrôle existants.
IMO, les nouveaux chefs de file des produits ont besoin de leur propre coaching intensif avant d’être prêts à développer la prochaine génération de chefs de produit. Je décourage donc les entreprises de leur confier la responsabilité d’équipes de produits non assaisonnées.
Octet sonore
Les chefs de produit qui réussissent doivent déléguer la plupart des travaux pratiques sur les produits, en se concentrant plutôt sur les activités au niveau des dirigeants. Cela signifie comprendre ce que chaque membre de l’équipe peut gérer, avoir un plan de mise à niveau et renforcer la confiance.
