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.

Share

Je serai ravi de lire vos commentaires et retours. Vous pouvez me contacter sur Twitter.

Merci et à bientôt !

Thomas


L’épisode

Découvrir 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

  • How To Accept Over-Engineering For What It Really Is

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 :

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 :

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


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.