⚡️ Interview d'Estelle, Product Engineer chez Flowie 🧠 Ce que ça va t’apporter : Comprendre le rôle de Product Engineer, voir s’il t’intéresse, et visualiser les chemins qui permettent de l’atteindre.
Our webinars will also be available in replay. Register to the event and access our replays whenever you want.
Nous serions ravis de t’aider à trouver le job que tu mérites ! Pas de spam, juste des offres sur-mesure qui correspondent au rôle et au salaire que tu recherches.
S'inscrireSoftware 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 :
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.
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.
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.
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.
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 ?
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.
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’
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 :
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 :
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 :
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.
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.
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.
Tout dépend de ton background.
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.
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.
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 👈🏻
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.
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à.
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 :
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
Is your job right for you? Download our Job Matcher and find out! Evaluate objectively how well any position — including your current one — fits with your core values and objectives.
L’humanité est confrontée à une crise sans précédent qui menace toute vie sur Terre. L’astronaute Ron Garan, de la NASA, s’attaque frontalement à ce sujet dans sa keynote: The Orbital Perspective. Cette vidéo est en anglais.
