Transcription

• Speaker #0

  Derrière chaque grande boîte, il y a un grand produit. Derrière chaque grand produit, il y a des gens talentueux, passionnés et ambitieux. Musique, come on here ! On les appelle Product Manager, CPO ou Product Leader. Quels que soient leurs titres, ils ont tous la même mission, devenir la clé de voûte de leur entreprise à la croisée du design, du business et de la tech pour créer les futurs produits indispensables de demain. Well, that's Clé de voûte ! Clé de voûte, c'est le podcast des products pour les products. Chaque semaine, je te fais passer un moment aux côtés des meilleurs leaders du produit français. Avec une mission, te livrer tous leurs secrets, méthodes et apprentissages pour devenir toi aussi la clé de voûte de ton entreprise. Oh, j'aime cette idée. Ce podcast est rendu possible par Stellar, un collectif de top CPO qui ont participé au succès de startups comme Zenin, Sunday, Spendesk ou BlaBlaCar. J'ai cofondé ce collectif avec une mission, aider les dirigeants d'entreprises tech à créer les produits donnés dans l'industrie. Retard sur la roadmap, équipe des amis, produits lents à décoller, ces problèmes, nos CPO les connaissent par cœur. Et ils débarquent à tes côtés pour les résoudre dans des formats rapides, actionnables et clés en main. Si tu es dirigeant ou CPO et que tu écoutes ce podcast, c'est qu'on a très certainement des choses à se dire. On se retrouve sur wearestellar.io ou via le lien en description de l'épisode. Je m'appelle Timothée Frein et bienvenue dans Clé de l'Oud. Hello, j'espère que tu vas bien. Aujourd'hui, j'aimerais te parler d'un sujet qui me tient à cœur puisque je l'adresse tous les jours en échangeant avec mes clients sur Stellar, le collectif de CPO que j'ai cofondé. Beaucoup d'entreprises tech font face à une difficulté lorsqu'elles grossissent. Elles perdent de la vitesse. Et ça pose un problème. Car une boîte qui ralentit, c'est une boîte qui prend moins de décisions, qui innove moins et qui dépense de l'argent anormalement. Autrement dit, c'est une boîte qui meurt à petit feu. Et s'il y a bien quelqu'un qui en connaît un rayon sur ce sujet, c'est Alex Watrellos, l'actuel CPO de Furious, ancien CPO de Sunday et membre de notre collectif Stellar. Chez Sunday, Alex s'est imposé un rythme difficile à tenir. Arrivé premier employé de Sunday, il recrute 25 products en 18 mois, tout en maintenant un rythme de delivery très soutenu. Fort de son expérience, de ses réussites et de ses challenges, Alex a repéré 6 erreurs qui détruisent la vélocité d'une boîte tech. J'avais très envie qu'il m'en dise plus sur ces erreurs et les solutions concrètes pour les éviter, alors je l'ai invité sur ma newsletter Product Inbox en janvier dernier, et je te propose ici d'en faire la synthèse sur ce podcast. Pour commencer à creuser doucement le sujet, Alex m'a évoqué le premier écueil souvent vécu par les boîtes tech, les mises en production trop complexes. Par mise en production ou MEP, on entend le fait de faire passer des changements dans le produit utilisé en live par les clients. C'est le baptême du feu pour les derniers développements. Mais quel est le problème ? Au début de Sunday, Alex et les équipes de développeurs subissent de plein fouet les bugs inhérents à toute MEP. Ces bugs sont d'autant plus présents qu'un produit est jeune. La réaction initiale d'Alex et des équipes, c'est de sécuriser les MEP en ajoutant beaucoup de tests et en ralentissant le rythme. Alex souligne que ce changement entraîne deux problèmes. D'abord, le bug est perçu comme une erreur grave et les développeurs n'osent plus produire sans multiplier les vérifications. Ensuite, le rythme de MEP étant ralenti, chaque MEP contient trop de codes, la rendant trop complexe à auditer et générant encore plus de bugs. La conclusion d'Alex, c'est qu'il y a à la fois une perte de rythme et une perte de qualité. Heureusement, tout problème vient avec sa solution, puisque Arnaud Lemaire, alors VP Engineering de Sunday, et ses équipes, décident de suivre une philosophie simple en faisant des releases, ce qu'Alex qualifie de non-événements. Mais qu'est-ce que ça veut dire concrètement ? Pour faire simple, Alex recommande de faire de la MEP, une affaire bénigne, qui peut être faite par tous, à tout moment. D'abord, il faut diminuer le nombre de bugs faisant partie d'une mise en production en diminuant sa complexité, puis diminuer l'impact de chaque bug. Alex m'a partagé deux initiatives à pousser pour mettre ce système en place. Tout d'abord, il faut mettre en production beaucoup plus fréquemment, pour avoir des MEP plus petites. Des petits changements engendrent moins de bugs, et ça devient plus facile de corriger les petits problèmes. On peut donc réduire exponentiellement la durée des tests, laissant plus de place au développement. Ensuite, il faut simplifier le rollback, c'est-à-dire le retour à la release précédente. Pour Alex, un simple bouton doit pouvoir régler n'importe quel bug de production en une minute. Ça minimise l'impact d'un bug, et ça le banalise au sein des équipes. Tout comme les mises en production fréquentes, le rollback simplifié permet de diminuer encore plus la durée des phases de test. Selon Alex, tout ce process a payé, puisqu'il partage les résultats obtenus chez Sunday, qui est passé de deux situations d'urgence par semaine à moins d'une par mois, alors même que les MEP devenaient beaucoup plus fréquentes. Ces deux solutions ont permis à Sunday de décupler sa vélocité, tout en minimisant le nombre de problèmes en production. Ça a aussi permis d'instaurer plus de sérénité au sein des équipes, où chacun a confiance dans la solidité du produit. On poursuit cet épisode avec un deuxième écueil dont nous parle Alex, qui concerne le cycle de vie des développements et qui peut massivement impacter la valeur livrée par une équipe produit. Pour permettre aux développeurs de coder sans dérangement, beaucoup d'entreprises adoptent des cycles de développement longs sur leurs gros chantiers. Ces cycles de développement en mode sous-marin ne prévoient pas de mise en production intermédiaire. Selon Alex, cette situation amène deux problèmes majeurs. Le premier, c'est que peu de temps après ces développements massifs, on peut se retrouver à adapter la nouvelle fonctionnalité au produit actuel qui a continué à évoluer pendant cette période. Ça entraîne beaucoup de travail supplémentaire et les nouvelles dépendances sont difficiles à repérer, ce qui rend les mises en production sujettes aux bugs. Mais le plus gros problème, c'est qu'on se prive de tout retour utilisateur pendant ce laps de temps. En adoptant le mode sous-marin, on passe à côté de tous les retours utilisateurs qui auraient pu être obtenus en mettant en production plus tôt. Pour éviter cet écueil, la solution est de mettre tout développement en production régulièrement, à savoir au maximum toutes les deux semaines. Peu importe la taille du chantier et même si la fonctionnalité est incomplète. Dans le cas de Sunday, Alex explique que les équipes avaient pour mission de construire un ledger, c'est-à-dire une base de données comprenant toutes les transactions qui y passent. Concrètement, chez Sunday, si le ledger fait défaut, les restaurateurs ne reçoivent pas l'argent de leurs clients, ce qui concerne quand même des centaines de milliers de transactions par semaine. C'était un développement très complexe à faire sur plusieurs mois. Toutes les semaines, les équipes de Sunday mettaient une nouvelle partie de ce ledger en production, ce qui leur permettait de gagner en confiance sur le système qui tournait à vide au début, jusqu'à progressivement le brancher sur des parties de plus en plus larges du code. En adoptant cette approche, Sunday a réussi à éviter les écueils de développement massif, permettant une progression constante du projet, tout en bénéficiant des retours utilisateurs dès que possible. Ensuite, on a continué de creuser le sujet avec Alex sur les écueils à éviter, et il a choisi de me parler des équipes instables. En startup, on a envie de faire tourner régulièrement les membres d'une squad, composée de product managers, de product designers et de développeurs, pour éviter les silos de connaissances. On aimerait que chaque personne ait un niveau de connaissance suffisant pour agir sur chaque bout de notre code et produit. On a tous et toutes entendu parler d'une personne clé au sein de l'entreprise dont on redoute absolument qu'elle s'absente, car elle connaît les choses que personne d'autre ne sait. Pour Alex, le problème de ce genre d'organisation, c'est qu'il faut beaucoup de temps pour s'assurer que chaque membre d'une équipe est un bon niveau de connaissance global. A chaque fois qu'une personne change de périmètre, elle doit se remettre à niveau sur ce sujet et réapprendre à travailler avec sa nouvelle équipe. Évidemment, Alex m'a proposé une solution à ce problème et recommande de garder une équipe telle qu'elle pendant au moins 6 mois, dans le cas d'une startup, sur un périmètre précis. Selon lui, pour une entreprise plus mature, on peut même allonger cette période de stabilité. Bien sûr, les aléas de l'entreprise imposent parfois des changements d'organisation sur une ou deux personnes. Mais il faut éviter de généraliser ses mouvements au sein des équipes pour préserver sa vélocité et son efficacité. En conclusion, maintenir les équipes en place pendant une durée minimale donnée a deux conséquences positives. Tout d'abord, on obtient des équipes plus efficaces, puisque collaborer avec les mêmes personnes dans le temps aide à mieux connaître leur façon de réfléchir et de travailler. In fine, cette collaboration stable augmente l'efficacité de toute l'équipe. Ensuite, on construit une meilleure connaissance de son périmètre. Chaque membre d'une équipe devient expert de son périmètre en évitant la dispersion sur d'autres sujets et partage seulement la connaissance sur ce périmètre avec les autres membres de son équipe. Selon Alex, cette réorganisation modifie totalement la productivité des équipes en seulement 6 mois puisqu'elles se font confiance et vont deux fois plus vite dans leur mission. Et on ne va pas s'arrêter là, sur les écueils, car il y a encore des points d'attention à garder à l'esprit pour ne pas détruire la vélocité d'une boîte tech. Alex m'a donc présenté le suivant, qui concerne la collaboration trop séquentielle. En effet, dans de nombreuses boîtes tech, la collaboration au sein de l'équipe produit suit un schéma qui ressemble à la logique fordienne. Ce qu'on entend par là, c'est la division du travail sur les chaînes de production. On a d'abord la product manager qui réalise des spécifications de solutions sans avoir de retour des techs et des designers. On a aussi la designer qui sort des maquettes abouties mais difficiles à coder, et enfin les développeurs qui codent une solution qui ne respecte pas 100% de la maquette et des specs par manque de temps. Alex m'a parlé de son expérience et m'a partagé qu'au début de Sunday, les PM avaient de gros périmètres produits et passaient trop de temps à encadrer les développements en cours. Ils n'avaient plus le temps de penser à l'après. En plus de ça, les développeurs et designers étaient frustrés. Les premiers car ils recevaient des designs trop complexes à coder, les seconds car leur design n'était pas respecté. Dans ce schéma, Alex identifie un gros problème. Chaque membre de l'équipe accomplit son rôle de manière linéaire, ce qui apporte un sentiment de sécurité et de clarté. Cependant, cette approche ne garantit pas la livraison d'un produit de haute qualité qui prend en compte toutes les contraintes et utilise pleinement les connaissances de chaque membre de l'équipe. Par exemple, les spécifications du produit ne sont pas toujours respectées, ce qui entraîne de la frustration pour la PM. De même, lorsque la maquette n'est pas suivie à la lettre, cela peut conduire à l'insatisfaction du product designer. De plus, un processus de développement fastidieux et stressant peut générer de la frustration chez les développeurs qui peuvent se sentir dépassés par les exigences du projet. Pour résoudre ce problème, Alex m'a recommandé de passer d'une logique séquentielle à une logique en boucle dans laquelle l'APM amène la designer et le tech en discovery. La designer s'assoit avec le tech pour faire une ébauche. Le tech code une fonctionnalité minimale et la montre à la designer qui y terre et ajuste ensemble. Cette solution a fonctionné en moins de deux mois chez Sunday. Pour continuer sur notre lancée, Alex m'a ensuite parlé d'un cinquième écueil à éviter, les process excessifs dans la collaboration. En effet, certaines entreprises mettent en place des process rigides pour construire leurs produits afin de contrôler et éviter tout risque. Alex a par exemple mentionné un document justifiant la valeur business d'un développement, la demande de validation par le product manager pendant un sprint, la création d'une maquette par un designer, la création d'un ticket sur Jira ou encore le scoping par l'équipe tech. Le problème avec ce genre de process pour Alex, c'est qu'ils sont inadaptés aux petits chantiers par nature, comme par exemple changer la position d'un bouton ou corriger un bug mineur, car ils font perdre beaucoup de temps. Il ajoute que cette lourdeur dans les process empêche les entreprises qui y ont recours de régler un bug dans la journée, les faisant perdre en agilité. En plus de ça, les équipes business deviennent frustrées puisque la friction pour des changements minimes les laisse dans l'incompréhension et diminue leur visibilité sur l'avenir du produit. Ils ont l'impression que leurs problèmes sont incompris et que leur urgence n'est pas partagée. Alex souligne également la dégradation de la vélocité comme les équipes produits sur ton startup gèrent des dizaines de petits développements par semaine. Rajouter un process de 5 minutes sur chaque développement entraîne une charge supplémentaire très forte aux dépens de la production. La solution se trouve dans l'équilibre entre la simplicité sur les petits chantiers qui passent par de la communication directe, communication orale de préférence, et la structure sur les gros paris, dits bets en anglais. Les équipes s'alignent sur l'objectif et la solution envisagée, puis elles mesurent le résultat du pari. Alex conclut en disant que résoudre simplement et rapidement les petits problèmes permet d'aller vite là où l'investissement en développeurs, et donc le risque, est faible. Les équipes business se sont écoutées et ont entre les mains un produit stable et bien fini. Pour les gros chantiers, en revanche, des bons process aident à produire les bonnes solutions aux bons problèmes. On termine cet épisode en beauté par notre dernier écueil, ce qu'Alex appelle la roadmap produit non objectivé. Concrètement, la roadmap est probablement l'outil le plus populaire des équipes produites tech. Dans la plupart des startups, le format utilisé est appelé feature-based roadmap, soit une roadmap basée sur les fonctionnalités. Bien que l'utilisation des feature-based roadmaps soit généralisée, son efficacité est discutable, surtout en startup. Selon Alex, en effet, les roadmaps basés sur les fonctionnalités donnent de la visibilité sur le futur du produit pour les mois à venir. Mais elles ne garantissent pas l'impact des fonctionnalités prévues. Plus simplement, les feature-based roadmaps favorisent le développement du produit, mais pas le développement d'entreprises. Alex considère que pour impacter ce dernier, la roadmap devrait non pas promettre des fonctionnalités, mais engager des résultats business chiffrés et mesurables. Pour illustrer ce sujet, on a ensuite fait une petite étude de cas avec Alex sur Netflix, un exemple fictif, en étudiant différents types de roadmaps que vous pourrez retrouver dans l'édition de la newsletter que je vous mets directement en description d'épisode. Avec le modèle des fonctionnalités fictives, on a une idée claire des fonctionnalités sur le point d'être développées. En revanche, c'est impossible de s'assurer d'une responsabilisation de l'équipe technique sur leur impact business. Alex m'a alors fait part de sa solution, qui consiste à transformer la roadmap pour ne plus réfléchir en fonctionnalités, mais en résultats. Pour ça, on introduit ce qu'on appelle une outcome-based roadmap. Ce format ne fait plus apparaître de fonctionnalités, on y inscrit directement des résultats chiffrés et mesurables qui sont définis au préalable. Voilà, j'espère que cet épisode t'a plu. Si c'est le cas, tu peux me soutenir de deux façons. Laisser 5 étoiles sur Apple Podcasts ou Spotify et un petit commentaire ou partager cet épisode à une personne de ton entourage. Je te remercie vraiment pour tes retours. C'est grâce à toi que j'améliore Clint Wood pour le rendre utile à ton quotidien. Je te donne rendez-vous la semaine prochaine pour un tout nouvel épisode riche en contenu actionnable. À très vite !