Bienvenue et merci. On est super fier parce que c'est la deuxième édition de ce reboot de French Produit avant que ça s'appelle French Produit. On avait commencé ça avant le confinement, le tout premier confinement. On avait fait une session, on avait planifié une deuxième session. Emmanuel Macron avait décidé d'annuler ça et du coup on a relancé ça grâce à Sébastien qui a pu me rejoindre parce que tout seul je ne pouvais pas le faire, ce n'était plus possible. Et on a fait une première session il y a deux mois, je ne sais plus, en novembre. Voilà, trois mois, quatre mois et qui était déjà un succès puisqu'on avait une trentaine de personnes, mais c'était dans un bar donc ça ne compte pas trop, ça trousse un peu. Et là c'est la première vraie session et en plus ça fait super plaisir d'être dans ces super locaux. Je te passe la main aussi parce que je ne suis pas chez moi. On était en faisant ce meetup avec François et puis après avec Johan, on se dit on fixe à combien ? Normalement c'est notre salle où on travaille donc normalement il y a des bureaux, c'est un peu un setup particulier, on s'est dit aller à 40 donc on est super content de voir qu'à 40 ça passe et super content de voir que vous êtes vachement nombreux donc merci et bienvenue chez vous dans les locaux de 5 degrés Sud. On est obligé de commencer par une partie un peu obligatoire pour utiliser cet adjectif là. Donc c'est tout simplement la présentation rapide de qu'est-ce que c'est que French Produit ? Donc French Produit c'est un mouvement, c'est une association qui est nationale. Donc avant comme disait François ça s'appelait la ProduConf et donc c'est devenu French Produit pour être à organisationnel et donc c'est l'association qui fédère la communauté des produits en France, donc vraiment tous les métiers du produit. Et qu'est-ce que c'est qu'aujourd'hui LPC ? Donc c'est un Slack French Produit qui avant s'appelait LPC Expedition donc si vous n'êtes pas sur le Slack n'hésitez pas à le rejoindre. Des chapters régionaux donc comme celui-ci du sud-ouest et particulièrement aujourd'hui Toulouse. Donc avec c'est des meetups, c'est de l'entraide et des partages successifs. Il y a des initiatives de la communauté, je pourrais pas trop vous en parler mais a priori il y a une ligue Mon Petit Gazon, je suis pas joueur de Mon Petit Gazon mais si jamais vous aimez le produit et Mon Petit Gazon, vous êtes au bon endroit. Des ressources donc des replays donc c'est pour ça qu'il y a un petit setup sympa donc c'est pour pouvoir le repasser en replay, des podcasts, des digestes et vraiment toute la communauté et la communauté FrenchIPO. Les valeurs cœur c'est que c'est gratuit pour tous, sauf pour ceux qui accueillent mais non mais c'est bon bref. Je me suis dit dans quoi je me suis emmarqué. Entre pairs donc entre membres, entre pairs PO, PM et designers et tous les métiers du produit et sans prosélytisme. J'espère que tout le monde sait ce que ça veut dire. Le Slack French Produits donc là c'est le QR code pour le rejoindre et si jamais vous avez des questions un peu plus sur le Slack, n'hésitez pas. Donc sur French Produits vous pouvez vous inscrire et puis après il y a une validation qui est faite par des membres de French Produits qui après vous avez plein de canaux sur le Slack dont le canal Chapteur Sud-Ouest où il y a toutes les personnes qui bossent dans le Sud-Ouest dans le produit. Et j'insiste sur ce point, si vraiment vous ne connaissez pas French Produits, ce Slack, il faut vraiment y aller si vous travaillez dans le produit parce que c'est vraiment la communauté numéro un en France et si vous avez des problèmes c'est sûr que vous allez trouver des gens qui ont déjà eu ces problèmes et qui pourront en plus avoir la motivation de vous aider à les résoudre. Et donc c'est partout en France. Donc on va surtout parler du Chapteur Sud-Ouest parce que c'est le seul qui nous intéresse mais il y en a partout en France. Et c'est vrai que dans ce cadre là, ici on est en fait avec Sébastien, on co-organise la partie Toulouse mais plus généralement Sud-Ouest. Donc on est en train de réfléchir aussi à comment monter des choses avec Bordeaux. Et si j'aurais peut-être pas dû dire ça là. L'équipe French Produits Sud-Ouest Toulouse, elle est là devant vous. Donc c'est deux personnes. Donc François Scipio chez Pictarine qui va nous en plus faire l'honneur de nous pitcher tout à l'heure. Et donc moi-même Sébastien Ambaud, Practice Leader Product Management chez 5° Sud. Donc l'occasion de vous parler de ce qu'est 5° Sud rapidement. Et après donc vous, aujourd'hui on est deux donc on pourrait être un peu plus. Donc si jamais ça vous intéresse de venir nous aider à monter ces meetups et à faire vivre la communauté Produits à Toulouse et bien n'hésitez pas à nous en parler à la fin. La partie obligatoire, donc les sponsors. Donc merci à HubVisory qui est un sponsor national. Sendinblue, deuxième sponsor national. Exalt, troisième sponsor national. Assurez-vous qu'il n'y en a pas 50. Et notre sponsor local pour le Sud-Ouest qui est BetClik. Donc voilà, ils soutiennent l'association, ça permet des fonds, ça permet de financer une partie des meetups, une partie des matos. Donc c'est grâce à eux qu'on peut faire aussi ces meetups. Le moment aussi obligatoire mais qui est important aussi, c'est de... Merci à notre hôte du soir, donc merci à 5° Sud. Donc merci moi-même et surtout merci Joanne qui nous a fait confiance, qui est responsable de 5° Sud, de nous accueillir dans les locaux et de me faire confiance pour hoster cet événement-là. Je vais vous parler quand même rapidement de ce que c'est, de ce qu'est 5° Sud et après on parlera vraiment des conférences. Donc c'est deux agences 5° Sud, donc Bordeaux et Toulouse. Donc Toulouse étant la première et qui a un an d'existence à peu près. C'est une cinquantaine de collaborateurs. Les valeurs de 5° Sud, c'est autour de trois. Donc l'adupérabilité, le fait d'avoir des relations durables à la fois avec les collaborateurs et entre membres de 5° Sud et avec nos clients. Oui parce que 5° Sud, pardon, c'est une agence de conseil en product management, on va commencer par le début. Donc notre métier c'est de conseiller sur les métiers du produit. Et les métiers du produit, pour nous, c'est cinq pratiques, donc c'est cinq pôles de compétences. Donc le product management que j'anime, le product design qu'anime Romain qui est dans la salle, le product development, product quality et product data. Et donc la vision de 5° Sud et 5° totalement, c'est la théorie produit une chose, l'implanter et la faire vivre en est une autre et c'est tout le challenge que nous sommes fixés. C'est vraiment être dépassionné du produit en même temps dans le terre-à-terre avec ce que vivent comme challenges aux clients. Co-construction, performance, j'en ai fini pour 5° Sud. C'est là où je relève ma casquette d'organisateur ce soir. J'ai le plaisir d'animer avec Cécile. Donc on a deux sujets, tout simplement. Ce sont des retours d'expérience autour du produit. On prévoit à peu près une heure de répartie en deux parties tout simplement. Et puis après questions réponses et apéro pour ceux qui ont raté la première partie. Bien, donc j'ai le plaisir de commencer en vous parlant de la culture produit qu'on a chez Pictarine. Alors d'abord moi j'aime bien poser une petite question parce qu'on n'est pas très connu encore dans le coin chez Pictarine. Est-ce que ceux qui ont déjà entendu parler de Pictarine peuvent lever la main ? Ah la vache ! C'est vraiment sincère là ? C'est chouette. Bon on se donne du mal pour se faire connaître donc ça fait plaisir que ça commence à porter ses fruits. C'est cool. Un petit mot sur qui on est. Justement histoire de poser un petit peu les choses, ça permettra d'éclairer un peu la suite de cette histoire de culture. Pour faire très bref, chez Pictarine on crée des applis iOS, Android et web qui permettent d'imprimer des photos. Alors notre truc c'est tout simplement vous passez commande en seulement 30 secondes dans l'application et vous choisissez typiquement les supports sur lesquels vous voulez imprimer vos photos. Donc ça va des tirages photos classiques à des magnets, des cartes de vœux, des posters, des toiles, etc. Et la magie c'est que 20 minutes plus tard vous allez chercher les produits photo imprimés dans le supermarché du coin. C'est là où il y a un truc qui est assez, on n'arrive toujours pas à s'y faire, c'est qu'en fait notre business il tourne exclusivement aux Etats-Unis parce que on a un partenariat avec les trois grandes chaînes de supermarché là-bas que sont Walgreens, CVS et Walmart et ça nous permet en fait d'être présent auprès de 20 000 points de vente sur tout le territoire américain. Et le truc qui est assez chouette, assez fou, c'est qu'on fait tout ça depuis la Belgique, à côté de Toulon. Quelques chiffres pour être très concret, Pictarine en fait c'est 372 millions de photos qui ont été imprimées et payées par nos clients, donc depuis le début. C'est également en moyenne sur l'année qui vient de s'écouler, c'est en moyenne 4,5 millions de dollars commandés chaque mois. Et côté App Store et Play Store, ça présente 18 millions de téléchargements et 4,9 sur 5 de rating. Un petit mot aussi pour donner un peu de contexte, on fait un petit zoom sur l'équipe produit chez Pictarine. Aujourd'hui chez Pictarine on est 40. On va dire que depuis toujours l'équipe produit c'est à peu près la moitié de la boîte parce que ça correspond à peu près à la place que ça prend dans l'ADN. Donc aujourd'hui on est 20. Et c'est important de dire un petit mot sur l'équipe produit parce qu'on a une configuration qui n'est pas forcément habituelle, c'est-à-dire que l'équipe produit chez Pictarine c'est d'abord les développeurs.
avec l'élite développeur donc qui constitue ce qu'on appelle le pôle engineering mais c'est également le pôle design avec les designers qu'on va trouver côté UI, UX également dans ce qu'on appelle le creative design chez nous et on a aussi au sein du pôle design les users et searchers et enfin on a le pôle product managers parce que depuis peu on peut appeler ça un pôle parce que alors on a Quentin qui est debout là bas qui est notre PM depuis quelques années maintenant et Flore qui lève la main vient de nous rejoindre en tant que PM et donc on a le droit d'appeler ça un pôle product managers donc voilà, voilà à quoi ressemble l'équipe produit et c'est pour ça, si je devais résumer un point vraiment important dans ce que je viens de dire c'est le côté, c'est à la fois les devs et les designers et tout ce que je vais dire dans la suite est vrai pour tout ce monde là Donc on commence la partie, notre culture produit je vais commencer par une phrase en très bref qui pour l'instant va être très en phase on ne va pas trouver du pictarine très spécifique c'est du très classique dans la culture produit en France et même à l'international en très bref, notre culture produit c'est identifier et résoudre des problèmes qui impactent le business et on fait ça en procédant par itération on met des hypothèses, on lance des expérimentations et on tire les mesures et on recommence la partie qui est cruciale là dedans c'est le impactant le business pourquoi ? Parce que par exemple, même chez Pictarine, on est fan de UX, on est fan de produit on veut vraiment que les clients vivent une expérience hors du commun mais du coup si on se concentre que là dessus, ça ne sera pas forcément au service du business c'est là qu'il y a une complexité à prendre en compte, on est là, on crée une entreprise donc toute la difficulté est là, comment on crée cette expérience, comment on met les clients ensemble tout en créant une entreprise qui grandit en particulier, ce que je viens de dire finalement, c'est la définition de faire du produit ça s'oppose à quelque chose, il y a plein de boîtes qui fonctionnent comme ça ou en particulier, chez nous, ce qu'on ne fait pas, c'est livrer des fonctionnalités prédéterminées à des dates prédéterminées dans la communauté produit, on appelle ça tout simplement du projet donc ça s'oppose au produit, ce n'est pas ce qu'on fait donc il n'y a rien de péjoratif là-dedans, c'est juste un mode de fonctionnement qui est très différent et en fait, ce travail de produit de manière très classique comme on le trouve dans la culture produit en France il est découpé en deux phases la première phase, c'est celle de discovery et elle consiste à comprendre le problème qu'on veut adresser et pour qui on veut l'adresser mais également découvrir la solution qu'on veut y apporter et là-dessus, et on commence à avoir la petite touche pictarine c'est qu'on le fait grâce à des expérimentations rapides et extrêmes alors je reviendrai sur ce mot rapide et ce mot extrême dans un instant et le point qui est très très important c'est que cette phase de discovery, elle s'achève lorsqu'on est capable d'estimer l'impact business de cette solution qu'on veut mettre en oeuvre et à ce moment-là, une fois qu'on est capable, on part dans la phase de delivery qui consiste à implémenter cette solution et on va le faire en adaptant les moyens qu'on met à disposition mais également le niveau de qualité alors pourquoi tout ça ? tout simplement, en fait, chez Pictarine, on n'aime pas perdre du temps, on n'aime pas bosser pour rien et donc, prenons un exemple très simple on a une super idée d'une super fonctionnalité grâce à plusieurs itérations de discovery, on s'aperçoit qu'on peut impacter 0,1% du chiffre d'affaires en tant que CPO, je vais dire, ben non, on ne le fait pas ou alors, allez, ça a l'air important pour la vision produit, il y a quand même quelque chose de symbolique derrière, on va donner 2 heures par exemple mais si par contre, on parle d'impacter 30% du chiffre d'affaires bien sûr, ça n'arrive pas tous les jours alors là, moi, je suis prêt à donner plusieurs mois, il n'y a pas de problème, il y a plusieurs personnes qui vont travailler là-dessus donc c'est cette idée de tout simplement ne pas bosser pour rien si au final, l'impact business n'a pas lieu on revient sur cette importance-là et donc, pour ce faire, on a formalisé, ça a l'air de rien, 12 principes et on a mis un temps fou pour les formaliser et du coup, on prend beaucoup de plaisir à les partager parce qu'on a beaucoup bossé dessus et que ça rentre vraiment dans l'ADN de Pictarine ces 12 principes, ils sont répartis en 3 catégories on a 4 principes pour la discovery 4 principes pour la delivery et 4 principes communs aux deux donc, on commence côté discovery, on a un mot d'ordre qui est radicalité alors, je ne vous cache pas qu'à chaque fois que je dis ce mot-là en dehors de chez Pictarine avec les actualités, j'ai toujours un petit peu peur mais, l'idée c'est quoi ? c'est que lorsqu'on est en phase de discovery notre unique but, c'est de trouver des indices sur le comportement de nos clients et de faire ça de la manière la plus radicale possible alors, qu'est-ce que ça veut dire radical ? les 4 principes sont les suivants le premier, c'est je fais au plus extrême en gros, on cherche l'impact on ne cherche pas la micro-optimisation un exemple très simple on ne va pas juste changer la couleur d'un bouton et voir ce qu'il se passe en prod ce qu'on va plutôt faire, c'est ajouter un écran en plein milieu du flow le truc qui fait chier vous savez, ces écrans qui rajoutent tu es en train de passer une commande et on te dit et pourquoi tu ne rajouterais pas ça dans ton panier ? ça n'a l'air de rien, mais ce truc-là peut casser la conversion en deux c'est ça qu'on cherche si on a une expérimentation qui impacte à seulement 3% le flow là, on ne va rien apprendre sur le comportement de nos clients on préfère casser la prod quitte, par exemple, en cassant la conversion le passage de commande en deux pendant quelques heures parce que bien sûr, on va perdre un petit peu d'argent à ce moment-là mais on estime que la boîte y perd davantage quand on n'apprend pas d'indice sur le comportement de nos clients en fait, on est assez proche, pour ceux qui connaissent un peu ça c'était un des mantras de Facebook à leur début c'était cette idée que moi je répète très souvent à mes développeurs si on ne casse pas la prod c'est qu'on n'est pas assez radical on prend trop soin de la prod et du coup, on n'apprend pas assez d'indice sur le comportement de nos clients le deuxième principe je prends des raccourcis un exemple on a une idée de super app je vais vous donner un exemple concret qu'on a vécu il y a quelques semaines on a signé un partenariat avec Ravensburger c'est génial et du coup, on veut lancer une app qui permet aux gens d'imprimer des puzzles Ravensburger avec leurs photos dessus en vrai, qu'est-ce qu'on pourrait faire ? on pourrait développer l'app lancer des campagnes marketing, etc. et voir ce qu'il se passe sauf que ça, ça prend du temps chez Pictarine, on est super rapide à coder mais là, ça prendrait facilement ça se compterait en semaines en fait, qu'est-ce qu'on peut faire ? on met une pub sur Facebook qui fait la pub de l'app alors on se donne un peu de mal au moins deux heures sur le design, le texte et on regarde si les gens cliquent dessus parce que si personne ne clique sur cette pub on a bien fait de ne pas coder l'appli dans le même esprit un autre exemple concret qu'on a vécu il y a pas longtemps on voulait savoir si les gens sont intéressés par la réalité augmentée pour voir les posters qu'ils s'apprêtent à commander sur le mur de leur salon alors la réalité augmentée, chez Pictarine, on ne connait pas trop on n'a pas trop codé de ça donc on sait que si on se lance là-dedans ça va être du boulot et en plus, on sait très bien ce qui va se passer au bout de trois semaines, un mois on arrivera à un truc qui est à peu près correct mais qui, à cause de plein de contraintes côté Apple et côté Google ne marchera pas de ouf d'un point de vue d'exécution qu'est-ce qu'on fait ? on rajoute un bouton voir mon poster dans mon salon et quand les gens ont réalité augmentée et quand les gens cliquent en fait, ils arrivent sur un écran qui dit juste bon, c'est pour bientôt en fait mais dis-nous si t'es intéressé alors c'est frustrant pour la personne mais en vrai, qu'est-ce qui se passe ? on va compter le nombre de gens qui ont cliqué sur ce bouton et on y revient s'il y a 3% des gens qui ont cliqué on a bien fait de ne pas coder tout ça par contre, et c'est ce qui s'est passé on a eu 30% de gens intéressés par ce truc-là donc là, on sait qu'on peut investir des choses dessus on a des indices voilà l'idée troisième principe c'est un de mes préférés je me donne l'autorisation pourquoi c'est un de mes préférés ? parce qu'absolument tout le monde qui arrive chez Pictarine il lui faut un temps fou pour y arriver l'histoire c'est quoi ? c'est... ben voilà, je suis développeur et je dois coder une fonctionnalité et ben je vais décider maintenant de la faire et je vais la faire maintenant je ne vais pas attendre la validation du manager là je vois sourire quelques visages, ça parle je ne vais pas non plus attendre 3% de data en plus pire je ne vais pas attendre la prochaine réunion on va décider tous ensemble on préfère cette idée de dire les gens, ils ont les infos dont ils ont besoin ils ont les compétences dont ils ont besoin ils prennent leurs décisions ils font les expérimentations qu'ils ont envie de tester et enfin je décide en gros, pardon j'implique le moins de personnes alors celui-là ça veut dire quoi ? c'est l'idée de dire je décide et je fais tout seul les collègues sont là pour m'aider et me soutenir
Alors, ça nécessite que j'explique un truc qui est assez important, c'est que chez nous, chez Pictarine, les développeurs, ils font le design UX de leurs features. Alors attention, on ne dit pas qu'il y a un besoin de compétences UX de folie, mais en fait, pour faire ces expérimentations qu'on a en Discovery, les développeurs chez nous, on dit qu'ils sont des développeurs produits, ça n'empêche pas qu'ils soient très bons côté tech, ils font le design UX de leurs features. Et je vais même être encore plus agressif, la plupart savent faire du design UI minimal. Ça veut dire quoi ? Ça veut dire que quand on veut faire ces expérimentations en Discovery, eh bien, on a tout simplement un développeur à la capacité de faire une expérimentation tout seul, de l'idée jusqu'à la mise en preuve. Alors attention, ça ne veut pas dire que c'est le cas tout le temps. Il y a des expérimentations, on a besoin de designers, sinon le test va être biaisé parce que la qualité va nuire à la pertinence du test. Donc dans ces cas-là, c'est pour ça qu'on dit « je n'implique », on ne dit pas « j'implique personne », on dit « j'implique le moins de personnes », on se pose la question. Il y a des moments où on va se dire « non mais là, il y a besoin d'un designer pour ça, il y a besoin de telles compétences pour ça, sinon le test ne vaudra rien en fait niveau fiabilité. » Donc ça, c'était côté Discovery. Côté Delivery, on a un mot d'ordre qui est « pragmatisme ». Donc là, on le devine un peu, on va un peu à l'opposé finalement. L'idée c'est quoi ? On retrouve cette notion de compromis que je disais tout à l'heure. L'idée c'est d'adapter les moyens et le niveau de qualité à l'impact business qu'on a estimé à la fin de cette phase de Discovery. En particulier, ça veut dire quoi ? Que le premier principe de Delivery, c'est « je m'assure qu'avant d'attaquer, je connais l'impact business qu'on a estimé ». Et ça souvent, pareil, quand on nous rejoint, on part en Delivery, on ne se pose pas cette question-là. Et du coup, ça crée des frustrations. Par exemple, ça nécessite de comprendre pas mal de choses côté métrique. Je vais vous donner un exemple très simple. Si par exemple, on se dit qu'on veut lancer quelque chose qui améliore la conversion d'un écran dans le flow. Si on le fait, par exemple, si on a remarqué qu'on augmente de 10% la conversion d'un écran qui est en début de flow, en fait, ça a beaucoup plus d'impact business que si c'est en fin de flow. Pourquoi ? Parce qu'il y a un jeu de multiplication. Donc, c'est un des exemples de petites questions qu'il faut se poser, qu'il faut comprendre pour voir à quel point l'impact, c'est quelque chose qui dit vraiment les choix qu'on fait. Après, on a les choses plus classiques. Si on veut augmenter la découvrabilité d'un produit, par exemple nos magnètes, ça a plus d'impact s'il y a plus de gens qui le découvrent, si le produit est plus cher qu'un autre. C'est aussi simple que ça. Le deuxième principe de Delivery, c'est j'adapte le délai. L'idée, c'est quoi ? C'est qu'on demande à nos développeurs et designers de s'engager sur un délai cohérent en définissant des milestones intermédiaires avec une bonne vitesse. Donc là, on retrouve des choses assez classiques dans le milieu aussi, mais c'est important de se le dire. Si on a estimé que pour cet impact business qu'on veut, on peut se donner 10 jours de travail avec l'équipe qu'on a choisie, eh bien, on va se dire à 3 jours, on estime qu'on aura ça, à 6 jours, on aura ça et à la fin, on aura bien ça. Ça permet tout simplement de détecter les retards, les problèmes, etc. Un de mes préférés aussi, c'est j'adapte la qualité technique. Ça concerne particulièrement les devs passionnés. Donc, moi, avant de passer du côté obscur en tant que CPO, je suis dev à la base. Donc, il y a ce truc où chez Pytarine, on a des devs passionnés, comme je pense dans pas mal de... C'est le cas de pas mal d'entre vous. Et on sait ce que c'est. Un dev passionné, il veut atteindre, il veut viser l'idéal théorique, je cite, propre. Soit parce qu'il l'a lu dans sa formation ou dans un des bouquins de référence du milieu, soit, un truc un peu plus récent, parce que son idole l'a préconisé. C'est ce que j'appelle l'idole. Vous savez, sur Internet, il y a des gens, des gourous d'architecture qui disent comment faire les archives. Et en fait, ces gens-là, s'ils ne se posent pas la question de l'impact business, qu'ils ont envie de faire un truc qui va leur prendre 3 mois, alors que je leur dis qu'on n'a qu'une semaine parce que sinon ça n'a pas de verrouilles, ils sont frustrés. Par contre, s'ils savent comment fonctionne et qu'ils comprennent ce truc-là, c'est magique. D'eux-mêmes, ils vont trouver un compromis. Ils vont se dire, OK, j'ai 10 jours et pas 3 mois, voilà ce que je peux faire. Et la prochaine fois, peut-être que je ferai mieux. N'oublions pas un truc qui est vrai en discovery, mais qui, en vrai, à terme, à long terme pourrait être vrai en delivery aussi, c'est qu'il ne faut pas s'attacher à son code. Si on se donne du mal pour écrire jour et nuit un code qui, au final, est mis à la poubelle, on est frustré. Mais si on sait qu'on vise un impact business, on se pose juste les bonnes questions, on met les efforts au bon moment. Je ne dis pas que c'est facile tout ça. Dernier principe de delivery, c'est j'adapte le niveau de polish. On a fait exprès d'utiliser cette terminologie qui est assez proche dans le monde des designers cette fois. Alors en général, nous, en interne, voilà ce qu'on dit. On dit que pour la plupart du temps, on va plutôt viser un good enough, c'est-à-dire quelque chose de suffisamment bon au niveau qualité, de design, parce qu'en fait, investir plus, le ROI ne serait pas forcément intéressant. Mais il y a des fois, parce qu'on ne veut pas être juste dans ce compromis par rapport à cet impact business, on va aller chercher plutôt le great, c'est-à-dire qu'on va passer du temps en animation, en micro-interaction, et même investir davantage en direction artistique. On y revient, comme tout à l'heure pour la qualité technique avec les devs, si le contrat n'est pas clair avec les designers, ça crée des frustrations. À l'inverse, si le contrat est clair, ils sont super excités à l'idée de de temps en temps aller chercher du great. Donc ça, c'était côté delivery. Côté principe commun, on a un mot d'ordre qui est engagement. Donc le premier principe, c'est je formalise une stratégie. Alors attention, ici, je sais qu'il y a des PM qui sont fans de ce mot stratégie, qui ont des méthodologies derrière et compagnie. Nous, ce n'est pas compliqué. C'est stratégie, c'est d'abord je mets des hypothèses. En faisant ce travail, par exemple en mettant en prod tel test ou telle feature, je m'attends à ça. Et par exemple, on va le formaliser, c'est le deuxième ingrédient important avec des KPIs. Par exemple, je pense qu'en modifiant l'écran de telle façon, je vais augmenter le panier moyen de 10%. Donc le panier moyen chez nous, c'est ce que la personne met dans son panier, donc ce qu'il commande au final. Et derrière, un plan. Alors le plan, c'est quoi ? Ça, c'est mon expérimentation. Peut-être que si mon hypothèse s'est validée, je ferai ça après. C'est juste un coup d'avance, pas plus. On réfléchit à des pistes potentielles, mais ce n'est pas une roadmap, ce n'est pas un backlog, ce sont des idées. Et là, on arrive à un autre point qui est crucial et qui est très important chez Pytarine. Les développeurs font les mesures eux-mêmes. Quand ils ont mis en proche leur dev, qui pour rappel, ils ont designé eux-mêmes côté UX, ce sont les premiers à faire les mesures. Alors c'est quoi les mesures ? C'est des datas quantitatives, avec les fameux logs pour savoir par où ils sont passés, qu'est-ce qu'ils ont cliqué, etc. Mais c'est également les observations des sessions vidéo des utilisateurs. Pour voir ce que ça donne en prod. Et là, c'est un point qui est crucial. Pourquoi on fait ça ? C'est que tout simplement, le développeur est beaucoup plus engagé. Donc quand il voit lui-même le résultat des hypothèses qu'il a formulées, quand il voit lui-même le résultat du design qu'il a fait et du code qu'il a pondu, il est beaucoup plus motivé pour aller chercher une réponse magique au problème. Et du coup, il a beaucoup plus de créativité aussi. Alors je tiens quand même à préciser un point, quand je parlais de design UX, ça n'empêche pas qu'avec notre design manager, Benoît, on challenge quand même de temps en temps, en fonction, on y revient, de l'impact business qu'on cherche, on va investir des efforts pour accompagner les devs. Et il y a des phases de design où il y a des gros investissements de temps en temps. Le dixième principe, c'est je communique. Alors celui-là, il peut paraître évident. Oui, on doit communiquer au boulot. Alors je vais être très clair, moi ce que je dis au sein de mon équipe, si on doit te demander où t'en es, c'est que tu ne fais pas ton boulot. Donc j'ai l'air d'un manager assez méchant en disant ça. Il y a au moins trois personnes ici qui pourront témoigner que je ne suis pas si méchant que ça. Mais du coup, c'est un point important en fait. Pourquoi c'est important ce jeu communique ? Ce n'est pas juste une histoire d'éviter le micro-management. Ce truc de, bon, t'en es où toutes les deux heures ? Ce que j'appelle communiquer, ce n'est pas forcément, je viens te voir pour te dire où j'en suis. Une démo par exemple. Il n'y a rien de mieux qu'une démo, c'est super chouette. On prend du plaisir à bosser ensemble en fait dans les démos. Et pourquoi on y tient ce jeu communique ? Parce qu'en fait, on arrive à ce principe numéro 11 qui est extraordinaire, c'est j'aide et je challenge. L'idée derrière ça, c'est je me rends disponible. Alors ça veut dire quoi ? C'est qu'en fait, lorsqu'on se rend disponible,
Et lorsque les gens communiquent et qu'ils se donnent l'autorisation, donc pour rappel, mais je suis sûr que vous avez appris par cœur, lorsque les principes 3, 10 et 11 sont appliqués, c'est extraordinaire. Je vais vous donner un exemple qui arrive encore il y a quelques heures, mais qui arrive à peu près tout le temps chez nous, c'est JC, un de nos devs, il se dit, tiens, j'ai envie de tester une bannière sur la homepage du site pour mettre en avant tel produit. JC est dev, alors je triche un petit peu, il a une petite touche designer quand même, mais ce n'est pas grave. Il ne dit pas, j'attends la prochaine réunion. Il ne dit pas, je garde ça pour moi. Il ne va pas voir le manager. Non. Qu'est-ce qu'il fait ? Il fait un visuel qu'il design en quelques minutes. Il le poste sur notre Slack en disant, voilà ce qui part en prod cet après-midi, parce que j'ai envie de tester ça. C'est ça mon hypothèse. C'est ça mon intuition. Et du coup, qu'est-ce qu'il se passe ? Lucas, on le dit dev, il peut intervenir en disant, c'est top, mais du coup, peut-être qu'on peut faire mieux. Par exemple, en se disant, plutôt après ce test ou à la place de ce test, je n'en sais rien. Il peut aussi dire, attention, parce que tu vas toucher tel composant technique, donc c'est risqué. À l'inverse, un designer peut intervenir en disant, je vais te faire gagner du temps, j'ai déjà une bannière qui est prête. Et là du coup, c'est magique, parce qu'on n'a pas eu de réunion, personne n'a perdu de temps. Il a eu une idée et de l'idée à la prod, c'est quelques heures et c'est parti. Pour aider et challenger, on utilise beaucoup le feedback. On essaie d'être de moins en moins mauvais en feedback, parce que c'est compliqué l'art du feedback. Et pour ça, une petite astuce qu'on voulait partager ici, c'est comment commencer ? Je passe les règles un peu classiques en matière de feedback sur, déjà, la bienveillance. On n'est pas là pour régler des comptes. Par exemple, dire à quelqu'un après un talk, dis-donc, tu avais l'air stressé, ça ne va pas trop l'aider. À l'inverse, c'est plutôt le côté actionnable. C'est ce côté, je veux dire, quelque chose qui va aider la personne et qui va pouvoir exploiter. Par exemple, moi, pour réduire mon stress, voilà ce que je fais avant un talk. Peut-être que ça pourrait t'aider. Et dans les outils qu'on utilise, tout simplement, c'est qu'on commence, on dit aux débutants en feedback, de commencer par le feedback critique en privé, juste un un, et du feedback positif en public, parce qu'en plus ça monte la voix à d'autres, donc c'est sympa, ça fait du bien. Et enfin, le principe numéro 12, je garantis une place pour l'imprévu. Alors, on a tous en tête l'imprévu pour lequel on n'a jamais de problème pour trouver la place, c'est quand il y a un problème en prod. Alors là, on est en train de perdre du fric, ne vous inquiétez pas, on arrête tout, c'est parti, on y va. Ici, ce qui nous intéresse plus, c'est le côté, la petite idée. Vous voyez, on est à la machine à café, et là, quelqu'un a une idée, qui est vraiment cool, mais ça ne rentre pas dans la roadmap, comment on fait ? Ça, c'est super dur, mais on essaie de respecter ce principe-là, parce qu'on est persuadé que c'est dans ces discussions autour de la machine à café ou à la bière qu'on a les meilleures idées, c'est-à-dire pas que dans les réunions formelles, mais aussi dans les réunions informelles. Et en conclusion, j'ai tout simplement un aveu à vous faire. En vrai, même nous, on galère de ouf avec tout ça. Donc, on ne respecte pas ça tout le temps. Je vais vous donner un exemple très concret, le dernier principe. Oh là là, cette année, on a été mauvais, donc on essaie de faire mieux cette année. Et en vrai, pourquoi c'est difficile ? Tout simplement, pour résumer, on est en train de demander à des devs et des designers de faire de la discovery de manière radicale sur une appli de prod qui pèse des millions. Donc, comment on fait ? A la fois, on leur demande de prendre soin de cette prod, mais à la fois, on leur demande de la casser, donc c'est compliqué. Voilà. Je vous remercie. Si vous avez des questions. Question par rapport à ces principes-là, est-ce qu'il y a un ordre ? Franchement, moi, ce qui m'a choqué un peu, c'est que je me donne l'autorisation, mais après, c'était un peu balancé par le fait que je communique, je challenge, donc ça, c'est bien. Mais du coup, comment... Enfin, si vous, les curseurs, entrez, OK, je me donne l'autorisation, OK, je me donne l'autorisation, je vais communiquer... Alors, déjà, je dirais que ce qui est compliqué, c'est qu'il faut déjà s'assurer, dans le process de recrutement, que les gens sont compatibles avec cette ADN. Parce qu'en gros, c'est culture fit. À partir de là, il y a ce truc où on essaie de clarifier le droit à l'erreur. On a déjà des cas qui sont des blagues en interne, mais des blagues bienveillantes. Sur cet esprit, par exemple, on utilise Google BigQuery pour nos datas quantitatives. Bref, c'est un truc qu'il faut apprendre, il y a un langage SQL pour faire les requêtes, tout le monde ne connaît pas en nous rejoignant. Ça coûte beaucoup, parce qu'on travaille sur des stocks de data qui sont pesants. On a déjà eu des cas, des nouveaux arrivants, quand ils font la formation, ils n'ont pas fait attention, ils ont fait une requête qui coûte 800 dollars. Et on en rigole, mais avec bienveillance. C'est-à-dire qu'on n'affiche pas la personne, on ne la punit pas, on n'engueule pas, etc. Alors évidemment, c'est facile à dire. Quand la boîte tourne bien, quand on a les moyens, c'est facile de dire 800 balles, on s'en fout. Mais on y revient. Parce que notre point de vue, ce n'est pas juste une histoire d'on a l'argent, c'est une histoire de si cette personne n'ose pas faire ses requêtes, elle ne va pas bien apprendre, elle ne va pas bien faire son boulot. Et donc on va y perdre beaucoup plus sur le long terme que ces 800 balles. Il y a déjà d'autres moments aussi où on a fait des bugs en prod qui coûtaient 15 000 balles. En fait, notre stratégie à ce moment-là, ce n'est pas d'aller faire un tir à la personne qui a mis en prod ça. On est plutôt en mode comment c'est arrivé, comment on peut faire mieux la prochaine fois pour ne pas que ça se reproduise aussi facilement. Mais on y revient, c'est vraiment une histoire. C'est presque plus entrepreneurial que du management. C'est cette idée de dire si les gens font trop attention, on va y perdre. La boîte va y perdre et va donc perdre beaucoup plus d'argent que ça. Tu dis, je connais l'impact business potentiel. On a pas mal parlé d'ailleurs dans la phase de Discovery où vous émettez des hypothèses. Est-ce que tu peux revenir un petit peu là-dessus ? Parce que pour moi, ça me paraît plutôt de sorcier. L'idée est d'estimer l'impact business potentiel, surtout à le chiffrer, à l'estimer en équipes. Qu'est-ce que vous faites pour estimer un vrai business ? Là-dessus, on est très à l'aise avec ce côté science-fiction. Ce qui nous intéresse ici, ce n'est pas d'avoir la vérité en fait. C'est de savoir l'intuition derrière, la motivation derrière. Je vais prendre un exemple très simple. Ça m'arrive tout le temps avec les devs qui disent, ce truc-là, il peut tout casser. Je dis, alors t'estimes à combien ? Je ne sais pas, c'est trop dur. Ça arrive tout le temps, c'est tout le temps comme ça avec les devs. Dis-moi un chiffre. Je ne sais pas, 1% ? Bon, ben voilà, on ne le fait pas. Et là, du coup, évidemment, je laisse la place à… Non, non, attends, en fait, je vais réfléchir. C'est ça qui est intéressant en fait. Là, pour le coup, c'est un mouvement algérien. S'il se bat pour ça, c'est qu'il a un truc, qu'il a envie qu'on aille chercher derrière. À l'inverse, quelqu'un qui me dit 10%, je dis, attends, attends, assieds-toi, on va en discuter. Parce que peut-être que oui. Donc ça, c'est la partie déjà qu'on est purement sur l'intuition. Mais souvent, on a de la data aussi. Alors, si je devais donner une règle un peu générale pour répondre rapidement à la question, on a un peu ce process de… On détecte des hypothèses en user research par des interviews, par exemple, ou des observations de terrain, donc par de la data qualitative, et qu'on essaie ensuite de valider à plus grande échelle grâce à de la data quantitative, par exemple avec un sondage. Ça permet de passer un peu du quali au quanti pour se dire, ouais, il y a bien quelque chose à aller chercher là-bas. Rebonsoir à tout le monde. Alors, je ne sais pas si je vous ferai une présentation aussi brillante que celle de François, mais surtout, je vais la faire courte. Moi aussi, j'aime bien parler autour d'un verre. Donc moi, je suis Cécile Méusy d'Acosta. Je suis Product Director chez LUCA. Je vais faire la même chose. Est-ce qu'il y en a quelques-uns parmi vous qui connaissent LUCA ? Ah, pas mal, moins populaire que Pictarine. Je ne gagne pas le concours de popularité ce soir, mais c'est plus que ce à quoi je commençais. Donc moi, j'ai commencé ma carrière chez LUCA en 2009. On était 7 à l'époque. J'en suis partie 5 ans plus tard. On était une quarantaine de personnes. J'ai été bossée ailleurs pour un autre éditeur, donc j'ai été bossée ailleurs. Et je suis ce qu'on appelle un salarié boomerang puisque je suis revenue à mes premières amours. Je suis revenue bosser pour LUCA en 2019. Là, on était déjà 150 personnes. Et maintenant, en 2023, on est 450. Donc j'ai vu la boîte grossir, grossir, grossir. Et c'est une aventure assez marrante. Donc, j'ai commencé ma carrière chez LUCA en 2009. J'ai commencé ma carrière chez LUCA en 2009. J'ai commencé ma carrière chez LUCA en 2009. J'ai connu LUCA A7. J'ai eu l'occasion de faire absolument de tout ce qui peut se faire chez un éditeur de logiciels. J'ai été sales. J'ai été customer success manager. J'ai été PM. J'ai fait du support. J'ai à peu près fait de tout sauf vraiment du dev.
et de la compta je pense mais j'ai vraiment vraiment vraiment fait de tout le thème dont j'avais envie de parler de ce soir on en discutait un petit peu moi il ya quelque chose cette expérience là le fait d'avoir fait un petit peu de tout dans un éditeur logiciel c'est que je vois que plus un éditeur grossit plus il commence à y avoir en fait la boîte commence à scinder un petit peu en deux ça se voit même des fois dans des petites petites boîtes mais entre une équipe business sales customer service manager et une équipe produit donc effectivement tout ce qui pm product designer développeurs et que des fois c'est un peu le choc des titans entre ces deux mondes moi j'ai vécu dans les deux mondes et j'en j'ai pas envie d'en choisir un j'adore fabriquer des logiciels j'adore réfléchir à me prendre la tête sur des nouvelles features et j'adore les vendre j'aime quand mes clients disent c'est cool ça marche bien ça me donne envie d'en faire d'en faire d'autres j'ai pas envie de choisir donc j'ai envie de plutôt ici de vous partager un peu quelques idées quelques pratiques qu'on a nous aussi chez lucas pour que ce soit pas le choc frontal justement entre ces deux équipes mais que vraiment on a envie d'aimer ces deux mondes alors avant ça je vous dis un petit mot très rapidement sur lucas qui en est donc on est un éditeur de logiciels on a un éditeur de solutions rh plus précisément on n'est pas tout neuf on a été créé en 2002 on va faire en fait 15 mois sidère nos 21 ans d'existence donc et donc on a un peu plus de 6000 sociétés clientes donc nous on fait du b2b nos clients c'est principalement des pme en france un petit peu à l'international c'est à dire des boîtes de 50 à 500 mille personnes ensuite le gros nom de marché c'est ça c'est à peu près les sociétés d'une centaine de collaborateurs et on a aujourd'hui un peu plus donc 6400 clients mais ça représente nous nos applications elles sont utilisées par tous les collaborateurs de l'entreprise donc ça fait qu'aujourd'hui on a un peu plus de 1,4 millions d'utilisateurs de nos solutions donc concrètement les applications qu'on fait dans la gestion rh ça va couvrir tout ce qui est vraiment la partie administrative des rh gestion des congés gestion des temps et activités toute la partie dossier rh du collaborateur également tout ce qui est également de la partie financière gestion de notre de frais gestion des achats un petit peu la partie ce qu'on appelle la gestion des talents gérer les entretiens annuels ou trémesses réelles des collaborateurs l'engagement aussi à coup d'eux peut le surveiller par exemple pour savoir comment ça se passe dans la boîte donner des conseils sur sur augmenter l'engagement des collaborateurs et le petit dernier je garde pour la fin parce que c'est mon périmètre à moi c'est là dessus que j'ai j'ai mon équipe tout ce qui va concerner la partie rémunération des collaborateurs suite leur rémunération l'intégration avec des systèmes de paye aussi qu'utilise nos clients puis la distribution des bulletins de paye j'irais que nous comme un petit peu comme ce que présentait françois chez pictarine on est une boîte résolument produits on fait bien évidemment du chiffre d'affaires le business d'anime mais c'est vraiment avant tout nos produits je sais pas si on fait les meilleures softs du secteur mais ce dont je suis sûr c'est qu'on y crame quelques neurones à les faire on se prend énormément la tête pour vraiment sortir des bons produits et ça c'est animé par un mantra fort chez lucas cette culture produit on a notre mantra vraiment nos principes quand on développe c'est qu'on doit consommer des applications pour ceux qui les utilisent et pas pour ceux qui les achètent ce que ça veut dire c'est que vraiment quand on crée une nouvelle future une nouvelle fonctionnalité on n'a pas en tête le boss de la boîte qui va signer la propale on fait pas cette feature là pour ce moment là on fait vraiment cette future là pour dire bon bah c'est qui mon personna très souvent chez nous c'est la responsable rh et encore plus souvent c'est le collaborateur d'une entreprise c'est l'utilisateur donc on va vraiment créer la meilleure expérience pour le collaborateur ça le moindre collaborateur qui va venir poser ses congés faire ses notes de frais là on va vraiment avoir une obsession produit c'est là dessus c'est dire bah c'est cette personne là qu'on qu'on adresse donc ça veut dire que dans nos arbitrages de roadmap des fois on va privilégier vraiment de passer du temps de consacrer de la ressource à ces fonctionnalités là plutôt qu'à des fonctionnalités des fois qui sont considérés un petit peu plus comme ils le veulent mais qui sont demandés qui vont être demandés justement par celui qui va signer la propale le gosse on sait que vraiment nous notre adn c'est pas ça c'est d'abord de faire la fonctionnalité pour le collaborateur et ça ça se traduit donc par notamment les interfaces de nos softs on a des products designers on casse on consacre énormément de temps à lui que ça lui se research aussi c'est hyper important dans nos jobs et ça anime vraiment chez nous les pm on est pareil d'ailleurs que ce que tu décrivais chez pictarine aussi on a une organisation produit tout à fait similaire dans le sens où nous ce qu'on appelle équipe produit c'est les product managers les product designers et les devs ils font intégralement partie des équipes produits et de la façon dont on est organisé mais c'est pas tout ça on a quand même aussi des équipes business des gens qui sont intéressés par vendre nos sortes et puis on est gentil avec nos petites solutions et on veut faire la plus belle interface pour nos utilisateurs mais on aussi rattraper par les réalités du terrain moi ça je les voyais beaucoup moins dans le lucas quand on était cette personne celui qui vendait la solution c'était très souvent celui qui allait déployer la solution ça a été à la fois sales et customer success manager et même c'était pas si rare que ça des fois c'était aussi celui qui développait la solution à cette personne ça marchait comme ça après quand on a grandi un peu plus qu'on était une quinzaine de personnes celui qui vendait déployer la solution c'était pas lui qui l'a codé mais par contre c'était son pote qui était assis dans le bureau en face de lui avec qui il allait boire des bières donc il y avait vraiment une très forte cohésion comme ça des équipes business et produits les demandes se concernaient plus on a grossi et plus on a vu apparaître un petit peu de monde comme ça qui se coisonnaient et puis des discussions de ce genre à côté sales bon bah ça y est vous allez nous assortir cette fonctionnalité parce qu'elle me permettrait de closer 50% de business en plus et puis bas à côté produit non non ou là c'est ça c'est trop compliqué on a besoin de plus de temps par contre on va faire un dark mode ça va être trop marrant c'est trop cool le dark mode on adore ça et ça ça tient pas mal à des mythes finalement côté côté côté côté business mais attends moi la fonctionnalité que je te demande après tout c'est juste un bouton à ajouter là dans ton soft je sais pas si dans vos métiers de product manager vous l'avez entendu non mais t'inquiète c'est rien tu mets juste un bouton là donc c'est un petit peu plus compliqué que ça ajouter un bouton je vous renvoie d'ailleurs il y a un excellent article petite parenthèse de jonathan le vitre qui est pm chez partout et son article il s'appelle existe exactement ça non ce n'est pas juste ajouter un bouton et c'est à destination des équipes business pour expliquer que le métier de pm c'est plus compliqué que juste décider d'ajouter un bouton un bouton là mais le côté business il y a les mêmes frustrations ou côté côté côté pm battant ok mais t'as vendu à mon à mon client une fonctionnalité qui n'existe pas et qui existera peut-être probablement jamais dans mon soft donc c'est un peu ça moi les affrontements des deux mondes que j'ai pu voir et donc je vais expliquer un petit peu nous les principes forts qu'on met en place pour éviter justement essayer de réconcilier ça équipe business équipe qui produit le premier un principe fort qu'on a nous chez lucas c'est que on ne vend pas la roadmap c'est à dire que on vend pas on peut pas proposer à nos clients même des très grands comptes on ne dit on ne propose pas quelque chose on s'engage pas contractuellement sur quelque chose qui n'est pas effectivement en production c'est juste pas possible alors quelque chose qui est peut-être peut-être là dessus c'est un petit parc particularité chez lucas nos sales il se plie complètement à ce à ce principe là notamment parce qu'ils ne sont pas commissionnés nos sales chez lucas finalement qui vendent ou qui vendent pas leur salaire à la fin du mois ce sera la même chose alors on est en train de réfléchir à des principes de commissionnement collectif on a vraiment ce principe fort qui est on apporte d'abord de la valeur à nos clients et chaque collaborateur individuellement n'a pas intérêt à vendre quelque chose à passer outre les règles et donc ça c'est assez assez confortable finalement pour nous équipe produit on vend pas la roadmap on va vraiment avoir le temps de faire des fonctionnalités pas de les développer rapidement dans notre coin parce que un sel cela vendu et ça va vraiment aussi c'est ça nous aider à co-construire avec nos clients cette roadmap et à être à vraiment leur proposer que la meilleure expérience possible de nos produits puisque c'est pas juste des features qui vont exister sur sur site et alors ce qui est arrivé également j'avais tendance un peu vite sur l'effet l'effet de mes slides ce qui est arrivé également justement là dessus parce qu'on ne vend pas la roadmap ça crée quand même des frustrations côté côté côté business que des produits on disait ok d'accord je vais pas proposer quelque chose qui n'existe pas pourtant moi j'ai besoin commercial d'avoir une vision sur ce qui va arriver sur mes produits parce que je sais que ça peut être l'élément déclencheur pour une vente j'ai besoin de savoir ça et de la même façon j'ai besoin moi de m'assurer en coéquipe commercial que mon équipe produit elle est bien en train de développer ce qui va me permettre de faire du business qui est vraiment attendu par par par par mes clients encore une fois quand on était plus petit c'était un dialogue était assez facile et plus on a grossi plus on a eu un nombre d'applications importantes et aussi un nombre d'utilisateurs importants plus c'était difficile finalement pour nos PM de suivre ça près et c'est là qu'on a fait intervenir le juge de paix en 2020 on a créé un premier job chez lucas qui existait pas avant qui était
Le PMM, Product Marketing Manager. Est-ce qu'il y en a parmi vous qui sont PMM ? Je m'attendais à au moins une ou deux. Est-ce qu'il y en a parmi vous qui ont des PMM dans leur entreprise ? D'accord, ça va un petit peu mieux. C'est assez marrant ce job-là de PMM parce que d'ailleurs, quand on regarde les formations, nous, je sais qu'en ce moment, par exemple chez Lukey, on est en train de beaucoup se prendre la tête sur les offres de postes de PMM et les grilles de compétences parce que c'est un job qui n'existait pas il y a encore 3-4 ans. C'est arrivé de façon assez nouvelle il y a quelques temps et c'est vraiment ce job-là assez fort qui permet de réconcilier le meilleur des deux mondes. Ça marche plutôt pas mal chez nous depuis qu'on l'a mis en place. Alors, je vous propose cette petite définition qui n'est pas du tout de moi, j'aurais dû retirer la citation, qui est de Tony Fadel. Tony Fadel, c'est un ancien d'Apple, c'était le lead designer de l'iPod. L'iPod est sorti et après, il a quitté Apple en 2007, quelque chose comme ça, pour aller créer Nest. Vous voyez ce que c'est, Nest, les thermomètres connectés. Il a écrit un bouquin génial que je vous recommande vraiment qui s'appelle Build. Et lui, il fait cette distinction-là que je trouve pas mal entre qu'est-ce que c'est un product manager finalement et un product marketing manager. Il dit que le product manager, c'est la voie du client. Le product marketing manager, c'est la voie du prospect. C'est-à-dire, c'est celui qui va vraiment permettre d'aller attraper ces clients qu'on n'a pas encore et ça va être ça le job principal d'un product marketing manager. Et c'est pas mal ça qu'on a respecté chez Luca. Qu'est-ce que fait un product manager ? Qu'est-ce que fait un product marketing manager ? Comme ça, on a un peu splité en deux les jobs. C'est un duo très fort finalement, nous maintenant, PM et PMM. Et on aime bien avoir la vision de dire finalement, le PMM, c'est le bras droit marché du PM. Comme beaucoup de boîtes de soft, on a un peu cette vision-là qu'in fine, le PM, ça doit être quand même le CEO de son produit. C'est-à-dire qu'il doit s'intéresser à tous les aspects de l'expérience utilisateur de son produit, de la façon dont on le vend jusqu'au SAV, au test qualité de son produit. Mais plus le produit est gros, moins il peut faire ça tout seul. Donc, il se fait aider du PMM qui va être lui vraiment la partie marketing et business du produit. Chez nous, plus concrètement chez Lucas, la façon dont ça fonctionne, c'est que le PMM, il n'est pas tout seul dans son coin à essayer de comprendre quel est le marché de son produit, qu'est-ce qui est attendu du business, et puis aller expliquer ça au business. On s'est organisé en squad. Il a sa petite squad, sa petite équipe. C'est-à-dire que la squad, en fait, c'est des représentants des équipes business. Alors nous, ce qu'on appelle équipe business chez Lucas, ça comprend bien sûr les sales, les commerciaux, l'équipe marketing aussi, comment je vais communiquer sur mon produit, comment je vais aller attraper des leads que mes commerciaux vont ensuite pouvoir closer. Et on a aussi une partie assez forte, étant un logiciel de B2B, il y a toute la partie customer success management. Être sûr que nos clients restent engagés sur nos produits, et puis assurer tout le support, toute la maintenance de nos produits pour qu'ils aient vraiment la meilleure expérience possible, surtout qu'on est en gestion RH des fois sur des problématiques qui peuvent être assez complexes. Donc, ils ont besoin d'accompagnement. Donc, notre petit PMM qui est ici, elle a à sa disposition toute cette squad-là, c'est-à-dire des représentants de ces équipes-là, qui vont vraiment venir la soutenir. Donc, la communication entre cette équipe-là, donc la squad Product Marketing Management et le produit, finalement le Product Manager, ça se fait dans les deux sens. C'est-à-dire, c'est vraiment la responsabilité du PMM d'aller traduire auprès de ces équipes business-là, de dire bon, voilà les fonctionnalités qu'on va sortir. Les fonctionnalités, des fois, quand ça vient des PMM, alors ça dépend de leur passif, j'ai envie de dire, de leur profil, mais ça peut être compréhensible par un humain du PMM qui a un profil assez tech-dev, ou lire son doc d'OSP comme ça, ultra conceptuel, il va falloir une petite phase de traduction du PMM pour aller expliquer aux sales de quelle fonctionnalité on parle. Donc, ça se fait dans ce sens-là. Les PMM sortent des nouvelles fonctionnalités, la PMM communique sur ces nouvelles fonctionnalités, mais surtout, ce qu'on cherche de plus en plus énormément à faire, c'est que ça se fasse dans l'autre champ, c'est-à-dire que ce soit vraiment cette squad-là qui drive, qui est une influence forte sur la roadmap du PMM. On retrouve un peu les idées d'impact business justement de nos fonctionnalités, et ça, c'est vraiment le PMM qui permet de gérer cette communication-là et d'aller collecter auprès de ces terrains-là les insights nécessaires. Comment on fait ça, du coup, concrètement ? Alors, vous l'avez compris, vendre la roadmap, ça, c'est non, non, non, non, non. Par contre, justement, tout l'intérêt de la squad, c'est qu'on va co-construire cette roadmap avec sa squad. Alors, comment on construit une roadmap ? Il y a plusieurs méthodes. Je vous ai sortie celle-ci vraiment pour la forme théorique, mais personnellement, je n'y crois que très moyennement. Est-ce que vous avez déjà entendu parler de la méthode RISE ? Il y a eu quelques articles. Je trouve très intéressant d'un point de vue théorique. RISE, ça veut dire, c'est l'anagramme de Reach, Impact, Confidence, Effort. Ça veut dire qu'en fait, on définit tout ce qu'on pourrait faire dans un produit. Vous voyez, ça, c'est notre product board, par exemple, qu'on définit justement tout notre backlog, tout ce qu'on pourrait imaginer. Et ensuite, pour chacune des fonctionnalités, on va aller mettre des notes sur le reach. Quelle est la population que je vais pouvoir toucher ? Quel est l'impact, l'impact business ? À quel point on est confiant de ces éléments-là ? Et quel est l'effort demandé ? Alors, ça tient peut-être au fait que, contrairement justement à Pictarine, qui est en B2C, nous, on est en B2B. Donc, même si on a de la data, on a probablement un volume de data moins important. Donc, on a un petit peu plus de mal là-dessus. Mais quoi qu'il en soit, on a quand même essayé de mettre en place ces méthodes-là dans Lucas. Ça a donné ces beaux petits tableaux, là, comme ça, qui ressemblent un peu à un jeu à la Pac-Man. On l'avait même appelé, là, cette vue sur product board, « viens voir l'oracle ». Moi, mon avis personnel là-dessus, c'est qu'on a passé plus de temps à définir c'est quoi cinq carreaux, c'est quoi trois carreaux, c'est quoi un carreau sur les différents éléments de Rice qu'à vraiment se poser la question de, mais finalement, nos clients, ils ont besoin de quoi ? Nos prospects, ils ont besoin de quoi ? Et quand on a pris un petit peu conscience de ça, de dire, c'est difficile, finalement, de faire des métrics et de faire du quantitatif là-dessus, on est revenu, justement, à la première méthode, de dire, non, mais attends, on va remonter d'un cran, hop, et on va revenir voir la squad, et on va faire beaucoup plus du qualitatif, et on va dire, bon, ben, OK, maintenant, on va essayer vraiment de comprendre ce que vous nous dites. C'est quoi vos retours terrain ? Voir même, on va vous demander de nous amener directement, en fait, sur le terrain. Vous accompagner auprès de nos clients pour mettre de côté tout ça, tous ces jolis petits carreaux, pour vraiment se forger, en fait, des opinions fortes sur quelles sont les prochaines grandes futures qu'on doit faire. Alors, par opposition à la méthode Rice, il y a une autre méthode que moi, j'aime beaucoup plus, qui est, pour le coup, beaucoup plus intuitive et moins théorique, et qui fait probablement moins joli sur un CV, des compétences lignées, etc. Mais on a appelé ça la méthode de la baguette magique. En plus, c'était cool, ça nous permettait de vous sortir cette jolie petite gifle de cendrillon, qui est quand même beaucoup plus sympa, vous l'avouerez, que ça. Le coup de la baguette magique, c'est une méthode assez simple qu'on utilise pas mal dans les squads. On l'utilise même, des fois, auprès de nos clients. Je vous pose la question, donc moi, je la pose à nos clients, je la pose à nos sales. J'ai une baguette magique avec laquelle je peux faire apparaître la fonctionnalité que tu attends le plus pour closer plus de deals, pour satisfaire plus nos clients, ou vous, clients, parce que ça va vraiment vous soigner la vie. Vous choisissez quoi et vous avez 30 secondes pour répondre pour que vraiment ça se fasse à l'intuition et au coup d'œil. Et c'est comme ça qu'on se forge des intuitions, auprès de nos équipes business. Et enfin, je vous avais dit que ce ne serait pas trop long, je terminerai là-dessus. Les autres méthodes qu'on utilise intensivement, et donc on s'appuie justement sur nos squads de représentants des équipes business pour pouvoir le faire, c'est d'aller déjà écouter nos sales. Alors, on a un super outil pour faire ça. Toutes les démos de nos produits que font nos sales sont enregistrées grâce à un soft qui s'appelle Mojo. Ça avait été un petit peu compliqué quand on l'avait mis en place. C'est un côté un peu flicage, qui n'est pas forcément un grave pour le sales en question. Mais finalement, ça a été très bien accepté avec un peu de communication en interne, parce que ce n'est vraiment pas le but. Ce n'est pas de fliquer les personnes pour voir si elles sont productives ou efficaces. Ça a deux objectifs. La première, c'est qu'on recrute énormément de jeunes commerciaux chez Lucas. Nos métiers sont complexes, nos produits sont complexes à apprendre. Donc, pouvoir réécouter sa démo, ça leur permet de rapidement monter en compétence, de voir les erreurs qu'ils font et de les corriger comme ça. Et le deuxième, c'est que c'est une mine d'or d'informations pour nous, équipes produits, pour comprendre nos produits. C'est-à-dire qu'en plus Mojo, il y a une sorte de couche d'intelligence artificielle qui est faite là-dessus, qui est hyper bien faite, qui identifie, il y a de la retranscription du dialogue entre les personnes qui assistent à la démo. Et ça permet donc de capter, par exemple, à un moment, quand le client parle de telle fonctionnalité ou qu'il y a un effet waouh qu'on entend autant du client qu'il est hyper content de la fonctionnalité qu'on lui montre, ou qu'au contraire, il challenge beaucoup, qu'il pose beaucoup de questions, celui qui a beaucoup de questions d'objection, etc. Donc ça, c'est génial à mettre en place. Et enfin, l'autre principe fort finalement aussi qu'on met en place nous, c'est de devenir satire. On est convaincu finalement qu'un PM, ça doit être aussi le premier commercial de son produit.
Donc on pousse beaucoup nos PM si ce n'est à aller faire eux-mêmes des démos, au moins aller assister à des démos de nos softs et à challenger en fait la façon dont on présente nos produits, voire même à être responsable de ça, c'est-à-dire à être dans la conception de leurs softs et de leurs nouvelles features, à aussi imaginer la façon dont on va les présenter à des clients. Voilà, et alors je vous parle d'une dernière petite expérience un peu marrante qu'on avait faite, qu'on n'a pas encore malheureusement poussé trop loin. Tout ça c'est très bien finalement pour créer le dialogue entre je suis PM, comment mieux comprendre le business et être sûre que je travaille sur les bonnes features, le prochain impact. On avait imaginé la problématique dans l'autre sens, c'est-à-dire nos commerciaux des fois ont du mal à comprendre pourquoi nos features ne sortent pas plus vite, pourquoi on ne travaille pas plus sur telles features. Et donc à l'occasion d'un start-up week-end chez Lucas, alors un start-up week-end ça ne se passe pas le week-end justement, mais on a en général deux jours par an, ce n'est pas obligatoire. On propose aux collaborateurs de tout couper, de venir s'enfermer dans une pièce et avec des petits teams de chez Lucas, d'imaginer n'importe quel projet qu'ils veulent, il faut juste que ce soit en rapport avec Lucas. On ne peut pas imaginer un projet de tireuse à bière, ou alors si c'est un projet de tireuse à bière, il faut qu'elle soit estampillée Lucas. Mais on a vraiment carte blanche, on crée les équipes qu'on veut, on a droit aux projets qu'on veut. Le dernier qu'on a fait, moi j'étais dans une équipe où on avait imaginé ça, on avait imaginé un jeu, on l'avait même appelé Sassy pour Sass, puisqu'on fait des outils Sass. C'était une sorte de jeu de loi à destination des business, pour comprendre comment on conçoit un produit. Donc voilà, on avait imaginé ça, on lançait des dés, on avançait de cases, de temps en temps on se retrouvait sur une case comme celle-ci par exemple, un client est très fou et contradictoire, il a tel besoin mais il a aussi tel besoin, il a pleins de deux ans, on ne comprend rien, donc ça faisait reculer 2-3 cases. Et à contrario, on pouvait tomber sur des cases un peu plus sympas, où en fait on avait une idée de génie, et en plus elle n'était vraiment pas coûteuse à développer, donc ça nous faisait avancer 2-3 cases. Jusqu'à la case mortelle, vous savez à la toute fin du jeu de loi, c'est un petit peu bâtard le jeu de loi, vous pouvez tomber à un truc qui vous fait revenir au début. Et nous la case mortelle, elle disait très exactement ceci, ta fonctionnalité est sortie, mais personne ne l'utilise, retourne à la case départ. Voilà, donc ça c'était un peu pour nos idées. Voilà, j'en ai fini avec cette présentation, est-ce que vous avez des questions ? Applaudissements C'est quel profil du coup qui mène le RISE ou qui utilise la baguette magique ? Alors c'est justement le PMM, le Product Marketing Manager, de plus en plus chez nous, mais ça peut être le PM aussi qui fait ça. Donc la discovery est vraiment menée par la partie product au sens du Product Manager ? Oui, tout à fait, la discovery, ça reste complètement la responsabilité du PM, mais maintenant qu'on grossit, il peut, il doit même s'appuyer sur le Product Marketing Manager, sur les sales, il doit aller chercher ces insights-là. Ok. Comme vous voulez. J'ai une question, au début vous avez fait la distinction, enfin le motto de votre boîte c'est vous designez, vous livrez des solutions pour vos users et non pas pour les vailleurs, mais comment du coup votre structure produit, elle est en service pour ce motto-là ? Parce qu'au bout d'un moment on a vu RISE, ok j'aurais besoin de ça pour avoir 50% de chiffre d'affaires, donc tu le sais que c'est par l'intérieur, et après il y a SQUAD, l'arrivée du PMM par définition, du PMM par le prospect, pour ça c'est encore le vaillant, et donc je ne vois pas comment, il y a quelque chose qui est, enfin je n'arrive pas à le lire. Oui, tu te demandes si ce n'est pas un peu bullshit finalement ce que j'ai raconté sur les utilisateurs. Non, non, non, non, il y a quelque chose qui manque en fait. En fait la philosophie de dire on fait vraiment des applications pour ceux qui les utilisent, ça se voit énormément dans l'interface de Soft Circle. Nous on fait des applications RH, donc ça veut dire qu'il y a toute une partie qui est utilisée par les collaborateurs. Je vais vous donner un exemple, par exemple vous avez été le dernier employeur pour lequel vous avez été recruté, vous avez probablement eu une phase de onboarding maintenant ce qu'on appelle, et peut-être selon les softs qu'ils utilisent, vous avez reçu avant même de faire votre premier jour dans la boîte, reçu un formulaire qui vous dit allez-y rentrez des infos parce qu'on va en avoir besoin dans la boîte. Et ensuite toutes ces infos-là que vous allez rentrer dans le formulaire vont aller dans l'ASI RH de votre entreprise et vont pouvoir être exploitées par les RH qui vont pouvoir faire des rapports, etc. Nous on va passer un temps monstre en UX, en product design, à faire la première partie de l'expérience, c'est-à-dire celle qui va avoir le plus de, là pour le coup, rise, de reach, qui va toucher le plus grand nombre de collaborateurs en disant en fait vraiment le premier problème à résoudre c'est que ce soit simple et ultra simple et ultra limpide pour le collaborateur. Et on insiste beaucoup là-dessus en démo, on le montre beaucoup, on montre beaucoup ces interfaces-là, alors qu'on s'adresse, quand on fait une démo, plutôt à des responsables RH, des DG, des DAF, qui eux, ça dépend de la culture de leur boîte bien sûr, mais vont être plus intéressés par justement ce qui les concerne, comment moi je vais gérer mes rapports, après que mon collaborateur il galère à remplir son formulaire d'onboarding ou pas, c'est pas grave, nous on pense pas ça, on pense qu'au contraire, cette partie-là, elle est importante. Dernière question, donc après. Vous avez expliqué votre jeu qui n'était que l'avant et le fait de pouvoir comprendre comment les projets avançaient, mais comment vous y arrivez alors que quand on tombe sur une case, on ne demande juste d'avancer ou de reculer ? Ouais, on a besoin de quelques itérations, je pense, sur le jeu, ce qu'on voulait surtout traduire, c'est ça, faire comprendre l'idée qu'il y a une grande partie d'imprévus, finalement, dans nos métiers, et donc de temps en temps, c'est des imprévus assez cools, c'est-à-dire qu'on imagine une nouvelle future qu'on n'avait pas du tout imaginée au départ, mais qui peut vraiment faire une différence, et très souvent, c'est des imprévus moins cools et qui nous font reculer de quelque part, ce qui fait que ça prend plus de temps que prévu, voire même que des fois, le projet peut être carrément arrêté. Merci d'avoir regardé cette vidéo !