Article original : My path from software engineering to product management
Par Sari Harrison
Et quelques conseils pour le faire vous-même
On me demande souvent comment passer à la gestion de produit. Par des ingénieurs logiciels, des chefs de projet, des chefs de produit marketing, des scientifiques des données, des personnes en assurance qualité… Je me demande s'ils savent ce qu'ils demandent.
Voici comment cela s'est passé pour moi.
L'amour au premier programme
Mon père a acheté un ordinateur pour la famille quand j'avais 12 ans. Il était livré avec un manuel de programmation BASIC et je me suis plongée directement dans le premier programme de tout le monde — Hello World ! Puis je suis passée à la copie du code pour le jeu « Sorry ! » du manuel, en trouvant et en corrigeant un tas de bugs.
Enfant, j'adorais toujours faire des puzzles, et la programmation était comme résoudre des puzzles pour faire faire à l'ordinateur ce que je voulais. J'ai été immédiatement accro et j'ai décidé que j'allais faire des études en informatique. Oui, à 12 ans.
Je regarde en arrière et je m'émerveille un peu. Si décisive… Si grande écoute de mon intuition… Pourquoi ne puis-je pas faire cela tout le temps ?? Je n'ai connu ce genre de clarté que quelques fois dans ma vie. Une autre étant le passage à la gestion de produit. Mais je m'emballe.
Apple Round 1
Après l'université, j'ai décroché mon emploi de rêve en tant qu'ingénieure logicielle chez Apple, à l'époque de John Sculley. J'ai travaillé sur le routeur Internet Apple sous la direction d'Alan Oppenheimer, qui a littéralement écrit le livre sur la pile de réseau d'Apple.
J'étais pratiquement la seule ingénieure féminine de l'équipe. Le gars qui installait mon téléphone m'a demandé si je « soutenais » Alan. Il m'a fallu quelques minutes pour réaliser qu'il pensait que j'étais la nouvelle assistante d'Alan. Mais encore une fois, je m'égare…
J'ai travaillé chez Apple pendant 8,5 ans lors de la première période (nous garderons la deuxième période pour une autre fois). J'ai eu 4 PDG. Après John Sculley, il y a eu Michael Spindler, Gil Amelio, puis le retour de Steve Jobs.
Quand Steve est revenu, il a licencié d'énormes parties de la main-d'œuvre et annulé de nombreux projets, y compris celui sur lequel je travaillais. Je n'ai pas réussi à obtenir un package de licenciement, ce que, à l'époque, nous considérions tous comme la meilleure option (que savions-nous ?).
J'ai continué chez Apple pendant quelques années de plus, livrant la première version du trousseau Apple et la première suite d'API Internet (Subwoofer). L'iMac a été lancé. J'ai parlé à la WWDC 3 fois. J'étais réussie selon la plupart des définitions, y compris la mienne.
Total Quality Management (TQM)
Apple n'avait pas de gestion de produit à l'époque (ni maintenant, d'ailleurs). Il y avait une équipe de marketing produit très légèrement dotée en personnel qui, hypothétiquement, rédigeait des « Documents de exigences du marché » (MRD). Mais si j'en ai jamais vu un, c'était fait après que nous avions écrit les spécifications techniques et ajouté ~0 valeur.
Heureusement, je suis née penseuse des premiers principes. Simon Sinek était probablement encore à l'école primaire, mais je commençais par le pourquoi de toute façon. Mon besoin de comprendre la bonne chose à faire ensuite et n'ayant personne pour me guider, m'a conduit à quelque chose appelé TQM.
Il y avait un consultant TQM qui traînait chez Apple, travaillant avec d'autres équipes, dont j'ai eu vent. Et je l'ai fait venir pour l'enseigner à l'équipe de routage.
Tel qu'on me l'a enseigné, le TQM était essentiellement la pensée design, mais uniquement axée sur la technologie. Et pour être honnête, il y a des éléments qui vont au-delà de la pensée design (désolée IDEO). En particulier, l'accent mis sur le fait que toute l'équipe développe de l'empathie pour le client, plutôt que seulement les designers.
Je me suis donc lancée dans les visites clients et j'ai acquis des insights produits grâce à l'empathie. Dès 1995. Cela m'a conduit à ma première idée de produit — la passerelle Apple/IP. Ce fut un grand succès jusqu'à ce que IP prenne le dessus sur la plupart des réseaux existants et qu'AppleTalk soit obsolète.
Et cela n'aurait pas vu le jour sans l'empathie client. Surtout puisque c'était un produit B2B. Nos clients ne l'ont pas « demandé ». J'ai simplement vu les problèmes qu'ils avaient de première main et que le tunneling IP à travers AppleTalk les aiderait.
Directly Responsible Individual (DRI)
Après mon temps dans le routage, je suis passée à l'équipe Cyberdog qui développait une suite d'applications Internet. FTP, Telnet, Gopher, SMTP et HTML… Je parie que beaucoup d'entre vous doivent chercher certains de ces termes ?. Nous avons tout fait cela avec une équipe d'environ 25 personnes et j'étais l'une des gestionnaires d'ingénierie.
Après notre première version, j'ai été désignée « DRI » de Cyberdog. Ce concept est unique à Apple et est la raison pour laquelle il n'y a toujours pas de gestion de produit à proprement parler. Le DRI est généralement un gestionnaire d'ingénierie et inclut à la fois la propriété du produit et la gestion de l'équipe d'ingénierie créant le produit.
C'est un excellent poste si l'équipe est raisonnablement petite. J'adorais cela. À l'exception du petit détail que je devais encore écrire du code.
J'aimais bien écrire du code, ne vous méprenez pas. Mais cela nécessitait que je sois complètement concentrée, ce qui n'est pas toujours possible dans un environnement rapide. Et je préférais de loin le reste de mon travail.
Je devenais parfois assez grincheuse. Je me souviens du sentiment quand mon testeur principal venait à ma porte alors que j'essayais de comprendre un bug super difficile. Il me fallait toute mon énergie pour ne pas crier « laissez-moi tranquille — je travaille ! ». Avec le recul, c'était vraiment de bonnes données ?.
Dans l'ensemble, j'étais une codeuse décente. Meilleure pour itérer sur le code de quelqu'un d'autre que pour commencer à partir de zéro. Mais j'étais une excellente DRI. J'adorais prendre des décisions de priorisation difficiles. J'adorais la recherche utilisateur. J'adorais faire avancer l'équipe, en coupant à travers l'ambiguïté. J'aimais même écrire des spécifications.
Gestion de programme Microsoft
En tant que DRI de Subwoofer (première suite d'API Internet), je suis allée chez Microsoft un jour pour voir si nous pourrions vouloir faire un peu de partage de code avec leur équipe Mac Internet Explorer.
Je me suis assise dans l'une de leurs salles de conférence et voici ce gars qui se présente comme le gestionnaire de programme. Je me dis « uh… puis-je parler à quelqu'un de technique, s'il vous plaît ? Où est le gestionnaire de développement ? »
Mais il s'est avéré qu'il était technique et comprenait les affaires. Intéressant, me suis-je dit… qu'est-ce que ce rôle exactement ?
Note à part pour ceux qui n'ont pas travaillé chez Microsoft. La gestion de programme est la gestion de produit. La discipline a commencé là où d'autres entreprises technologiques avaient le marketing produit et la gestion de produit comme une seule personne. Microsoft a été le premier à les séparer. Le premier à avoir quelqu'un complètement concentré sur ce que nous devrions construire, pourquoi, et un peu comment. Et ils l'appellent « gestion de programme ».
En 2001, j'ai reçu un appel d'un ami qui travaillait autrefois chez Apple avec moi et dont l'entreprise (WebTV) avait été rachetée par Microsoft. « Sari », a-t-il dit, « nous avons besoin de gestionnaires de programme ici et j'ai pensé à toi. »
Il savait, avant moi, que j'étais une PM. Même si nous avions tous les deux passé la plupart de notre carrière chez Apple où ils n'existaient pas.
J'ai rejoint l'équipe (laissant derrière moi une tonne d'actions Apple, oops…). Mon ami est parti pour Google peu de temps après. Mais j'avais trouvé ma vocation d'un point de vue disciplinaire et je n'ai jamais regardé en arrière.
Réflexions finales et quelques conseils
Mon histoire est celle de quelqu'un qui est une PM dans l'âme et qui a trouvé sa voie de manière organique. Donc ma première question pour vous est exactement celle-ci :
Êtes-vous une PM dans l'âme ?
Regardez bien pourquoi vous voulez être une PM. Il est difficile de comprendre ce qu'est le rôle si vous ne le faites pas déjà, alors comment le savez-vous ? Pourquoi êtes-vous attiré par cela ? Lisez quelques-uns de mes autres blogs. Êtes-vous sûr ?
Faites-vous déjà le travail ? Sans le titre ?
Si vous êtes dans un rôle d'ingénierie, de projet, de programme ou de design aujourd'hui et que vous n'avez pas de PM, qui fait le travail du PM ? Le travail — définir le produit, faire avancer les choses, être le catalyseur pour que les décisions difficiles soient prises — doit être fait. Par quelqu'un.
Si c'est vous, et que c'est votre partie préférée de votre travail, alors c'est un bon signe que c'est le bon rôle pour vous. C'est aussi comment vous pouvez vous vendre lors d'un entretien.
Essayez là où vous êtes.
Si vous avez une PM, demandez-lui si vous pouvez aider d'une manière ou d'une autre. La plupart des PM vont sauter sur l'occasion parce qu'ils sont submergés de travail. Oui, vous devrez le faire en plus de votre travail de jour. Désolé ?♀️.
Faire le changement dans votre organisation actuelle est ce que je recommande, si possible. Vous connaissez déjà le produit et la technologie et c'est une aide énorme.
Faites savoir à votre leader PM que vous êtes intéressé. Découvrez ce qu'ils recherchent. Demandez des idées pour pratiquer les compétences requises ou prouver que vous les avez.
Suivez un cours.
Obtenez une formation. Il y a un tas de cours de gestion de produit que vous pouvez suivre. Je ne vais pas en recommander un en particulier. Renseignez-vous. La principale chose qu'un cours aidera est de vous exposer à ce qu'est le rôle et de vous donner un peu de vocabulaire. Et montrer aux gestionnaires d'embauche que vous vous souciez assez pour consacrer du temps et de l'énergie. Cela élargira également votre réseau.
En parlant de réseau… Ce que je ne pense pas aider beaucoup, c'est le « réseautage ». Ce que je veux dire par là, c'est assister à des événements de réseautage, des rencontres ou des conférences. Les relations que vous commencez là peuvent vous aider dans quelques années si vous les cultivez. Mais elles ne vous aideront pas de sitôt.
Utilisez votre réseau.
Je pense que votre réseau existant peut aider. C'est ainsi que j'ai obtenu mon premier rôle de PM sans vraiment l'avoir prévu. Quelqu'un qui pense à vous comme une excellente option est la meilleure façon d'obtenir un emploi, y compris en tant que PM. Alors faites savoir à votre réseau existant que vous voulez faire le changement. Et non, je ne connais pas de raccourci pour construire un bon réseau ?.