Comme je vous l'expliquais dans la première partie de ce cours, le métier de Product Manager, en plus de présenter de multiples variations, ne s'apprend pas à l'école. En effet, même s'il existe des méthodes et des outils largement présents dans le Product Management, l'impact du contexte de chaque entreprise est tellement important que les utiliser tels quels est peu fréquent.
La progression d'un Product Manager est donc rythmée par ses tentatives, qu'elles se soldent par des réussites ou des échecs.
Sortez de votre cadre
Je vous rassure tout de suite, je ne m'apprête pas à vous faire une énième leçon du fameux think out of the box. Je vais par contre vous encourager et vous expliquer comment get out of the box.
Comme pour n'importe quel poste, lorsque l'on arrive dans un nouveau contexte, que ce soit en changeant d'entreprise ou juste d'équipe, il y a un temps d'adaptation pendant lequel on s'applique à intégrer le fonctionnement et les concepts qui lui sont propres. Pour un Product Manager, ce travail est déterminant, car s'il n'est pas réalisé correctement, ce sont les futures décisions qui risqueront d'en pâtir.
De plus, outre le fonctionnement et les concepts, le travail du PM est impacté par la culture, l'historique, la stratégie, le marché, la concurrence, et autres éléments qui composent l'environnement du poste.
Ça veut dire qu'on nous laisse plus de temps pour nous adapter ?
Eh... non. Ca veut dire que vous allez devoir commencer à travailler sans avoir de certitude sur tout ce qui vous entoure. Et c'est ça qui va vous faire progresser.
À chaque obstacle, le Product Manager va devoir improviser, tenter quelque chose en utilisant ce qu'il a appris de ses précédentes expériences. Parfois, ce sera pertinent et parfois il se trompera complètement ! Dans les deux cas, il y aura de l'introspection à faire et des leçons à tirer.
Prenons un exemple !
Vous venez de démarrer en tant que Product Manager dans une équipe de recherche et développement (R&D). Auparavant, vous étiez dans une équipe en charge de l'application mobile, et fonctionniez en suivant la méthodologie agile Scrum.
Votre équipe de R&D ne suit aucune méthodologie de travail connue et vous avez du mal à trouver votre place, donc vous décidez de mettre en place Scrum, qui fonctionnait parfaitement dans l'autre équipe.
Au planning, vous définissez, un peu dans la douleur, le contenu du premier Sprint avec l'équipe. À la fin de celui-ci, la réalisation est totalement à côté de ce qui avait été prévu. L'équipe vous explique alors qu'en R&D, on ne connaît que très rarement à l'avance les tâches qui vont être nécessaires pour avancer, et la majorité fera son apparition au cours du travail.
Scrum nécessitant impérativement de connaître son périmètre pour être appliquée, vous venez d'apprendre que cette méthodologie ne convient pas en R&D.
Vous voyez sûrement où je veux en venir : pour progresser en tant que Product Manager, vous devez sortir de votre zone de confort, et aller vous confronter à des contextes que vous ne maîtrisez pas.
Apprenez de vos échecs
Je suis loin d'être le premier à mettre l'accent sur le sujet : on apprend beaucoup plus d'un échec que d'une réussite. Si accepter l'échec ne paraît pas naturel, c'est pourtant une étape par laquelle le Product Manager doit passer s'il veut pouvoir expérimenter.
Faire des erreurs fait partie de la vie des Product Managers, quelque soit leur niveau d'expérience. Une simple recherche Google vous listera les plus gros échecs des sociétés qui, pourtant, sont leaders des plus grosses industries. Ce qui va compter, c'est que le PM comprenne ce qui ne s'est pas passé comme prévu, qu'il en tire un enseignement, et qu'il ne refasse plus cette erreur. Sa capacité d'analyse, que je mentionnais dans les qualités humaines primordiales du poste, sera donc très fréquemment mise à l'épreuve.
D'accord, mais si je commence par me tromper à chaque fois que l'on me confie une tâche, je doute que mon manager soit satisfait !
C'est vrai ! Heureusement, si vous êtes rigoureux dans la phase d'introspection qui suit un échec, vous en apprendrez suffisamment pour ne plus refaire la même erreur, ainsi que beaucoup d'autres qui auraient pu arriver.
Pour vous donner des éléments qui vous aideront à analyser un échec et en tirer les bons enseignements, voir quelques questions que je me pose lorsque quelque chose ne se passe pas comme prévu :
Ai-je suffisamment approfondi le sujet avant de me lancer ?
Qu'aurais-je pu mesurer pour détecter le problème plus vite ?
Y a-t-il des éléments du contexte qui ont eu un impact que je n'avais pas anticipé ?
Ces questions vous permettront de répondre à la question :
Dans la même situation, que ferais-je différemment et pourquoi ?
C'est cette réponse qu'il faudra ajouter à votre panel de connaissances et qui vous servira très certainement dans un futur contexte.
Ne vous accaparez pas des responsabilités des autres
Comme je le mentionnais au début de ce chapitre, les attributions du PM se déclinent en de très nombreuses variations. Ainsi, vous n'allez pas uniquement progresser sur vos compétences touchant au Product Management, mais aussi sur vos compétences annexes, comme le design, l'analyse de données ou encore la communication. Pour autant, si vous restez Product Manager, ces compétences doivent rester annexes.
Ainsi, si vous arrivez dans un contexte dans lequel ces attributions sont propres à d'autres postes, apprenez à déléguer. Vous aurez toujours la possibilité de donner des idées ou de proposer des alternatives, mais ce ne sera pas à vous de décider.
En bref
Le Product Manager progresse en découvrant de nouveaux contextes ;
Les essais doivent toujours être suivis d'une introspection pour en tirer des apprentissages ;
Les attributions annexes du PM doivent être déléguées lorsqu'elles deviennent l'attribution principale de quelqu'un d'autre.
Les différents contextes servant de fuel à la progression, échanger avec d'autres PM est un très bon moyen d'augmenter vos connaissances, sans pour autant avoir à changer de poste toutes les deux semaines. C'est le sujet du prochain chapitre !
