Business : La malédiction du chef de produit Know-It-All – Chemin vers le produit

Lâcher les avis techniques mérite le respect.

Ouivous êtes un chef de produit travaillant sur un logiciel ou un produit technologique très avancé. Vous avez des tonnes d’expérience, une compréhension technique approfondie et pouvez tracer la meilleure voie à suivre pour votre équipe de développement – si seulement ils pouvaient vous écouter.

Il est courant que les PM, en particulier ceux qui ont une solide expérience technique, souhaitent conduire des discussions techniques pour leur produit. Tout simplement parce que vous êtes le « PDG du produit« Ne signifie pas que vous devez tout savoir et prendre toutes les décisions de mise en œuvre. En abandonnant vos avis techniques sur la «façon» dont le produit fournit le résultat escompté, vous pouvez rendre l’équipe beaucoup plus efficace.

Maintenant, vous vous demandez peut-être: « Les développeurs me respecteront-ils s’ils pensent que je ne suis pas technique? » Peut-être pas. Mais ils ne vous respecteront certainement pas si vous vous trompez. En outre, gagner le respect mutuel signifie d’abord montrer que vous appréciez leur rôle et leur propriété dans la conception et la mise en œuvre du produit.

Mieux vaut garder le silence et être considéré comme un fou que de parler et de lever tout doute. – Abraham Lincoln

Je ne dis pas que vous devez ignorer les tendances technologiques ou que vous pouvez être incurable sur la façon dont les choses fonctionnent – bien au contraire. Si vous apprenez les moindres détails de votre domaine, vous pouvez devenir un chef de produit complet.

Chaque produit a des problèmes urgents qui n’ont pas grand-chose à voir avec la mise en œuvre. Un chef de produit efficace obtiendra des réponses aux questions essentielles: qui sont les utilisateurs, qu’achèteront-ils? Comment sera-t-il emballé et évalué? Comment allons-nous gagner en notoriété et en adoption? Quelles exigences légales ou de conformité devons-nous prendre en compte? Ces questions sont essentielles au succès du produit, et vous – le chef de produit – devez les poser et y répondre.

Certaines de ces décisions apparemment indépendantes de la mise en œuvre auront des conséquences réelles sur l’équipe de développement. Par exemple, un modèle de tarification basé sur l’utilisation peut nécessiter une plomberie de comptage étendue. Votre capacité à découvrir et à décrire les limites strictes et les contraintes négociables qu’un développeur doit résoudre vous fera un atout inestimable pour l’équipe.

Comment allez-vous enquêter de manière approfondie sur ces problèmes si vous passez tout votre temps à essayer de déjouer les ingénieurs?

Il y a de nombreuses années, à l’époque où j’étais programmeur, j’étais assis avec un collègue dans son bureau (j’ai dit que c’était il y a longtemps). Un chef de produit malchanceux est entré et a pointé le tableau blanc, qui avait encore les gribouillis restants d’une entrevue de codage.

« COOL! » il s’est excalmé.

L’autre développeur et moi nous sommes regardés. Il a parlé le premier.

« Pourquoi pensez-vous que c’est cool? » Il a demandé.

« C’est comme … du code, non? »

Nous avons tous deux éclaté de rire. Probablement pas la réponse la plus professionnelle, mais comment pourrions-nous nous aider?

Lorsque je suis devenu plus tard chef de produit moi-même, j’ai partagé le scénario ci-dessus avec mon homologue responsable du développement pour illustrer l’extrême non technique que je ne voulais pas devenir. Cette histoire aide à ouvrir une conversation franche sur la façon de diviser efficacement les responsabilités – tout en respectant sainement le point de vue de chacun – en travaillant ensemble vers un objectif commun.

Lorsque nous travaillons avec des gens brillants, nos insécurités nous donnent le sentiment d’être imposteur. Nous pensons que faire partie de cette équipe, de cette entreprise, de ce projet est une erreur. Nous pensons: «Je suis un faux. Je n’appartiens pas. « 

Travailler avec des ingénieurs brillants est intimidant. Nous avons donc l’envie d’impressionner les ingénieurs de l’équipe en les surprenant par leurs connaissances techniques.

Vous pourriez partager certaines informations techniques que vous avez trouvées au cours d’heures de recherche tard dans la nuit et obtenir des signes d’approbation. Mais permettez-moi de partager un sale petit secret – ils vous font juste rire .¹

Peut-être pas à chaque fois, mais il vaut mieux supposer que oui.

Je suis tombé dans ce piège, plus récemment que je ne voudrais l’admettre. Je travaillais avec un développeur extrêmement compétent sur un outil de mise à jour du logiciel IoT. Je me suis dit que nous avions besoin d’un programme d’installation «auto-extractible», ce dont je me suis souvenu en créant des applications sur Windows il y a de nombreuses années.

Il a patiemment attendu pendant que j’expliquais l’idée et j’ai finalement roulé des yeux. J’ai soudain réalisé que j’agissais en dehors de mon domaine d’expertise, et je devrais m’en remettre à lui. Je lui ai dit d’oublier la conception que j’avais proposée, c’était son travail de comprendre cela. Il était soulagé de ne pas avoir imposé de contraintes techniques inutiles.

À ce stade, vous pensez peut-être que votre formation technique est plus susceptible de vous causer des ennuis que de vous aider. Pas du tout. Votre expérience technique est un atout. C’est lorsque vous oubliez votre rôle qu’il devient un passif. Si vous entendez quelque chose de louche, par tous les moyens, repoussez.

Vous pouvez vous retrouver dans une équipe avec un responsable du développement faible ou inexpérimenté. Ou celui qui retourne le script et essaie de vous passer outre. Ces situations nécessiteront de la finesse. Votre rondeur et votre conscience de soi peuvent sauver l’équipe – si elles sont utilisées correctement.

L’opposé d’un Know-It-All est un Learn-It-All. Un état d’esprit ouvert qui reste curieux découvrira une vérité plus profonde et des solutions plus riches à tous les problèmes que vous rencontrez. Plus nous vieillissons, plus nous réalisons à quel point nous en savons peu.

Notre cerveau peut travailler contre nous lorsque nous essayons de faire nos preuves. Parfois, nous pensons que nous sommes plus intelligents que nous. D’autres fois, nous manquons de confiance parce que nous regardons autour de nous et voyons tellement d’éclat.

Si vous êtes chef de produit, soyez attentif à la façon dont vos propres préjugés peuvent avoir un impact sur votre relation avec l’équipe de développement. Concentrez-vous sur les besoins des clients, comprendre le marché, documenter les personnalités, clarifier les priorités et effacer le chemin de la paperasserie en matière juridique, de sécurité, de confidentialité et de questions financières.

Si vous venez d’un milieu technique et que vous êtes passé à la gestion de produits, il peut être particulièrement effrayant de laisser tomber les avis techniques. Accordez-vous de l’espace pour prioriser les compétences et les connaissances qui feront de vous un chef de produit vraiment exceptionnel, pas un savoir-tout.