Interview de Zacchary Wengrow – PM @Meero

Zacchary a été PM chez ManoMano et chez Meero.
Il nous parle d’évangélisation produit auprès des équipes métier, de la philosophie du 80-20, d’abnégation, de l’importance pour un PM d’avoir une bonne compréhension tech et de la notion de « footprint ».

Hello Zacchary, peux-tu nous parler de ton parcours?

J’ai fait une école de commerce où j’ai suivi un Master en finance & un Master en Entrepreneuriat, mon objectif était de rejoindre le monde du VC. En sortie d’école, j’ai fait un stage en M&A qui ne m’a pas plu et c’est là que j’ai rejoint Mano mano en tant qu’opérationnel en finance puis j’ai évolué vers un poste de chef de projet pour l’équipe finance, sur les sujets de facturation, paiement, fraudes etc…
A posteriori je me rends compte que c’était un poste qui ressemblait beaucoup au métier de PM : mon rôle était de représenter l’équipe finance et de m’assurer que les projets finance s’inscrivaient bien dans les projets plus globaux de ManoMano. En parallèle, je construisais la vision long terme des problématiques finance, en récoltant et analysant les besoins business et en définissant la meilleure manière d’y répondre dans le futur.

Au sein de ManoMano notre équipe était devenue incontournable. En l’absence de PM on était montés en compétence techniquement. Aucun de nous n’avait de formation dev, mais nous avons appris sur le tas, à force de discussion avec l’équipe IT. Nous n’avions pas de compréhension détaillée de ce qui se passait dans le code mais nous arrivions à comprendre le fonctionnement de nos stacks techniques et à identifier des solutions potentielles à nos problèmes.

A plusieurs reprises j’ai ressenti la frustration de ne pas être celui qui interagit plus directement avec la squad et d’avoir la légitimité de le faire. C’est là que j’ai vraiment décidé de faire du produit, pour avoir réellement ce pouvoir d’agir, être celui qui pose le ticket dans le sprint.

Qu’as-tu fait après ManoMano?

Après plusieurs années chez ManoMano j’ai rejoint Meero. Je rentrais de l’etranger, je n’avais jamais entendu parler d’eux mais j’ai vu qu’il y avait beaucoup de postes ouverts, notamment dans le produit (ils avaient levé 205 millions d’euros 2 mois avant). Après plusieurs années à travailler sur le paiement chez ManoMano je savais que c’était une compétence rare et recherchée, j’ai vu qu’ils recrutaient un PM paiement et j’ai contacté directement le VP Produit sur Linkedin, et en 5 jours c’était signé.
Chez Meero j’étais attendu comme le messie car il n’y avait pas de PM dédié en face de l’équipe finance. Moi qui n’avait jamais eu le titre de PM, j’ai eu un gros syndrome de l’imposteur ! Je savais que j’avais des lacunes côté technique, donc à ma manière j’ai essayé de les combler: j’ai lu plein de livres, suivi des cours de code … et je me suis mis dans un état d’esprit “fake it til you make it”!

En arrivant chez Meero on m’a tout de suite assigné une équipe. J’ai eu beaucoup de chance car 2 mois après mon arrivée, le lead tech paiement de Blablacar, Jeremy, nous a rejoint pour devenir lead tech de mon équipe, et très vite j’ai compris qu’il était hyper compétent et que je pouvais vraiment compter sur lui, on forme un super binôme!

Peux-tu nous parler de ton rôle de PM Paiement chez Meero?

Pendant les premiers mois je me suis concentré sur ma montée en compétence, j’ai acquis une petite connaissance des problématiques techniques, je me suis plongé dans la base de données pour comprendre sa structure …
A l’époque il y avait une dette technique monstrueuse. La finance n’était pas encore gérée en feature teams et les demandes côté métier étaient prises à la volée. Mon rôle a surtout été d’éduquer les équipes métier. A l’époque il n’y avait pas de roadmap finance, pas de feature team, et j’ai dû communiquer sur le rôle du PM, les nouveaux process qui allaient être mis en place, et le fait que j’étais là pour les aider et pas commune fonction support, ce qui voulait dire que j’avais aussi le pouvoir de répondre non à une demande.

Tout de suite on s’est positionnés comme une équipe rattachée à la team finance, et non une équipe indépendante. J’avais à cœur de créer une vraie relation Tech – Business en incluant les devs en amont dans la compréhension des besoins métier. Très vite on s’est fait confiance car nous avons compris que nous voulions la même chose et que nous allions dans la même direction.

Qu’as-tu appris au sein de tes expériences de PM que tu aimerais partager?

La philosophie du 80-20: il vaut mieux mettre une ou deux semaines à résoudre 80% du problème, que de mettre 6 mois à en résoudre les 100%.
Cette philosophie est bien sûr à arbitrer versus le risque (elle n’est pas forcément applicable face à une problématique légale de type RGPD), et le type de structure (c’est une philosophie plus start up que grand groupe).

Que ce soit chez ManoMano ou Meero on m’a vraiment inculqué cette philosophie de trouver une solution sans dev, de manière ingénieuse, et certains diront “dirty”. D’après moi, être dans cet état d’esprit de débrouille en mode MVP est la meilleure manière de s’entraîner à devenir PM.

Qu’est ce qui différencie un bon PM d’un excellent PM?

Un.e bon.ne PM a beaucoup d’abnégation. Il/elle sait extraire l’essence, et le pourquoi des tickets de son backlog. Il comprend ce qui est fait, pourquoi c’est fait, et il sait surtout très bien le communiquer.
"Un.e bon.ne PM a beaucoup d’abnégation. Il/elle sait extraire l’essence, et le "pourquoi" des tickets de son backlog. Il comprend ce qui est fait, pourquoi c’est fait, et il sait surtout très bien le communiquer."
Un.e excellent.e PM porte la vision au niveau de la boîte, il/elle est capable de challenger ce sur quoi la feature team travaille en le confrontant à la vision de la boîte.

Que conseillerais-tu à une personne qui veut se lancer dans le produit?

Plusieurs conseils!
Déjà, il ne faut pas avoir peur de poser des questions, je l’ai beaucoup fait au début de ma carrière.

Ensuite, il faut avoir du culot. Le produit est un métier de culot, il faut savoir tenter des choses, être ingénieux et créatif.

Aussi, et de manière plus pragmatique, je pense qu’il faut avoir une bonne compréhension tech. Certains diront que c’est inutile et c’est peut être comme ça que ça marche dans les très grands groupes où tech et produit communiquent peu. Mais selon moi un PM n’est pas juste PM. Il est PM, PO, QA, business analyst, product designer, dev.

Finalement, il ne faut pas avoir peur de ses lacunes ! Selon moi, c’est un métier polyvalent que tout le monde peut faire et qui n’est pas réservé aux ingénieurs ! Il faut savoir identifier ses lacunes et travailler dessus ou compenser avec le reste.

Quel est le meilleur conseil qu’on t’ait donné?

Quand j’étais chez ManoMano le CFO m’a expliqué la notion de “footprint” : quand tu poses ton pied dans du sable mouillé, plus tu appuies ton pied fort et longtemps, plus l’auréole grandit. Concrètement, il ne faut pas hésiter à apporter de la valeur à tous les sujets, même s’ ils ne font pas partie de la job desc. Aller chercher l’extra mile, proposer son aide, permet d’augmenter son impact, et c’est un conseil applicable à toutes les carrières !

‍