Dans la Tête d'un PM #1
Hugo Michalski (Side) : appliquer les concepts de code au produit et à l'organisation
Bonjour,
Je suis ravi de partager avec vous la première édition du podcast et de la newsletter Dans la Tête d’un PM. Un mercredi sur deux, vous recevrez une interview avec un Product Leader de la scène française afin de démystifier le Product Management.
Pour cette première édition, vous pouvez écouter mon interview d’Hugo Michalski, co-fondateur de Side.co. Vous trouverez le lien vers l’épisode, ainsi que les questions auxquelles Hugo répond, dans cette newsletter.
Je partage également mes show notes : ce sont les principales leçons que je tire de cette interview, accompagnées des concepts principaux que j’ai tenté de clarifier, car certains termes utilisés en Product peuvent être obscurs (comme les squads ou les microservices mentionnés 👇) ou utilisés sans que l’on comprenne ce dont on parle (Agile 👋). Si vous êtes aussi d’une curiosité insatiable et aimez aller au fond des choses, vous trouverez des ressources complémentaires pour vous aider à aller plus loin.
J’espère que vous aimerez cette interview. Si vous l’avez trouvée intéressante, vous pouvez vous abonner à la newsletter, au podcast et les partager avec vos amis.
Je serai ravi de lire vos commentaires et retours. Vous pouvez me contacter sur Twitter.
Merci et à bientôt !
Thomas
L’épisode
“Il faut avoir un peu de vision et un petit peu de folie pour faire du produit, mais parfois je trouve qu’on met ça un peu trop sur un piédestal”
L’invité :
Dans cet épisode, j’interview Hugo Michalski. Hugo est en charge de l’équipe Produit chez Side.co qu’il a co-fondé fin 2015. La mission de Side est de révolutionner l’expérience du travail temporaire dans les grandes villes françaises et couvre différents industries, de la logistique au retail. De formation technique, Hugo a d’abord assuré la direction technique avant de s’étendre au "product management", au design et à la data.
Vous pouvez trouver cet épisode sur Apple Podcasts, Spotify ou votre application de podcasts préférée.
Dans cet épisode vous allez apprendre :
Qu’est-ce que Side ? Quel est le profil de Pierre ? Qu’a-t-il appris à l’école 42 ? Comment est-il passé du code au produit ?
Est-il nécessaire de savoir coder pour faire du produit ? En quoi est-il important d’avoir des profils divers dans l’équipe produit ? Que conseille t-il aux profils business pour avoir une mentalité tech ?
Quels sont les liens entre les développeurs et les PM ? Quel est le processus pour sortir une feature chez Side ? Comment s’assurer que l’équipe produit soit toujours en phase avec la vision de l’équipe ? Quelles sont les relations avec l’équipe business ?
Comment identifier les déviations du produit ? Quels sont les thèmes que l’on devrait davantage aborder dans le produit ? Qu’est-ce que le “design champagne” ?
Quelles sont les ressources qu’il utilise ? Quel est son processus pour assimiler le contenu des livres qu’il lit ? Qu’aurait-il aimé savoir plus tôt chez Side ?
Ce qui m’a marqué :
J’ai été fasciné par la façon dont Hugo applique des concepts du code à son approche du produit et des organisations. Si vous ne devez écouter que ça, l’analogie qu’Hugo dresse entre l’organisation en squads et l’architecture en microservices (vers 06:07) donne une idée des ponts qui peuvent être dressés entre des champs de connaissances, et de la façon dont les problèmes de Product peuvent être résolus en s’appuyant sur son domaine de prédilection. Nous avons abordé de nombreux autres thèmes, que vous trouverez listés dans cette newsletter.
Pour ne pas manquer les épisodes suivants et leurs show notes, pensez à vous abonner à la newsletter :
Show notes
Qu’est-ce que Side ? Quel est le profil de Pierre ? Qu’a-t-il appris à l’école 42 ? Comment est-il passé du code au produit ? (01:22)
Hugo a co-fondé Side avec trois autres associés
La mission de Side est de mettre en relation des travailleurs avec des entreprises autour de missions flexibles de la façon la plus simple possible
Hugo a commencé par gérer la partie technique de Side. À mesure que Side a crû, son périmètre s’est élargi à l’ensemble du produit : Product Management, Tech, Design et Data.
Quand s’est-il rendu compte qu’il devait se concentrer sur le produit ? (04:07)
Les plus grands enjeux de Side sont des enjeux d’expérience utilisateur et de data pour faire le meilleur matching possible entre travailleurs et entreprises, ce qui a justifié de rapprocher les équipes tech et produit
Ce qu’il a appris à 42, en software et en quoi cela lui a-t-il servi pour faire du produit ? (06:03)
À 42, Hugo a acquis une approche de déconstruction des problèmes, de recherche et de persistance, qu’il a ensuite appliqué chez Side
Avoir étudié l’informatique a été déterminant dans son approche produit et organisationnelle : Hugo a pu faire des parallèles entre les concepts de code et des concepts d’organisation
Par exemple la distinction entre architecture monolithique et architecture microservices est aussi applicable à une organisation produit : favorise t-on des petits groupes indépendants ou une grande équipe qui prend un sujet à la fois en essaye de le traiter le plus rapidement possible ?
Il n’y pas de bonne réponse, Hugo illustre avec des choix à effectuer
Différence entre une architecture monolithique et une architecture microservices (crédit : Introduction to Monolithic Architecture and MicroServices Architecture)
Définitions et ressources sur le sujet :
Une architecture monolithique décrit une application réunissant l’ensemble des composants dans un unique code-source et serveur
Une architecture microservices décrit une application utilisant différents modules autonomes répondant chacun à un but défini (e.g. gérer les inscriptions) et utilise une interface définie (API) pour communiquer avec les autres services
Introduction to Monolithic Architecture and MicroServices Architecture
Un Design pattern (patron de conception) est une solution générale et ré-utilisable à un problème survenant souvent dans la conception de logiciels
L’over-engineering est une solution trop robuste ou complexe pour un certain problème
Un exemple d’over-engineering (crédit : https://xkcd.com/530/)
Est-il nécessaire de savoir coder pour faire du produit ? (11:46)
Non, mais ça dépend du secteur et de la technicité du produit
Il est toujours intéressant d’avoir une compréhension de la technologie cependant
Dans le cadre de la Discovery et de la Delivery, avoir une compréhension technique permet de cerner les enjeux, d’identifier et de sélectionner des solutions, ainsi que de comprendre les ressources qui seront requises pour mener les projets
Définitions et ressources sur le sujet :
Le but du Product Discovery est d’identifier les risques associés au développement du produit avant sa mise en production en production afin de parvenir à un product backlog (liste des fonctionnalités à développer) validé
Le but du Product Delivery est de construire et de livrer des produits que l’entreprise puisse proposer à des utilisateurs et vendre
Product Discovery, Silicon Valley Product Group
The Four Big Risks, Silicon Valley Product Group
Discovery vs. Delivery, Silicon Valley Product Group
Inspired, Marty Cagan
Comment acquérir la compréhension technique nécessaire ? (18:56)
Il ne faut pas confondre savoir coder et comprendre les contraintes techniques
Il est essentiel de rester près de la tech, ce qui passe par un dialogue constant avec les développeurs, se spécialiser sur une plateforme et l’expérience
Il faut avoir de la curiosité et regarder comment se font les choses
Side a construit une équipe Produit avec des PM aux compétences complémentaires
Quel est le processus pour sortir des features chez Side ? (21:22)
Après avoir essayé plusieurs méthodes, l’équipe Product/Tech fonctionne en squads
Ils s’imposent de ne pas travailler sur un projet pendant plus de deux semaines, ce qui oblige à du pragmatisme et de la rigueur intellectuelle
Définitions et ressources sur le sujet :
L’organisation en squad a été popularisée par Spotify et consiste en des équipes cross-fonctionnelles, regroupant des membres avec des compétences complémentaires (développeurs, designer, Data analyst, Product manager) sur une thématique donnée
Failed #SquadGoals, Jeremiah Lee : l’implémentation des squads chez Spotify est relative et n’a pas aussi bien marché qu’espéré
Bet Six Weeks | Shape Up : la six-week roadmap de Basecamp
Les OKRs (Objectives and Key Results) définissent la direction souhaitée (l’objectif) et une mesure afin d’évaluer la distance qu’il reste à parcourir (les key results)
La méthode Agile est une approche itérative de la gestion de projets et du développement logiciel : une équipe Agile livre son travail par petits incréments exploitables
Une plateforme est un environnement permettant l’exécution d’application. iOS et Android sont des plateformes mobiles par exemple.
Comment assurer que le travail de l’équipe Produit soit aligné avec la stratégie de Side ? (28:40)
Un plan stratégique trimestriel définit les priorités pour Side et une vérification régulière est menée pour s’assurer que le produit contribue à la stratégie
Ils utilisent certains indices pour repérer des déviations, comme ceux provenant des Sales et de la répartition des comptes clients
De quoi ne parle t-on pas assez en produit ? (36:21)
Hugo identifie une tendance à sacraliser le produit
Il ne faut pas mettre le produit sur un piédestal : le produit doit être au service d’un besoin et de l’entreprise
Pour s’assurer que le produit remplisse bien sa fonction, il faut être proche des utilisateurs que ce soit en menant des interviews utilisateurs ou en participant aux rendez-vous clients
Ceci permet d’évaluer le product-market fit et de mesurer un décalage entre le produit et sa valeur perçue
Ceci permet aussi d’éviter le “design champagne” : quelque chose de très beau mais pas utilisable par un utilisateur. Il est important de confronter son produit à des utilisateurs et ne pas réinventer la roue
Définitions et ressources :
Le product-market fit est le stade auquel l’on a prouvé que le produit apportait de la valeur aux utilisateurs
Transcript of Andy Rachleff on “How to Know If You've Got Product Market Fit”
Rahul Vohra Shares Superhuman's Product Market Fit Framework
Quelles sont les ressources qu’Hugo utilise ? (41:06)
Au-delà des ressources et de livres spécifiques, le plus important est l’approche : prendre une ressource et aller jusqu’au bout. Hugo extrait l’essence des livres qu’il lit en prenant des notes, en lisant lentement et en mettant en application ce qu’il a appris
High Output Management, Andy Grove
Measure What Matters, John Doerr
The Five Dysfunctions of a Team, Patrick Lencioni
The Phoenix Project, Gene Kim, Kevin Behr and George Spafford
Il écoute également des podcasts, conférences, vidéos et échange avec ses pairs
Qu’est-ce qu’Hugo aurait aimé savoir plus tôt ? (44:42)
Il aurait aimé être plus au contact du terrain, il aurait aimé avoir une vision plus large, plus vite. Il a cependant conscience qu’il est important de creuser et maîtriser un sujet à la fois
Ressources mentionnées dans l’épisode
High Output Management, Andy Grove, dont la préface par Ben Horowitz, co-fondateur et General Partner du fonds de venture capital Andreessen Horowitz, qui fait les louanges du livre dans The Hard Things about Hard Things, devrait vous donner une idée de l’impact du livre en tech
Measure What Matters, John Doerr
The Five Dysfunctions of a Team, Patrick Lencioni
The Phoenix Project, Gene Kim, Kevin Behr and George Spafford
Dans le podcast Dans la Tête d’un PM, j’interview les meilleurs product leaders français pour comprendre leur parcours, leurs modes de pensée et leurs méthodes, afin de vous permettre de découvrir les secrets de ce métier et de trouver votre propre voie.
Pour recevoir les futurs épisodes de ce podcast, abonnez-vous à la newsletter. La newsletter accompagne la publication de chaque nouvel épisode, un mercredi sur deux, et j’y inclus des ressources liées au contenu de l’épisode ainsi que du contexte sur les notions de Product Management abordées lors de la discussion.
Si vous aimez le podcast, abonnez-vous et notez le podcast sur Apple Podcast ou votre plateforme favorite. Je serai ravi de lire vos feedbacks et commentaires.