Bonjour à tous, bienvenue à cette rentrée du French Produit à Paris avec ce nouveau Meetup où j'ai le plaisir de recevoir Lucie qui va nous parler de sa vie à Content Square et notamment comment scaler une équipe produit. Juste avant de lui laisser la parole, quelques mots sur le French Produit et sur nos sponsors, sans qui rien ne serait possible. Le French Produit, qu'est-ce que c'est ? C'est une communauté qui connecte les amoureux du produit. Concrètement, ce qu'on fait, c'est qu'on est une association qui fédère la communauté produit en France et ce qu'on fait pour fédérer cette communauté, on organise soit des événements où on pousse des contenus et je vais rentrer dans le détail juste après, mais vous avez sûrement entendu parler du Slack French Produit, des initiatives comme ce Meetup-là et l'idée, c'est grâce à ces événements d'échanger, de parler produit entre des personnes du produit. Ce qui est important aussi, c'est qu'à notre cœur, quand on est une association, c'est que c'est gratuit et c'est pour tout le monde. On est entre pères, donc chacun peut exprimer ses idées et échanger avec d'autres personnes du produit et aussi, bien sûr, on n'est pas une secte et on ne compte pas le devenir. Donc voilà, sans prosélytisme. Un petit focus sur un de nos produits phares, notre Slack, qui est le Slack French Produit. Aujourd'hui, on est une communauté de 1 700 personnes du produit sur ce Slack-là, où on échange quotidiennement sur des enjeux produits. Pour ceux qui ne connaissent pas ce Slack-là ou qui souhaiteraient le rejoindre, voici un QR code où, de toute façon, si vous tapez French Produit, vous pourriez avoir accès au Slack et c'est dans ce Slack-là que, notamment, vit une grande partie de notre action en faisant vivre cette communauté-là. Un petit détail aussi sur comment on est organisé. Nous, l'association French Produit, on est divisé en huit chapters régionaux. Donc là, nous, on est celui de Paris. Concrètement, celui de Paris, c'est six personnes que je vous présente là. L'idée, ce n'est pas de les présenter, mais si jamais vous avez des idées aussi, que vous souhaiteriez aussi participer à l'association, n'hésitez pas à nous contacter directement ou soit directement, par exemple, sur LinkedIn ou directement sur le chapteur Paris, sur le Slack, ou directement par mail, paris.frenchproduit.com. C'est fini pour le French Produit. Un petit mot sur nos sponsors. Donc là, je vais laisser Fabrice, le président de French Produit, parler. Merci. Tout le monde me connaît, je ne vais pas me présenter. J'espère que tout le monde me connaît. Si tout le monde ne me connaît pas, je suis hyper vexé. Alors oui, effectivement, French Produit, c'est relativement nouveau. On l'a créé en février. C'est la continuité des efforts qui ont été faits dans la communauté depuis 2013, puisque la communauté produit française va fêter ses dix ans. À l'époque, il y avait 15 personnes, dont la moitié était là pour les pizzas et les bières gratuites. Il y aura quand même des pizzas et des bières gratuites, je vous rassure. Ça a beaucoup changé et entre autres, on a changé de nom. On était le PCX. Aujourd'hui, on a séparé l'organisation de la conférence que vous connaissez, qui est la produconf, qui est assurée à 100 % par TIGA, avec toujours des gens comme moi qui vont aider sur la partie speakers, et tout le reste de la communauté, des éléments communautaires, sont associatifs. C'était une vraie volonté de séparer les choses. Et on a trois sponsors, trois étoiles. Les sponsors trois étoiles, c'est des gens qui vont nous soutenir sur l'ensemble des chapters qu'on a. Donc, en gros, c'est grâce à eux qu'on est capable d'avoir des moyens pour l'association. Aujourd'hui, c'est couvrir des frais, c'est être capable de vous inviter pour des apéros, et ce, dans toute la France. Tout le monde n'a pas forcément la possibilité d'avoir plein d'endroits où il y a 75 ou 100 personnes qui veulent venir. De temps en temps, c'est plus petit. On va investir dans ces moyens-là. Et on essaie de pousser des initiatives au-delà, sur des notions de diversité et d'inclusion, par exemple, via FrenchCPO, qui va lancer un programme avec FitinTech, d'intégration, de coaching par des CPO, de product managers femmes, aujourd'hui, pour les accompagner vers des postes de Head of Product ou de CPO. C'est les choses qu'on lance. Le premier à avoir répondu à l'appel, c'est Bytheory, dont vous avez un magnifique représentant ici, dans la personne de Xavier, qui est Advocate. Ne me demandez pas ce que ça veut dire. Et à lui non plus, d'ailleurs. Il n'a toujours pas compris. Voilà. Bytheory. Alors, ça fait longtemps que Bytheory est engagé dans la communauté produit et agile, de façon plus générale. Vous les connaissez probablement. Il y a des gens de Bytheory qui ont sûrement travaillé chez ManoMano à un moment ou à un autre. Ils nous soutiennent partout et ils sont particulièrement soutenants à Paris et à Lille. Donc, si on a ici des gens qui travaillent à Lille, éventuellement, sachez qu'il y a aussi Bytheory à Lille. Le deuxième sponsor qui nous a accompagnés, c'est Cédine Blu. Ce n'est pas grave. Donc, Cédine Blu. Qui connaît Cédine Blu ? OK, pas mal. Ça me permettra de leur dire qu'ils sont quand même un peu connus. Cédine Blu, qui est une boîte lyonnaise à l'origine, qui nous soutient aussi. C'est un sponsor trois étoiles. Et moi, j'ai appris en discutant avec eux qu'ils étaient leaders en Europe et aux États-Unis sur la section PME. Donc, ça fait partie des champions dont on n'entend pas assez parler. Et pourtant, ils sont presque trop humbles. Et c'est aussi pour ça, pour être un peu moins humbles, qu'on a décidé de les mettre en sponsor. Comme ça, ça va les guérir un petit peu. Voilà, Cédine Blu. Vous aurez Sylvain Ramos, qui est leur VP Product, qui viendra, et un nouveau LF Product, Michael Bastien, qui est un ancien petit gars, mais je ne fais pas du tout de la pub pour petits gars. Hein, Thomas ? Et le troisième, c'est Exalt. Exalt, qu'on a la particularité, ils sont lyonnais aussi, et qu'on a la particularité d'être quasiment à tous les endroits où vous avez un chapteur Trend Produits. Donc, ils sont présents partout en France et ils ont une particularité qui est qu'ils ont adapté le produit dans leur organisation. C'est-à-dire qu'ils font tout par le biais du produit en orga. Donc, ils font des OKR en interne, mais ils font aussi des squads en interne, même chez des gens qui ne sont pas du tout product. Ils ont tiré le modèle jusqu'au bout. Ça ne marche pas toujours, parce que les modèles ne marchent pas toujours parfaitement. Et ils y terrent. Donc, ils ont suivi la logique produit, de l'orga est un produit. Donc, voilà, c'est suffisamment rare pour être remarqué. Si vous voulez devenir sponsor, votre bois le dire sponsor, il y a toujours des places pour sponsoriser à Paris. Donc, on accepte des gens qui sont sponsorisés locaux, pas forcément des sponsors d'associations. Et on a toujours besoin de gens qui nous hostent pour les meetups. Donc, si votre entreprise a envie de payer des bières et des pizzas à des gens qui viennent pour se faire un peu de pub en brand, n'hésitez surtout pas à contacter les gens de l'équipe et on sera ravis de venir chez vous pour parler produit. Voilà, merci. C'est tout pour moi et je vais aller me mettre dans un coin pour déranger personne. Merci, Fabrice. Un petit mot aussi de Mano Mano qui nous accueille aujourd'hui dans leur loco, notamment pour les bières et les pizzas, mais pas qu'eux. Bienvenue, François. Merci. Bonsoir à tous. Donc, moi, je m'appelle François. Je suis VP Product de Mano Mano. Je voulais simplement vous souhaiter la bienvenue et vous dire qu'on est ravis de vous accueillir au nom de toute l'équipe produit de Mano Mano. Il y en a certains qui sont parmi nous. Vous les reconnaîtrez à leur petit badge. Mano Mano a toujours été proche de la culture produit et des équipes de la communauté produit au sens large. C'est toujours une préoccupation forte de la boîte de voir comment est-ce qu'on pouvait développer la culture produit et les équipes. Et on est ravi de pouvoir vous accueillir. On a un petit big up à Damien Renaud, qui est un de nos talentueux senior lead PM, qui a animé un meetup il y a quelques mois de cela sur les app. Ceux qui ne connaissent pas Mano Mano, en quelques mots, c'est une scale up qui a été créée il y a un peu moins de dix ans et qui est devenu le leader européen en ligne du bricolage, du jardinage et des produits de la maison. Voilà, on a un peu plus de 1000 en France et en Espagne, un peu partout. On est présent dans six pays où on vend nos produits, les six plus gros pays européens et l'équipe produit en a un peu plus de 60. Donc voilà, on va être très intéressé par ce que va nous présenter Lucie, parce que c'est un thème qui nous parle forcément beaucoup, puisqu'on a aussi accompagné cette hyper croissance d'une scale up. Donc voilà, encore une fois, ravi de vous accueillir et on espère que vous avez passé une bonne soirée. Merci beaucoup. OK, on arrive à la partie encore plus intéressante. Donc, bienvenue Lucie dans les locaux de Mano Mano. Lucie, en quelques mots, elle a rejoint Content Square quand on pouvait compter le nombre d'employés sur les données de main et depuis, ils sont 1500 en quelques années. Donc voilà, Lucie, tu vas nous expliquer comment tu as fait pour scaler cette équipe produit à marche forcée. Bienvenue Lucie. Merci. Je vais garder mon téléphone avec moi. Ce n'est pas parce que je veux faire autre chose en même temps, c'est parce que j'ai un million de slides et trop de trucs à vous raconter, donc juste pour être sûre que j'avance suffisamment vite. Je ne vais pas avoir le temps de rentrer dans le détail de tous les thèmes, mais je voulais partager avec vous un panorama des thèmes qui ont été importants pour nous. Et puis après, on peut en discuter autour d'une bière et d'une pizza, parce que j'ai l'impression que ça fait partie du temps fort de ce meetup. OK, donc rapidement, Content Square, c'est 1500 employés et 72 nationalités. On a.
un peu plus de 1 000 clients en entreprise et on a 1 million de clients mid-market et SMB depuis qu'on a racheté Odjar l'année dernière. Et moi, je ne vais parler que de la croissance de Content Square, je ne vais pas parler d'Odjar aujourd'hui, juste pour que vous sachiez de quoi on parle. On a un NPS sur notre produit de 50. Pando vient juste de sortir son benchmark et apparemment, ce n'est pas best-in-class, donc on a encore pas mal de boulot pour aller plus loin. On a une croissance de 100% d'année en année, je reviendrai sur ce que ça veut dire après. On a fait 6 acquisitions sur les 34 derniers mois et 6 levées de fonds sur les 6 dernières années et on collecte plus de 15 trillions d'interactions chaque jour sur les sites de nos clients. Je voulais aussi vous dire un petit mot sur notre business model. Déjà, on a un produit data, donc tout ce qu'on fait, pour n'importe quoi qu'on met entre les mains de nos clients, ça veut dire qu'on a collecté de la donnée, qu'on l'a storée et qu'ensuite, on l'a mise en forme, donc on bosse beaucoup sur la performance du tag, on bosse beaucoup sur nos bases de données et on bosse beaucoup sur la data visualisation. On a un modèle SaaS Enterprise qu'on appelle iTouch, ça veut dire qu'on n'a aucun client qui peut venir de lui-même mettre sa carte bleue sur le site et s'auto-onborder. Ça va systématiquement passer par une équipe de sales et par une équipe de customer success. Et ça, c'est important de le comprendre parce que vous allez voir que tout ce que je vous raconte, en fait, on peut créer les meilleurs produits du monde. Si on n'est pas capable de convaincre nos sales et nos customer success de le vendre, il y a peu de chances que ça trouve son chemin. Donc, c'est très, très différent d'un produit fait de grosses. On a ce qu'on appelle une stratégie London Expand, j'en reparlerai un peu après, mais en gros, l'idée, c'est de vendre un premier produit à nos clients. Et puis ensuite, quand ils sont contents avec leur premier produit, de continuer à leur vendre plein de produits pour qu'ils aient toute la gamme Content Square. Ensuite, les deux autres drivers de la croissance, c'est les JO. Donc, on a plus d'une dizaine de bureaux partout dans le monde. Et le troisième driver de la croissance, c'est les acquisitions. Voilà, et en produits R&D, on n'est pas loin de 500. Les équipes produits R&D représentent un tiers de la C-Squad et dans l'équipe produits, on est 80 aujourd'hui. Je vais vous parler de la présentation, elle est structurée en deux parties. Les choses pour moi que vous devez faire dès le début, qui sont indispensables pour faire décoller votre produit, qui sont d'avoir une vision, une stratégie assez forte et les choses qui sont venues pour nous après avec le scale. Et je vais vous parler un peu de notre toolbox à nous pour faire grandir l'équipe produits. Pour les questions, je crois que c'est tout à la fin. Donc, n'hésitez pas à noter vos petites questions pour qu'on puisse revenir sur la fin. Posez toutes les questions que vous avez, il n'y a pas de tabou. A priori, il n'y a pas grand-chose que je ne puisse pas vous raconter. Et au pire, si je ne peux pas vous dire, je vous dirai que je ne peux pas vous dire. Voilà, donc du coup, je disais, pour moi, ce qui est hyper important, je vais me mettre là parce que sinon je vois mal les slides. Un truc hyper important, c'est de travailler votre product vision et votre product stratégie hyper tôt pour aligner vos stakeholders et aussi pour inspirer, je vais me mettre là parce que je m'entends en double. Donc, pour aligner vos stakeholders et pour inspirer vos équipes, vos clients et vos investisseurs. Donc, une product vision, c'est vraiment le pourquoi. C'est pourquoi c'est important ce que vous faites. Je suis désolée, je n'ai pas l'habitude de parler, c'est horrible de dire ça, je n'ai plus l'habitude de parler en français, donc j'ai peut-être un peu buggé sur certains mots. Et c'est pour ça aussi que les slides sont en anglais. En gros, c'est vraiment de définir ce que c'est le rêve. Et moi, je pense qu'il y a un truc hyper important, c'est que plus la vision est ambitieuse, plus vous avez de chances d'embarquer les gens pendant longtemps. Et typiquement, je ne sais pas qui dans cette pièce a déjà rencontré John, Jonathan Sharkey, notre fondateur, mais c'est quelqu'un qui a une vision complètement démesurée. Moi, la première fois que je l'ai rencontré, c'était donc il y a huit ans et demi. À l'époque, il y avait moins de dix employés chez Content Square. Tout le monde avait entre 20 et 30 ans. C'était un tout petit appartement en bas des Champs-Élysées. Il m'a déjà dit, et à cette époque-là, il m'avait dit, cette boîte, elle va être leader mondial de son secteur. Et les États-Unis, ça va devenir notre principal marché. Moi, je vais partir vivre aux US et si tu veux, tu viens avec moi. Et ça, c'était il y a huit ans et demi. À l'époque, ça paraissait complètement fou. Et en fait, c'est ce qui s'est passé. Donc, je pense qu'il ne faut pas avoir peur de sa vision. L'autre truc important, c'est que c'est fait pour durer une vision. Donc, il ne faut pas avoir peur de viser loin. Tesla, ils ont depuis toujours cette vision des voitures autonomes. Il y a dix ans, ça paraissait complètement impossible. Donc, je pense qu'il ne faut pas avoir peur de rêver en grand et aussi de viser quelque chose qui n'arrivera pas dans les deux ou trois prochaines années parce que c'est important d'engager les gens sur la durée. Un autre truc qui est hyper important pour moi, c'est que pour moi, c'est là où le CEO et le CPO s'alignent. Donc, après, un CPO, ça s'appelle parfois Head of Product, parfois VP Product, peu importe. Mais je pense que tant que vous n'avez pas créé l'alignement avec votre CEO et tant que la vision que porte l'équipe produit n'est pas parfaitement alignée avec la vision que veut porter le CEO, vous n'allez rien pouvoir décliner. Parce qu'en fait, si vous n'êtes pas d'accord sur la direction, vous ne serez jamais d'accord sur les chemins. Donc, ça paraît un peu évident de dire ça, mais je pense que c'est un exercice sur lequel il faut énormément travailler. On me pose souvent la question de comment est-ce qu'on peut choisir de devenir CPO ou VP dans une boîte produit. Je ne suis pas hyper bien placée pour répondre parce que moi, je suis arrivée au tout début et que je suis arrivée en tant que customer success. Donc, c'est la vie qui a fait que je suis devenue le CPO. Mais je dirais que c'est important dès le départ d'être sûr que vous avez un... que vous croyez dans le rêve de la boîte et que vous êtes aligné sur la vision, parce que ça sera hyper difficile de changer cette vision-là. Et en fait, c'est pareil quand vous rentrez en tant que Product Manager. Moi, je vous encourage vraiment à toujours demander ce que c'est la vision de la boîte, parce que c'est pareil, vous allez travailler beaucoup d'heures par semaine pour faire avancer ce rêve. Et en fait, si vous n'y croyez pas, même si c'est 40 heures, ça va sembler 100 heures. Et si vous y croyez fort, même si c'est 80 heures, ça va sembler 20 heures. Et puis, la dernière partie, c'est que moi, je pense que c'est hyper important d'avoir une product vision forte et c'est peut-être encore plus important de la partager. Ce n'est pas un secret, votre product vision. Je pense que plus vous allez la partager, plus vous allez avoir de retours et plus vous allez être capable d'engager les gens. Moi, je commence tous mes entretiens par la vision Content Score, par exemple. Et du coup, juste pour vous donner un exemple, donc nous, notre vision, enfin notre vision ou notre rêve, notre mission and purpose, c'est qu'on imagine un monde dans lequel tout le monde reçoit l'expérience qui Love, Enjoy, Desire, Seek and Desire. Et quand moi, j'ai rencontré John il y a huit ans, on avait une phrase qui était beaucoup moins fancy, mais il avait déjà cette ambition de créer un produit qui allait changer l'expérience utilisateur de chaque personne qui utilise un site web. Et donc, ce n'était pas du tout dit de la même façon, mais c'était déjà cette très grande vision. Et ensuite, le boulot qu'on a fait ensemble, c'est qu'on a réfléchi à ce que ça veut dire d'un point de vue produit. Et donc, la vision que vous voyez là, en gros, nous, notre idée, c'est de dire que de la même manière que quand vous arrivez dans un magasin, s'il y a quelqu'un qui arrive dans un magasin et qui court et qu'il est transpirant, vous n'allez pas lui parler de l'ADN de la boîte, vous allez l'aider à acheter le plus vite possible sur un site Internet. On devrait aussi être capable de comprendre quelle est l'intention d'un utilisateur et du coup, lui proposer des parcours de navigation qui sont adaptés à son intention. Et donc, ça, c'est la vision sur laquelle on s'est mis d'accord. Ça fait longtemps qu'on s'est mis d'accord sur cette vision. Et du coup, je vous dis, on la représente systématiquement. Et c'est ce que je mettais sur la slide après. Je ne compte même plus le nombre d'engueulades qu'on a eues avec John sur la manière d'approcher cette vision-là. Mais le truc qui est hyper important, c'est qu'on a toujours eu cette North Star et ce rêve en commun et cette envie d'aller au même endroit. Et donc, ça nous a toujours rapproché et aidé à trouver des solutions sur la stratégie Azure, qui est du coup mon point d'après, qui est aussi super important parce qu'en fait, la stratégie, c'est la manière dont vous allez rendre la vision plus concrète en disant, OK, pour atteindre ma vision, je vais avoir besoin de travailler sur 6, 7, 10 blocs de valeurs. Et pour l'année prochaine, on va s'attaquer à un bloc de valeurs ou deux blocs de valeurs. Tous les autres, on sait qu'on va devoir les régler, mais ce n'est pas notre problème de maintenant. Et ça, ça vous permet de vachement bien aligner vos stakeholders qui, chaque fois qu'ils vont vous demander un truc, vous allez pouvoir leur dire soit non, ça ne fait pas partie de la vision, soit oui, c'est super intéressant, mais on le fera plus tard, ça ne fait pas partie des choses qu'on fait maintenant. Et du coup, moi, je trouve que c'est un outil hyper efficace. En fait, tout ce que je dis, ça marche au niveau du produit.
en général, mais ça marche au niveau de vos lines ou de vos squares ou de vos squads, ça dépend comment vous les appelez. Je pense que de la même manière que moi, mon job, c'est de m'assurer que je suis alignée sur la vision avec mon CEO et qu'il est d'accord avec la stratégie, je pense que le rôle d'un PM, c'est d'être sûr qu'il est aligné avec la vision de son leadership et que son leadership achète sa vision, sa stratégie. Voilà, je vous en reparlerai après, mais nous, pour construire cette vision, on utilise beaucoup de données marché, mais on la fait aussi valider avec nos clients via les Customer Advisory Board. Et donc, ce qu'on fait, c'est qu'on en a un par grande G.O. Donc, on en a deux en Europe, un en Asie et un aux U.S. Et ça représente nos 5 à 10 clients les plus engagés avec Content Square et aussi, il y a quand même une grosse représentation de nos plus gros clients, de ceux qui payent le plus cher pour avoir Content Square. C'est là où, dans un modèle B2B Enterprise, vous allez avoir une approche un peu différente que si vous avez un modèle B2C. Mais du coup, ce qu'on fait, c'est qu'on les réunit et on leur fait, on leur présente notre vision, nos stratégies, on les fait réagir là-dessus. Et je vous montrerai juste après comment on fait. Voilà, et puis, qu'est-ce que je n'ai pas dit ? Oui, c'est bon, j'ai tout raconté ici. Donc, du coup, sur les Customer Advisory Board, en général, ce qu'on fait, c'est qu'on fait un Buy a Feature ou un Buy a Use Case, ça dépend. Et donc, on met notre, on fait sur ces fameux blocs de valeurs là, dont je vous parlais, on fait un petit slide par Use Case. Chaque Use Case a un prix et on donne de l'argent à nos clients. Et avec l'argent qu'ils ont en total, tous ensemble, ils peuvent acheter un tiers de tout ce qu'on a mis sur le mur. Et tout seuls, ils ne peuvent quasiment rien acheter parce que la plupart des Use Cases sont plus chers que l'argent qu'ils ont en individuel. Et donc, ça les oblige à discuter des Use Cases qui sont les plus intéressants pour eux sur la prochaine année. Parce que c'est ça la consigne, c'est qu'est-ce que vous voulez voir apparaître dans le produit dans la prochaine année. Et on ne respecte pas toujours l'ordre qu'ils font parce que déjà, on a un seul roadmap, une seule roadmap pour tous les pays. Donc, on est quand même un peu obligés d'agréger les feedbacks. Et en fait, c'est plus ici, ce qu'on cherche à récupérer, c'est plus de l'information qualitative, de comprendre pourquoi est-ce qu'un Use Case est important pour eux. C'est pour ça que c'est important qu'aucun client puisse acheter des Use Cases tout seul parce que du coup, les clients sont obligés de parler entre eux et de se convaincre mutuellement et donc de vous expliquer pourquoi ils vont l'utiliser, comment ils vont l'utiliser. Et donc, ça crée une matière hyper riche qu'ensuite, vous pouvez réutiliser. Et comme toute donnée qualitative, ça vous donne des hypothèses qu'ensuite, vous allez pouvoir tester avec votre donnée un peu plus quantitative, mais ça vous donne des points d'entrée, des insights que vous allez ensuite pouvoir confirmer ou infirmer avec votre data. Ça, c'est notre stratégie. Notre stratégie, vous allez voir, c'est à la fois la stratégie produit et le modèle qu'on utilise. Donc, nous, c'est une suite de produits. Les produits, vous les voyez en haut, qui vivent tous sur une même plateforme et avec un écosystème de partenaires très fort et des services. C'est ce que je vous disais tout à l'heure, c'est qu'en fait, nous, on n'a aucun client qui utilise la plateforme en parfaite autonomie. On a tout le temps des équipes de customer success qui les aident à soundborder, à créer de la valeur et à mesurer la valeur qu'ils créent avec QuantanSquare. Et donc, vous voyez, tout ça, c'est représenté dans un graphe. Et ensuite, ce qui est hyper important, c'est aussi de dire dans quel ordre vous allez faire les choses. Donc, par exemple, nous, en 2022, on renforce les investissements sur les produits existants. On lance trois nouveaux investissements. Et après, il y a ces quatre, c'est ce que j'appelais tout à l'heure les blocs de valeurs. Il y a ces quatre blocs de valeurs qui sont pour plus tard. Donc, pour le moment, on dit oui, c'est intéressant, mais on n'a pas du tout commencé à faire de discovery dessus et on ne s'engage pas du tout sur une timeline. Ça, je pense vraiment que vous pouvez le faire dès le début. Au début, les slides, elles sont un peu moins designées, mais ce n'est pas grave. Mais je trouve que c'est hyper, hyper important pour engager les équipes dès le départ. Du coup, je ne sais pas si vous y voyez bien de ce côté, si je me mets là. Oui, ça va. OK, du coup, je vais juste revenir rapidement sur ce que ça veut dire concrètement d'être dans une boîte en hyper croissance. Quand on parle de 100% de croissance hier en hier, ça veut dire qu'à la fin de l'année dernière, on faisait 200 millions de chiffres d'affaires et qu'à la fin de cette année, on sera pas loin de 400 millions. Donc, ça veut dire qu'en un an, on a onbordé le même nombre de clients qu'on avait onbordé les neuf ans d'avant, puisque la boîte, elle a 10 ans. Donc, c'est ce type de stress qu'on met sur l'organisation, en fait, où on avait 600 ou 700 clients à la fin de l'année 2021 et on en aura plus du double à la fin de l'année 2022. Pour nous, sur les deux ou trois dernières années, sur la Product House, donc, quand on dit Product House, c'est produits et R&D, on a doublé la taille de l'équipe chaque année. Voilà, c'est pareil. Ça veut dire qu'en fait, cette année, on doit recruter et onborder autant de gens qu'on avait recrutés et onbordés sur les neuf années d'avant. Donc, en début d'année, on était 50. À la fin de l'année, on sera 100 dans l'équipe produits. Donc, pareil, c'est un gros... Ça oblige à se réinventer en permanence. Et ensuite, nous, on a fait, donc, je vous le disais tout à l'heure, six rangs de funding et six acquisitions. Le funding, ça met quand même un peu de pression aussi sur l'organisation parce qu'à chaque fois, ça veut dire des nouveaux investisseurs. Ça veut dire s'engager sur un business plan. Ça veut dire qu'il faut vraiment délivrer sur tous ces objectifs. Et les acquisitions, c'est hyper intéressant aussi, parce qu'en fait, chaque fois que vous faites une acquisition, vous accueillez une équipe qui a une culture et une manière de travailler complètement différente. Donc, c'est passionnant parce qu'on apprend plein de choses. Mais pareil, ça oblige à se remettre en question tout le temps. Et je pense qu'en fait, c'est ça, vraiment, le cœur d'être une scale-up, c'est être d'accord pour se dire que tous les six mois ou toutes les années, si ce n'est pas tous les six mois, il va falloir complètement changer la manière de travailler parce que ce qui marchait super bien ne marche plus. Et on est un peu obligés de faire ça parce que sinon, si tu essayes de faire un process ou d'avoir une orga produit qui va marcher pour les trois prochaines années, elle est complètement inadaptée au début et à la fin. Parce qu'au début, tu mets des process pas possible en place alors que tu n'es pas assez nombreux. Et à la fin, au contraire, tu as un truc qui part complètement en live parce que ce n'était pas assez structuré. Du coup, pour moi, le plus important, en fait, quand vous commencez à scaler, si vous êtes un product leader, c'est que votre taf, ce n'est plus de faire du produit, c'est de créer une équipe qui, elle, va faire des produits. Et en fait, on parlait tout à l'heure, Fabrice parlait de réfléchir aux organisations comme un produit. Et c'est vraiment ça, c'est-à-dire que moi, aujourd'hui, je considère que mon produit, c'est mon équipe. Et du coup, j'ai le même boulot d'arriver à comprendre les needs, les pains et les desires, de faire ma continuous discovery, de sans arrêt faire des interviews avec les gens dans l'équipe pour comprendre ce qui marche et ce qui ne marche pas, de définir des problèmes avant de switcher directement sur les solutions. En fait, toute la méthodologie produit, on essaie de l'adapter à notre organisation. Et je pense que c'est comme ça qu'on arrive à changer tous les six mois ou tous les ans de manière de travailler sans que ce soit trop, trop impactant pour les équipes. Du coup, je vais parler de... J'ai laissé mon portable là-bas, du coup, il est quelle heure ? Parfait, super. Du coup, je vais vous parler de six outils que... Merci beaucoup, c'est trop sympa. Je vais vous parler de six outils que nous, on utilise. Évidemment, il y a plus de choses qui sont faites. Mais je trouvais que c'était ça, les choses les plus importantes. Et donc, la première, je pense qu'un des premiers challenges quand on scale, c'est d'arriver à maintenir le knowledge dans l'équipe produit, donc la connaissance. Et quand on parle de la connaissance, ici, c'est la connaissance produit, client et marché. En fait, je pense que quand on commence à scaler, ce qu'il faut se dire, je ne l'ai pas dit, c'était écrit dans la salle d'avant, mais je ne l'ai pas dit. C'était ça que je voulais dire. En fait, une des raisons, enfin, à partir du moment... Nous, aujourd'hui, on a 20 équipes produits. Donc, si moi, je dois décider de la roadmap de 20 équipes produits, c'est impossible et je deviens le bottleneck. Et donc, en fait, il y a tellement de, comme dirait notre ami Marty Kagan, de « half problem to resolve », que du coup, vous ne pouvez plus compter sur les leaders produits ou le leadership produit pour résoudre ces problèmes. Donc, vous êtes obligés de décentraliser la prise de décision et de donner beaucoup plus d'autonomie aux équipes et de construire des équipes qui vont mieux savoir résoudre les problèmes que vous. Et donc, ces fameuses « empowered teams », moi, je pense qu'elles commencent vraiment par une connaissance très, très forte du produit, des clients et du marché. Donc, moi, ce que je dis tout le temps aux product managers, c'est que chaque fois qu'ils parlent à un sales ou quelqu'un du customer...
success, leur objectif de meeting, ça devrait être que le sales ou le customer success ou l'organisation, ils apprennent au moins trois trucs sur leurs clients. Parce que si les sales et le customer success font confiance que vous comprenez mieux, en l'impression que vous comprenez mieux les clients, que vous comprenez mieux les marchés qu'eux, ils vont vous faire confiance sur la priorisation de la roadmap et les solutions que vous mettez dans la roadmap. Si à l'inverse, ils ont l'impression que vous comprenez beaucoup moins bien le marché, les clients et le produit, ils ne vont pas vous faire confiance et c'est normal. Ils ont raison de ne pas vous faire confiance. C'est vraiment important de construire son knowledge, mais aussi vraiment, et encore une fois, c'est assez particulier au business enterprise où il y a autant de poids sur les équipes sales et le customer success, il faut que ce soit vos partenaires parce qu'encore une fois, même si on a créé le meilleur produit du monde, s'ils n'ont pas confiance que c'est le meilleur produit du monde, comme les clients ne peuvent pas acheter par eux-mêmes sur un site web, personne ne va pouvoir profiter de cette super valeur. Du coup, nous, pour aider avec cet exercice, petit à petit, on a rajouté plein de rôles dans l'organisation. On a commencé par rajouter du product marketing qui nous a vachement aidé sur la partie marché, compréhension de la concurrence. C'est hyper important quand vous commencez à ouvrir des nouveaux pays parce qu'en fait, dans les nouveaux pays, ils ont été éduqués avec d'autres concurrents, donc ils ont en tête des use case différents. Ils ont aussi une culture différente, une manière d'aborder la valeur qui est hyper différente. Nous, on s'appuie quand même beaucoup sur le product marketing pour nourrir les équipes produits sur tout ce qui est marché. Sur la connaissance client, on a des OKR dans les équipes de faire au moins un meeting client par semaine et on essaye au maximum que ce soit le trio, donc product design, product marketing et tech lead qui participe à ce meeting. La vérité, c'est que cet OKR n'est jamais atteint. On a vraiment du mal à avoir un meeting par client, mais moi, j'ai l'impression qu'en posant cet objectif, on arrive quand même à avoir un ou deux meetings par mois qui restent beaucoup mieux que zéro. Et enfin, la connaissance produit, c'est rigolo. Tout à l'heure, on discutait du fait que chez Mano Mano, dans l'onboarding, il faut fabriquer un truc avec ses mains, donc être en contact avec le produit bricolé. Nous, c'est pareil. On demande vraiment à nos équipes d'utiliser le produit et on leur demande d'utiliser le produit de deux manières. On utilise Content Score sur Content Score, donc on utilise Content Score pour mesurer l'adoption de nos fonctionnalités, pour regarder comment les gens naviguent dans le site. Ça, je pense que c'est hyper important quand on a un outil d'expérience analytique et qu'on fait du produit. C'est hyper important de « eat your own food », right? Mais par contre, comme nous, on est un produit B2B, aujourd'hui, on a 10 000 monthly active users, là où nos clients, ils ont des centaines de millions de gens, entre des millions et des centaines de millions de gens qui viennent tous les jours. En fait, le trafic a rien à voir et l'usage est assez différent. Donc, on demande aussi aux équipes de faire des « analysis challenge » et donc, le « customer success » met les équipes dans les conditions d'utiliser le produit. Donc, les équipes produits, on leur demande de faire une analyse comme le client ferait l'analyse et ensuite, ils sont évalués, entre guillemets, par les équipes « customer success » de la même manière que les équipes « customer success » font du « feedback » et évaluent les clients. Et ça, c'est un truc qu'on a mis en place assez récemment parce qu'en fait, on s'est rendu compte qu'il y avait plein de petites choses qui étaient agaçantes dans le produit et qu'on n'arrivait pas à prioriser par rapport à mettre en place des nouvelles fonctionnalités ou des nouveaux « use case » parce que les équipes produits, elles ne sentaient pas suffisamment le « pain » de ces petites choses et donc, en fait, quand on les oblige à utiliser le produit et à constater par eux-mêmes, ça les pousse vachement plus à faire ça. Ensuite, du coup, il y a la mise en place du portfolio produit. Donc ça, en gros, c'est comment est-ce qu'on gère son organisation produit ? Du coup, au tout début, nous, on avait un fichier Excel géant qui répertoriait toutes les idées de « features » de John, il y en avait beaucoup, de moi, il y en avait beaucoup et de tous les gens de la boîte et chaque quart d'heure, on repriorisait ces « features » et on allait voir les « product managers » et on leur disait « bon, bah du coup, toi, c'est cool, tu as un projet, toi, ton projet, c'est ça, toi, ton projet, c'est ça, toi, ton projet, c'est ça et maintenant, allez-y, codez-le. Donc ça, ça marche à peu près, même si ce n'est pas idéal au tout début, d'autant plus que nous, au tout début de Compte en Score, l'équipe produit, on était en charge à la fois du produit et de l'onboarding des clients self-service parce qu'en gros, le modèle de Compte en Score au tout début, c'était qu'on était une agence de service et Fabrice qu'en témoignait parce qu'il a été un de nos tout premiers clients et en fait, on livrait des rapports d'analyse et on disait « voilà les 10 trucs qu'il faut que vous changez dans votre site web pour améliorer votre expérience » mais John a toujours eu cette vision d'être une plateforme self-service et donc, en gros, nous, notre enjeu, c'était de se dire comment est-ce qu'on passe d'un usage hyper expert de nos data analysts et de notre customer success qui fait des recos aux clients tous les mois ou tous les quarters à un usage beaucoup moins expert de n'importe qui dans l'équipe digitale ou dans l'équipe produit qui en fait vient tous les jours ou toutes les semaines pour apprendre des nouvelles choses. Donc, on n'est plus du tout sur un usage ad hoc, mais sur un usage beaucoup plus récurrent. Bref, tout ça pour dire qu'au tout début, on n'avait même pas cinq ou six clients en self-service et l'équipe produit, on était en charge des deux et donc le matin, on allait former des clients sur le produit et l'après-midi, on revenait brainstormer sur comment est-ce qu'on pouvait changer l'expérience. Et donc, quand on est dans ce genre de dynamique, avoir ces listes de fonctionnalités, etc., c'est quelque part, en fait, en allant chez le client comme ça, on fait son continuous discovery en permanence, on peut tester ses idées en permanence et donc, du coup, ça ne marche pas trop mal, même si, encore une fois, ce n'est pas forcément idéal. Mais sauf qu'en fait, quand on commence à avoir cinq ou six product managers et une cinquantaine de développeurs et qu'on passe moins de temps chez le client, ça ne marche plus du tout. Donc, on a créé les Square pour Content Square et les Square, c'était, on s'est dit, OK, maintenant, on va identifier quatre ou cinq grands sujets sur lesquels on veut travailler et on va mobiliser des équipes. D'ailleurs, ce n'était pas quatre ou cinq grands sujets, c'était les fonctionnalités, les principales fonctionnalités de la plateforme. Donc, il y avait une équipe en charge du zoning, il y avait une équipe en charge du journal analysis. Ça ne vous dit peut-être rien, mais en gros, c'est les grandes fonctionnalités qu'on a, c'est les rapports qu'on a dans le produit. Donc, chacun était en charge d'une fonctionnalité. Donc, c'est vraiment une logique de feature team et on n'avait que les développeurs app qui faisaient partie de ces feature team. On avait ensuite les data engineers et la data collection faisaient partie d'un grand pool. Donc, ce qui était bien, c'est qu'on avait les développeurs app qui commençaient à se spécialiser sur les problématiques du module. Mais par contre, dès qu'il fallait avoir recours à une nouvelle data ou changer la manière dont on modélisait la donnée pour que ça devienne plus efficace, on se retrouvait avec des ingénieurs qui n'avaient jamais entendu parler du problème. Donc, il y avait un temps de downboarding qui était super long et puis, il fallait convaincre les gens qu'ils viennent sur ce projet-là et pas sur l'autre projet. Donc, c'était la guerre des ressources en permanence. Et donc, du coup, mais la raison pour laquelle on faisait ça, c'est parce qu'en fait, les développeurs app, les DT et les data collection, ils travaillaient sur des technologies qui n'ont rien à voir. Et en fait, ça les faisait chier de faire le daily ensemble. Ils n'avaient rien à se raconter parce que les équipes, elles étaient hyper focalisées sur le delivery et très peu focalisées ou pas suffisamment focalisées sur toute la partie discovery et comprendre pourquoi on fait les choses. Et en fait, maintenant qu'on a beaucoup plus focalisé les équipes sur résoudre des problèmes et créer de la valeur, les devs, même s'ils ne codent pas avec les mêmes technos, ils ont beaucoup plus de choses à se raconter et ils peuvent trouver des solutions ensemble. Et ensuite, quand on passe sur la partie plus delivery et plus technique, chacun sait ce qu'il a à faire et ça améliore vachement la collaboration. Donc aujourd'hui, ça ressemble à ça. Toutes les équipes sont mappées sur nos deux plus grands objectifs business qui sont growth et retention efficiency. Donc en gros, sur la partie growth, l'idée, c'est de regarder, donc plus on va vers le haut, plus ça aide la growth et plus on va sur le côté, plus ça aide la rétention. Donc en haut, il y a les fameux produits qu'on vend et en bas, il y a la plateforme qu'on utilise. On a la plateforme que tous nos clients utilisent et qui est beaucoup plus là pour, vous le voyez, c'est écrit, la partie product foundation, c'est vraiment tout ce qui est le cloud, le tag, etc., donc vraiment les fondations du produit. Et ensuite, dans la partie value for all product, on a tous les outils qui permettent de s'onborder plus vite sur la plateforme, de créer des produits, de créer des services, de créer des services, de créer des services, de créer des services, de créer des services.
créer de la valeur plus vite et de monitorer la valeur. Donc, par exemple, pour donner un exemple concret, le dashboard, il fait partie de value for all product parce que peu importe que vous utilisiez le produit merchandising ou le produit finance fixe, vous avez besoin d'un dashboard et c'est beaucoup plus intéressant si vous pouvez agréger vos données dans un même endroit. Voilà, et on a mappé les features à l'intérieur de ces domaines-là. Donc, par exemple, dans le produit CS Digital qui est là pour améliorer les pages et les parcours, il y a une team dont la mission, c'est de créer des parcours qui permettent aux utilisateurs d'atteindre plus vite leurs objectifs et à l'intérieur, on a mis la feature journey analysis qui est la feature la plus utilisée. Mais l'équipe, elle sait que c'est son rôle de maintenir cette feature, mais que s'il y a un moment où il faut dépasser cette feature ou créer quelque chose de nouveau ou la tuer parce que ce n'est plus la bonne manière, elle sait qu'elle a entre guillemets le pouvoir de le faire parce que son but, c'est de créer cette vision ou de résoudre ce problème et pas de maintenir la feature. Et je pense que ça n'a l'air de rien, mais c'est un énorme changement de mindset dans les équipes. Et donc, du coup, ce qu'on avait en tête quand on a mis en place ce portfolio, c'était d'essayer de se focaliser beaucoup plus sur les outcomes pour les clients. Permettre à nos clients de créer des seamless experience, ça veut dire des expériences où il n'y a pas de bug, de créer des expériences engageantes, ça veut dire que les produits et les contenus sont engageants. Donc, au lieu de dire tu vas maintenir cette feature, on dit voilà la valeur que ça va créer pour le client et aussi focaliser sur la business value pour qu'on t'en sois parce qu'on est tout le temps dans cette articulation de créer de la valeur pour nos clients, tout en créant de la valeur pour l'organisation parce que s'il y a de la valeur pour les clients, mais pas de valeur pour l'organisation, il n'y a plus d'organisation, donc il n'y a plus de valeur pour les clients. Moi, je trouve que c'est aussi hyper important de comprendre, de bien gérer cette articulation dans votre organisation produit. Le deuxième objectif, c'était de donner beaucoup plus d'autonomie aux équipes, ça je vous en ai parlé, sur qu'est-ce qu'on met en place pour atteindre cette mission. Et le premier objectif qu'on s'était donné, c'était d'éliminer les dépendances. Et en fait, on s'est rendu compte que c'était impossible d'éliminer les dépendances. Et du coup, on a essayé de les minimiser et de mettre en valeur les endroits où il y avait des dépendances. Et donc, en l'occurrence, le dashboard dont je vous parlais tout à l'heure, qui est une fonctionnalité qui est utilisée par tous les produits, c'est hyper important que le product manager qui a dans son scope le dashboard, il sache qu'il a cinq produits clients et qu'il y a énormément de dépendances. A l'inverse, les gens qui travaillent à rendre les parcours et les pages plus fluides, eux, ils ne réfléchissent pas aux autres produits, ils ne pensent pas aux dépendances avec les autres produits. Donc, on a vraiment séparé en deux les endroits où il y a beaucoup de dépendance et les endroits où il n'y a pas de dépendance. Et ensuite, un truc qui est super important, c'est que quand vous commencez à mettre en place ce genre d'organisation, c'est hyper important d'être sûr que vous avez le moins de dépendance possible d'un point de vue technique et que vous avez tout ce qui est micro composants, micro architecture, etc. Je ne suis pas la meilleure pour vous expliquer exactement comment ça marche, mais en tout cas, le bénéfice pour l'équipe produit, c'est qu'on peut faire des releases à tous les endroits du portfolio sans que ça impacte les uns les autres. Je ne sais pas où est-ce que vous en êtes tous dans votre croissance produits. Nous, à un moment, ça a été un énorme bottleneck parce qu'on se retrouvait avec des trains de release où il fallait que la release machin soit passée pour que toutes les autres passent. Mais en fait, il y avait un bug sur la release machin, donc en fait, on prenait deux mois de retard sur toutes les releases et ça, c'était l'angoisse. Donc, ça, c'est aussi un conseil. C'est au moins côté produits, c'est plus côté tech de porter cette vision-là. Mais vous, en tant que product manager et product leader, c'est votre responsabilité de laisser de la place dans la roadmap pour travailler sur ces sujets de dette technique suffisamment tôt. Parce que si vous attendez trop longtemps, soit il n'y aura pas d'après parce que vous avez attendu trop longtemps, soit ça va vous coûter encore plus cher. Donc, en fait, quand on a toutes ces petites équipes, c'est parfois un crève-cœur de se dire qu'on va investir sur la techno et sur scaler tout ça alors qu'on a mille idées de use case qu'on peut mettre en place. Mais moi, je suis contente qu'on les fait suffisamment tôt. Donc, du coup, ça, on en a pas mal parlé d'organiser les équipes pour résoudre des problèmes plutôt que de délivrer des listes de features. C'est le fameux kill the roadmap. Quand on dit kill the roadmap, évidemment, ce n'est pas d'arrêter de partager avec vos équipes et vos clients sur quoi vous voulez travailler, mais c'est d'arrêter de partager des listes de features. De toute façon, vous allez voir que plus votre organisation grandit, moins les gens comprennent les fonctionnalités parce qu'en fait, plus le produit grandit, moins il y a de gens qui sont en capacité de comprendre l'ensemble des fonctionnalités qui sont livrées sur le produit. Et donc, c'est hyper important de plutôt parler de la valeur que vous avez créée avec ces fonctionnalités et de présenter les fonctionnalités comme des solutions ou des exemples de choses que vous pouvez faire pour créer cette valeur. Nous, on a été, pour le coup, ça a été plus long que dans plein d'autres organisations, je pense, de passer sur ce modèle-là. On est resté sur un modèle top-down assez longtemps et ça a été notamment lié à l'acquisition de Clicktail, qui était un de nos plus gros concurrents aux États-Unis. Et en fait, leur produit avait énormément de dettes techniques et de dettes en général. Et donc, il fallait qu'on puisse migrer nos clients le plus rapidement possible. Et donc, en fait, c'était plus important d'aller vite que de faire bien. Et donc, dans ce cas-là, l'approche top-down en disant aux équipes exactement quoi faire, ça permettait d'aller plus vite. Je crois, si c'était à refaire, je pense qu'on referait de la même manière parce que l'organisation n'était pas prête à absorber tous ces changements et on n'était pas prête à donner autant d'autonomie. Mais par contre, on l'a payé après parce que le moment où on a commencé à mettre beaucoup plus d'autonomie dans les équipes, on avait déjà 10 Product Units. Donc, ça veut dire créer du changement sur 10 équipes, alors que si on le fait quand on en a 3 ou 4, c'est quand même plus fluide et plus facile d'accompagner ce changement-là. Voilà. Et puis, des petits tips. Si vous êtes dans des organisations où les gens, ils n'ont pas cette culture produit de parler des problèmes en premier, la technique des 5 pourquoi, ça marche très, très bien. Pourquoi tu veux cette fonctionnalité ? Parce que blablabla. Pourquoi tu veux ça ? Parce que blablabla. Et ça, souvent, ça vous permet de remonter à la root cause et de vous rendre compte qu'en fait, il y a 5 features qui sont demandées dans le Channel Product Feedback qui servent à résoudre exactement le même problème. Et donc, en fait, au lieu de développer 5 fois une solution au même problème, vous allez choisir la meilleure solution et vous allez gagner du temps. Et c'est ce que je disais, c'est ce que je dis en bas là, c'est qu'en fait, souvent, c'est plus efficace de diminuer le nombre de fonctionnalités qu'on veut mettre en prod que d'essayer de recruter une tonne de développeurs. Souvent, dans le scale, il faut arriver à faire les deux. Mais si vous arrivez à stopper des idées avant de les mettre en prod, avant d'avoir commencé à poser la première ligne de code, vous allez gagner énormément de temps et créer de la valeur beaucoup plus vite pour vos utilisateurs. C'est cet exemple d'avoir très, très souvent plein de fonctionnalités qui répondent aux mêmes besoins ou la première idée qu'on a pour résoudre un problème n'est pas forcément la bonne. C'est pour ça que c'est hyper important de faire des tests avec vos utilisateurs et de vraiment challenger les solutions que vous avez en tête. Nous, on a la chance d'avoir des hyper experts du produit en interne, donc on peut vachement se reposer sur le customer success, notamment pour tester l'usage de nos solutions. Mais arriver à trouver une communauté de clients ou d'utilisateurs qui vous font confiance, à qui vous faites confiance, qui peuvent vous aider à avoir ce retour hyper rapidement, ça aide vachement. Ça, je pense que tout le monde connaît. Si vous ne connaissez pas, je vous invite très, très fortement à lire Marty Kagan parce qu'il l'explique beaucoup, beaucoup mieux que moi. Mais en gros, tout ce que je viens de vous raconter sur arriver à faire en sorte que les équipes se focalisent sur résoudre des problèmes plutôt que délivrer des listes de features, vous n'arriverez pas à le faire tant que vous n'arrivez pas à bien mettre en place cette cellule entre un product manager, un designer et un tech lead qui, selon la fameuse formule de Marty Kagan, n'ont pas de handover parce qu'ils travaillent ensemble et qu'ils collaborent ensemble sur la création des solutions. Je ne sais pas si vous avez déjà entendu ce truc-là, mais il le dit tout le temps quand il fait des talks, mais que très, très souvent, on lui demande quel est le meilleur outil de handover entre produit et design, puis entre design et la tech pour dire OK, moi, j'ai défini la valeur. Toi, tu as défini les wireframes et puis le dev va coder. Il dit en fait, si vous vous posez cette question-là, c'est que vous avez un problème parce que vous travaillez beaucoup trop en séquence et vous êtes complètement dans un modèle waterfall alors que si vous arrivez à discuter de ces trois trucs-là avec les trois personnes en présence, vous allez trouver beaucoup plus vite des solutions beaucoup plus efficaces. Voilà, je fais un petit point timing, il nous reste dix minutes. Un autre truc qui a été hyper important pour nous, toujours dans cette logique de décentraliser.
la prise de décision et de donner beaucoup plus d'autonomie aux équipes. Ça a été de définir notre product life cycle et donc de définir les différentes étapes dans lesquelles chaque produit doit passer. On n'a rien inventé. C'est le modèle de Zendesk, plus ou moins, qu'on a pris le même modèle, mais ensuite, on l'a vachement mis à notre sauce. Il y a une partie où il faut avoir bien compris et défini l'opportunité sur laquelle on veut travailler. Ensuite, une partie sur laquelle il faut s'assurer que la solution qu'on propose, ça va être la solution la plus valuable, usable et feasible. Et ensuite, on passe aux phases de delivery et alpha, bêta, control rollout et general availability, j'en parlerai après. Ça, c'est la manière dont on fait du progressive deployment. Chaque équipe a un goal. Une des métriques qu'on utilise le plus, c'est les weekly active users. Typiquement, sur chacun des produits, les équipes ont des objectifs de création de weekly active users. Ensuite, elles vérifient que ce qu'elles font dans les produits, ça permet d'avoir de plus en plus de weekly active users. Ensuite, on a des checkpoints, c'est-à-dire à chacun des points de passage. Chaque fois que ça change de couleur, on a un checkpoint pour s'assurer que l'équipe est alignée sur la compréhension de l'opportunité, sur l'opportunité qu'on va suivre, sur la compréhension de la solution. Et vous avez Enrique de la team qui est là, qui est programme manager chez nous. C'est en partie le rôle de s'assurer que ces checkpoints sont respectés. C'est souvent un bien plus joyeux bordel que ce slide-là. Mais en tout cas, ça donne un peu, ça donne une démarche à l'équipe, sachant que parfois, il va falloir, on va passer beaucoup plus vite sur les premières étapes parce qu'on a déjà plein de connaissances et on sait un peu mieux où on veut aller. Et d'autres fois, quand on lance un nouveau produit sur un marché qu'on connaît mal, eh bien, on va pouvoir, on va passer peut-être un ou deux quarters sur l'étape de discovery, l'étape de solutionning. Ça, j'ai raconté. Ah oui, et du coup, évidemment, c'est hyper important de, pour arriver, en fait, pour arriver à faire en sorte que votre organisation arrête de vous juger sur le nombre de features que vous avez délivrés dans un quarter. Il faut se mettre d'accord sur ces fameux goals et derrière, reporter à l'organisation, est-ce qu'on a atteint ce goal ou pas? Donc, nous, on a mis en place l'arrivée des Product Analysts, notamment, qui nous permettent de bien mesurer l'évolution des Weekly Active Users, l'impact des différentes releases sur tout ça. Ah oui, et ça, c'est pareil, c'est du copier-coller de notre ami Marty. Mais je pense qu'il y a un truc qui est hyper, hyper important, c'est de bien comprendre que quand vous êtes sur des modèles comme ça, où vous laissez beaucoup plus de latitude aux équipes pour prendre des décisions, ça demande dix fois plus de coaching que quand vous faites du top-down. Parce qu'en fait, quand vous faites du top-down, vous allez leur dire, OK, tu fais ça, ça, ça, et puis tu reviens trois mois plus tard, tu te rends compte que tout est en retard, que rien n'a été fait. Mais voilà, alors qu'en fait, dans un modèle où c'est hyper important d'accompagner les équipes, par exemple, sur la première phase, quand on décide sur quel problème on veut travailler, souvent, c'est hyper dur de choisir un problème, parce qu'en fait, il y a quatre problèmes. Les quatre problèmes, ils ont l'air super importants. Et souvent, les équipes, elles ont peur de prendre la décision. Et donc, c'est hyper important de pouvoir être là aussi pour leur dire, écoute, ce n'est pas grave, tu vas prendre un problème. Et si tu te rends compte après qu'il n'y a pas de bonne solution, tu reviendras à un autre problème. Et ça, ça demande le recul d'un manager et de quelqu'un de plus expérimenté aussi pour arriver à le faire. Donc, ça demande beaucoup plus de coaching et de management. Donc, ce n'est pas une manière de diminuer le nombre de ressources dont l'équipe produit, si jamais votre CEO vous demande. Sur la partie go-to-market, du coup, c'est les phases alpha, bêta, control, roll-out et general availability. Ici, ce que ça veut dire, c'est qu'au début, on a entre 5 et 10 clients qui peuvent utiliser le nouveau produit ou la nouvelle fonctionnalité. Ensuite, on a entre 10 et 50. Après, on a entre 50 et 100. Et après, il n'y a plus de limite. Ça, c'est un truc que nous, en fait, ce qui est marrant, c'est que nous, on est très B2B, très enterprise, mais nos clients, ils sont très B2C. Donc, en fait, on navigue un peu dans les deux mondes. Cette notion de progressive deployment, si vous êtes en B2C, vous allez souvent la gérer avec de la bêtesse en s'assurant sur 5% ou 10% de la population que tout va bien, en checkant bien vos métriques pour voir que vous n'êtes pas en train, j'en sais rien, d'augmenter le à toutes cartes, mais de complètement tuer la conversion parce que parfois, on a des effets un peu comme ça. Et nous, on utilise une matrice de maturité. Et en fait, les produits, pour passer aux étapes d'après, il faut qu'ils aient atteint certains critères de maturité. Et ça, c'est les critères de maturité qu'on utilise. Donc, on en a neuf. Je ne vais pas rentrer dans le détail. J'imagine qu'on partagera les slides avec vous après. Mais du coup, en fait, chaque quart d'heure, on fait le travail de réévaluer nos produits sur la viabilité, la désirabilité, la fisabilité, etc. Et pour chacun de nos pays, chacun de nos produits, on fait une évaluation. Et sachant qu'un produit en alpha, on lui demande, on est beaucoup moins exigeant qu'un produit qui est en GA. Donc, en fait, le niveau d'exigence de chacun de ces critères évolue en fonction du niveau de maturité des produits. Ça, c'est un outil de communication qui est hyper efficace avec les execs et les stakeholders, parce que ça permet de bien identifier, de montrer que vous êtes en conscience des risques et des forces et des faiblesses de vos produits et que vous êtes conscient des forces et que vous allez travailler sur les faiblesses et que vous ne vous racontez pas que vous êtes beaucoup plus beau que ce que vous êtes vraiment. Et ça permet de vraiment bien aligner tout le monde sur les sujets sur lesquels on doit travailler. Et ce qui est intéressant, je trouve, c'est que, par exemple, on a un truc sur l'enablement et on a un truc sur... Non, c'est ça, en fait. Donc, la partie enablement, c'est est-ce que les sales savent vendre? Est-ce que le customer success s'est onboardé? Est-ce que l'implémentation s'est implémentée? Parce que toujours pareil, nous, nos produits, il n'y a personne qui peut créer de la valeur avec si l'organisation n'est pas bien alignée pour créer de la valeur dessus. Donc, ça est la partie responsabilité. Ça, on l'a ajouté un peu après et ça vient avec une volonté de faire beaucoup plus attention à la manière dont on traite la donnée. Nous, on traite des énormes volumes de données. Donc, c'est hyper important d'être dans les, on dit, highest standards of privacy. On fait de plus en plus gaffe aussi sur la partie sustainability. Donc, tout ça, on le gère dans cette partie-là. Voilà. Et du coup, pour vous aider à avancer, je pensais que j'avais viré cette slide, pour vous aider à, on peut parler déjà, mais pour vous aider à faire vivre ce Product Lifecycle et nous, pour nous aider à faire vivre cette matrice, on a une équipe de programmes managers qui est vraiment là pour aider l'équipe à mettre en place toutes ces pratiques. Donc, vous avez Enrique qui est juste là, si vous avez des questions à la fin de la présentation. Voilà. Et je finis par la partie la plus importante, qui est vraiment genre, à la fin, faire du produit, c'est que travailler avec des humains. Donc, c'est quand même la partie la plus importante de tout ce que vous faites. Là, j'ai listé un peu les grandes questions qui se posent un peu au fur et à mesure. Dans une scale-up, il y a toujours la question de promouvoir des gens en interne ou de recruter des gens de l'externe. C'est un dilemme qui est assez compliqué parce que les gens de l'externe, ils n'ont jamais le même savoir que les gens de l'interne. Et en général, quand vous grandissez très, très vite comme ça, les choses ne sont pas super bien documentées. Et donc, d'avoir des gens qui comprennent tout, qui comprennent tout l'historique de pourquoi on a fait les choses, c'est hyper important. C'est des gens qui comprennent la culture aussi de la boîte, qui comprennent la manière de fonctionner, qui mettent vachement de l'huile dans les rouages. Et d'un autre côté, quand on grandit aussi vite, c'est hyper rassurant d'aller chercher des gens qui ont déjà connu les phases d'après. Et moi, je pense qu'il faut vraiment arriver à faire un mix des deux. Il faut arriver à identifier les profils dans les équipes qui sont suffisamment adaptables pour mener toutes les transitions successives et qui aiment ça aussi, parce que ce n'est pas le cas de tout le monde. Et renforcer aussi l'équipe avec des gens qui viennent de l'extérieur. Après, il ne faut pas vous planter, parce que si vous ramenez des gens de l'extérieur qui n'ont pas la bonne culture, c'est hyper compliqué pour les équipes, parce que déjà que c'est une frustration quand on recrute en externe. Si en plus, ce n'est pas des gens qui apportent de la valeur, qui les aident et qui les aident à grandir, c'est encore plus frustrant. Moi, il y a un truc aussi qui m'a vachement marquée, c'est qu'au tout début de Content Square, quand on était quatre dans l'équipe produit, on avait besoin de couteaux suisses, on avait besoin de gens qui savaient tout faire. Et maintenant, quand on est 80, on a besoin de gens qui sont assez spécialisés et qui aiment bien rester dans leur périmètre. Et du coup, c'est hyper difficile d'arriver à engager les gens dans la durée.
sur de tels changements, donc moi, je n'ai pas la solution là-dessus. Je pense que ça se gère au cas par cas. En tout cas, c'est un truc auquel il faut faire attention. Vous aurez cette slide. Ça, c'est les rôles qu'on a ajoutés au fur et à mesure dans l'équipe produit. D'abord, pour aider sur le go-to-market. Ensuite, pour aider à maintenir le knowledge. Et ensuite, pour focaliser beaucoup plus sur l'exécution et l'excellence produit. Parce que vous verrez, plus la boîte grandit, plus l'excellence des process devient importante. C'est ce que j'ai dit tout à l'heure, c'est que si vous mettez en place cette excellence trop tôt, vous allez casser complètement l'agilité. Et si vous la mettez en place trop tard, vous risquez d'avoir un joyeux bazar à cliner. Et bien sûr, ça veut dire qu'aujourd'hui, ça ressemble à ça, une product line chez Content Square. Donc, les petits carrés, ça représente les product unit, c'est vraiment les équipes produits. Et ensuite, la product line, c'est la structure autour du produit. Vous voyez, ça fait un monde de fou. Et donc, du coup, il faut faire attention au syndrome de « too many cooks in the kitchen ». Et bien s'assurer que vous continuez à prendre des décisions, que vous continuez à avancer. Je ne sais pas si vous avez déjà vu ce visuel de… Il y a un gars qui rame dans une barque et il y a huit personnes qui l'encouragent. C'est exactement ce qu'il faut essayer d'éviter quand vous mettez en place ce genre de choses. Ça, c'est le rhino. C'est notre animal mascotte chez Content Square. Et en fait, quand on a commencé à mettre en place tous ces changements, on a appelé ça la rhino méthodologie. Parce que moi, j'ai trouvé que c'est hyper important de brinder le changement et de créer une dynamique un peu fun autour de tous ces trucs-là. Et l'autre truc, c'est qu'il y avait beaucoup de gens qui étaient réfractaires à appliquer une méthode telle qu'elle a été décrite dans un bouquin, en disant, nous, on n'est pas une boîte californienne, on ne travaille pas de la même manière. Ce qui est applicable à Google, Facebook, ce n'est pas applicable à toutes les boîtes. Et donc, on a vraiment fait ce travail-là de s'inspirer de ce qui se fait ailleurs, mais de l'écrire dans notre propre rhino méthodologie. Et ça, c'est 16 months, c'est le temps de gestation d'un bébé rhino dans un rhino. Et c'est aussi le temps que ça prend de changer une organisation. Et là, vous allez me dire, même c'est bizarre ce que tu dis qu'il faut tout changer tous les six mois, mais ça prend 16 mois de tout changer, mais c'est pour ça que c'est marrant. Tout ça, c'est les gens qui travaillent en permanence sur améliorer la rhino méthodologie, donc pour faire comme un produit, ce que je vous disais au début, pour faire évoluer le truc en permanence. Et puis, voilà, are you ready for the ride of your life ? Vous voyez, on essaye de faire des trucs un peu sympas comme ça. Et je pense que le plus important, c'est de ne pas oublier le fun. Nous, c'est hyper important dans notre culture chez Compton Square. On se retrouve hyper souvent pour faire la fête ensemble parce que quand on met autant de stress sur l'organisation à avancer très, très vite, à tout changer comme ça, c'est dix fois plus facile de le faire si on a bien rigolé la veille avec notre voisin. Donc, ça fait vraiment partie de notre culture d'avoir des soirées déguisées, de réunir. Ça, c'est toute la product house. Là, on est 400. Et c'était ce qu'on était au dernier kick-off avant le Covid. Et au prochain kick-off de février, on sera 1500. Voilà. Merci. Merci beaucoup, Lucie, pour ce partage d'expérience avec beaucoup d'énergie. Donc, j'ai apprécié. Donc, j'imagine que la salle aussi. Est-ce que vous avez... Bon, on a dépassé un peu, mais est-ce que vous avez... On a peut-être le temps pour quelques questions quand même. Avez-vous quelques questions pour Lucie ? Tiens, je vais lancer le truc. Moi, j'en ai noté une. Tu as parlé pas mal de recrutement, comme vous allez beaucoup grossir, etc. Vous êtes dans plusieurs pays. J'allais dire, première question, c'est comment est-ce que tu fais pour gérer, parce que tu as dit que c'est beaucoup d'humains, le fait que tu as des gens dans ton équipe produit qui sont français, US, Italiens, Espagne, Allemagne. Parce que du coup, factuellement, c'est des cultures différentes, des méthodes de fonctionner différentes, etc. Comment est-ce que toi, tu fais en sorte que tout soit à peu près homogène et fais en sorte que tout roule bien ? C'est une super question. Et je dirais même que c'est la principale raison pour laquelle je suis chez Content Square huit ans et demi plus tard. C'est parce que ça amène énormément de richesse dans les échanges. Je pense que quand on est tous pareils, peut-être on a l'impression que les choses vont plus vite parce qu'on réfléchit tous pareil. Mais en fait, quand on commence à avoir beaucoup plus de diversité dans les équipes, on se rend compte qu'on apprend énormément, qu'on change notre manière de faire. C'est des exemples tout bêtes, mais par exemple, pour un Américain, arriver cinq minutes en retard à un meeting, c'est hyper irrespectueux. Alors que pour un Français, c'est juste normal. Et donc, en fait, c'est apprendre ce genre de choses, les Américains. Ils vont toujours vous dire que c'est amazing. Et après, trois fois, la quatrième phrase, ce sera le vrai feedback qu'il faut écouter. Alors que nous, on est hyper direct. On va dire tout de suite ce qu'on pense. Et un Américain, il va très, très mal recevoir un feedback de Français parce qu'il va se dire, il est hyper impoli, c'est horrible. Et à l'inverse, un Français, il ne va pas entendre le feedback d'un Américain parce qu'une fois qu'on lui a dit que c'était trop amazing, il a arrêté d'écouter. Donc, c'est plein de petites choses comme ça qu'il faut apprendre des autres et créer un environnement de travail dans lequel tout le monde peut s'épanouir. Et ça aussi, ça pose des problèmes parce qu'il y a des blagues qu'on ne peut plus faire. Et il y a des gens pour qui c'est vraiment une frustration aujourd'hui de devoir faire plus attention à ce qu'ils disent, de ne plus pouvoir faire certaines blagues. Mais à la côté de ça, créer un environnement inclusif où différentes cultures peuvent se sentir bien, ça apporte tellement de richesse à la boîte qu'on est prêt à faire ce sacrifice-là. J'ai une question, merci beaucoup déjà pour cette présentation qui est super inspirante. J'ai une question autour de la… Tu as parlé de la product knowledge, c'était un vrai sujet. Dans ma propre expérience, on a un gros sujet de la product knowledge notamment vis-à-vis des sales et des CSM. Comment est-ce que vous la gérez en termes vraiment opérationnels parce qu'en fait, on multiplie les supports, les académies, les formations, les workshops. Et au bout d'un moment, on ne sait plus par quel bout attraper le sujet. Déjà, nous, assez tôt, on a mis en place des fonctions Sales Enablement et Customer Success Enablement. Le product marketing travaille les pitchs, travaille la proposition de valeur et il y a des équipes qui font partie des équipes Sales et Customer Success qui sont vraiment là pour trainer les sales et le customer success avec des systèmes de certification pour s'assurer que les gens ont écouté, suivi, compris, etc. Donc, je pense qu'en fait, nous, sans la certification, ça ne marchait pas. Donc, il y a un peu ce côté coercitif. Et ensuite, c'est marrant parce que moi, j'ai l'impression qu'on est méga nuls sur ces sujets de communication. Et un truc dont on a beaucoup discuté sur les dernières semaines, c'est qu'on a tendance à essayer de rajouter des process sur des process et des meetings sur des meetings. Et en fait, les sales de Customer Success, nos clients, ils ont déjà 300 000 meetings qu'ils ne savent pas comment gérer. Et si nous, on essaye d'ajouter un meeting produit en plus pour parler du produit, en fait, ils ne sont pas disponibles, leur temps d'écoute n'est pas bon. Et donc, en fait, ce qu'on va essayer de faire maintenant, c'est de mieux comprendre le calendrier et les routines de chacune des équipes et s'insérer à l'intérieur de leur meeting d'équipe pour ne pas leur prendre du temps en plus. Et pareil avec les clients. Une des raisons pour lesquelles on n'arrive pas à faire un meeting par semaine, c'est parce que le Customer Success a un peu tendance à bloquer. Alors qu'en fait, le Customer Success, ils font un QBR par quarter avec les clients. Ils ont au moins deux meetings pour faire d'autres trucs. Et si nous, on arrive à venir à ces meetings juste écouter, en fait, on apprend déjà trop de trucs. Donc, moi, je vous donnerais ce conseil-là. Nous, on est au début d'essayer de faire ça, mais au lieu de créer des routines nouvelles pour parler du produit, essayez de vous insérer dans les routines des équipes. Merci beaucoup pour ta présentation. Je vais aussi parler de collaboration Sales et Customer Success. On est en train d'essayer de le développer, de l'accélérer et on met en place le Rhinoprocess. Généralement, on utilise le Rhinoprocess pour les engager et accélérer le passage d'une étape à une autre. Est-ce que tu as des tips pour les engager ? Tu veux dire pour les engager sur une méthodologie comme la méthodologie de produit ? Oui, et puis les engager sur chacune des étapes pour aller chercher les customers en bêta, passer à l'étape d'après. Moi, j'ai l'impression que les Sales, ils vont t'aider s'ils sentent que toi, tu vas pouvoir les aider. Donc, tu vois, c'est ce que je disais tout à l'heure, si dans un meeting avec… quand le Sales, il fait un meeting avec toi, il apprend trois trucs ou que quand tu reviens d'un meeting client, le client est trop content, eh bien, il va te créer le meeting d'après. Donc, je pense que les organisations Sales, ce sont des organisations qui sont hyper pragmatiques et si tu leur apportes de la valeur, eux, après, ils te rendront service. Donc, je pense qu'il faut vraiment réfléchir à ça, c'est comment est-ce qu'on les aide et comment tu leur… tu vois, s'ils sont en galère sur un deal, tu vas leur faire une présentation au roadmap et tu les aides à gagner le deal, eh bien, ils vont t'ouvrir toutes les portes du monde. Donc, vraiment s'inscrire dans une relation de partenaire et d'essayer de les aider le plus possible. Mais encore une fois, il n'y a pas de recette miracle. Je pense qu'on en parlait tout à l'heure avec le patron des Sales Europe et je disais, en fait, tant que nos équipes, elles ne se connaissent pas, elles ne cèdent pas. Genre, moi, quand t'appelles un de mes product managers…
à minuit pour lui dire qu'il était en galère sur un truc, il ne te répond pas parce qu'il ne te connaît pas. Mais par contre, si tu as déjà bossé sur un deal ensemble, tu as déjà créé de la valeur ensemble, peut-être que là, tu as beaucoup plus de chances qu'il ne te répond. Donc, je pense que ça reste de l'humain tout ça. Bonjour, merci pour la présentation. C'était très intéressant. Et moi, j'avais une question sur les différents profils dont tu as parlé qui s'ajoutent finalement autour de l'équipe produit, donc programme manager, user research. Alors, je ne les ai pas tous en tête. Et j'aurais aimé que tu détailles un peu à quelle étape du scale de l'entreprise vous avez fait intervenir ces produits. Peut-être que ça va être un peu trop précis, je ne sais pas comme question. Non, je vais te répondre assez high level et suivant pour en reparler après. Mais en gros, ça, c'est un peu la chronologie dans laquelle c'est arrivé. On a d'abord eu des équipes pour assurer plus de collaboration avec le sales et le customer success. Donc, c'est les équipes go to market, product knowledge, product marketing. Ensuite, on s'est rendu compte qu'avec des organisations sales et customer success de plus en plus grosses, nous, on était de plus en plus loin des clients. Donc, il a fallu renforcer plutôt les gens qui t'aident à maintenir du knowledge sur ton marché, tes clients, etc. Et enfin, à une étape un peu plus grande où tu te rends compte que l'exécution devient de plus en plus importante et de plus en plus contraignante, on a rajouté Product Ops et Programme Manager. En termes de taille ? En termes de taille, franchement, product knowledge, product marketing, on a eu quasiment au tout début. Donc, je dirais, quand on était, ça devait être notre embauche 5 et 6 dans la team. Product Stratégie, UX Research, c'est venu il y a 3-4 ans. Product Analyse, 7 années. Et Product Ops, Product Manager, ça a commencé l'année dernière. Et je crois que c'est la dernière question. Merci beaucoup, c'était hyper intéressant. J'ai bien compris que ton travail maintenant, c'était plus de mettre en place les équipes produits, les process, etc. Est-ce qu'il y a encore des éléments sur lesquels tu ne transitions pas ? Tu veux vraiment avoir ton mot à dire ? La vision, ça se met à jour, j'imagine. Enfin voilà, c'est quoi vraiment les choses que tu ne veux pas lâcher ? C'est hyper important pour toi. J'essaye de ne plus du tout intervenir sur la partie fonctionnalité, mock-up, etc. Parce qu'en fait, sinon j'ai 36 000 feedbacks et ça fout le bordel. Donc ça, j'essaye de ne pas du tout faire. Et même quand ils essayent de me solliciter dessus, j'essaye de ne pas répondre à ces sollicitations-là. Je sais qu'il y a plein de CPU qui ont une approche complètement différente, de dire, moi je veux rester au contact, je veux pouvoir continuer à donner mon avis sur ce truc-là. Je pense que ça dépend vraiment. Mais moi, j'ai tendance à, si on ne fait pas ce que j'avais envie qu'on fasse, après ça m'énerve. Donc je me tiens à l'écart de ce truc-là. Et par contre, je travaille beaucoup, beaucoup sur la vision et la stratégie. Ça, je considère que ça reste 100% mon taf. À la fois, la maintenir à jour, s'assurer que tous les stakeholders sont alignés, la présenter le plus souvent possible et la rediffuser dans les équipes. Tu vois, on vient juste d'avoir notre survey d'engagement et l'équipe produit, c'est l'équipe qui a l'impression de moins bien comprendre la stratégie de la boîte, de toute la boîte. Et du coup, parfois, c'est un peu désespérant. C'est-à-dire que j'ai l'impression de passer toute ma vie à faire ça. Mais aussi, je pense que nos équipes, c'est celles qui en ont le plus besoin. Donc peut-être qu'elles sont à un niveau, enfin moi, je me rassure en disant ça, peut-être qu'elles sont à un niveau un peu meilleur, mais qu'elles ont besoin d'encore plus, tu vois. Mais en tout cas, tout ça pour dire que je pense que plus la boîte agrandit, plus le rôle, c'est de définir et maintenir le cap et pour s'assurer que tout le monde part dans la même direction. Parce qu'après, si les gens prennent un peu des chemins de traverse, mais qu'ils ont tous la même North Star, ils vont se retrouver et ça va créer de la valeur. Alors que s'ils essayent, s'ils partent dans des directions qui sont opposées, là, ça ne va pas du tout créer de valeur et ça va écarteler l'organisation. Et on a pas mal parlé d'organisation, création de nouveaux rôles. Et je crois que tu as montré une slide qui montrait les gens qui avaient travaillé sur ces évolutions. C'est quel type de profil ? Est-ce que c'est une équipe mixte, product, engineering ? C'est qui chez vous qui réfléchit à ces évolutions ? Alors, c'est énormément les programmes managers. Et ensuite, c'est des représentants de la tech, du produit et du design. Je pense, là, tu vois, sur ce slide, il y a... Ah, et du coup, tu as Customer Success Ops et Sales Ops aussi, qui font partie de ce truc-là. Justement, pour qu'ils comprennent bien comment on travaille et qu'on puisse mieux fonctionner ensemble. Avec le Customer Success, on a un programme qui s'appelle Ride the Rhino Together, pour mieux apprendre à travailler ensemble et voir... Parce qu'en fait, si le Customer Success continue à te dire « je veux un bouton bleu », alors que toi, tu dis à tes équipes « on n'en réfléchit plus en termes de bouton bleu, on réfléchit en termes de visibilité du bouton », eh bien, tu vois, tu as une trop grande déconnexion. Donc, c'est hyper important d'évangéliser tous ces trucs-là auprès des équipes Customer Success et Sales. Lucie, j'ai une dernière question parce que personne ne l'a posée. Tu coaches pas mal de PM, ton métier, c'est de coacher les gens, mais qui te coache ? Qui me coache ? Eh bien, déjà John. Je pense que John, notre CEO, c'est quelqu'un... Enfin, je ne sais pas s'il me coache, en tout cas, il m'inspire. C'est quelqu'un qui a une énergie débordante. Moi, je pensais que c'était quelqu'un qui avait beaucoup d'énergie. Ensuite, j'ai rencontré John, je me suis rendu compte que je n'avais pas autant d'énergie que ça. Le fait qu'il ait une vision si grande, ça aide vachement. Et après, nous, on est une boîte qui n'avait pas une culture produit au départ, qui avait plutôt une culture sales, et donc c'est plutôt moi qui ai amené la culture produit chez Content Square. Et donc, je suis allée vachement la chercher à l'extérieur. Je vous ai parlé de Marty Kagan plein de fois, c'est un peu ma Bible. Parfois un peu trop, on dirait que c'est un gourou, mais ça a été hyper important. J'ai fait deux fois des coachings avec lui. Je trouve que ça apporte aussi énormément par rapport à lire les bouquins parce qu'il partage énormément d'expériences qu'il a vécues avec les équipes. Donc, ça rend les choses beaucoup plus concrètes. Et ensuite, j'ai essayé d'appliquer ce que je vous disais, c'était de ramener aussi plein de gens de l'extérieur et de recruter des gens qui sont dix fois meilleurs que moi. Et je pense que ça, c'est vraiment la clé pour grandir dans une entreprise. Il ne faut pas avoir peur de recruter des gens qui ont beaucoup plus d'expertise que vous et qui, du coup, vont vous pousser vers le haut. Parce qu'en fait, quand la boîte agrandit, si vous n'avez pas un effet, je ne sais pas trop comment dire, mais un effet de l'équipe qui vous porte vers le haut, vous n'allez pas réussir à grandir aussi vite que la boîte. Donc, voilà. Par exemple, en ce moment, on est en train de recruter un SVP product qui va être le patron de tous les product directors. Et je suis à la recherche de quelqu'un qui a beaucoup plus d'expérience produit que moi. Et je pense que c'est hyper important de ne pas se sentir menacé par ce genre de profil. Au contraire, de voir à quel point ça va être enrichissant. Et moi, j'ai justement la vision, la stratégie à apporter. Voilà. Super. Merci beaucoup, Lucie, pour ce meet-up.