Software Engineer + Product Manager = Product Engineer ?
Oui, mais…
C’est pas si simple.
En réalité, le Product Engineer tend plutôt vers le rôle de Software Engineer que vers celui du PM.
D’accord, mais là tu dois te demander :
- C’est quoi Product Engineer et en quoi ça consiste concrètement au quotidien ?
- Quelle boites sont à la recherche de ces profils ?
- Comment devenir Product Engineer si je suis Software Engineer ou PM aujourd’hui ?
Pour comprendre tout ça, on est partis à la rencontre de Estelle Recuero, Product Engineer chez Flowie.
Elle nous raconte son quotidien, sa vision du rôle, et son parcours pour devenir Product Engineer.
Avant de rentrer dans les détails, un peu de contexte 👇
Le rôle de Product Engineer est encore niche, mais des offres apparaissent petit à petit sur le marché.
Ce rôle est un peu à contre-courant de la tendance d’hyper-spécialisation observée dans l’Engineering ces dernières années.
Une hyper-spécialisation où les développeurs se définissent par le langage qu’ils maîtrisent. (ex : Node.js developer)
Voire même par leur framework. (ex : React developer)
Mais la tendance évolue.
À l’heure où l’IA, et notamment les LLMs, progressent de jour en jour, le rôle du Software Engineer hyper-spécialisé est remis en cause.
Certaines boites tech cherchent désormais des profils plus polyvalents, avec un scope plus élargi, tout en étant capable de délivrer techniquement.
Le Product Engineer en est l’illustration : il est à la croisée des chemins entre le produit et l’engineering.
Allez, passons au concret avec l’interview d’Estelle.
Estelle, tu peux nous raconter un peu ton parcours ?
Je suis Product Engineer chez Flowie depuis 1 an.
En parallèle, j’interviens chez Maestro, une école de Product Management.
J’ai un background de Product Manager, j’ai travaillé plutôt dans des petites équipes Product, chez Malt et Sarenza, entre autres.
Après 3 ans de CDI en tant que PM, je suis devenue freelance.
J’ai travaillé notamment avec Mozza.io où j’ai pu faire de la Product Strategy.
C’était super intéressant, mais je me suis rapidement rendue compte que j’avais plutôt envie d’évoluer sur la partie technique.
J’ai cette appétence technique depuis le début de ma carrière.
Du coup, j’ai décidé de me former sur la partie Engineering, en parallèle de mes missions freelance en PM.
Tu t’es formée seule sur la partie Engineering ?
Non, j’ai fait l’école 42, j’ai suivi le tronc commun pendant 2 ans et demi.
J’ai mis un peu de temps à finir le cursus, vu que j’avais des missions freelance à côté.
C’était assez intense.
La formation de 42 est bien plus poussée qu’un bootcamp de développement web, tu repasses sur toutes les notions algorithmiques, etc.
Mais c’est ce que je recherchais, je voulais me plonger en profondeur dans le développement.
Tu avais cette ambition de devenir Product Engineer au moment tu décides d’entrer à 42 ?
Non, au départ j’avais plutôt pour objectif de devenir Technical Product Manager.
J’avais fait pas mal de Product Strategy en freelance, c’était très intéressant, mais pour moi c’était un rôle un peu court-termiste.
Il y a assez peu de gens qui font de la Product Strategy dans les entreprises en interne, on fait plutôt appel à des consultants généralement pour s’en occuper.
Du coup, à la fin de ma formation à 42, la question qui s’est posée était :
Est-ce que je deviens Technical PM ou Product Engineer ?
Je te coupe : c’est quoi la différence entre Technical PM et Product Engineer ?
Ce ne sont vraiment pas du tout les même métiers.
Un Technical PM est plus proche d’un PM classique.
Un Product Engineer est plus proche d’un Software Engineer.
Un Technical PM, c’est un PM spécialisé sur la partie technique, typiquement sur ce qu’on appelle les dev tools.
Il travaille souvent sur un produit destiné à des développeurs (ex : Datadog).
Les Technical PM ont souvent été Software Engineer avant de se reconvertir. Pour moi, c’est juste impossible d’être Technical PM sans background technique.
MAIS le Technical PM ne code pas.
C’est la différence avec un Product Engineer, qui va à la fois avoir un scope de PM : (discovery, delivery, etc.) et un scope de Software Engineer, puisqu’il code.
Ok, et donc finalement tu as choisi Product Engineer plutôt que Technical PM. Pourquoi ?
Le fait que le Product Engineer mette vraiment les mains dans le code m’a davantage attirée.
Du coup j’ai rejoint une première petite boite où je les aidais sur la tech et le produit, puis j’ai rejoint Flowie en tant que Product Engineer, où j’ai à la fois un scope produit et dev’
Concrètement, comment ça se traduit au quotidien d’avoir les scopes Produit et Dev’ ?
Déjà, il faut savoir que la Stratégie Produit est exclue de mon scope.
Elle est gérée par les leads et les founders chez Flowie.
Mon travail commence une fois que les que les décisions stratégiques sur le produit ont été priorisées.
A partir de là, je vais dérouler la partie PM de mon scope.
Dès qu’un sujet produit arrive (on appelle ça une initiative chez Flowie), je vais devoir définir :
- Pourquoi on fait ça ?
- Quel est le besoin ?
- Quel est le problème auquel on répond ?
Ces réponses vont nous permettre d’imaginer avec les autres Product Engineers et le designer comment l’initiative peut se traduire concrètement au niveau du produit :
- Quelles fonctionnalités développer ?
- Quelle UX/UI ?
- Quel parcours utilisateur ?
On construit ensuite des wireframes, qu’on va valider avec les leads/founders.
Et ensuite, je passe sur la partie Engineering de mon scope, puisque je vais :
- Définir techniquement comment on implémente ces nouvelles features.
- Coder moi-même ces features.
Ça paraît énorme en charge de travail, non ?
Oui, ça l’est parfois !
La charge de travail d’un Software Engineer est déjà conséquente, donc rajouter des missions de PM, ça fait parfois beaucoup.
Du coup, on se pose la question de recruter un PM.
Pour nous, ce n’est pas incompatible d’avoir des Product Engineers et un PM vu la quantité de travail.
Le PM aurait davantage de recul sur la priorisation globale des sujets, et nous ça nous déchargerait de certaines tâches.
Pour autant, on continuerait d’être impliqués sur le produit, en travaillant en collaboration avec le PM, et à travailler sur la delivery.
Si je suis Software Engineer et que je m’intéresse au produit, je devrais plutôt viser PM ou PE ?
Bonne question.
Chez Maestro, je vois beaucoup de Software Engineers qui s'intéressent au produit et veulent devenir PM. Mais je leur dis souvent :
“Attention, quand tu seras PM, tu ne feras plus du tout de code”.
Je leur suggère justement de penser au rôle de Product Engineer s’ils veulent continuer à coder.
Mais ils sont encore peu à connaître ce rôle.
C’est normal, c’est encore niche, mais ça se développe !
Donc si tu ne peux pas te passer du code, et que tu ne souhaites pas trop t’écarter de ton rôle de Software Engineer, il vaut mieux viser un rôle de Product Engineer.
D’ailleurs, quel type de boites recrutent des Product Engineers ?
Comme je le disais, les postes de Product Engineer sont encore assez rares, même si ça commence à devenir un peu plus fréquent d’en voir passer.
Par exemple, j’ai vu June.so récemment qui recherchait un PE.
GitLab a aussi des Product Engineers.
Mais typiquement, 100% des process que j’avais en tant que Product Engineer, c’était avec des start-ups early-stage.
C’est assez logique, car combiner 2 compétences est hyper intéressant pour ce type de structure.
Donc, en tant que Product Engineer, il faut généralement être prêt à évoluer dans un environnement de jeune start-up, avec des petites équipes.
Comment on devient Product Engineer ?
Tout dépend de ton background.
1. Tu as un background Software Engineer
Il faut vraiment développer ton product mindset et tes compétences produit.
Être intéressé par le produit n’est pas suffisant pour être Product Engineer, il faut se former.
Tu peux te former dans une école (typiquement Maestro), et surtout commencer à t’intéresser de plus près au produit dans ta boite.
2. Tu as un background Produit
Dans ce cas, il faut se former à l’Engineering.
Je considère que le passage de PM à Product Engineer est plus compliqué que le passage de Software Engineer à Product Engineer.
Pour moi, c’est plus facile/rapide de développer son product mindset que de développer le scope Software Engineer.
Tu peux devenir développeur assez rapidement, via un bootcamp par exemple, mais être un bon développeur, ça prend du temps.
C’est pour ça que j’ai voulu faire une formation longue et solide avec 42.
Mais même après 42, je continue à devoir beaucoup travailler pour rattraper la partie technique.
Product Engineer, c’est vraiment un nouveau métier ?
Oui et non.
Les early-stage start-ups cherchent généralement des Software Engineers qui ont une appétence produit.
C’est fondamental au début d’une boite d’avoir des dev’ qui comprennent le produit, qui sont prêts à tester et échouer, et à itérer rapidement.
C’était un peu implicite jusque-là.
Le terme “Product Engineer” commence à formaliser ce besoin.
Benjamin et Thomas nous avaient effectivement mentionné la partie produit lorsqu’ils nous partageaient leur expérience de premier dev’ ici 👈🏻
Quels bilan et perspectives pour toi ?
Ce rôle me plaît énormément parce qu’il est complet.
J’adore coder, mais je ne pourrais pas “seulement” shipper des features sans être impliquée en amont sur le produit.
Pour l’instant je m’épanouis, je me vois bien continuer à ce poste.
On est encore une petite équipe (15 personnes dont 8 Software Engineers), donc il faudra voir comment le rôle évolue quand on recrutera un PM.
Je suis d’ailleurs curieuse de savoir comment ça se passe pour des Product Engineers dans des scale-ups, notamment quand ils ont des PMs dans l’équipe.
Un dernier conseil pour les Software Engineers qui envisagent la voie de Product Engineer ?
Si tu es Software Engineer, pose toi la question :
Qu’est-ce que tu aimes dans la partie Produit ?
Je vois beaucoup de gens qui veulent faire du produit faire de la stratégie et prendre des décisions, mais moi au quotidien je fais surtout de la delivery.
La Product Strategy ça fait beaucoup rêver, mais il ne faut pas devenir Product Engineer pour faire de la stratégie. Ce ne sera pas ta mission principale, et il faudra peut-être plutôt viser PM dans ce cas-là.
Un dernier conseil pour les PM qui envisagent la voie de Product Engineer ?
Si tu es PM, et que tu as envie de te réorienter vers un rôle de Software Engineer, sans abandonner la partie Produit, alors Product Engineer est une bonne option !
Par contre je te conseille de :
- Passer du temps / investir sur ta formation : évalue bien les pour et les contres entre formations rapides vs formations longues.
- Rejoindre une boite où tu seras bien encadré au niveau Engineering, avec au moins 1 ou 2 très bons Software Engineers. Ça t’aidera à progresser plus rapidement, et à pouvoir poser des questions.
On remercie Estelle pour son temps, et on te partage une ressource pour compléter cet article : Le Product Engineering Manifesto sur GitHub
A très vite ☀️
Le talent club