Rachel Dubois - Beyond agile: Product Innovation at Google, Airbnb, Spotify, Vinted & Amazon

[00:00:07] Bonjour à tous. Youpi ! Donc, trois choses. Premièrement,
[00:00:15] Je suis totalement française, mais on m'a demandé de parler en anglais aujourd'hui. Alors, supportez-moi sur ce point. C'est une toute nouvelle conférence. Je ne l'ai donnée nulle part ailleurs. Donc, vous êtes un peu des cobayes pour moi ? Les retours sont les bienvenus.
[00:00:35] Je suis aussi, j'ai eu une pneumonie, donc je suis un peu malade. Et parfois, ça se voit. Alors, supportez-moi sur ce point.
[00:00:45] Commençons. Au-delà de l'Agile.
[00:00:49] Alors, et si tout ce que vous saviez sur l'Agile, la gestion de produit et l'innovation était faux ?
[00:00:58] Youpi ! Quand nous pensons à l'innovation produit dans la tech du moins, nous avons cette idée dans notre cerveau. C'est une sorte de super pouvoir magique de designers très créatifs dans des entreprises très agiles, geek et tech. Et la connexion habituelle.
[00:01:23] Innovation égale découverte égale Agile. Mais aujourd'hui, je ne suis pas là pour parler de ça comme on l'entend souvent. Je ne vais pas parler de la découverte et de la livraison en double piste. Je ne vais pas parler de sprints, de framework, de vélocité et de rituels. Je suis là pour parler de ce qui sépare les très grandes entreprises de produits du reste d'entre nous. Quelque chose de vraiment fondamental, c'est l'impact.
[00:01:59] Et aussi, je vais essayer de vous montrer que vous êtes peut-être piégés dans une sorte d'illusion.
[00:02:09] Il y a quelque temps, je travaillais pour une entreprise, je suis consultante, je travaillais pour une entreprise qui était comme la perfection Agile. Je suis coach Agile. Donc, un rêve. Agile, bien sûr, ils avaient des sprints bien rythmés, des démos, des rétros, comme dans les livres, vraiment. PMs, POs, Scrum Masters, coachs, OKRs, tout, toute la magie Agile. Et honnêtement, vraiment un exemple de ce à quoi devrait ressembler une entreprise Agile moderne, n'est-ce pas ? Mais ensuite, je suis allée voir l'équipe de direction et nous avons examiné les chiffres.
[00:02:52] Et bien, pas si bien.
[00:02:58] Impact zéro. Je ne dis pas qu'il n'y a pas eu d'impact, non, non, impact commercial nul. Les KPI étaient stables au mieux, en déclin sinon. Et des fonctionnalités, magnifiquement livrées dans un cimetière numérique.
[00:03:19] La panique était palpable. Rachel, nous faisons tout correctement, n'est-ce pas ? Ils ont demandé.
[00:03:30] Oui.
[00:03:33] Vous faites tout bien, mais les mauvaises choses.
[00:03:39] L'efficacité sans apprentissage n'est que du gaspillage.
[00:03:43] C'est gaspiller de l'argent, du temps, tout.
[00:03:51] Laissez-moi vous demander quelque chose.
[00:03:55] Quelle a été la dernière fois où vous avez réellement mesuré l'amélioration après avoir livré quelque chose ? Un réel changement de comportement client.
[00:04:09] Je ne parle pas du nombre de fonctionnalités que vous avez livrées. Ça ne m'intéresse pas. Je ne me soucie pas des points. Je ne me soucie pas du nombre de sprints que vous avez réussis. Je parle d'un impact commercial réel et mesurable.
[00:04:28] Essayez de vous en souvenir. Compris ?
[00:04:33] J'espère que ce n'était pas si tard, j'espère.
[00:04:39] Le problème est que nous avons tendance à confondre la vitesse et le volume en matière de livraison avec la capacité d'innovation. Nous confondons en quelque sorte le mouvement avec le progrès.
[00:04:53] Et en faisant cela, nous perdons complètement de vue le business.
[00:04:58] Et l'entreprise qui innove réellement en apportant des changements sur le marché, elle opère dans un univers totalement différent, une réalité totalement différente.
[00:05:15] Je m'appelle Rachel.
[00:05:18] J'ai travaillé dans la tech pendant les 25 dernières années, principalement en tant que chef de produit, le codage n'était pas vraiment mon meilleur talent, pour être honnête. Et en tant que coach Agile et coach produit pendant peut-être 15, 17 ans, d'accord ? J'ai eu la chance de travailler au sein d'équipes produit chez Spotify et Vinted, qui sont deux entreprises incroyables axées sur le produit, deux licornes incroyables. Et aussi, j'ai eu la chance d'interviewer de manière approfondie des PMs et des équipes chez Amazon, Airbnb et Google pour le livre que j'écris sur la gestion de produit. Et ma conférence d'aujourd'hui est vraiment de voir derrière les rideaux.
[00:06:10] Rencontrez Anna.
[00:06:13] Anna est fictive, bien sûr, mais elle est très représentative de la PM avec qui j'ai travaillé chez Spotify.
[00:06:20] Alors, nous allons la suivre dans son parcours.
[00:06:28] Anna ne commence pas sa semaine en ouvrant Jira.
[00:06:34] Elle commence la semaine et la plupart des jours, pour être honnête, en ouvrant les coulisses pour accéder aux tableaux de bord.
[00:06:42] Ces tableaux de bord ne montrent aucun avancement du projet ou avancement de la livraison. Ils affichent des données, et ces données concernent vraiment la performance du produit, la performance technique, l'utilisation par les clients.
[00:06:59] Et elle regarde ces barres. Qu'est-ce qui est chaud ? Qu'est-ce qui monte ? Qu'est-ce qui tombe ? Qu'est-ce qui est surprenant ?
[00:07:10] Qu'est-ce qui est bloqué ?
[00:07:12] Elle regarde les données brutes. Elle a regardé les tendances. Il n'y a pas d'explication, juste des signaux. Et parfois, et le rouge apparaît.
[00:07:29] Alors elle va voir l'équipe avec laquelle elle travaille.
[00:07:33] Elle les connaît bien.
[00:07:36] Y compris elle, la PM, elle travaille avec des ingénieurs, des designers et des data scientists. Ils se connaissent assez bien. Ils travaillent sur ce domaine de produit depuis des années.
[00:07:48] Et ils ont un objectif clair. Celui-ci a été communiqué par l'équipe de direction de l'entreprise et est très étroitement lié aux objectifs et à la stratégie de l'entreprise.
[00:08:00] Leur objectif n'est pas de livrer un plan d'histoire dans le backlog ou n'importe quelle feuille de route. Leur objectif est de comprendre les problèmes des utilisateurs et comment ces problèmes entravent le succès commercial de l'entreprise.
[00:08:18] Et aujourd'hui, le problème ici est celui-ci. Pourquoi le taux d'achèvement des playlists partagées a-t-il chuté de 8 % au cours des derniers jours ?
[00:08:34] C'est potentiellement une perte d'argent.
[00:08:40] Ils ont des suspects habituels, bien sûr.
[00:08:44] Ils connaissent leur affaire, n'est-ce pas ? Ils connaissent leur truc comme le domaine de produit. Ils ont peut-être des hypothèses à ce sujet, sur la raison pour laquelle cet indicateur clé a chuté.
[00:08:56] Mais ils veulent garder l'esprit ouvert.
[00:09:00] Alors ils vont lancer une enquête. Ils commencent par analyser les données qu'ils possèdent déjà. Ont-ils manqué quelque chose ?
[00:09:09] Y avait-il un motif auquel ils n'avaient pas prêté attention ? Peut-être des points de données qu'ils n'ont pas vus. Y avait-il des motifs ?
[00:09:20] Et ensuite, ils vont aussi regarder les entretiens avec les utilisateurs qu'ils ont pu faire auparavant ou les focus groups précédents, et ils regardent aussi les sondages, les tendances et les recherches fournies par les équipes de données et d'intelligence. Plus sur les macro-tendances et le marché.
[00:09:39] Ils vont aussi avec les ingénieurs essayer de regarder les logs et les rapports de surveillance technique. Il pourrait y avoir une explication quelque part, n'est-ce pas ?
[00:09:49] Et ils collectent les données.
[00:09:55] Pourtant, ils sentent qu'il manque quelque chose.
[00:10:00] Quelque chose est étrange avec les données.
[00:10:04] Quelque part, il y a quelque chose qui manque, un indice.
[00:10:09] Alors ils ont décidé d'aller rencontrer le support client pour essayer de voir si dans le ticket de plainte, il pourrait y avoir quelque chose qui était lié à la fonction.
[00:10:24] Pour vraiment, vraiment enrichir la compréhension de la situation.
[00:10:30] Ils ont eu des choses, des plaintes de certains utilisateurs, et ils ont décidé d'approfondir cela. Alors ils contactent les utilisateurs.
[00:10:40] Ceux qui se sont plaints.
[00:10:44] Et pour explorer davantage, ils ont réservé des entretiens avec eux.
[00:10:50] Courts entretiens, entretiens enregistrés. Et ils essaient de mieux saisir l'intention de l'utilisateur lorsque le problème, lorsque la situation était douloureuse pour eux. Et ils ont capturé cela en utilisant un framework que beaucoup d'entre vous connaissent déjà, je suppose, qui est le 'job to be done'. Pour vraiment comprendre ce que les clients veulent faire. Et comment ils ont été bloqués en le faisant.
[00:11:20] Sur cette base, ils retournent tous ensemble.
[00:11:25] Brainstorming sur le problème qu'ils n'ont pas couvert lors des entretiens, lors de l'analyse des données. Et ils essaient de les transformer en opportunités. Ils utilisent une autre façon de le faire, très classique encore une fois, rien de fantaisiste, comment pourrions-nous, par exemple, ça fonctionne pour cela ? Transformer les problèmes en opportunités, les relier, les structurer en un arbre d'opportunités et de solutions, par exemple, si vous connaissez le travail de Teresa Torres.
[00:11:57] Et pour chacun d'eux, ils essaient de cartographier leurs options. Ils essaient aussi d'indiquer leur poids.
[00:12:07] Pour qu'ils puissent les comparer.
[00:12:10] Pour qu'ils puissent les prioriser. Afin qu'ils puissent vraiment se concentrer sur ce qui est le plus juteux à résoudre pour eux, car on ne peut pas tout résoudre. Il faut donc se concentrer.
[00:12:22] Et tous ensemble, ils décident sur quelques-uns d'entre eux, ils misent sur eux.
[00:12:30] Ils décident qu'ils vont construire des alternatives aux affichages et au tunnel par lequel l'utilisateur passe. Pour tester leur hypothèse et leur compréhension et essayer de voir s'il existe un moyen de trouver un affichage ou un tunnel plus efficace.
[00:12:53] Youpi ! L'étape suivante est d'élaborer, de transformer l'hypothèse en quelque chose de plus tangible, n'est-ce pas ? Quelque chose que nous pouvons livrer aux utilisateurs.
[00:13:06] Donc ici, deux étapes. Premièrement, transformer les hypothèses en quelque chose sur lequel nous pouvons vraiment, vraiment articuler notre stratégie. Ils vont utiliser le framework DIBB. DIBB signifie données, aperçus, croyances et paris. C'est un moyen très simple et léger de capturer cela et de structurer les connaissances et la stratégie de l'équipe. Ainsi, les PM et les data scientists travaillent généralement dessus. Ils ont une sorte de protocole d'expérimentation : si changement, alors effet, car données rationnelles, une manière très scientifique de le faire. Ce qui est vraiment important ici, c'est de faire un lien clair entre cela et le changement qu'ils attendent des comportements des clients et le changement qu'ils attendent sur les KPIs qu'ils recherchent, n'est-ce pas ?
[00:13:56] Par exemple,
[00:14:00] Si nous changeons la position du point d'accès aux listes de lecture partagées sur la page d'accueil, alors nous pourrions voir une augmentation de ce taux d'engagement utilisateur spécifique. Si non, cela signifie que ce n'est pas le problème, que nous devons changer et pivoter, n'est-ce pas ?
[00:14:19] Ils construisent assez rapidement les variantes en utilisant Encore, donc Encore est le système de design de Spotify qui a l'UI ou aussi le comportement encodé, et cela est directement disponible pour tout le monde via Figma. Directement injecté dedans.
[00:14:38] Donc ils peuvent vraiment faire travailler les ingénieurs et les designers pour construire ces variantes, ces alternatives des mêmes écrans et affichages et ainsi de suite.
[00:14:48] Et tout le code qu'ils créent est placé derrière le feature flagging, et la représentation colorée là.
[00:14:59] Le feature flagging est utilisé pour contrôler l'affichage et la diffusion des variantes aux utilisateurs, n'est-ce pas ?
[00:15:08] Donc cela est fait très rapidement, en quelques jours.
[00:15:12] Parce que je ne veux pas rater la fenêtre de la sortie hebdomadaire de l'application mobile, pardon, la sortie hebdomadaire de l'application mobile. Donc chaque jeudi, nous terminons, nous publions l'application.
[00:15:23] Et ping, ils y parviennent, le code est livré. Alors maintenant, l'équipe peut utiliser via des backends, ils peuvent configurer la campagne de tests A/B. Ils peuvent décider quel échantillon de la base d'utilisateurs, rappelez-vous que Spotify compte environ 600 à 700 millions d'utilisateurs, donc nous pouvons segmenter cela très facilement. Faire des échantillons, définir des panneaux de contrôle et lancer des campagnes de tests A/B.
[00:15:57] Juste un, non. Nous parlons toujours de tests A/B, comme A ou B, mais la vraie vie n'est pas ça. La vraie vie, c'est plus A, B, C, D, il y a plusieurs variantes qui sont livrées et testées le même jour.
[00:16:17] À tout moment, il y a 2 000 expériences qui se déroulent chaque jour chez Spotify.
[00:16:26] Et ce n'est pas la plus grande entreprise. Amazon, j'en suis sûr, en a bien plus que ça.
[00:16:33] Mais cela vous donne l'ampleur de l'innovation dans laquelle ces entreprises investissent des efforts. Et je pense que c'est vraiment quelque chose que nous voulons retenir. N'oubliez pas que l'objectif ici est de lancer des expériences pour obtenir des informations et faire avancer la stratégie. Nous devons donc beaucoup expérimenter.
[00:16:57] Quelques jours plus tard, les premiers résultats commencent à arriver.
[00:17:10] Je suis désolé.
[00:17:12] Les premiers résultats commencent à arriver et nous pouvons déjà voir des schémas intéressants. Alors l'équipe examine les détails des résultats et essaie de voir s'ils sont bons ?
[00:17:23] Sont-ils suffisamment bons, ce qui est légèrement différent, n'est-ce pas ? N'y a-t-il aucun mal ?
[00:17:30] Certaines variantes sont très bonnes d'un côté et peuvent être minimes de l'autre sur d'autres KPI et c'est ce à quoi nous voulons prêter attention. Donc le nouveau design montre que certaines variantes n'ont aucun effet. Certains d'entre eux améliorent le taux d'achèvement. Ouah ! Mais d'autres, ils créent des dommages. Et ils créent des dommages sur ils augmentent la désinscription des utilisateurs premium, ce qui est exactement ce que nous ne voulons pas, n'est-ce pas ? Nous voulons gagner de l'argent, donc nous ne voulons pas que cela diminue.
[00:18:07] Alors ils ont ces conversations très passionnées tous ensemble en équipe. Faut-il tuer, faut-il faire évoluer ? Qu'est-ce que nous devons tuer, qu'est-ce que nous devons faire évoluer ?
[00:18:19] Et comment nous faisons cela sur la base des découvertes.
[00:18:23] Ils décident ensemble, ils ne blâment pas. Ils apprennent ensemble.
[00:18:31] Il n'y a pas de stress vraiment. Le retour arrière est facile, il suffit de désactiver via le backend.
[00:18:38] Analyse rapide, désactiver, qu'avons-nous manqué, qu'avons-nous appris, passer à autre chose.
[00:18:49] L'équipe nettoiera la variante indésirable de la base de code lors de la prochaine session de refactoring. Et avancer vers la prochaine chose à explorer dans l'arbre d'opportunités et de solutions. Parce qu'ils ont toujours un problème à résoudre.
[00:19:04] Répéter l'opération.
[00:19:07] Ce n'est pas linéaire, c'est plutôt quelque chose comme ça.
[00:19:12] C'est un véritable pipeline de produits, où l'innovation circule de partout à chaque étape. Ce n'est pas un plan de livraison rigide.
[00:19:22] Ce n'est pas une feuille de route visionnaire. C'est une sorte de système vivant, si vous faites une métaphore. Il est capable de sentir, tester, ajuster, réagir, apprendre. Nous parlons plutôt d'une sorte de créature vivante.
[00:18:56] aller de l'avant vers quelque chose de nouveau à explorer dans l'arbre des solutions d'opportunités. Parce qu'ils ont toujours un problème à résoudre. Rincer et répéter.
[00:19:07] Ce n'est pas linéaire, c'est plutôt quelque chose comme ça.
[00:19:11] Il s'agit d'un véritable pipeline de produits où l'innovation circule de partout à chaque étape. Ce n'est pas un plan de livraison rigide.
[00:19:21] Ce n'est pas une feuille de route visionnaire.
[00:19:24] C'est une sorte de système vivant, si l'on prend la métaphore. Il est capable de sentir, de tester, d'ajuster, de réagir, d'apprendre. Nous parlons plutôt d'une sorte de créature respirante.
[00:19:44] Et plus important encore, c'est un système conçu pour maximiser l'apprentissage, pas pour maximiser la livraison. J'ai commencé cette présentation en vous montrant une illusion agile dans une entreprise. Passons à la vraie vie, voulez-vous ?
[00:20:08] Dissequons les licornes !
[00:20:17] Le gilet.
[00:20:20] Donc, d'abord, nous devons nous mettre d'accord sur quelques bases, vous et moi. La première est, répétez après moi, un produit n'est pas une liste de tickets dans Jira. Essayez.
[00:20:38] Oui.
[00:20:41] Un produit n'est pas une feuille de route à exécuter. D'accord ? Nous devons vraiment changer le discours là. C'est douloureux. C'est mortel. Changez cela. C'était il y a 20 ans. Passez à autre chose.
[00:21:00] Merci. Merci. Donc, nous ne gérons pas les backlogs, nous sommes d'accord là-dessus. Ce que nous faisons, c'est que nous développons et maintenons une créature vivante ou un produit. Un qui sent, réagit, évolue, apprend à survivre et à prospérer. C'est ce que nous voulons faire. Et cet organisme, comme tout organisme dans le monde, avait au moins trois systèmes de base : un système nerveux, un système immunitaire et un système circulatoire.
[00:21:29] Système nerveux. Le système nerveux donne aux licornes la capacité d'observer, de sentir et de ressentir le monde extérieur. Pour qu'elles le comprennent.
[00:21:44] Sans système nerveux, il n'y a pas de perception, il n'y a pas d'action. Un produit sans capteurs, journaux et traqueurs, sans surveillance fonctionnelle et technique est aveugle et sourd. Vous ne voulez pas ça. Vraiment, vous ne voulez pas ça. Chez Airbnb, par exemple, ils ont fortement automatisé la génération d'insights. Donc, il y a plein d'algorithmes qui détectent chaque, ce qu'ils appellent les comportements anormaux des utilisateurs, ou chaque modèle d'utilisation en évolution. Chaque déviation par rapport à ce qu'ils ont observé, c'est faible, c'est un camion, c'est poussé vers vous. Parce que ce sont de petits signaux du monde extérieur que le monde change. Et nous devons nous adapter pour devenir, pour rester pertinents.
[00:22:42] Tous ces petits signaux sont comme des déclencheurs d'alertes, on peut faire la métaphore, c'est comme des nerfs réagissant à la douleur.
[00:22:53] Ou à la brûlure. Vous voulez savoir si vous vous brûlez la main, n'est-ce pas ? Pareil.
[00:23:02] Mais sentir ne suffit pas, il faut ensuite traiter les données, il faut en faire quelque chose, n'est-ce pas ? Pour que cela ait un sens, pour réagir correctement à ces signaux, le marché vous sent. Et toutes les licornes ont intégré dans leur ADN de fonctionnement que vous ne pouvez pas faire cela si vous séparez la découverte de la livraison de la solution, l'essai et la réalisation. C'est pourquoi ils ont des équipes produit composées de plusieurs fonctions : EPDA, ingénierie, produit, designer, analyste de données. Ce n'est pas une option, c'est une norme.
[00:23:50] Donc toute la découverte reste au sein de l'équipe. Ce sont eux qui dirigent et combinent le travail exploratoire quand c'est nécessaire, les entretiens, les groupes de discussion, peu importe. Et l'expérimentation sur le produit et l'analyse de données. Et ils font cela en tant qu'équipe entière. C'est un sport d'équipe.
[00:24:13] Cela peut être désordonné parfois, mais c'est la meilleure façon de le jouer. Un flux, une équipe.
[00:24:22] Si votre système nerveux s'atrophie, que va-t-il se passer ? Vous continuerez à livrer, mais vous ne saurez plus si cela affecte ou non les clients, les utilisateurs et les marchés. Vous perdrez de vue l'évolution du marché et cela pourrait être fatal.
[00:24:46] Système immunitaire. J'étais perdu.
[00:24:50] Donc l'innovation est risquée.
[00:24:54] Chaque fois que vous codez et livrez de nouvelles variantes, vous ne livrez pas seulement de la valeur, d'accord ? Vous prenez également un risque. Pourquoi cela ? Parce que vous injectez potentiellement dans votre base de code de l'instabilité, des anomalies, des régressions, des bugs, appelez ça comme vous voulez, des agents pathogènes.
[00:25:13] Et si votre produit n'a pas un système immunitaire fort, chaque nouvelle fonctionnalité que vous livrez peut devenir mortelle. Ce n'est pas une métaphore.
[00:25:24] C'est vraiment comme ça que le logiciel fonctionne et comment il se dégrade d'abord silencieusement, puis tout d'un coup.
[00:25:34] Donc vous voulez avoir cela, et c'est pourquoi les licornes ont fortement investi dans les éléments de ce système immunitaire. Développement basé sur la branche principale pour réduire l'enfer de l'intégration. Hmm ? Le 'feature flagging', nous l'avons déjà mentionné pour contrôler l'exposition et découpler le déploiement et la mise en production. Et aussi pour pouvoir activer, désactiver via le backend sans avoir besoin de relancer quelque chose.
[00:26:04] Et vous pouvez tester en production, c'est tout. Tests automatisés. Pour détecter les problèmes avant que les utilisateurs ne les trouvent, n'est-ce pas ? Observabilité pour détecter les anomalies très, très tôt. Un solide pipeline CCD pour livrer rapidement et en toute sécurité. Culture DevOps. Équiper et soutenir l'ensemble de l'organisation. Tout cela. C'est un incontournable, c'est une norme, c'est presque une commodité. Allez. Pour eux du moins.
[00:26:41] Mais réagir et empêcher de nouvelles variantes de vous nuire et d'endommager votre produit n'est peut-être pas suffisant.
[00:26:48] Parfois, nous devons aussi faire de la prophylaxie. Amazon, par exemple.
[00:26:55] Ils ont des routines pour supprimer activement chaque fonctionnalité, chaque variante qui affecte les KPI d'affaires.
[00:27:10] S'il y a une baisse, il y a un arrêt. Indépendamment de l'investissement sur la fonctionnalité. D'accord ? Pourquoi ça ?
[00:27:20] Et ils ont aussi des revues régulières de toutes les fonctionnalités qu'ils ont, en les comparant avec les données, l'utilisation et ainsi de suite. S'il n'est pas utilisé ou a une très faible utilisation, il pourrait être supprimé. Pourquoi cela ? Parce que nous ne voulons pas garder dans notre système des choses qui ne sont pas nécessaires. Car il y aura de la pourriture, ils vont pourrir.
[00:27:47] Et ils vous rendront malade. Payez votre dette technique. Payez votre dette de conception. Élaguez l'arbre.
[00:27:57] Je vous suggérerais, un jour de refactoring, de tenir le médecin à distance. Ainsi, un système immunitaire robuste est vital pour une innovation rapide, car il vous empêchera de ruiner votre entreprise et votre produit à cause de vos bonnes intentions.
[00:28:16] Alors que nous passons au système circulatoire, nous allons réfléchir à la manière de maintenir notre produit en vie et en diffusion continue.
[00:28:28] Oui. Parce que l'innovation ne consiste pas seulement à lancer des choses. C'est aussi s'assurer que ce que nous avons lancé est nourri pour grandir.
[00:28:39] Donc, première chose, convenons que le produit ne vit et ne se nourrit pas des rapports trimestriels. D'accord ? Le reporting ne vous rendra pas performant. Cela n'a aucun effet sur la croissance, n'est-ce pas ? Ce qui est important, c'est que vous portiez une attention régulière à la garantie que votre produit et les personnes qui le gèrent sont réellement nourris. Pour y parvenir, nous devons non seulement relier les points dans les données et relier les hypothèses aux effets, hmm ? Mais nous devons également nous assurer que dans l'organisation, l'information et l'intelligence sont partagées et circulent librement au sein de l'entreprise. Cela signifie que vous devrez connecter les gens. Cela signifie que vous devrez connecter le flux d'informations entre les équipes, et la collaboration est essentielle.
[00:29:47] Pensez à toutes les trois pièces que je vais vous donner qui contribuent à l'ensemble du tableau. Premièrement, automatisez vos alertes.
[00:29:57] Toutes les alertes qui apparaissent en cas de chute, d'utilisation, de problème, de quoi que ce soit, automatisez-les et poussez-les directement là où c'est le plus pratique pour que votre équipe les trouve.
[00:30:13] Habituellement, par exemple, c'est un canal Slack.
[00:30:17] Donc ils n'ont pas à courir après ça. Les données viennent à eux. Ensuite, deuxièmement, les tableaux de bord, ils devraient être accessibles à tous. Tableau de bord technique, tableau de bord produit, oui, aussi tableau de bord métier. Comment les gens peuvent-ils travailler s'ils n'ont pas accès à cette information ? Devrait être en libre-service, utiliser Tableau, permettre à vos chefs de produit de faire des requêtes, de chercher des choses. Cela ne devrait pas être quelque chose de caché dans une sorte de, je ne sais pas, Google Drive privé ou chez certaines équipes, cela ne fonctionne pas. Et le flux libre ne concerne pas seulement les outils. C'est aussi une question de comportements. Il s'agit de la façon dont vous communiquez, collaborez, vous rencontrez et travaillez tous ensemble. Essayez donc aussi de mettre en place des rituels pour qu'ils travaillent. Faites une revue régulière des expérimentations en cours. Effectuez des vérifications de la réalité.
[00:31:10] Faites des revues de performance, partagez-les largement. Au moins dans l'entreprise, au sein de l'entreprise.
[00:31:16] Nous devons nous assurer que toutes ces conversations se déroulent entre les fonctions.
[00:31:24] Nous sommes humains, je sais qu'en agile, nous voulons, je dis ça, briser les silos. D'accord, c'est comme la devise agile, briser les silos. Honnêtement, tant qu'il y a des êtres humains, il y aura des silos. Alors, passez outre, d'accord ?
[00:31:39] Vivez avec ça, il y aura des silos. Ce que nous devons nous assurer, c'est qu'il n'y a pas de royaume. Le royaume, ce sont des gens qui décident qu'ils ont une forte propriété de cette partie des choses et qu'ils la régulent, la contrôlent et la filtrent. Cela, vous devez le pourchasser agressivement, mais les silos, passez outre.
[00:32:02] D'accord ? Tout cela est ce dont notre créature vivante a besoin. Système nerveux de service, dont nous avons parlé, système immunitaire, système circulatoire. Quelque chose manque.
[00:32:18] Ouvrons le cerveau de la licorne. Jetons un œil dans la salle de contrôle.
[00:32:26] Ha.
[00:32:30] Tout le design revient, le mérite revient à une petite fille de 11 ans qui utilise ChatGPT.
[00:32:40] Alors, voyons ce qui se passe dans la salle de contrôle. Je vais vous parler de ce qui se passe au cours des 21 premières heures d'échec massif d'une fonctionnalité chez Unicorns Company. D'accord, parlons-en. Vous venez, vous avez travaillé sur, vous faites partie de l'équipe, vous venez de déployer ces nouvelles fonctionnalités très sophistiquées, et elles ont été déployées sur toute la base d'utilisateurs. Des millions d'utilisateurs partout dans le monde, n'est-ce pas ? L'équipe est super confiante. Ils ont fait un travail exploratoire, ils ont interviewé des utilisateurs, ils ont énoncé leurs hypothèses, ils ont testé les prototypes, ils ont fait des pré-tests, ils ont lancé les variantes, ils ont fait des tests A/B très très sérieux, et tous les résultats semblaient très bien, vraiment.
[00:33:30] Ils ont donc décidé de mettre à l'échelle l'expérimentation. 1%, 2%, 5%, tout le monde. Hourra.
[00:33:41] Mais maintenant, quelques jours après le déploiement complet des choses, youpi, les chiffres commencent à paraître un peu bizarres, n'est-ce pas ? Bizarre. L'utilisation diminue, nous n'aimons pas ça. Les KPI critiques commencent à clignoter et nous commençons à perdre de l'argent.
[00:34:03] C'est vraiment mauvais.
[00:34:06] C'est comme si cela nous faisait du mal.
[00:34:10] Bienvenue dans la salle de contrôle où les crises sont gérées. Où le drame s'intensifie.
[00:34:18] Où les dirigeants ont obtenu leurs salaires.
[00:34:24] Non, première chose, ne paniquez pas. C'est mauvais.
[00:34:30] Mais pas de drame.
[00:34:33] C'est un cas d'utilisation de conception.
[00:34:37] D'accord ? Ça fait juste partie de l'état d'esprit d'expérimentation.
[00:34:42] Parfois on réussit, parfois on apprend, dit-on.
[00:34:47] Donc pas de drame. Pas d'escalade. Pas de jeu de la faute, pas d'augmentation de salaire pour les dirigeants. Non, non. Interrupteur d'arrêt d'urgence.
[00:35:00] Il vous suffit juste de désactiver les variantes.
[00:35:05] C'est tout. Terminé.
[00:35:08] Juste une minute après que l'équipe ait décidé d'éteindre parce que c'était nuisible, la fonctionnalité était mauvaise, peu importe, ils ne comprennent pas pourquoi, mais ils montrent que c'est mauvais, ils éteignent, l'affaire est classée.
[00:35:22] C'est le pouvoir d'avoir une détection précoce des anomalies, le système nerveux dont nous venons de parler. Vous pouvez agir vite et en toute sécurité.
[00:35:35] Alors, parlons de l'interrupteur d'arrêt d'urgence juste un instant, car il y a une chose très intéressante là-dedans, pas seulement technique, n'est-ce pas ?
[00:35:41] Donc, quand vous arrivez au produit, y a-t-il des chefs de produit ici ?
[00:35:47] Hé, je vous aime.
[00:35:50] Donc, en matière de gestion de produit, il y a deux grandes questions auxquelles vous devez faire face. Enjeux élevés. La première est : devons-nous l'expédier ? Et puis il y a la question de savoir si nous devons le tuer, n'est-ce pas ?
[00:36:04] Ce qui s'est passé, c'est que la plupart des entreprises, pas les licornes, mais les entreprises, sont en quelque sorte très obsédées par la première. Ils sont très stressés à ce sujet, alors ils créent des moments de 'go-live', et vous avez des comités de pilotage, et vous devez écrire des tonnes de documents pour dire que nous allons le livrer et le mettre en service, parfois c'est même un plan, vous avez plein de choses comme ça, n'est-ce pas ?
[00:36:33] Chez les licornes, ils ont fait le choix inverse. Ils se sont placés du côté de l'élimination du spectre. Et c'est un différenciateur clé. C'est à quelle vitesse pouvez-vous dire, non, tuez-le et faites-le.
[00:36:58] Et les licornes axées sur le produit sont vraiment, vraiment bonnes à cela.
[00:37:03] C'est pourquoi chaque équipe peut lancer des choses. Sans faire d'histoires, en en faisant toute une histoire.
[00:37:10] Parce qu'ils sont très doués pour la tuer. Parce qu'encore une fois, l'objectif ici n'est pas de livrer la perfection, mais de vraiment valider si ce que vous livrez crée de bons ou de mauvais effets et des dommages. C'est pourquoi ils ont créé cette culture où chaque équipe peut désactiver une fonctionnalité sans avoir à demander l'approbation d'un vice-président, sans bureaucratie, sans jeu de la faute, juste un apprentissage rapide. Et cette capacité à désactiver n'est pas seulement une idée technique de dernière minute.
[00:37:46] C'est la partie essentielle du modèle de fonctionnement du produit. Interrupteur d'arrêt d'urgence équivaut à maturité. Ce n'est pas la peur de l'échec. Vous montrez simplement que vous êtes capable de bien échouer et d'avancer.
[00:38:00] Au suivant. Donc quelques jours après. Les équipes prennent un moment pour réfléchir un peu. Appelez cela une rétrospective si vous voulez.
[00:38:13] Parce que chaque équipe est propriétaire de son résultat, mais elle a aussi la responsabilité d'apprendre de ce qu'elle a fait, n'est-ce pas ? Alors ils se demandent. Qu'avons-nous appris ?
[00:38:26] Qu'avons-nous mesuré qui nous a surpris ? Celle-ci est très intéressante. Quelles étaient nos croyances qui se sont avérées complètement fausses ? Et plus important encore, comment vais-je utiliser cela, allons-nous utiliser cela pour changer les prochaines choses que nous allons faire ?
[00:38:49] Donc ce n'est pas un luxe occasionnel de travailler comme ça pour eux. C'est juste de l'hygiène. C'est comme ça, ça marche. Et d'ailleurs, ils sont assez ouverts à ce sujet, ils ont publié des articles et des billets de blog et donné des conférences, etc., donc ce n'est pas nouveau. Donc moi, ce qui me dérange ici, c'est pourquoi tant d'entreprises croient encore que faire quelques entretiens au début du projet et ensuite livrer des tonnes de fonctionnalités sans rien tester suffira. Je ne comprends pas. Ce n'est donc pas un luxe occasionnel de travailler comme ça pour eux. C'est juste de l'hygiène. C'est comme ça. Ça marche. Et d'ailleurs, ils sont assez ouverts à ce sujet. Ils ont publié des articles et des billets de blog et ont donné des conférences, etc. Donc, ce n'est pas tout nouveau. Donc, ce qui me dérange ici, c'est pourquoi tant d'entreprises croient encore que faire quelques entretiens au début du projet, puis livrer des tonnes de fonctionnalités sans rien tester, suffira. Je ne comprends pas.
[00:39:35] Laissez-moi vous donner un aperçu des trois principales illusions fatales que je vois autour de moi, car il y en a plus de trois. Et qui, je crois, nous retiennent. Elles ont toutes l'air raisonnables, elles ont toutes l'air de faire sens, mais elles ne le sont pas, n'est-ce pas ? Donc, la première est celle-ci. Nous faisons de la découverte, nous parlons aux utilisateurs. Oui. Nous avons fait un groupe de discussion avant le lancement. Oui. Nous avons des entretiens avec les utilisateurs tous les mois. Woo. Nous avons une recherche d'utilisation, sympa, sympa, sympa.
[00:40:11] Nous recueillons les commentaires des utilisateurs. Nous avons le NPS, peu importe. C'est vraiment bien, c'est bien, c'est vraiment très bien, continuez comme ça. Mais ce n'est pas suffisant.
[00:40:23] Parce qu'il y a une légère différence entre ce que disent les utilisateurs et ce qu'ils font. Cela vit en quelque sorte entre deux dimensions différentes du multivers. Ils ont de bonnes intentions, les utilisateurs, ce ne sont pas de mauvaises personnes. Mais leurs mots ne correspondent pas à leurs comportements. Si vous demandez aux gens : quelles sont vos émissions préférées sur Netflix ? Ils essaient de vous donner des choses plus intellectuelles qu'ils ne le font, ils ne vous disent pas qu'ils regardent, je ne sais pas, Emily in Paris, par exemple. D'accord ? Nous ne montrons pas la merde quand nous sommes interviewés. Les humains. Donc, les licornes. Je comprends cela et c'est pourquoi ils ne se contentent pas de demander aux gens ce qu'ils veulent, ils observent et ils vérifient avec des données. Est-ce qu'ils font vraiment ça ? Parce que les informations qu'ils veulent obtenir ne sont pas basées sur des opinions, mais sur des modèles, des contradictions, une utilisation réelle. Les meilleures équipes produit que j'ai vues ne cherchent pas de validation. Ils cherchent la vérité, même quand ce n'est pas confortable pour eux.
[00:41:38] Parfois, ils n'ont même pas besoin d'écrire une seule ligne de code pour tester cela. Vous pouvez utiliser l'approche du magicien d'Oz pour tester si vous allez gaspiller votre argent pour quelque chose qui en vaut la peine ou non. Faites semblant. Montrez une nouvelle interface utilisateur, mettez un humain derrière, imitez les choses, essayez de voir si les gens l'utilisent vraiment.
[00:42:05] Vous obtiendrez des données, ces données alimenteront votre analyse de rentabilité. Vous prendrez de meilleures décisions. Voyez si cela vaut la peine ou non de vraiment coder les choses.
[00:42:18] Deuxièmement, nous sommes très bons pour livrer. Nous livrons beaucoup et vite.
[00:42:24] Nous entendons cela, nous l'avons même entendu ici, ces deux derniers jours.
[00:42:29] Nous livrons le double en deux fois moins de temps. référence for a book. Nous avons réduit notre TTM de moitié. Hourra ! Nous livrons tous les jours. Notre délai de livraison a été amélioré de 30%. Bien. Parfait. Tout cela est super bien, ne vous méprenez pas là-dessus. Mais cela a-t-il changé quelque chose concernant les humains réels qui vous paient pour vos fonctionnalités, produits et services et sur lesquels vous gagnez de l'argent ? Parce que sinon,
[00:43:05] qui s'en soucie ?
[00:43:08] Les licornes ne se soucient plus de livrer des fonctionnalités. Ils se soucient de livrer des choses qui leur prouveront s'ils ont raison ou tort sur la façon dont ils comprennent leur marché, comment ils comprennent comment ils gagnent de l'argent. Et ils veulent faire cela avec le meilleur retour sur investissement. Ce qui signifie qu'ils veulent faire cela avec le moins d'argent dépensé.
[00:43:32] Moins c'est plus.
[00:43:35] Et d'ailleurs, c'est pour ça que les MVP existent, hein ? Ne faites pas de MVP de six mois, de grosses choses et ainsi de suite, hein ? Vous ne comprenez pas.
[00:43:46] Donc, nous devrions avoir quelque chose comme ça, comme chaque livraison devrait être attachée à une déclaration d'hypothèse explicite, choisissez DIBB, choisissez votre propre truc si vous voulez, cela ne change pas. Et connectez cela aux KPI métier qui font partie de votre business case. D'accord ? Et livrer beaucoup, ce n'est pas réussir.
[00:44:09] La vélocité et la productivité sont totalement inutiles si vous ne modifiez pas la courbe commerciale.
[00:44:22] La troisième.
[00:44:25] Nous avons des OPR. Je suis désolé, je vous vois, je vous ressens, vraiment.
[00:44:32] Nous sommes, nous avons une ligne ou nos équipes avec des OOKRs. Ils ont tous la même chose. Oh, super. Euh, nous avons des vérifications mensuelles, hebdomadaires, peu importe, tous les plans de livraison sont liés aux objectifs, etc., etc., bien fait, vraiment bien, bien fait, bien fait.
[00:44:47] Sauf si vos OKR ne sont que de vagues intentions et s'alignent sur les résultats. Pas de flux d'apprentissage, pas la capacité réelle de tester, d'apprendre, d'ajuster et d'abandonner.
[00:45:03] Si souvent, les OKR sont comme ça. Il faut quelques secondes pour le lire. Comme vous pouvez le voir, tout tourne autour du plan de livraison et des jalons. C'est vraiment mal conçu, vous le direz sûrement. Parce qu'aucune de ces clés ne nous dit comment l'expérience utilisateur va s'améliorer pour les nouveaux utilisateurs et comment cela va se connecter pour augmenter notre base d'utilisateurs premium par exemple.
[00:45:33] Juste avant cette session, nous avons entendu Console Sorgen nous expliquer pourquoi nous détestons tant les OKR. Et ce n'est pas lié à eux-mêmes, mais à la façon dont nous les utilisons mal et au système que nous créons pour mal les utiliser.
[00:45:53] Alors, réécrivons notre très mauvais OKR que je viens de vous montrer dans une sorte de langage de licorne.
[00:46:01] Bam.
[00:46:03] Voyons-nous une différence ?
[00:46:18] La différence que nous avons vue est que la façon dont ils sont formulés crée de l'espace pour que l'équipe explore. Il y a des problèmes à résoudre. Ce ne sont pas des choses à implémenter. Et cela change tout, vraiment tout.
[00:46:38] Donc, nous ne voulons pas de feuille de route centralisée et de microgestion. Nous voulons avoir un alignement fort sur le problème que nous voulons résoudre et la capacité des équipes à perdre le contrôle, je dirais, pour qu'elles trouvent la meilleure solution à cela. Et à exécuter. Toutes ces trois illusions sont très mortelles parce que ce sont elles qui nous empoisonnent.
[00:47:03] Alors, quelle est la voie à suivre, Rachel, parce que vous êtes une personne très déprimante. Je le vois dans vos yeux. Non, je ne le suis pas. J'ai une veste fantaisie, vous vous souvenez ? Donc, mon antidote sera de reprogrammer votre POM, modèle d'exploitation de produit. Il est temps de réfléchir et de parler des choses que nous pouvons faire pour élever le niveau du jeu. Parce que oui, il y a des alternatives. Non, vous n'avez pas à être Spotify ou Airbnb, et d'ailleurs, vous n'avez pas besoin de les imiter, pouvons-nous résoudre cela ?
[00:47:38] Et vous n'avez pas non plus besoin d'avoir Google Google un budget somptueux pour faire ça. Parce qu'il ne s'agit pas d'implémenter des choses, d'embaucher des ressources ou des outils, quels qu'ils soient. Il pourrait même s'agir de se débarrasser de certains d'entre eux, donc, cela étant dit.
[00:47:57] Tuons les mythes avant. Vous pourriez penser que les licornes sont des licornes, elles ont parce qu'elles ont cette culture magique et ces styles de leadership qui les ont rendues si magiques. Mais vraiment, Amazon, Google, Spotify, Airbnb, Vinted, bien qu'ils soient tous des licornes, ils ne vivent pas au pays des rêves magiques où tout est beau. En fait, ils couvrent un large éventail de cultures et de styles de leadership et certains d'entre eux, vous pourriez même les qualifier de toxiques. Ce n'est donc pas cela. Ce n'est pas tant une question de culture et de leadership. Mais le point commun qu'ils ont est cette forte rationalité commerciale derrière ce qu'ils font et comment ils le font. Parce qu'ils comprennent vraiment la technologie.
[00:49:02] Si votre entreprise dépend fortement de la technologie, par exemple, vous êtes une plateforme ou un marché ou un service de streaming, cela signifie que la technologie est la façon dont vous gagnez de l'argent. Cela signifie que la technologie est votre entreprise.
[00:49:23] Ce n'est pas un fournisseur de services, c'est le cœur de votre entreprise. Et si c'est le cas, la façon dont je l'ai présenté est exactement la façon, la meilleure façon pour vous de le développer et de le maintenir. Point final.
[00:49:43] Donc, des solutions.
[00:49:48] Nous allons changer le POM.
[00:49:53] Les Anglais, vous ne comprendrez peut-être pas, mais c'est une blague nulle et drôle. Je suis désolé, je suis fatigué. Changeons le système de pensée de l'entreprise. Donc, l'idée ici est de passer de 'Je suis un gestionnaire de backlog' à 'Je suis plutôt une personne de logique de pipeline d'apprentissage', où tout coule pour cela. Donc, je vous donne mes conseils. Utilisez-les ou non.
[00:50:18] Le premier. Hourra ! Faites de l'expérimentation, n'implémentez pas les choses.
[00:50:27] Rien que ce premier changement d'état d'esprit, ça va beaucoup changer. D'accord ? Le premier. Facile, celui-ci est facile, juste comme l'état d'esprit.
[00:50:39] Deuxièmement, ça devient de plus en plus délicat.
[00:50:45] Ha.
[00:50:47] Chaque fonctionnalité que vous allez lancer aura un énoncé d'hypothèse qui dit clairement quel est le problème que vous voulez résoudre, pourquoi c'est un problème, quelles sont les données qui vous le disent, comment vous avez forgé cette conviction, quelles sont les métriques cibles que vous voulez changer, comment cela et un protocole de test, d'accord ? Je veux ça. Je ne veux pas de format d'user stories ou quoi que ce soit, je veux ça.
[00:51:17] Parce que c'est ce qui compte vraiment.
[00:51:21] Troisième. Équipes produit. S'il vous plaît, que les équipes produit les considèrent comme des mini-laboratoires. Dirigés par des EPA, assurez-vous qu'il y a de l'ingénierie et du produit et du design et des analystes de données, tous dans le même flux. D'accord, il n'y a pas un seul chef, ils partagent le fardeau, ils partagent la responsabilité, ils partagent la propriété. Ils ont un accès complet à toutes les données, ils ont une vision claire du problème qu'ils veulent résoudre et ils ont une forte appropriation pour les résoudre. Cela changera beaucoup. Vraiment.
[00:51:58] Et le dernier.
[00:52:01] refusez de faire évoluer quelque chose si vous n'avez pas de signaux positifs clairs.
[00:52:08] Je veux que vous arrêtiez de livrer des choses juste parce que vous devez les livrer, même si cela n'a aucun effet sur l'entreprise. Arrêtez de faire ça. C'est absurde. Nous produisons trop.
[00:52:22] Nous devons nous concentrer sur les choses, les bonnes choses à livrer. D'accord ?
[00:52:28] Et le dernier bonus pour vous.
[00:52:33] Mon préféré. Oh, non, il y avait celui-ci aussi, j'ai oublié celui-ci. Celui-ci est super amusant, jouez anti-roadmap trimestriellement.
[00:52:43] C'est une revue trimestrielle où vous allez avoir vos équipes et PMs et leadership et ainsi de suite et vous vous rassemblez et au lieu d'avoir cette revue de roadmap où vous ajoutez des choses sur le tas, n'est-ce pas, vous vous souvenez de celle-là, celle-ci vous la tuez et ensuite vous avez ça et la question ici est qu'est-ce que nous allons retirer et tuer.
[00:53:06] C'est super amusant à faire. Et c'est super sain pour le système sur le produit que vous possédez. Voyez la conversation qui va émerger là-dessus, ça va vraiment, vraiment changer la donne. Alors vérifiez le coût des choses, combien de revenus, combien d'utilisation et ainsi de suite, s'il n'y a pas de valeur, ça ne devrait pas rester.
[00:53:28] Astuce bonus, c'est mon bonus, arrêtez les bêtises.
[00:53:34] Donc, je suis coupable à ce sujet parce qu'il y a 10 ans, j'ai j'ai écrit sur le double track de la découverte et de la livraison, d'accord, parce que j'étais paresseux et c'était plus facile pour moi de dire que nous allons faire cette séquence. Ce n'est pas bon.
[00:53:52] La livraison et la découverte doivent se faire dans la même équipe par la même personne. Ce n'est pas facile, je suis d'accord avec vous, c'est compliqué, c'est pourquoi nous devons le faire et nous devons faire plus. Et d'ailleurs, arrêtez de traiter les ingénieurs comme des fournisseurs de services. D'accord ?
[00:54:11] Ils ne sont pas là juste pour coder des choses.
[00:54:15] Ce sont des gens intelligents. Des gens très instruits. Ils sont très bons pour résoudre les problèmes, pour résoudre les problèmes. En comprenant comment ça marche. Et les meilleures équipes que j'ai rencontrées ont des ingénieurs dès le premier jour pour réfléchir aux problèmes des clients. L'ingénierie sont des gens très créatifs.
[00:54:38] Si vous les laissez bloqués juste sur le codage, je pense que vous perdez votre argent pour rien, ça n'en vaut pas la peine.
[00:54:52] Alors, je vais vous laisser maintenant. Je pense que je suis plus ou moins à l'heure, en retard, à l'heure, je ne sais pas. Plus personne ne s'en soucie. Ok, cool.
[00:55:03] J'aimerais que vous y réfléchissiez.
[00:55:07] Et si dans votre entreprise, vous arrêtiez de livrer des choses et qu'au lieu de cela, vous commenciez à apprendre votre métier. Parce que tout est là, vous devez apprendre comment vous gagnez de l'argent. Il n'y a rien de mal à parler d'argent, de performance, d'utilisation, de pénétration du marché. Des taux, de tout cela.
[00:55:31] Nous devons être meilleurs en intelligence économique, nous devons être meilleurs à cela. Nous tous, ingénierie incluse. D'accord ? PM d'abord, ingénierie incluse. Et c'est tout. Alors.
[00:55:47] Merci à l'équipe de From de m'avoir ici aujourd'hui, c'est vraiment très émouvant. Merci à tous les grands sponsors, car ce sont eux qui rendent possible ce genre de temps et d'espace pour que nous soyons là. Ehm merci à vous d'être ici avec moi.
[00:56:08] Je m'appelle Rachel. Je suis une personne très colorée, comme vous pouvez le voir. Si vous voulez être amis avec moi, vous pouvez scanner ce code QR. Et si vous voulez me donner un feedback, faites-le s'il vous plaît. C'est une première, toute première ébauche, c'est une ébauche. Je serai super contente, mais ne faites pas ça avec des formulaires anonymes et tout, venez me parler. Merci.

Transcription (Traduit)