Product Inbox 📬 Focus #20 - 6 erreurs qui détruisent la vélocité d’une boîte tech (+ comment les éviter)
Par l'ex CPO de sunday
Après avoir lu cette édition, ce serait super que tu prennes 15 secondes pour me dire ce que tu en as pensé :)
👉 Comment as tu trouvé cette édition ?
Hello 👋, bienvenue dans cette 20ème édition Focus de Product Inbox ! On est désormais 10,327 sur cette newsletter. Merci pour ta lecture et ton soutien 💛.
Je m’appelle Timothé et si ce n’est pas déjà fait, tu peux :
Faire décoller ton produit grâce à notre collectif de top CPOs
Écouter mon podcast Clef de voûte
Me suivre sur Linkedin
Ween soutient Product Inbox 🫶🏻
Depuis 1 an, on entend parler d’IA à toutes les sauces.
Et il y a une question que je reçois beaucoup de la part des Product : “Comment utiliser l’IA pour devenir meilleur ?”.
J’avoue, je ne savais pas quoi leur répondre au début.
Mais certains outils ont commencé à faire leurs preuves.
C’est le cas de Ween (outil 🇫🇷) .
Car il attaque un problème qui concerne tout le monde : la prise de décisions.
Grâce à l’IA, Ween accélère la recherche utilisateur pour aider les équipes à prendre de meilleures décisions produit. Pour ça, l’outil transforme la donnée qualitative en opportunités produit.
Concrètement :
Tu charges tes interviews utilisateurs dans Ween
Ween trouve automatiquement les insights pertinentes
Chaque insight est communicable à ton équipe via mini-vidéos
Bonus, avec la fonction “Ask AI”, Ween répond à ta question en se basant sur toutes tes interviews et feedbacks utilisateurs.
Ce n’est pas pour pour rien que PlayPlay, Lunii ou IAD l’ont adopté dans leur quotidien.
Cette édition Focus t’est offerte par Ween. Je t’ai même négocié un discount de 20% sur la 1ère année avec le code PRODUCTINBOX. Il te suffit de t’inscrire ci-dessous à la version d’essai gratuite :
Introduction
Je suis super content de t’envoyer cette édition que je prépare depuis plusieurs mois.
Elle me tient à cœur car elle répond à une problématique que de nombreuses entreprises vivent. A tel point que je ce sujet m’obsède.
Pour réaliser cette édition, j’avais besoin de l’aide de quelqu’un qui a vécu ces sujets de vélocité sur le terrain.
Et j’ai directement pensé à Alex Wattrelos, l’ex. CPO de sunday.
Alex, c’est un CPO pragmatique, qui a vécu une expérience extraordinaire chez sunday. Là-bas, il a créé le MVP en un mois puis a construit une équipe de 25 Product Managers en 18 mois. Dans son aventure intense et rythmée, le job d’Alex a été d’assurer un niveau de cadence et de qualité Produit élevé. Pour ça, il a dû éviter quelques pièges.
Je l’ai invité à nous en faire part dans cette édition de Product Inbox qui constitue un des dossiers les plus techniques jamais sorti depuis la création de la newsletter.
J’en profite pour t’informer qu’Alex est un des membres fondateurs du collectif Stellar que j’ai co-fondé pour aider les dirigeants de startups à faire exploser la croissance de leur boîte grâce au Produit. Si tu vis les écueils évoqués dans cette édition, c’est notre job de les résoudre. On se tient à ta dispo pour te donner un coup de main :)
DISCLAIMER : dans cette édition Alex met en avant une liste d’écueils et de solutions non exhaustive.
🚀 TL;DR
MEPs trop complexes allongent les tests et complexifient le code. Pour corriger ça : rollback instantané + MEP plus fréquentes.
Développements trop gros : moins de lien avec les retours utilisateurs et + de bugs. Solution : découper chaque gros développement en une série de petits + les mettre en prod’ régulièrement.
Équipes instables = lenteur. Garder une équipe telle quelle pendant 6 mois min.
Collaboration séquentielle du trio PM/Designer/Tech ralentit une boîte (et baisse la qualité du produit). Solution : collaboration en boucle.
Process trop complexes = baisse de vélocité. Solution : équilibre entre petits chantiers (décisions rapides, à l’oral) et gros chantiers (décisions structurées)
Roadmap sans objectifs : + de temps pour répondre aux problèmes clients. Solution : roadmap basée sur des résultats (outcome-based roadmap).
Ecueil 1 : des mises en production trop complexes
1. Contexte
Le 1er écueil souvent vécu dans les boîtes tech concerne la façon de mettre en production. Par mise en production (”MEP”), on entend 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.
2. 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. Mais ce changement entraîne 2 problèmes :
Le bug est perçu comme une erreur grave
Chaque MEP contient trop de code, la rendant trop complexe à auditer.
“Ton rythme ralentit très vite : non seulement tu passes beaucoup de temps en test, mais tu créés un système où créer un bug est vécu comme une grave erreur. Les développeurs n’osent plus produire sans multiplier les vérifications. En plus, comme tu ralentis ton rythme de MEP, chaque MEP contient beaucoup plus de code. Alors elles deviennent plus complexes, plus dures à auditer. Et elle génèrent encore plus de bugs qu’avant. C’est perdant-perdant : moins de rythme ET moins de qualité”.
3. Solution
Heureusement pour sunday, Arnaud Lemaire (VP Engineering) et ses équipes décident de suivre une philosophie simple : une release doit être un “non-événement”.
Concrètement, mettre en production doit être une affaire bénigne, qui peut être faite par tous. Et à tout moment. Ce système consiste à :
Diminuer le nombres de bugs faisant partie d’une MEP en diminuant sa complexité
Diminuer l’impact de chaque bug
Et pour le mettre en place, il faut pousser 2 initiatives :
Mettre en production beaucoup plus fréquemment. Ce qui engendre des MEP plus petites. Des petits changements engendrent moins de bugs. Et ça devient plus facile de corriger les problèmes. Par conséquent, on peut réduire exponentiellement la durée des tests, laissant plus de place aux développements.
Cycles de développements avec MEPs simplifiées Simplifier le rollback (ndlr : le fait de revenir sur la release précédente). A l’aide d’un simple bouton, n’importe quel bug en production peut être réglé en 1 minute. Cela minimise l’impact d’un bug et le banalise au sein des équipes. Tout comme les MEP fréquentes, le rollback simplifié permet de diminuer encore plus la durée des phases de test.
Cycles de développements avec MEPs et rollbacks simplifiés
4. Résultats
Ces deux solutions ont permis à sunday de décupler sa vélocité tout en minimisant le nombre de problèmes en production. Cela a permis aussi d’instaurer plus de sérénité au sein des équipes où chacun a confiance dans la solidité du produit.
“Nous sommes passés de deux situations d’urgence par semaine à moins d’une par mois. Tout en passant d’une mise en production par semaine à plusieurs par jour.”
Ecueil 2 : Des gros développements
1. Contexte
Avant même la MEP, le cycle de vie des développements peut massivement impacter la valeur livrée par une équipe produit. Pour permettre aux développeurs de coder sans dérangements, beaucoup d’entreprises adoptent des cycles de développements longs sur leurs gros chantiers. Ces cycles de développements “en mode sous-marin” ne prévoient pas de MEP intermédiaires.
2. Problème
Cela amène deux problèmes :
“Le premier problème des développements trop gros est que tu te retrouves, 3 mois plus tard, à adapter ta nouvelle fonctionnalité au produit actuel qui a continué à se développer durant cette période. Ça t'amène beaucoup de travail supplémentaire et les nouvelles dépendances sont dures à repérer. Ce qui entraîne des releases sujettes aux bugs. Mais le plus gros problème, c’est que tu te prives de tout feedback utilisateur pendant ce temps. Si tu passes en mode “sous-marin”, tu ne bénéficies pas de tous les retours utilisateurs que tu aurais eu en mettant en production plus tôt.”
3. Solution
Pour éviter l’écueil précédent, la solution est de mettre tout développement en production régulièrement (au maximum toutes les 2 semaines). Peu importe la taille du chantier et même si la fonctionnalité est incomplète.
4. Résultats
“Chez sunday, les équipes avaient pour mission de construire un “ledger”, c’est à dire une base de données comprenant toutes les transactions qui y passe. Si le ledger fait défaut, les restaurateurs ne reçoivent pas l’argent de leur clients. On parle de centaines de milliers de transactions par semaine. C’était un développement très complexe sur plusieurs mois. Toutes les semaines, nous mettions un nouveau bout de ce ledger en production. Plus on avançait, plus on gagnait en confiance sur le système (qui tourne à vide au début). Jusqu’à progressivement le brancher sur des parties de plus en plus large de notre code.”
Ecueil 3 : Des équipes instables
1. Contexte
En startup, on a envie de faire tourner régulièrement les membres d’une squad (PM, Product Designer, Devs) pour éviter les silos de connaissances. On aimerait que chaque personne ait un niveau de connaissances 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 qu’elle s’absente car elle connaît des choses que personne d’autres ne sait.
2. Problème
Ça prend un temps fou de s’assurer que chaque membre d’une équipe ait un bon niveau de connaissances 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.
3. Solution
Pour éviter l’instabilité des équipes, il est recommandé de garder une équipe telle quelle pendant au moins 6 mois (dans le cas d’une startup) sur un périmètre précis. 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 ces mouvements au sein des équipes pour préserver sa vélocité et son efficacité.
4. Résultats
Maintenir les équipes en place pendant une durée minimale donnée a 2 conséquences positives :
Des équipes plus efficaces : 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
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. Elle partage seulement la connaissance sur ce périmètre avec les autres membres de son équipe.
“Quand tu fais une réorganisation d’entreprise, tu vois une énorme différence dans la productivité des équipes entre le jour 1 et le jour 180. Après 6 mois, les équipes se connaissent, se font confiance, et vont facilement deux fois plus vite.”
Ecueil 4 : Une collaboration trop séquentielle
1. Contexte
Dans de nombreuses boîtes tech, la collaboration au sein de l’équipe Produit suit un schéma qui ressemble à la logique Fordienne (division du travail sur les chaînes de production) :
La Product Manager réalise des spécifications de solutions sans avoir de retours des Tech et des Designers.
La Designer sort des maquettes abouties mais difficiles à coder.
Les Développeurs codent une solution qui ne respecte pas 100% de la maquette et des specs par manque de temps.
“Au début de sunday, nos PMs avaient de gros périmètres Produit et passaient un temps fou à encadrer les développements en cours. Ils n’avaient plus le temps de penser à l’après. De plus, les développeurs et designers étaient frustrés. Les premiers car ils recevaient des designs trop complexes à coder. Les seconds car leurs designs n’étaient pas respectés.”
2. Problème
Cette séquence classique de collaboration rassure les membres de l’équipe car chacun accomplit son rôle jusqu’au bout. Mais la collaboration en séquence ne permet pas la livraison d’un produit de qualité, prenant en compte les contraintes et utilisant les connaissances de chacun.
Les spécifications ne sont pas respectées → la PM est frustrée.
La maquette n’est pas respectée → la Product Designer est frustrée.
Le développement a été fastidieux et stressant → les développeurs sont frustrés.
3. Solution
Pour y remédier, on peut passer d’une logique séquentielle à une logique en boucle :
La PM 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 au designer. Ils itèrent et ajustent ensemble.
“Nous avons essayé ce mode de collaboration sur un développement dans une de nos équipes qui subissait une charge de travail trop forte. Deux mois plus tard, toute l’équipe fonctionnait sur ce mode et postait des nouvelles features tous les deux jours sur le Slack de la boite.”
Ecueil 5 : Des process excessifs dans la collaboration
1. Contexte
Certaines entreprises mettent en place des process rigides pour construire leur produit. L’objectif ? Contrôler et éviter tout risque. Quelques exemples courants de process au sein des équipes Produit et tech :
Document justifiant la valeur business d’un développement
Demande de validation par le Product Manager pendant un sprint
Création d’une maquette par un Designer
Création d’un ticket sur Jira
Scoping par l’équipe tech
2. Problème
Par nature, les process sont inadaptés aux petits chantiers car ils font perdre beaucoup de temps. Exemples de petits chantiers : changer la position d’un bouton ou corriger un bug mineur.
“J’ai vu beaucoup d’entreprises mettre en place une dizaine d’étapes de validation et inclure trois équipes différentes pour chaque nouvelle demande Produit. À cause de la lourdeur des process, ces entreprises n’ont aucune chance de régler un bug dans la journée.”
Le cumul de process pour des petits chantiers a des conséquences néfastes sur toute l’entreprise :
Les équipes Business deviennent frustrées. 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.
Perte d’agilité. La latence induite par chaque process limite les réponses rapides.
Dégradation de la vélocité. Les équipes Produit, surtout en 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, au dépend de la production.
3. Solution
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).
La structure sur les gros paris (“bets”). Les équipes s’alignent sur l’objectif et la solution envisagée. Puis elles mesurent le résultat du paris.
4. Résultats
“Résoudre simplement et rapidement les ‘petits’ problèmes permet d’aller vite là où l’investissement en devs (et donc le risque) est faible. De plus, les équipes business se sentent écoutées et ont entre les mains un produit stable et bien fini. Pour les ‘gros chantiers’ : des bons process aident à produire les bonnes solutions aux bons problèmes.”
Ecueil 6 : Une roadmap produit non objectivée
1. Contexte
La roadmap est probablement l’outil le plus populaire des équipes Produit et Tech. La plupart du temps, le format utilisé est appelé “feature-based roadmap” (ndlr : ou roadmap basée sur les fonctionnalités). Voici un exemple ci-dessous :
Bien que l’utilisation des “feature-based roadmaps” soit généralisée, son efficacité est discutable, surtout en startup.
2. Problème
Les roadmaps basées 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 de l’entreprise.
Pour impacter ce dernier, la roadmap devrait non pas promettre des fonctionnalités, mais engager des résultats business chiffrés et mesurables.
Prenons un exemple connu : Netflix.
Voici ce que pourrait être une “feature-based roadmap” pour Netflix (fonctionnalités fictives) :
Sur cette roadmap, on a une idée claire des fonctionnalités sur le point d’être développées. En revanche, il est impossible de s’assurer d’une responsabilisation de l’équipe technique sur leur impact business.
3. Solution
La solution consiste à transformer la roadmap pour ne plus réfléchir en fonctionnalités, mais en résultats. Pour ça, on introduit une “outcome-based roadmap”. Ce format ne fait plus apparaître de fonctionnalités. On y inscrit des résultats chiffrés et mesurables qui sont définis au préalable.
Reprenons la roadmap de Netflix en version “outcome-based” cette fois :
Par exemple, si on s’intéresse à l’item “Boost mobile viewing time by 20%”.
Scénario 1
Pour atteindre ce résultat, une multitude de fonctionnalités peut fonctionner :
"Implement adaptive streaming for enhanced mobile playback quality."
"Introduce mobile-exclusive content or early access features."
"Optimize app interface for easier mobile navigation."
Pour augmenter de 20% le temps de visualisation d’un utilisateur sur mobile, les 3 fonctionnalités précédentes sont possibles. Après avoir sorti la 1ère fonctionnalité, l’équipe Produit de Netflix mesure une augmentation de seulement 3% → échec.
Alors elle développe l’option 2 “Introduce mobile-exclusive content or early access features”. Résultats : 9% d’augmentation → échec.
Puis l’équipe développe l’option 3 "Optimize app interface for easier mobile navigation”. Résultats : 23% → succès.
L’équipe Produit de Netflix a dû sortir 3 fonctionnalités pour atteindre le résultat recherché.
Si elle avait utilisé une “feature-based roadmap”, elle aurait atteint son objectif en sortant la 1ère fonctionnalité. Pourtant, elle n’aurait pas atteint les résultats attendus.
Scénario 2
Prenons un exemple qui se déroule différemment. L’équipe Produit de Netflix doit désormais atteindre l’objectif “Improve user satisfaction by 10%”. Pour atteindre cet objectif, l’équipe a 3 solutions en tête :
"Curate weekly personalized content recommendations.”
"Enhance video quality and adaptive streaming options.”
"Offer customizable subtitles and accessibility options.”
Elle commence par la solution 1, "Curate weekly personalized content recommendations”. En mesurant les résultats, l’équipe obtient une augmentation de la satisfaction utilisateur de 18%. Objectif atteint ! Elle n’a pas à sortir les 2 autres solutions comme prévu. Elle gagne beaucoup de temps et peut passer à la suite de la roadmap.
📝 Synthèse
Pour préserver la vélocité de ton équipe produit et tech, tu dois faire attention aux :
Mises en production complexes
Gros développements
Équipes instables
Collaborations séquentielles
Gros process collaboratifs
Roadmaps sans objectifs
J’espère vraiment que cette édition t’a aidé à y voir plus clair sur le sujet de la vélocité qui n’est pas des plus simples à appréhender.
💫 Qu'est-ce que Stellar ?
J’ai cofondé Stellar pour accompagner les dirigeants de startups à faire de leur Produit un moteur de croissance inarrêtable.
Et pour activer cette croissance, on a créé :
Un collectif de 15 CPO des meilleures boîtes tech (Zenly, Yousign, BlaBlaCar)
Des formats d’intervention rapides (moins d’une semaine)
Des solutions concrètes à actionner dans la foulée.
Résultats : vous améliorez vos metrics business, votre vitesse d’exécution et la qualité de votre Produit.
Nous avons accompagné 40 clients depuis notre lancement (dont Zeliq 🇫🇷, Edusign 🇫🇷, Fountain 🇺🇸, Tennders 🇪🇸, Predict4health 🇫🇷).
Notre ambition : vous faire atteindre vos objectifs business et positionner votre produit en leader de son marché.
Envie de travailler ensemble ?
Pour me soutenir :
Si l’édition t’a plu, ce serait super que tu la partages 🙏
Timothé