La relation Tech et Produit
Avec un background en école d’ingé, des expériences chez SetKeeper, Datadog et Aircall, Matthieu Allegre est aujourd’hui Software Engineer @Pigment.
Je le rencontre pour discuter de la relation entre la Tech et le Produit.
Je vous laisse découvrir ses conseils et recettes miracles pour construire une bonne relation.
Ça ressemble à quoi une journée type dans la peau de Matthieu?
Au-delà des rituels comme le stand up meeting, il n’y a pas vraiment de journée type 😁.
En réalité, ça dépend dans quelle phase d’un projet on se trouve.
Au début et à la fin d’un projet, le rythme de la journée peut être assez chaotique. On va surtout fonctionner au jour le jour par ordre de priorité et une journée peut englober : des revues de code, du brainstorming sur des choses techniques, investiguer des bugs, faire des entretiens…
Au milieu d’un projet c’est plus simple de se focaliser sur des heures de code pur.
Au quotidien, combien de temps passes-tu avec un Product Manager ?
Encore une fois c’est un peu lié à la phase du projet.
Au début (recherche et cadrage), je peux passer beaucoup de temps avec le Product Manager. On va échanger pour être sûr de se poser les bonnes questions, définir la direction dans laquelle on veut aller niveau produit, voir ce qu’il est techniquement possible de faire etc …
Au milieu du projet (implémentation), si tout se passe bien je peux prendre le relais sur le management de projet pur et on se fait un point de synchro 1 à 2 fois par semaine.
A la fin (roll out), ça devient généralement super intense et on passe quasi toute la journée ensemble!
Quelles sont les méthodes de travail qui fonctionnent bien selon toi ?
Ça dépend beaucoup de la maturité de l’entreprise, de l’équipe, des projets…
De mon point de vue il n’y a pas de recette miracle. Il y a plein de bonnes choses à prendre des méthodes agiles ou scrum. L’idéal c’est de tester ce qui fonctionne et ce qui ne fonctionne pas. La bonne approche c’est de rester flexible et de chercher comment s’améliorer.
Chez Aircall par exemple, on a beaucoup itéré. On est passé par plusieurs systèmes différents et au final on a convergé vers quelque chose qui marchait bien à un moment donné. Ça ne veut pas non plus dire que ça reste figé dans le temps et que dans plusieurs mois on ne changera pas à nouveau.
Personnellement ce que j’aime c’est :
- Avoir des rétrospectives régulières avec l’équipe. Ça permet de savoir ce qui fonctionne (et le célébrer) et ce qui peut être amélioré.
- Avoir la vision d’ensemble et comprendre le problème. Cela permet de donner un sens à ce qu’on fait et de se sentir impliqué.
Ce que j’aime moins :
- Les process très lourds où tout est traqué. On n’a pas toujours besoin d’une métrique pour nous apprendre que quelque chose a moins bien fonctionné, la plupart du temps on le sait déjà.
Pourquoi est ce que c’est important de trouver la bonne manière de travailler ensemble ?
Si chacun travaille de manière isolée, le danger est de réellement passer à côté de quelque chose…
Si un Product Manager travaille tout seul dans son coin et fait ses specs sans parler à l’équipe Tech, il risque d’inventer une solution utopique. Le risque à la fin c’est qu’elle soit irréalisable ou trop coûteuse.
A l’inverse si un Tech bosse tout seul dans son coin il risque de développer une solution super exhaustive qui couvre absolument tous les besoins mais sans être sûr que ça réponde au bon.
C’est dans l’alliance qu’on aboutit à la solution qui répond au bon problème et apporte rapidement et efficacement de la valeur à l’utilisateur.
Ça ressemble à quoi la relation idéale ?
Je pense que c’est primordial de construire une relation de confiance et de communiquer.
Le plus important c’est de réussir à sentir lorsque la personne a besoin de présence (être disponible, répondre à ses questions…) ou au contraire de liberté (quand tout roule).
Un truc tout bête et que j’encourage c’est de prendre régulièrement un café. Avoir une discussion libre sans ordre du jour. C’est généralement pendant ce moment qu’on va naturellement échanger sur des idées, des best practices, désamorcer certains petits problèmes dont on n’a pas eu le temps de parler.
J’en profite pour te poser deux questions que beaucoup de Product Manager se posent…
Faut-il déjà avoir une expertise tech pour être un bon Product Manager?
En tant que Product Manager, je ne pense pas que ce soit indispensable de savoir coder.
En revanche ce qui est important c’est d’être intéressé par la Tech et de discuter avec les équipes pour comprendre comment les choses fonctionnent et ça tu ne le liras jamais dans un bouquin.
Je pense aussi qu’en tant que Product Manager, avoir des bases en SQL te permet de gagner un temps fou et d’être plus autonome au quotidien.
Pourrais-tu me donner une qualité non négligeable pour être un bon Product Manager ?
De mon point de vue, pour être un bon Product Manager il faut avoir une vision 360° de son produit.
Ca veut dire qu’il faut récupérer des insights auprès des utilisateurs, parler aux équipes en interne (Sales, Success, Support…), travailler main dans la main avec le design et la tech, se synchroniser avec la vision stratégique de la boîte.
Je pense qu’il faut donc être curieux et passionné par les gens pour récupérer facilement et naturellement toutes ces informations, les digérer et trouver les solutions qui répondent aux bons problèmes.
Pour clôturer cette interview, pourrais-tu me faire une phrase Tech incompréhensible et nous la traduire ?
“ Je suis en train de push une PR pour fixer les E2E cassés sur la CI ” 😅
Traduction :
👉 J’ai codé n’importe comment
👉 J’ai cassé les tests automatiques et
👉 Je suis en train de réparer ça
Merci Matthieu 🙏🏻
