💡 Cet article fait partie de notre dossier complet sur Shape Up à découvrir ici 💡 Et si tu as besoin d’un rappel sur ce qu’est Shape Up, voici la session de rattrapage. |
En septembre 2020, la licorne française spécialiste de l’assurance santé change son mode de fonctionnement interne et passe à la méthodologie Shape Up. Gabriel Hubert, product lead chez Alan (aujourd’hui cofondateur de la startup d’IA gen Dust) nous raconte l’envers du décor.
Salut Gabriel. Est-ce que tu peux déjà nous rappeler le contexte chez Alan avant la mise en place de Shape Up ?
Gabriel Hubert : Personnellement, je suis arrivé en mars 2020. L’équipe comptait une petite trentaine d’ingénieurs, 5 PM, 4 designers, 4 spécialistes de la data et une personne en recherche utilisateur. A peu près la même taille que Basecamp en somme.
On fonctionnait en roadmaps trimestrielles. C’est-à-dire que, tous les 3 mois, on mettait la boîte à l’arrêt dans son intégralité pour réévaluer la priorisation des problèmes.
On a un outil de production composé de 5 crews (les équivalents des squads chez Spotify) qui fonctionnent de manière très autonome avec des équipes pluridisciplinaires. Dans la culture d’Alan, la responsabilité partagée et l’autonomie sont centrales, pour avoir le moins de rigidité hiérarchique possible.
C’est vraiment important de le souligner car, quand on parle de méthodo et d’orga produit, il faut toujours prendre en compte la taille de la boîte, sa culture et les profils qui la composent.
En septembre 2020, vous passez donc dans une orga inspirée de Shape Up. Pourquoi ce changement ?
G.H. : Déjà, on est plusieurs chez Alan à venir de boîtes qui sont orientées produit. On s’abreuvait grosso modo aux mêmes oasis d’infos, plutôt anglo-saxonnes (Ben Thompson, Casey Newton…) donc c’était difficile de passer à côté de Shape Up.
Et je dirais qu’il y a deux éléments qui ont fait clic dans nos têtes :
- Tout d’abord, cela insistait bien sur la définition d’un problème en amont puis sur l’importance de laisser l’équipe prendre possession de l’espace des solutions.
- Et ensuite, il y avait la notion d’appétit. C’est-à-dire la manière de formaliser le périmètre variable d’une solution, dans un temps et des efforts définis. On ne double pas la taille de l’équipe ou l’on n’accorde pas des semaines supplémentaires si les choses n’avancent pas comme prévu. Cette idée n’est pas nouvelle mais elle est très bien exprimée dans Shape Up.
Et c’est arrivé à un moment où l’on voyait émerger quelques enjeux chez Alan. Par exemple, toutes les équipes ne doivent pas résoudre des problèmes à la même vitesse. Dans l’assurance santé, il y a en effet un gros moment fort à la fin de l’année.
Aussi, les coûts de coordination de la boîte n’allait pas en linéaire mais en exponentiel. Ce qui est tout à fait normal. Mais on commençait à toucher du doigt le fait qu’arrêter tout le monde tous les trois mois, changer de problème et repartir de 0, n’était pas toujours la solution la plus efficace. C’est parfois utile, souvent stimulant, régulièrement sexy… mais pas toujours efficace.
Comment s’est faite la transition vers Shape Up ?
G.H. : Super rapidement. En gros, on n’a pas eu de Q4. On est passé directement de Q3 à C6 (traduction pour celles et ceux qui croient qu’on joue à la bataille navale : “du trimestre 3 au cycle 6”). J’aimais bien l’idée de rapidement pouvoir tester.
On a donc écrit sur un document la façon dont on voulait le mettre en place. Puis on a commencé à écrire des premiers briefs (l’équivalent des pitchs dans Shape Up). Et on a enchaîné sur la Betting Table. Depuis ce moment, on est en rétro permanente pour analyser ce qui marche bien ou moins bien.
Justement, qu’avez-vous gardé ou écarté de la méthode du bouquin ?
G.H. : Le Dual Track, on ne l’a pas gardé. Par ailleurs, on est sur des cycles de 7 semaines avec une seule semaine de cool down. On pourrait faire du 6 + 2. Franchement, il n’y a pas de bonne ou de mauvaise réponse. Ce qui compte en réalité, c’est comment tu utilises ton cool down.
On a aussi ajouté un élément en amont de la Betting Table. Cette notion est en effet assez compliquée dans Shape Up. Il faut réussir à définir des principes pour éviter de te reposer toujours les mêmes questions au moment de la décision de tes prios. On a donc créé ce qu’on appelle un “strategy pack”.
C’est un document partagé de manière transparente (une page Notion) où l’on écrit la version actuelle de notre stratégie, que l’on peut manipuler comme une app. C’est-à-dire qu’on la met à jour à chaque évolution. Et c’est sur cette base que l’on va prendre nos décisions de priorisation dans la Betting Table.
L’idée, c’est de créer un cycle où les roadmaps sont continues et où les prios de la boîte peuvent évoluer. Et où il est donc simple et transparent de modifier l’appétit de l’entreprise à résoudre certaines poches de problèmes plutôt que d’autres. On parle d’une équipe produit de près de 120 personnes aujourd’hui donc il est important que cela soit clair !
Comment se passe l’écriture des briefs ?
G.H. : On va dire qu’en pratique les product managers sont souvent à la manœuvre dans l’écriture. Souvent pour des questions de disponibilité. Et, généralement, les grands axes de ce que l’on veut mesurer vont être définis par les PM. Tandis que les Product designers et les ingés vont discuter de l’interface et de l’expérience. Mais, en soi, tout le monde peut ajouter un brief.
Nous avons ce qu’on appelle un “Planning Hub” qui est l’endroit où tout le monde peut voir où l’on en est. Très basiquement, c’est un fichier Excel. Sur un onglet, tu as le calendrier avec les échéances pour rendre les briefs. Sur un autre, la liste des briefs. Et enfin des tableaux croisés dynamiques que l’on génère automatiquement pour rappeler à tout le monde les ressources disponibles dans la boîte et l’appétit que le strategy pack a déterminé par type de problème.
Ensuite, quand tu ajoutes un brief, tu dois indiquer :
- le lien vers le brief
- une description en un tweet
- le problème
- et la poche d’appétit dans laquelle tu penses que cela va
Et après, comment se déroule la Betting Table chez Alan ? Vous qui ne faites pas de réunion et qui travaillez beaucoup en asynchrone.
G.H. : En effet, chez nous, toutes les grandes décisions se prennent à l’écrit. On ne fait pas de réunion pour ça. Je dirais qu’il y a trois filtres :
- Une première vague d’élimination en déterminant les briefs les moins alignés avec le strategy pack.
- Dans la deuxième vague, on fait des choix. On essaie de percevoir ce qui est vraiment impératif, on va regarder l’appétit et les ressources disponibles. Et l’objectif, c’est qu’on soit à 10 % près dans les bonnes zones de convergence entre l’appétit et les ressources à ce stade.
- Enfin, on passe en intra brief. Les briefs ont été sélectionnés au préalable, on sait qu’on va les faire, mais, là, on les challenge. On va beaucoup discuter dans les documents. En mode : “Là, tu as mis 3 objectifs à atteindre, est-ce qu’on ne peut pas ne se concentrer que sur un ?”. Ou “Tu as dit que tu as besoin de tant de ressources en data. Est-ce qu’il est possible de faire avec un peu moins ?”
Au final, on obtient une liste de briefs priorisés corrélés à des objectifs.
S’ouvre alors une période de 48 heures où les communautés métiers vont allouer les ressources de la façon la plus fidèle à l’esprit des briefs. En fonction des dispos et des compétences de chacun.
On essaie de faire tout cela sur 10 jours, une semaine ou deux avant le cool down.
Mais concrètement, qui décide lors de la Betting Table ?
G.H. : Alors nous, on est assez opposé à Basecamp ici. Je ne vois pas trop le rôle de product lead ou d’engineering lead comme décisionnaire de la stratégie de la boîte. On porte tous et toutes plusieurs casquettes chez Alan.
Pour répondre à la question, chacune de nos 5 business units comprend une personne en lead qui est responsable de l’atteinte des résultats. Donc, à la betting table, tu vas avoir ces leads, les PM et les ingés référents de ces BU. Toutes ces personnes sont impliquées. Les fondateurs sont présents pour challenger mais ils n’ont pas un rôle plus important plus que cela.
L’idée, c’est de répandre le pouvoir de décision au lieu de le concentrer. Ce qui est en opposition claire et nette avec la la philosophie de Basecamp évoquée dans Shape Up.
Est-ce que cela veut dire que les équipes peuvent changer de business units en fonction des cycles ?
G.H. : Franchement, on essaie d’être pragmatique. Pour nous, le plus important c’est que les personnes se sentent bien et qu’on trouve des bonnes solutions aux problèmes. Donc dans les faits, oui, cela peut arriver que des personnes bougent.
Après, certaines personnes ont intérêt à rester sur plusieurs cycles. C’est très clair pour les PM, assez clair pour les Product designers et relativement clair pour les ingés en lead.
Quel bilan tires-tu de cette nouvelle façon de travailler, avec du recul ?
G.H. : Je trouve qu’il y a énormément de valeur à mettre des mots précis sur des notions qui étaient un peu diffuses. Comme la notion d’appétit. Je ne me vois pas revenir dans une boîte où l’on valide un projet sans prévoir, dès le début, de débrancher la prise au bout d’un certain temps si on voit qu’on n’a pas réussi à répondre au problème.
Je ne me vois pas revenir non plus à un mode de fonctionnement où l’on n’est pas capable de comparer entre eux des projets qui peuvent répondre de façon différente à notre stratégie. Avec une vraie discussion sur les problèmes et l’impact des potentielles solutions.
Je trouve aussi qu’il y a énormément d’externalités positives à être ouvert et transparent sur le processus de planification. Que chaque personne puisse aller sur un Excel, lire les briefs, pouvoir commenter et poser ses questions… Que les ingés disposent de plusieurs semaines avant le début d’un cycle pour voir ce qui est en train de se faire.
Pour moi, la qualité d’une équipe, c’est quand ses membres ne sont pas là à ne s’intéresser qu’à leur morceau de territoire mais, plutôt, aux problèmes que rencontre la boîte. Je trouve ça génial qu’on parle autant de stratégie avec autant de personnes.
Et pour ne pas mettre trop des étoiles dans les yeux des lectrices et lecteurs… quelles sont les limites de Shape Up que vous avez constaté ?
G.H. : Il y a beaucoup de choses… Je dirais qu’il ne faut pas oublier que Basecamp est une formidable machine à marketing et que cela reste une petite boîte. Autrement dit, il y a des choses que tu vois quand tu es 100 personnes mais pas à 10. Tous les coûts et problèmes de coordination ne sont pas les mêmes, comme je l’ai déjà dit.
Shape Up, c’est en quelque sorte une grande mise à plat avec une promesse d’évaluation non biaisée de l’impact potentiel d’un projet par rapport à un autre. C’est très vrai. Mais dans le contexte de Basecamp, tu parles d’une équipe qui est dans un cône de problèmes pour un cône d’utilisateurs donnés.
Mais ça ne s’applique pas à des décisions comme “Comment on priorise l’Espagne par rapport à la France ?” par exemple. Ce qu’ils rappellent d’ailleurs dans l’introduction du livre. Shape Up ne te donne pas de réponse à ça.
On se pose aussi la question de savoir si c’est toujours bon de tout remettre à plat toutes les 8 semaines. Si cela ne serait pas mieux d’être plus explicite sur certains appétits multi-cycles. Autrement dit : comment formaliser le fait qu’on ne veut pas forcément remettre en question une équipe lors des prochaines betting table, si on voit qu’elle doit bosser sur un sujet bien au-delà d’un cycle ?
Enfin, la betting table ne répond pas non plus à la question : comment tu crées une vision et une roadmap ambitieuse à 12-18 mois ? Ce n’est pas en faisant un super coup toutes les 6 semaines que tu garanties que tu vas dans la bonne direction. C’est plutôt en faisant un plutôt bon coup toutes les 6 semaines… en accord avec l’endroit où tu veux être dans un an ! D’où l’importance du strategy pack chez nous. Pour ne pas perdre de vue la direction globale.
💡 Retrouve tous nos articles sur le sujet dans notre dossier complet sur Shape Up ici 💡 |
Sur le même thème
“Joint Roadmaps”, “PAM”, “Semester Planning” : Le modèle de roadmap de Deezer pour mettre en musique toute…
Deezer, la plateforme de streaming musical a récemment instauré un mécanisme de roadmap commune. Décryptage de l’ensemble du processus.
Comment BlaBlaCar a revu la conception de sa roadmap produit
Décryptage avec Benjamin Retourné, Chief Product Officer de BlaBlaCar, de la nouvelle roadmap produit du champion du covoiturage et du bus.
La méthode d’Alan pour faire sa roadmap produit
Découvrez les coulisses du processus de roadmap d'Alan, la licorne d'assurance santé, avec Thomas Rolf, son Chief Product Officer.
Comment préparer son produit à l’adoption du modèle Product-led Growth (PLG) : l’exemple Fleet
9/12 - La startup qui simplifie la gestion de parc informatique a revu son modèle économique pour intégrer une composante PLG en 2022.……
Comment AB Tasty a créé de zéro un nouveau produit en product-led Growth (PLG)
11/12 - En 2020, AB Tasty lance un nouveau produit, Flagship. Sa particularité ? Un modèle purement PLG. Récit de Jean-Yves Simon, son CPO.
Culture Lean chez Theodo : 3 exemples de pratiques pour faire de meilleurs produits
Créée en 2009, Theodo a adopté la culture Lean dès 2013. Gemba, RDP, Dojo... Benoit Charles-Lavauzelle raconte ses pratiques concrètes.