La gestion des produits est un travail cool, sans doute l’un des rôles les plus recherchés dans les affaires aujourd’hui. Mais, si vous y êtes depuis assez longtemps, vous finissez inévitablement par entendre une version de cette phrase à un moment ou à un autre:
Dieu sait seulement quand mon produit va être expédié!Homme d’affaires frustré (ou PM)
Ou une version de l’inverse…
Les chefs de produit… ils nous donnent toujours plus de choses à faire.Ingénieur frustré
J’ai entendu plusieurs variantes de ces phrases plus d’une fois. Dans mes heures les plus sombres, j’aurais même pu murmurer une version douce de l’une d’entre elles sous mon souffle.
Bien sûr, ces sentiments sont normaux, voire sains, avec modération. La gestion des produits et l’ingénierie doivent être constamment poussées pour que des progrès soient réalisés. Trop à la fois et la corde se casse à cause de la tension. Trop peu et la chaîne se relâche et rien n’est fait. Alors, comment vous assurer que la corde a toujours la bonne tension, ne se relâche pas et ne se casse jamais?
Bien que je ne me considère pas comme un expert (et je ne le ferai jamais … je pense qu’il est important de cultiver la mentalité de l’apprenant), je pense avoir appris les leçons – dans certains cas, durement gagnées – sur la manière de travailler efficacement avec, communiquer avec et motiver les ingénieurs qui pourraient être utiles à d’autres chefs de file de la gestion de produits alors qu’ils cherchent à améliorer la vitesse et le délai de mise sur le marché de leurs équipes (si tout va bien agiles).
Voici certaines des choses à garder à l’esprit lorsque vous travaillez avec des ingénieurs que j’ai tirées de mon expérience. En cas de doute, ceux-ci devraient vous servir d’étoile du Nord.
1. Commencez par pourquoi
Les chefs de produit possèdent le «quoi» et le «pourquoi»; les ingénieurs possèdent le «comment».
Si vous embauchez des ingénieurs intelligents et leur dites simplement quoi construire sans expliquer l’analyse de rentabilisation ou l’impact potentiel de votre produit ou fonctionnalité (en d’autres termes, si vous ne commencez pas par le Pourquoi), tu:
- Risque de démotivation (entraînant des retards, ou pire) si les ingénieurs ne comprennent pas la valeur du produit ou de la fonctionnalité sur laquelle vous souhaitez qu’ils travaillent.
- Perdez du temps en sur-construisant (ou pire, en construisant la mauvaise solution) parce que, si les ingénieurs avaient compris que le problème était résolu, ils auraient pu avoir une meilleure (ou plus rapide) façon de le résoudre
- Risque d’être mal compris sur un ou plusieurs détails (ou même une plus grande partie) du produit, ce qui aurait pu être évité si le pourquoi avait été clairement précisé dès le départ.
En commençant par pourquoi est la plus grande chose que vous puissiez faire pour motiver votre équipe d’ingénieurs (en fait, toute votre équipe) à avancer vers un objectif commun.
2. Soyez ouvert au «comment» (et soyez ouvert aux commentaires et aux changements):
Cela est particulièrement vrai pour les PM qui ont une formation en ingénierie ou qui ont été habitués à être enracinés dans les mauvaises herbes / la mise en œuvre.
En général, une fois qu’un problème a été identifié, il peut être résolu de plusieurs façons. Ne dictez pas le comment. Discutez avec les membres de l’équipe d’ingénierie qui y travailleront et demandez-leur de faire des recommandations sur le comment, afin de pouvoir choisir parmi les options (en évaluant les compromis sur les coûts de mise en œuvre et l’impact commercial). Cela vous aidera à trouver la meilleure solution pour vos clients ET à gagner du temps sur votre équipe.
3. Lorsque vous réussissez, merci. Lorsque vous échouez, regardez-vous d’abord
Cela comporte deux parties: détourner l’éloge et absorber le blâme.
En tant que PM, attendez-vous à ce que vos succès soient reconnus. Sachez que les dirigeants vous féliciteront souvent pour les succès de l’équipe – cela vaut toujours la peine d’être humble et de détourner les éloges de toute l’équipe. Non seulement cela permettra aux dirigeants de vous respecter davantage, mais cela aura également pour effet de renforcer la confiance de votre équipe en vous, ce qui est essentiel pour les succès futurs de votre équipe. En outre, faire le contraire ne fera que se retourner contre vous et vous faire apparaître comme un porc d’attention avide de pouvoir.
Le revers de cette pièce est la panne ou l’échec occasionnel. Lorsque quelque chose échoue, soyez le premier à intervenir publiquement et à en prendre la responsabilité. S’il est évident que ce n’était pas de votre faute et qu’un membre de votre équipe a foiré, appelez-le comme un échec de «notre» part, et en tant que chef de l’équipe, prenez immédiatement la responsabilité de résoudre le problème. Ne redirigez jamais les accusations qui vous visent.
Quoi que vous fassiez, assurez-vous d’envoyer des remerciements et de donner du crédit à l’équipe d’ingénierie lorsque les choses vont bien.
4. Faites suer les petites choses – soyez détaillé et spécifique
Aucun détail n’est trop petit. De nombreux PM laissent les détails techniques (ou pire, les détails du produit) aux ingénieurs, utilisant «ce n’est pas mon travail» comme excuse. Mais la compréhension des détails techniques vous aidera à comprendre ce qui est difficile, ce qui est facile et à faire de meilleurs compromis. Cela a également pour effet d’améliorer le produit et de gagner le respect de l’équipe d’ingénierie, ce qui n’est pas facile à trouver. Les deux sont des valeurs ajoutées qui vous rendent indispensable à l’équipe et à l’organisation. N’oubliez pas qu’en tant que chef de produit et chef d’équipe, il vous incombe de conserver par écrit tous les détails. Il suffit de ne pas rendre vos spécifications si verbeuses que personne ne se donne la peine de les lire.
5. Soyez toujours transparent et impliquez les ingénieurs tôt (donc la propriété est partagée)
Les ingénieurs sont très analytiques, mais beaucoup comprennent également une stratégie commerciale et produit solide. En plus de cela, ils sont également très sceptiques – les meilleurs remettent tout en question (de manière collaborative et constructive). Impliquez l’ingénierie tôt et souvent, afin que tout le monde ait la possibilité de contribuer à la vision du produit et d’acheter là où le produit se dirige.
La transparence renforce la confiance et la confiance conduit à de grands efforts. La pire chose que vous puissiez faire est de garder un air de mystère lorsque des décisions sont prises. N’oubliez pas que la création d’un excellent produit est un processus collaboratif.
6. Ne vous engagez jamais sans eux
Tu ne devrais jamais – je veux dire jamais – s’engager sur des dates, faire des estimations d’efforts ou communiquer des plannings de projets sans consulter votre équipe d’ingénieurs. Encore une fois, les chefs de produit issus de l’ingénierie sont particulièrement sensibles à cela, mais cela peut être facilement résolu en s’assurant que votre responsable de l’ingénierie est connecté avant qu’un engagement majeur ne soit pris envers l’une de vos parties prenantes.
Cela dit, vous pouvez contester les estimations (en interne avec votre équipe d’ingénieurs et avec un raisonnement solide) avant de communiquer les calendriers de projet aux parties prenantes. Assurez-vous simplement que vous êtes aligné avec votre équipe avant d’atteindre ce point.
7. Débloquer votre équipe d’ingénieurs est toujours votre priorité absolue
En tant que propriétaires de produits, nous sommes souvent submergés de choses à faire et de demandes de nos équipes de parties prenantes, y compris le développement commercial, la gestion des comptes, le marketing, etc. Cependant, il devrait toujours être votre priorité absolue de répondre à une question ou d’aider à tester une fonctionnalité qui aiderait à débloquer votre équipe d’ingénierie (surtout si elle travaille sur une tâche pour vous dans un Sprint qui a déjà été mis en mouvement). . Répondre aux parties prenantes et aux demandes des clients doit toujours venir en deuxième position.
Au final, cela revient au respect. Qu’est-ce qui est le plus important, votre temps ou le temps collectif de tous les membres de votre équipe d’ingénieurs?
8. Respectez leur temps
Comment vous sentiriez-vous si vous étiez au milieu d’un calcul mathématique long mais important, et qu’on vous demandait de tout laisser tomber pour regarder un e-mail que quelqu’un venait de vous envoyer? C’est essentiellement la vie d’un ingénieur, 100 fois.
Ne sois pas cette la personne.
Tout ce sur quoi travaille un ingénieur est probablement plus important que ce dont vous avez besoin en ce moment. Demandez-vous à quel point cela est critique et en ai-je besoin maintenant? Vaut-il la perte de productivité que cette demande va inévitablement coûter à l’équipe? Puis-je demander à quelqu’un en dehors de l’équipe d’aider, ou mieux encore, puis-je le faire moi-même?
9. Connaissez (et soyez la voix de) votre client
N’oubliez pas que l’entreprise est en affaires pour s’assurer que les clients sont satisfaits. Cela devrait toujours être votre North Star.
Il est donc de votre devoir d’être préparé avec des informations (qu’elles soient qualitatives ou quantitatives) sur la façon dont le client ou le client pense les choses, quels sont leurs besoins et les idées pour améliorer leur vie. C’est un excellent moyen de motiver votre équipe d’ingénieurs et de gagner leur respect.
Dans la même veine…
10. Aligner la perspective avec l’utilisateur
Souvent, le gagnant est le HiPPO (l’opinion de la personne la mieux payée), mais ce n’est pas nécessairement la meilleure façon de construire de bons produits. Si vous faites du client ou du client la personne la plus importante dans le processus décisionnel, l’accord et l’alignement dans l’ensemble de l’organisation (et pas seulement avec votre équipe d’ingénieurs) deviennent beaucoup plus réalisables.
11. Définir les attentes par l’expérimentation
Lorsqu’il s’agit de prendre des décisions, les données expérimentales constituent un bien meilleur point de départ pour la conversation que les opinions.
12. Valider la demande pour parvenir à un consensus
Rien ne motive plus un ingénieur qu’une victoire rapide (ou sûre). À cette fin, vous pouvez utiliser des expériences pour clarifier et valider la demande pour un produit ou une fonctionnalité avant l’écriture d’une seule ligne de code. Et lorsque vous le faites, regardez ce que les données vous disent et utilisez-le à votre avantage lors de votre plaidoyer.
13. Utiliser les conceptions uniquement comme outil de compréhension mutuelle
Cela rejoint mon point précédent sur l’implication précoce des ingénieurs. Tant que cela ne les éloigne pas du temps d’écran productif, les ingénieurs l’apprécient (et sont plus facilement intégrés dans une idée) lorsqu’ils sont inclus dans les e-mails / discussions / premières maquettes de concepts. Dans le même esprit, les dessins, lorsqu’ils sont présentés pour la première fois à l’équipe d’ingénierie, ne doivent pas être gravés dans la pierre.
Idéalement, les conceptions devraient être utilisées comme un outil pour expliquer une solution possible à un problème client que vous pouvez tous aborder. Si les conceptions sont toujours «verrouillées et chargées» et rarement modifiées après les avoir montrées à l’ingénierie, vous ne les impliquez probablement pas assez tôt dans le processus et, par conséquent, vous vous trompez.
14. Toujours tester (ABT)
ABT fait généralement référence à une culture d’expérimentation et de découverte continue de votre client, mais j’aime suffisamment l’acronyme pour l’utiliser ici également.
Les meilleurs chefs de produit considèrent que les tests (ou «Signature du produit» ou «Acceptation du produit», quel que soit le nom que vous puissiez utiliser dans votre flux de travail) constituent une partie importante de leur travail. Une fonction d’assurance qualité distincte est importante, mais il est également important que le travail de test ne soit pas quelque chose que vous laissez aux autres. Et tout en testant le produit, assurez-vous de savoir si la solution que votre équipe a créée fonctionnera pour vos clients – et si ce n’est pas le cas, qu’est-ce qui doit être changé pour le faire.
15. Réduisez le processus au minimum
Personne n’aime les processus, certainement pas les ingénieurs. Surtout quand cela conduit à une perte de temps et à des barrages routiers inutiles. Limitez au minimum les logiciels ou les feuilles de calcul de suivi, les rapports d’état et les e-mails de mise à jour exécutifs interfonctionnels. Mieux encore, éliminez-les. Voici ce que j’ai trouvé fonctionne généralement bien pour la plupart des équipes agiles:
Bihebdomadaire:
Du quotidien:
- Standups
- Évaluation des progrès du sprint
- Par-dessus tout, trouvez des moyens de collaborer et de travailler plus étroitement ensemble au quotidien.
16. Mettre l’accent sur l’établissement de relations solides
Cela va au-delà de l’établissement de relations avec uniquement votre équipe d’ingénieurs. S’il est important de maintenir les limites, cela aide également si vous ne séparez pas vos vies personnelles et professionnelles de manière trop rigide. En plus de reconnaître et d’apprécier le travail des autres, demandez aux gens comment étaient leurs week-ends. Prévoyez du temps pour écouter et comprendre. Donnez aux gens le bénéfice du doute. Si vous gérez une équipe, assurez-vous que tout le monde prend le temps dont il a besoin pour être en bonne santé et heureux (ce qui se traduit indirectement par la productivité et la réussite de l’équipe). Ou, comme Ken Norton aime à le dire, «Apportez les beignets».
17. Soyez réaliste avec les attentes, mais poussez-les
Les ingénieurs ont des bases pratiques. Bien qu’il soit important en tant que leader de l’équipe de démontrer que vos plans sont réalistes et peuvent être exécutés, ils doivent également être difficiles. Nous n’aurions pas eu les lancements réussis de fusées SpaceX si Elon Musk n’avait pas poussé ses ingénieurs à dépasser ce qu’ils pensaient être leurs limites.
Par-dessus tout: appréciez votre équipe d’ingénieurs, respectez-les, communiquez fréquemment avec eux et vous serez en or.
Crédits: quelques-unes des idées ont été inspirées par le blog sardonique de Ken Norton et le blog de Megan Berry sur le même sujet.
