Bonjour à tous et bienvenue à ce replay du meetup Product et santé mentale. Alors il y avait un petit problème de recording au moment du meetup, donc toute la première partie je vous propose qu'on la fasse ensemble ici, toujours depuis les bureaux Blablacar. Déjà pour commencer, pour me présenter, je m'appelle Alexis Colonna, je suis Product Manager chez Mocha.care. Et Mocha.care, qu'est-ce que c'est ? C'est une solution d'accompagnement des entreprises et des employés sur tous les sujets de santé mentale. Au moment où on a commencé à se poser la question de ce meetup, on s'est dit c'est super intéressant de parler de santé mentale, on n'en parle pas assez, mais est-ce que c'est vraiment un sujet chez les Product ? Est-ce que ça arrive ? Est-ce que c'est vraiment une problématique ou pas du tout ? Et c'est pour ça qu'on a lancé l'étude Product et santé mentale, vous avez peut-être entendu parler, pour savoir et un peu comprendre justement quelles étaient les problématiques. Et vous allez voir, tout ce meetup va réutiliser des enseignements qu'on a eus grâce à cette étude pour pouvoir vous proposer des conseils actionnables. Et donc 56%, ce chiffre vient de l'étude justement, c'est le nombre de Product People qui considèrent que les équipes produits sont plus sous pression que les autres. C'est un chiffre qui est extrêmement intéressant, parce que ça veut dire qu'on a plus d'un Product People sur deux qui se dit que les équipes produits sont plus sous pression que les autres. D'où tout l'intérêt de ce meetup, de comment on peut faire pour en sorte que justement, on gère mieux la santé mentale dans le Product. Et donc justement, on va s'atteler à voir ça à travers des choses beaucoup plus adaptées au Product. On va voir ça à travers quatre parties. Première partie, la relation à soi. Deuxième partie, la relation management. Troisième partie, la relation aux équipes client-facing. Quatrième partie, la relation aux équipes tech. On va à chaque fois voir ça à travers des cas concrets, des exemples et des choses vraiment complètement actionnables. Aussi, tous ces conseils seront résumés dans une note auxquelles vous pourrez avoir accès à la fin du meetup. En dernière slide, vous aurez un petit QR code pour la télécharger. Vous n'aurez pas forcément besoin de prendre des notes pendant que vous écoutez ce replay. La relation à soi. Pourquoi commencer par la relation à soi ? Tout simplement parce qu'avant de pouvoir se poser la question de la relation avec les autres, comment on s'améliore sur ces sujets-là, il faut déjà voir comment on prend soin de soi dans un premier temps. On sait que le milieu du produit, c'est un milieu où il y a de la pression, il y a du stress, on a de la responsabilité. Et c'est toutes ces choses-là qui peuvent être assez compliquées finalement. Et on va essayer de voir comment on peut essayer de gérer ça. Première partie sur la relation à soi, les limites. Le défaut un peu classique de tous les Products, c'est de vouloir un peu combler toutes les problématiques, mettre en place plein de nouvelles choses, plein de process et ainsi de suite. Et on peut vite avoir du mal à se mettre des limites et ne pas être capable justement de, de temps en temps, se laisser un peu d'espace pour accepter et gérer cette pression et ne pas surcharger hyper rapidement. Premier conseil pour se mettre des limites, c'est d'être capable de prendre du recul. C'est hyper important de pouvoir prendre du recul, ça paraît quelque chose de très simple et finalement ce n'est pas si simple que ça. Un des tips qu'on peut avoir, c'est de se dire que prendre du recul, pour pouvoir le faire, ce qui est important, c'est de connaître ses priorités et vraiment ses priorités du moment. Et donc moi, le conseil que je donne là-dessus, c'est de se dire, faites l'exercice, soit seul, soit avec votre manager, de vous fixer les trois priorités de votre semaine et de vous dire quelles sont mes priorités, quelles sont les trois plus importantes et de pouvoir travailler dessus. Et c'est vraiment quelque chose, vous ne vous dites pas j'en fais cinq, j'en fais dix, non, les trois priorités. Pour vous donner un exemple, moi au moment où je préparais ce meetup, j'avais comme priorité préparé ce meetup, préparé la sortie de l'étude sur laquelle se base ce meetup, mais on m'a aussi demandé de faire d'autres choses comme par exemple aider les équipes à faire la nouvelle carte de visite de Mocha. Je savais que mes priorités, ce n'était pas ça, donc j'ai pu me concentrer justement sur ma préparation de meetup et facilement m'enlever de la charge en me disant, ça, ce n'est pas ma priorité et mon impact ne va pas être maximal à cet endroit-là. Une autre chose que vous pouvez faire pour prendre du recul et poser des limites, c'est d'utiliser un principe de conseil qui s'appelle les trois cercles. En gros, le principe des trois cercles, c'est de se dire, toutes les choses sont dans l'un de ces trois cercles, soit un cercle de contrôle, donc quelque chose sur lequel je peux agir moi directement, soit un cercle d'influence, donc quelque chose sur lequel je peux demander à quelqu'un d'agir, soit un cercle de préoccupation, quelque chose sur lequel ni moi ni personne peuvent vraiment agir. Et c'est hyper intéressant, parce que quand on vient remettre les choses dans ces cercles-là, on vient se rendre compte que des fois, on se crée souvent de la charge mentale pour des choses sur lesquelles on ne peut rien faire. Et c'est aussi cet exercice que vous pouvez faire. Typiquement, la crise actuelle des startups, c'est quelque chose qu'on a tous dans le cercle de préoccupation et sur lequel on ne peut rien faire. Donc finalement, il faut être capable aussi de se dire, je vais me le sortir de ma charge mentale, parce que ce n'est pas quelque chose sur lequel je peux agir. Et si c'est quelque chose sur lequel vous avez du contrôle ou de l'influence, en ce cas-là, plutôt que de ruminer sur le sujet, il faut vraiment être capable de passer à l'action directement. Les injonctions, c'est quelque chose dont on parle, je pense, assez souvent dans le produit, mais qui est assez intéressant. Il faut être capable de se libérer des injonctions. Et donc, je vais vous dire quelque chose qui ne va sûrement pas vous plaire, mais non, vous n'aurez jamais lu tous les livres de Product Management, écouté tous les podcasts, assisté à tous les meetups, regardé tous les webinars. Ce n'est pas possible et ce n'est finalement pas grave. Et donc là, vous allez me dire, ah bah oui, mais imaginons que justement, cette ressource dont on parle, peut-être que j'en aurais besoin plus tard, comment je fais ? En effet, on a tous ce truc-là de voir passer sur LinkedIn, dans des newsletters, des ressources qui peuvent paraître intéressantes. Et dans ce cas-là, ce que je vous conseille de faire, c'est quelque chose que moi j'ai mis en place, c'est de vous dire, vous faites une petite base de données Notion, une petite feuille Excel, une petite later library, en se disant, ok, voici quelles sont les ressources et je me note les ressources intéressantes, je mets le lien et pour l'instant, je ne vais pas la regarder, mais le jour où j'en ai besoin, je sais que je pourrais aller la voir. Et donc là, on peut aussi regarder mes exemples à moi, par exemple, Product Shop, c'est quelque chose qui m'intéresse, ça pourra me servir un jour dans ma carrière, mais pour l'instant, je n'ai pas le temps de le faire, donc du coup, ce n'est pas grave, je ne vais pas le regarder, je le mets de côté et je sais que je pourrais y revenir super facilement. Et vous aurez dans ma note Notion, justement, le template pour ça, pour très facilement le mettre sur votre Notion et le mettre en place chez vous. Quelque chose aussi d'assez important, c'est d'être capable de relativiser. Relativiser, pourquoi ? Parce que souvent, on parle beaucoup de frameworks, de choses à mettre en place et ainsi de suite. Et en fait, ce qu'il faut aussi être capable de dire, c'est qu'on n'a pas tous les mêmes moyens, on n'a pas tous le même temps, les mêmes capacités et ce n'est pas grave, ce n'est pas quelque chose de fondamentalement gênant. En effet, si vous êtes dans une entreprise où vous avez 25 products, peut-être que vous avez plus le temps de faire de la discovery, de passer 40%, 50%, voire 60% de votre temps à faire de la discovery. Par contre, si vous êtes dans une équipe de 4 personnes avec 2 PM, comme c'est le cas chez Mocha, en fait, vous n'avez pas ce temps-là et ce n'est pas grave. Vous êtes capable de se dire « en fait, je n'ai pas les moyens et ce n'est pas gênant. » Ce qui compte à la fin, c'est qu'on apporte de la valeur au user, finalement, la façon dont on le fait, on le fait en fonction de nos moyens et de nos ressources. Pareil pour les frameworks. Dites-vous que les frameworks, c'est bien, ça peut aider à répondre à certaines problématiques, mais peut-être que pour chacun des frameworks, vous pouvez juste prendre quelques petites choses qui sont intéressantes et pas forcément vous dire « je dois tout le temps l'appliquer, dans tous les cas, appliquer 25 frameworks ». Et ça passe aussi pour ce meet-up. Tout ce que je vais proposer ici dans ce meet-up, c'est des visions qui marchent très bien dans un écosystème comme Mocha, mais qui n'est peut-être pas forcément quelque chose qui marche partout. Et dans ce cas-là, je vous invite à vous dire « ça, ça peut être intéressant, je peux le mettre en place de mon côté, ça, ça ne l'est pas et ce n'est pas grave, je passe à autre chose ». La relation au management. Maintenant, on va parler d'une relation hyper importante qui est la relation au management. Il faut savoir que, d'après notre étude, c'est l'une des relations, même c'est la relation, qui a le plus d'impact sur la santé mentale des product managers. Plus de 51% des products, au global, disent que la relation au management, c'est ce qui a le plus d'impact sur la santé mentale. Donc, c'est quelque chose de vraiment extrêmement important sur lequel on va se pencher un petit peu plus longtemps. Premier truc, pour la relation au management, souvent la problématique, c'est les deadlines. En effet, on a tous tendance à se dire qu'on se met des deadlines, et en fait, à la fin, on sait que finalement, on se met des deadlines qu'on sait déjà qu'on ne va pas tenir, et on passe plus de temps en tant que product manager à venir justifier des deadlines et des retards, plutôt qu'à faire notre travail vraiment de priorisation, de mise en place de choses, de discovery, ou de délivrer. Et donc, automatiquement, ce n'est pas passionnant comme chose. Pour les deadlines, quelque chose qui peut être super intéressant à explorer, c'est une méthodologie qui s'appelle shape-up. Pourquoi ? Parce que shape-up, ça va venir vraiment complètement renverser le paradigme, en se disant que l'objectif, ce n'est plus de s'engager sur des features, mais s'engager plutôt sur des problèmes auxquels on va résoudre. Et ça, c'est hyper intéressant, c'est-à-dire qu'en fait, ça vient complètement changer la façon dont on va discuter avec le management. Et on ne va pas dire « Ah tiens, on aura résolu ça », mais « Ah tiens, on aura fixé tel problème, on n'aura pas mis cette feature en place ». Je m'explique globalement, dans shape-up, comment ça se passe comme méthodologie. C'est, au tout début, on va se dire « Tiens, on a un problème sur lequel on a envie de travailler, et ce problème, on a envie de travailler pendant X temps. Et c'est un temps entre une et six semaines qui est complètement défini, ferme, et sur lequel on va s'engager. » Et tout l'objectif…
c'est justement d'être capable de maximiser l'impact qu'on va avoir dans ce temps donné. Donc déjà pour un PM, c'est passionnant parce qu'on doit retravailler la façon dont on fonctionne pour vraiment faire des choses qui viennent s'empiler pour venir construire une feature complète. Et si je prends un exemple un peu bête, imaginons votre problématique, c'est un user qui est à pied et qui vous dit je veux aller plus vite. C'est ça sa problématique. Si en tant que product, vous allez voir une vision un peu d'avenir, c'est-à-dire mon user, je le mets dans une fusée, il va aller super vite, super loin et ça va être trop bien. Mais si jamais le temps imparti pour ça, c'est deux semaines, en fait votre user, qu'est-ce que vous allez faire ? Vous allez lui faire un vélo. Mais un vélo, ça répond à ce problème qu'il veut aller plus vite. Aujourd'hui, il est à pied, il va en vélo, il ira beaucoup plus vite. Et c'est un peu tout le principe de ShapeUp, de se dire en fait, on va arrêter de s'engager sur une feature hyper précise, mais plutôt sur un problème qu'on résout. Ça force aussi un peu d'inventivité côté produit, parce que tout problème peut être résolu par des choses extrêmement simples, comme des choses extrêmement complexes. Et ça vient en fait créer la simplicité. Si c'est simple pour vous, si c'est simple à mettre en place, c'est aussi simple pour le user. Donc c'est ça qui peut être hyper intéressant à travailler avec ShapeUp. Et le gros intérêt que ça a là-dessus, c'est que vous êtes du coup complètement ferme sur vos deadlines. C'est-à-dire que si vous dites à votre Comex, dans six semaines, j'aurai travaillé sur, je ne sais pas, l'amélioration du taux de conversion de ce flow, vous êtes sûr que dans six semaines, votre taux de conversion, vous aurez travaillé dessus pour l'améliorer et vous aurez quelque chose qui sera en production et efficace. Peut-être que vous n'allez l'améliorer que de 5 ou 10%. En attendant, vous savez que dans six semaines, ce sera bon. Et vous n'aurez pas ce truc de dire, je vais créer une énorme feature, ça va être extrêmement complexe, je vais être super en retard, je vais pouvoir m'engager auprès de personne. Et ça vient aussi créer vraiment la confiance entre le management et les équipes produits. Et c'est quelque chose qui n'est pas forcément facile à faire dans certains contextes d'entreprise. C'est pour ça que ça peut être intéressant au tout début de vraiment se dire, la première chose, c'est de réussir à convaincre les stakeholders. Et justement, ces exemples-là sont intéressants pour les convaincre, de se dire, en fait, tu vois, dans six semaines, on aura travaillé sur quelque chose, on l'aura amélioré. Peut-être qu'on n'aura pas une full feature, mais par contre, on aura un truc qui marche et qui est efficace en prod, on n'aura pas de retard. Et de le tester peut-être dans des petites équipes. Typiquement, c'est quelque chose pour le tester sur une sous-partie, une squad, par exemple, et de voir si ça marche bien. Nous, ce qu'on a chez Mocha, c'est qu'on se rend compte, ça nous permet de délivrer extrêmement vite des choses de très bonne qualité et d'avoir des mises en production très régulières. Après les deadlines, parlons roadmap. J'ai vu que c'est un sujet dont tout le monde parle beaucoup sur LinkedIn en ce moment. J'étais très surpris, je me suis dit, ça tombe au bon moment. Les roadmaps, on aime bien faire en général des roadmaps sur le très long terme, avec des grosses roadmaps à trois ans, où je sais exactement ce que je vais faire en Q3 2025. Ce n'est pas forcément une bonne idée. Pourquoi ce n'est pas une bonne idée ? Déjà, parce que premièrement, ça permet d'avoir aucune adaptabilité. Et ça, par rapport au marché, c'est hyper embêtant. Je prends un exemple super concret. On parlait de crise start-up tout à l'heure. Imaginons, vous êtes une entreprise où la majorité de ses clients sont des start-up de 50 à 60 personnes. Globalement, au moment où la crise est arrivée, vous avez dû vous dire, si je veux survivre, mon seul moyen, c'est de shifter et d'aller plutôt vers des plus grosses entreprises, des clients un peu plus importants. Très bien, mais sauf qu'en fait, un client important, il y a des fonctionnalités de base que vous n'allez pas avoir parce que vous avez des start-up qui vont vous demander et qui vont être deal-makers. Typiquement, on prend du SSO. En fait, un client, si vous voulez aller voir un client de 500 personnes, il va vous dire, je veux du SSO, alors que votre start-up de 50, très clairement, ce sera moins intéressant. Et si vous avez cette roadmap qui est complètement remplie, déjà, c'est quasi impossible de finalement se dire, je vais rajouter mon SSO hyper rapidement parce qu'il va falloir tout redécaler et donc, il va falloir se réaccorder avec tous les stakeholders qui sont impliqués par la roadmap pour pouvoir réussir à faire ça. Deuxièmement, ça n'apporte pas d'agilité en interne aussi. Fondamentalement, dans nos équipes produits, on passe notre temps à chercher, à avoir des idées et des fois, on a des super bonnes idées qui prennent auprès de toute l'entreprise, on a trop envie de les travailler. Et en fait, si ma super bonne idée que j'ai aujourd'hui, je me dis, la seule place disponible, c'est Q4 2026, ce sera peut-être plus une si bonne idée que ça, à ce moment-là, ce ne sera pas très utile. Et enfin, dernier truc, ça peut être super frustrant. Imaginez un sales, il faut se mettre à sa place à ce moment-là, imaginez un sales finalement qui voit que sa feature qui est deal breaker, elle arrive dans deux ans. Lui, il sait que son deal est perdu, sauf s'il travaille sur des longueurs de sales cycle beaucoup plus importants et du coup, on crée la frustration dans toutes les équipes. Donc, l'idée n'est pas de dire, on supprime la roadmap, ce n'est pas ça que je veux proposer très clairement parce que la roadmap, elle a un intérêt principal qui est de dire, je donne de la visibilité, à la fois, moi en interne, dans mon équipe, au sein de toute l'entreprise et peut-être même en externe auprès de mes clients, selon si on décide de la communiquer ou pas. Mais en fait, si on se pose la question de qu'est-ce qui est vraiment important à ce moment-là, c'est de se dire, ce qui est hyper important pour tout le monde et qui doit être très fixe avec une grande certitude, c'est ce qu'on travaille maintenant, ça, on ne doit pas s'en servir de surprise sur ce qu'on est en train de faire, avec un peu moins de certitude, parce qu'on va travailler sûrement juste après et avec encore moins de certitude, on n'est vraiment pas sûr, on n'a pas envie de commit sur le sujet, parce qu'on travaillera beaucoup plus tard. Et ce qui est hyper intéressant avec ça, c'est que vous gardez la visibilité pour tout le monde, tout le monde va réussir à comprendre, finalement, comment avance le produit, vers quelle vision on va, mais en même temps, vous gardez énormément de flexibilité. Et ça, c'est hyper pratique. Et moi, si je vous prends un exemple chez Mocha, qui est assez marquant, je trouve, il y a trois mois maintenant, je pense, je m'arrête, Bérangère, s'il dit des bêtises, il y a trois mois, Bérangère qui est ici, elle travaillait sur un sujet qui était de se dire, comment on va mieux former les managers à la santé mentale ? Sujet hyper intéressant, et au départ, c'était parti sur vraiment quelque chose d'assez simple, de se dire, tiens, on va mettre du contenu un peu spécifique et c'est tout. Et finalement, quand toute l'équipe a bossé dessus, il y a eu une super bonne idée qui était de se dire, pourquoi on ne les formerait pas d'une autre manière, on n'inventerait pas une autre manière de former les gens ? Et on s'est dit, tiens, est-ce qu'on ne ferait pas une thèse de micro-learning sur Slack ? Et quand on a proposé cette idée-là, toute l'entreprise s'est dit, ah, c'est une super bonne idée, c'est trop bien. Donc, vous connaissez les sales, ils ont commencé à le pitcher aux clients. Et les clients ont dit, ah, mais trop bonne idée, je pense que ça va vraiment répondre à une problématique, parce qu'en effet, moi, j'ai du mal à faire venir les gens à des ateliers de deux heures sur gérer sa santé mentale et ainsi de suite. Par contre, si je leur dis, sur Slack, tu as un petit bot un peu sympa qui va t'envoyer un message, ça va marcher. Et ça, c'était il y a trois mois l'idée. Et en fait, aujourd'hui, on va le lancer publiquement. Très précisément aujourd'hui, on l'a lancé publiquement d'ailleurs. Et on a pu le faire parce que justement, en fait, on avait cette flexibilité dans le roadmap de se dire, OK, est-ce que dans ce soon, finalement, on ne peut pas dégager des choses qui sont un tout petit peu moins urgentes que ce pari-là qu'on a envie de faire parce qu'on se dit qu'on y croit à notre sujet et qu'on a vraiment envie d'avancer. Partie leader. Alors, pour ceux qui me connaissent, je ne suis leader de rien du tout en produit. Mais c'est intéressant, c'est, on a posé, dans l'étude, il y a pas mal de retours qui sont venus justement sur le rôle du product leader et notamment sur des problématiques que je trouve assez intéressantes et on va passer au conseil tout de suite parce qu'il est très simple, qui étaient les pratiques de communication. Globalement, la plupart des gens disaient, en fait, je n'ai pas de vision produit, ce qui est quand même très embêtant pour quelqu'un qui travaille dans une équipe produit. Ma roadmap change en permanence, je ne comprends pas vraiment ce qui se passe et tout est assez flou. Et je trouve que ça, c'est hyper intéressant, c'est de se dire, en fait, aujourd'hui, le rôle du product leader, ça doit être de communiquer et de communiquer en externe. Et je pense que ça, c'est quelque chose qu'ils font tous très, très bien, mais aussi en interne de mon équipe et communiquer quel que soit le niveau de certitude que j'ai sur les choses. Et je pense qu'il y a souvent une erreur qui est faite, qui est de se dire, moi, je le prends de mon côté non leader justement, c'est de se dire, souvent, on se dit, si les choses ne sont pas certaines, il n'y a pas besoin de les communiquer aux opérationnels parce que finalement, ça va peut-être être amené à changer. Mais au contraire, justement, c'est là où c'est intéressant de venir créer cette communication-là parce que ça permet de dire aux gens, peut-être que des choses vont changer plus tard, mais au moins, tu es au courant directement. Plutôt que d'avoir ces effets-là qui peuvent être assez complexes, de se dire, du jour au lendemain, on vient bouleverser ta roadmap, on te dit finalement ta priorité, ce n'est plus la même priorité et toi, tu n'as toujours pas compris pourquoi et tu es en mode, OK, j'ai bossé trois mois pour rien. La relation aux équipes client-facing et aux clients. Relation qui peut être prenante, surtout qu'en général, on en a beaucoup en face de nous et on a beaucoup de feedback. Et donc, la question, c'est comment on peut faire en sorte de mieux gérer ça, de mieux gérer ces retours, ces demandes permanentes, ces feedbacks permanents. Et ce qui est assez intéressant, c'est que ce sont des choses qu'on peut faire nous et pas forcément qu'on peut leur demander à eux parce que ça, c'est toujours plus compliqué. Sur la gestion des demandes. Un premier truc, c'est comment on accueille la demande. Et je pense que c'est hyper important de se poser là-dessus et de se dire, OK, comment on peut accueillir une demande correctement ? Et pour ça, il y a un principe qui est pas mal utilisé, notamment par les psychologues, mais qui peut être utilisé par tout le monde et je vous invite vraiment à ce que tout le monde l'utilise, qui paraît très simple et qui est en fait très complexe et qui s'appelle l'écoute active. Et en gros, ça part du principe de se dire que on ne sait pas vraiment écouter les gens de base. C'est-à-dire que quand on se parle à deux, finalement, on ne s'écoute pas tant que ça et on est plus là pour rebondir en permanence et pas pour vraiment s'écouter. Et tout le principe de l'écoute active, c'est de se dire, justement, on va changer ça et je vais créer de la confiance avec la personne en commençant déjà par dire, je l'écoute et je reste complètement silencieux. Ce qui est, je pense, la chose la plus dure à faire. Moi, je suis très bavard, donc c'est très compliqué. Ne pas transmettre de jugement. Donc pareil, vraiment, je la laisse donner sa vision et je ne retransmets pas de jugement. Je ne ramène pas la discussion à moi et ça, je pense que c'est hyper intéressant, notamment en produit. On peut facilement avoir ce truc-là et je pense que je suis dans ce gros défaut, de se dire, très bien, je le ramène en fait à ma roadmap, à mes priorités, à mon travail en cours. En fait, là, ce n'est pas la question. Quand quelqu'un vient vous faire un feedback ou vous faire une demande, il n'a pas forcément envie que vous lui rappelez les priorités du moment, mais il veut, lui, s'expliquer.
et dans un premier temps, il faut être capable d'accueillir cette demande-là, quitte à ce que vous lui disiez non après. Je suis en train de dire qu'il faut dire oui à tout le monde. Reformuler, du coup, en utilisant les mots de l'autre, c'est pareil, technique très simple, c'est quand on utilise les mots d'une personne, elle se sent beaucoup mieux comprise. Donc on n'a pas besoin de reformuler de manière très complexe, il faut juste réutiliser ces mots et s'assurer justement, en reformulant, on verbalise ce qu'on a compris, pour être sûr qu'il n'y ait pas de malentendu, et on va parler malentendu juste après, et avoir une attitude supportive. Pareil, ne pas être fermé, parce que si vous venez me parler, comme ça, vous n'avez pas très envie de me parler, je pense, et vous ne vous sentez pas super écouté. L'incompréhension, qui est justement dans cette gestion des demandes, peut être hyper intéressante, quand on modélise un petit peu une discussion entre deux personnes, notamment dans des conflits. Ce qui est assez intéressant, c'est que souvent, on commence avec beaucoup de désaccords et un petit peu d'accords, et au moment où on commence à discuter, il y a une énorme part de malentendu et d'incompréhension qui vient se créer, et finalement, c'est justement tous ces côtés un peu écoutes actives, la capacité à prendre du recul, à vraiment discuter avec la personne, et à reformuler les choses, utiliser ces mots, et ainsi de suite, qui permet de venir un petit peu supprimer ce malentendu, pour arriver à la fin sur quelque chose, où en fait, on est d'accord sur pas mal de choses. Et donc ça, c'est un très bon conseil, qui est très dur à appliquer, et moi, si je prends un exemple où je ne l'ai pas appliqué justement, et je ne l'ai pas bien fait, parce que je pense qu'on apprend beaucoup plus de ses erreurs que de ses succès, il n'y a pas très longtemps, il y a quelqu'un de client-facing qui est venu nous voir, en nous disant, ok, il faut changer ce message d'erreur sur cette page, spécifiquement pour ce client, il faut écrire un message d'erreur particulier. C'était une page de connexion. Ce jour-là, j'étais un petit peu stressée, j'avais beaucoup de choses à gérer, et du coup, j'ai fait la chose qui n'est pas la bonne chose à faire, qui était de fermer la porte très très rapidement, et dire, no go, on n'avance pas sur le sujet, on ne va pas faire ça, parce qu'on ne va pas créer du custom en mettant une erreur très précise. Donc ça, c'est bien, c'est exactement ce qu'il ne fallait pas faire. Et là, Héloïse a bien fait les choses à ce moment-là, il fallait justement discuter, se dire, en fait, quand on a discuté avec la personne, on s'est rendu compte que toute la problématique, ce n'était pas du tout une problématique très tech, de ce message d'erreur n'est pas bon, ainsi de suite, toute la problématique, c'était, elle, elle avait un client où il n'y avait pas assez d'activation dessus, elle était stressée, du coup, et elle avait besoin de faire de l'activation. Sauf qu'en fait, quand on discute de ça, et qu'on a mis, qu'on a tous malentendu un peu parti, la solution, elle est hyper simple, comme nous, activer un client, c'est juste se dire, on va lui envoyer un email un peu bien targueté pour qu'il y ait des comptes qui soient créés, et on va y arriver. Et en fait, finalement, on est parti d'une situation où moi, j'étais insatisfaible et frustrée parce qu'on m'a fait une demande que je ne trouve pas légitime, la personne en face est complètement frustrée parce qu'on lui a mis une porte, à un moment où moi, avec 1% d'effort, j'ai 100% de satisfaction de la personne en face. C'est ça qui est intéressant aussi de se dire, c'est que quand on partage et qu'on arrive à un peu supprimer ces malentendus, on va venir être capable de proposer des solutions qui nous arrangent tous, parce que je pense qu'à la fin, on sert tous le même but dans une entreprise, donc on a aussi envie que les gens puissent avancer. Les demandes custom, je pense grande spécialité, l'habitude de tout le monde, avoir soit un sales qui vous dit, oui, moi, il me faut exactement ce truc-là, mais à peu près ce qu'il y a aujourd'hui, mais pas exactement ce qu'il y a aujourd'hui finalement, parce que sinon, mon client ne signe pas. Je pense que c'est un peu notre vie et c'est assez intéressant. Et comment on peut mieux les gérer ? Je pense qu'il n'y a quasiment aucune réponse officielle sur ce sujet-là et je serais hyper intéressée qu'on en discute après d'ailleurs, mais je vais vous présenter un peu trois façons qui peuvent permettre d'aider ces sujets-là. Première chose, la formation. Parce qu'en fait, si vous avez des demandes custom, déjà, ce qu'on se rend compte la plupart du temps, c'est que les gens ne connaissent pas assez votre produit et ne savent pas forcément que vous pouvez répondre à cette problématique en tweakant un petit peu le produit, en utilisant des fonctionnalités un petit peu différemment que ce qu'on a l'habitude. Donc vraiment les former. Et aussi les former sur la façon dont vous fonctionnez dans l'équipe. Parce qu'en fait, finalement, les gens peuvent se permettre de faire des demandes custom et ainsi de suite parce qu'ils ne comprennent pas votre métier. Ils ne comprennent pas ce que vous faites au quotidien. Et je pense qu'on a du mal en tant que produit à se rendre compte qu'on fait partie des rares équipes avec des process extrêmement précis, avec des façons de fonctionner extrêmement précises et extrêmement calcables dans toutes les entreprises. Alors que finalement, une équipe sales ou finance, elle peut fonctionner de 15 manières différentes selon l'entreprise dans laquelle elle est. Comment on forme les gens ? Je ne vais pas inventer la roue là-dessus, mais globalement, ce qui peut être intéressant, c'est de se dire qu'on les forme déjà dès qu'ils arrivent. Et donc notamment, à leur onboarding, venir. Nous, on a fait, par exemple chez Mocha, quelqu'un qui est onboardé depuis pas longtemps, on va lui donner un petit challenge d'aller faire des choses dans le produit. Et qui qu'il soit, ça peut être quelqu'un du support ou ainsi de suite, on va lui donner accès à la partie, par exemple, de gestion RH qui n'est pas accessible pour les employés en temps normal pour qu'elle ait un petit challenge et qu'elle aille essayer le produit et bien le comprendre déjà pour pouvoir s'y faire. Et après, la former sur les process. Et d'autres choses qu'on fait, c'est, par exemple, quand on a une grosse feature importante, du coup, on fait des pléniers, entre guillemets, où on va dans l'open space, on passe une demi-heure à expliquer toute la feature, pourquoi on la fait, pourquoi elle est intéressante, qu'est-ce qu'elle permet de faire et surtout aussi, qu'est-ce qu'elle ne permet pas de faire et là où on va avancer. Ça peut être aussi des Q&A à organiser de temps en temps. Je pense que c'est assez intéressant pour certains sujets de se dire, OK, vous prenez toute l'équipe concernée et vous faites une heure où ils vous posent toutes les questions et vous autorisez les questions les plus bêtes et ce n'est pas du tout un souci. Moi, typiquement, un truc que je faisais aussi dans mon ancienne entreprise, c'était un truc que j'avais appelé « take four demise » et qui était de se dire, OK, je vous donne une heure où moi, je suis disponible et vous pouvez me poser les questions les plus nulles possibles, ce n'est pas grave. En fait, l'objectif, c'est que vous soyez formés, que vous compreniez et que vous ne les reposiez pas. Et ça peut être aussi venir à certains moments très spécifiques et c'est l'exemple ici, la semaine dernière, il y avait le sales day de ce trimestre où nos sales s'étaient réunis pendant une journée et justement, je suis venue une heure pour dire, OK, comment ça marche notre process ? Le gros focus a été notre process, comment il fonctionne, c'est quoi en fait, qu'est-ce que je fais au quotidien, qu'est-ce que toute l'équipe fait au quotidien et pareil, après, reparler un peu de comment on fait la démo, de pitcher le produit, et ainsi de suite. Et ça, c'est hyper important parce que vous allez aussi leur donner de la visibilité. Conseil qui marche mieux, encore plus, boire des verres, très clairement, c'est une blague et pas vraiment une blague en même temps, quand vous créez du lien social avec les gens et je pense notamment pas mal aux équipes commerciales qui peuvent être des fois un petit peu séparées des autres équipes dans les entreprises, quand vous créez du lien social, vous allez vous rendre compte que finalement, ça va résoudre énormément de vos problèmes que vous pouvez avoir avec ces équipes-là. Et moi, je prends un très bon exemple. Justement, on voulait pouvoir passer du temps à venir dans des démos de sales pour pouvoir y assister et c'est quelque chose qui était assez compliqué parce que l'équipe sales ne nous proposait pas forcément, on avait un peu du mal, ce n'était pas le sujet qu'on avait réussi à mettre en place et finalement, en buvant des verres, je me suis retrouvée avec un sales qui m'a un peu défiée de venir à une démo avec lui. J'étais très contente à ce moment-là et c'est un peu comme ça qu'on a déclenché le truc. On a un peu dit « Ok, je vais venir à une démo, ça s'est bien passé » et du coup, on s'est dit « Ah, il faut peut-être qu'on essaye de faire en sorte que ça se passe mieux et que les autres personnes de l'équipe produit puissent aussi venir à des démos. » Et donc vraiment, buvez des verres, ça vaut le coup. C'est peut-être le meilleur moyen pour avoir des bonnes relations avec les équipes client-facing et que vous compreniez aussi parce que je pense que c'est à ce moment-là où vous allez vraiment avoir au quotidien, qu'est-ce qui eux les frustre et ça peut permettre de créer une meilleure relation après. Et enfin, si tout ça ne marche pas, un petit conseil qui est un conseil donné par un PM de chez AWS que je trouvais hyper intéressant qui est de se dire que si vous n'arrivez pas à rendre ces équipes un peu plus actrices que demandeuses, vous pouvez les forcer à être actrices, entre guillemets. C'est moins sympa comme ambiance mais ça marche bien. C'est de se dire que globalement, vous avez un problème et c'est de se dire globalement, vous avez un principe, vous dites à la personne qui est responsable de l'équipe client-facing, vous lui donnez un token qui représente une semaine de développement de 2Dev par exemple sur un trimestre. Et vous lui dites « Ok, à partir de maintenant, il y aura une semaine dans le trimestre que je pourrai t'allouer pour faire un truc custom que tu auras décidé. » Bien sûr que c'est vous qui allez scoper les choses et on ne va pas mettre n'importe quoi dans le produit mais par contre, la problématique auxquelles on répond, c'est elle qui le décide. Et là, ce qui est hyper intéressant c'est que vous venez de complètement renverser les choses parce que finalement, c'est votre head of sales qui se retrouve à faire une partie de votre métier de devoir prioriser et de devoir prioriser avec son équipe et devoir dire à ses sales « Attends, en fait, là ce que tu demandes, moi je n'ai pas envie d'utiliser mon token pour ça, ce n'est pas ça qui est dealmaker. Je vais peut-être attendre un petit peu ou je vais peut-être le faire pour un autre sujet qu'on m'a proposé. » Donc, ça peut être fait et je pense que c'est assez intéressant parce que ce qu'on peut gagner là-dessus, c'est que vous êtes dans une situation où vraiment, il y a un délai réel avec l'équipe et les sales ont l'impression que vous, vous ne faites rien pour eux et vous, vous n'en pouvez plus leur demander. Ça peut être un moyen de créer une vraie solution parce que finalement, en fait, une fois par trimestre, il y aura une feature qui sera faite ou un bout de feature qui sera fait pour les sales. Après, si ça se passe bien, je pense qu'il vaut mieux partir sur les autres solutions d'avant, former, discuter, c'est plus sympa quand même. Enfin, la relation à l'équipe tech. Ce qui est très cool déjà, là où je suis très contente, c'est que dans l'étude, c'est-à-dire que ça marche un peu mieux que ce qu'on peut dire et entendre dire des fois. Première problématique, c'est comment on s'aligne. C'est souvent un truc qu'on voit assez fréquemment qui est de se dire, en fait, on a un head of product qui doit lancer une feature et on a un head of engineering qui doit diminuer sa dette technique. Déjà, on sait que là, on est foutu parce que finalement, comment ça marche ? Qu'est-ce qu'on priorise en termes de développement ? Est-ce qu'on priorise du développement pour aller vers des nouvelles features et du business ou du développement pour limiter ou pour diminuer la dette technique sachant qu'en plus, aller vendre à des stakeholders ce que diminue la dette technique ?
La dette technique, c'est quelque chose qui est intéressant pour plus tard, pas forcément facile. Il y a une réponse qui est apportée souvent à ça, qui est de dire on va créer un CPTO. Honnêtement, je n'y crois pas forcément, parce que je pars du principe que juste on crée un niveau d'hierarchie en plus et qu'à la fin, on aura toujours un Head of Product qui n'aura pas le même objectif que le Head of Engineering et du coup, ça n'a pas trop marché. Par contre, un truc hyper simple et qui marche extrêmement bien, c'est des objectifs communs. Quand je dis objectifs communs, ce n'est pas quelques objectifs communs. C'est 100% des objectifs complètement communs aux deux équipes. Par exemple, chez Mocha, nos OKR sont exactement les mêmes pour l'équipe produit et l'équipe tech et surtout, ce qui est hyper intéressant, c'est qu'on commis tous sur ces OKR-là. Je trouve que c'est un aspect hyper sympa. Déjà, en produit, c'est cool parce que quand quelqu'un travaille sur la dette technique, vous n'avez rien fait et votre OKR est rempli. Franchement, ça peut être un bon avantage, mais surtout, vraiment, c'est que ça vient permettre de créer une situation où quand il faut prioriser, quand il faut se dire, est-ce qu'on fait plutôt passer ce thème-là ou est-ce que ce thème sur la data, on va plutôt y passer deux semaines ou quatre semaines, on va pouvoir se dire, en fait, c'est un de nos OKR aussi. Typiquement, en Q3 2022, un de nos OKR, c'était de créer une nouvelle data architecture. En fait, à ce moment-là, on se dit, oui, on va passer du temps dessus, on va investir du temps d'aide sur le sujet et on va passer nos OKR. Et du coup, il n'y a vraiment zéro question qui se pose et il n'y a aucune bataille qui peut se faire parce qu'en fait, on est tous alignés, on a tous comité sur exactement les mêmes choses. La responsabilisation. Je pense que c'est assez marrant parce que quand je parle à beaucoup de PM récemment et quand j'en discute, souvent les reproches qui viennent sur les devs, c'est, en fait, j'en ai marre, ils ne suivent pas mes specs, quoi que je fasse. De toute façon, et quand je tais, ça ne marche jamais. Bon, ça déjà, oui, souvent ça ne marche jamais quand on taise, on fait de la tech. Mais je pense que la question qui est intéressante à se poser là-dessus, c'est, est-ce que c'est de leur faute ou est-ce que c'est de notre faute ? Et bien, je pense que la réponse, elle est beaucoup plus de c'est de notre faute. On s'attend à ce que des gens soient responsables en les infantilisant énormément et en leur laissant aucune possibilité d'être justement des ingénieurs réellement. Et c'est ça que je trouve assez intéressant, c'est de se dire, comment on transforme la vision et qui en plus est une vision assez française, française ou européenne, parce qu'on n'a pas trop ça aux Etats-Unis, mais comment on transforme la vision d'un dev comme quelqu'un qui est exécutant et qui va juste être responsable de développer ce qu'on lui a demandé de développer en un dev qui est quand même un ingénieur, c'est-à-dire qui le connaît le produit. Et d'ailleurs, je pense que le meilleur exemple pour dire que les devs connaissent le produit ou une capacité de compréhension du produit, c'est qu'en général, quand il n'y a pas de specs et qu'on ne sait plus comment marche le produit, on va demander aux devs d'aller chercher dans le code. Finalement, ils peuvent le comprendre ce produit-là. Et pour ça, solution un peu radicale, mais en fait, ce n'est pas si radical que ça, c'est de se dire, OK, il faut peut-être arrêter avec les spécifications techniques hyper complexes, et typiquement les PRD qui font 25 km. Déjà, ce n'est pas passionnant à écrire, ça ne sert à rien, parce que comme vous le dites, en effet, un dev, de toute façon, il ne va pas le faire. Mais pas parce qu'il n'a pas envie de le faire, il ne va pas le faire, parce qu'il ne sera sûrement pas capable de le faire, parce que quand il va aller dans le code, il va se rendre compte que ce que vous proposez, ce n'est pas la bonne idée techniquement. Et ça, ce n'est pas du tout un souci. Il va aller vers des choses beaucoup plus simples et se dire, en fait, vous, en tant que product, vous pouvez faire une spécification très conceptuelle de ce qu'on veut, mais après, la spécification ultra technique de comment ça se passe dans le code, vous devez la faire, soit c'est le dev qui le fait tout seul, soit vous devez la faire avec un dev, parce que sinon, vous n'avez pas la capacité de le faire. Et pour ça, nous, ce qu'on fait, par exemple, chez Mocha, c'est, globalement, avant de lancer un chantier, plutôt que d'avoir des énormes specs de tous les côtés, et ainsi de suite, on a une note comme ça, qui n'est vraiment pas beaucoup plus grande que ça en temps normal, qu'on partage avec les devs, qui est notre note de kick-off, ce avec quoi on commence à travailler, et qui est de dire, ok, on répond à tel problème, on a tels objectifs, on a telle métrique de succès, voici les designs qu'on a imaginés, et qui vont pouvoir être amenés à changer si jamais on se rend compte qu'ils ne peuvent pas, qu'on ne peut pas les faire, et après, on a une liste d'initiatives, mais qui n'est pas un truc, là, j'ai changé le texte, mais fondamentalement, l'initiative, c'est sur un thème qu'on a en ce moment, elle faisait vraiment cette taille-là. C'est de se dire, ok, typiquement, problématique récente, il y a une fonctionnalité sur Mocha qui est de rechercher un praticien, et les filtres qu'on fait pour ces praticiens n'étaient pas mis en mémoire. Est-ce que j'ai besoin de faire une spécification technique pour expliquer pendant 4 heures la manière dont je veux que mes fils soient en mémoire, alors qu'en plus, en tant que produit, j'en ai un peu aucune idée, ben non, finalement, en gros, ce que je dis à mon dev, c'est, moi, ce que je veux, c'est que mes filtres restent en mémoire, parce que j'ai envie que tu ne retapes pas ton fil 25 fois à chaque fois que tu fais une recherche. Et après, c'est le rôle de mon dev d'aller lui se dire, OK, qu'est-ce que je peux te proposer ? Est-ce que j'ai des solutions super simples, et je peux te proposer de te dire, ben tiens, je ne sais pas, ça va s'enregistrer sur un cookie, et du coup, c'est bon, et c'est déjà en place en 2 jours, ou est-ce que j'ai des solutions complexes, et ça, on va en discuter. Et c'est ça qui est intéressant, c'est de vraiment se dire, ben en fait, vos devs, ils ont une super bonne connaissance, et plus vous leur donnez la responsabilité, mieux ça va marcher. Et je pense que c'est souvent le truc, c'est qu'on se dit, ben oui, ils ne sont pas assez responsables, mais on ne leur donne pas la responsabilité. Si vous leur donnez 100% de responsabilité, la plupart du temps, ils vont vous prouver qu'ils en ont, de la responsabilité, et qu'ils peuvent gérer les choses. Et on le voit notamment, moi je trouve que c'est un truc qui est assez formidable, et que je n'avais pas vécu ailleurs, c'est typiquement quand il y a un incident. Moi, mon habitude, c'est quand il y a un incident, globalement, mes devs se disent, je me casse, je m'en vais, et toi, tu es là un peu tout seul, en train de dire, OK, je vais tout gérer, on va voir si ça passe ou pas. En fait, chez Mocha, les devs sont tellement impliqués dans le produit que les jours où il y a eu un... Jules s'en va à ce moment-là. Les jours où il y a eu un incident, Jules qui était là, justement, il n'y a pas très longtemps, ils étaient complètement autonomes. C'est-à-dire qu'en gros, moi j'ai vu l'incident, je n'avais pas besoin de leur dire, ah tiens, il faut que tu fasses ça, comment tu fais, comment tu gères, et ainsi de suite. Non, ils se sont mis ensemble, ils ont discuté, ils se sont dit, OK, on prend du temps, on met un plan d'action, et en fait, une heure plus tard, il n'y avait plus d'incident. Et c'est ça qui est intéressant, c'est de se dire, vous vous responsabilisez, vous êtes tellement rendu maître du produit aussi, que du coup, les jours où il y a des problèmes, ils vont vers ça. J'ai beaucoup parlé. J'ai énormément parlé, j'ai l'impression. Moi, ce que je trouvais intéressant, c'est que vous vous posiez un peu sur, tiens, lequel vous avez un peu envie d'appliquer, et si vous avez des questions là-dessus, je suis ravie qu'on prenne des questions. Et sinon, je vous invite à tous cligner ce petit QR code, puisque, comme je vous l'avais dit, vous n'avez pas besoin de prendre des notes. J'ai fait une grosse note notion avec tous les conseils résumés. Ça évite de passer son temps à écrire. Je ne sais pas combien de temps j'ai duré. Est-ce que tout le monde a pris le petit QR code et je peux changer le slide ? Au pire, je renverrai le QR code. Est-ce que vous avez des questions ? Enfin, déjà, merci beaucoup de m'avoir incité. Moi, je vais prendre le micro parce que c'est moi qui l'ai, donc je fais ce que je veux. Moi, j'ai une question. Tu as parlé de l'étude et puis on en a déjà parlé un petit peu de ce que vous allez, vous, en faire. Après, parce que je sais que vous allez la communiquer. Il y a des gens qui me posaient la question. D'ailleurs, est-ce que là, comme ça, dans la salle, l'étude dont on a parlé, ça vous parle ? Est-ce qu'il y a des gens qui ont participé ? Il y a une étude qui a... Ouais, il y a une, deux mains. Quand vous la recontextualisez, au moment où on a voulu faire ce meet-up sur la santé mentale, on s'est dit le sujet, il est un peu... On ne sait pas trop où on va aller, parce que pour le coup, c'est un sujet dont on a envie de parler, on ne sait pas forcément si ça va fédérer et tout. Et de voir tout ce monde-là, ça nous fait dire une chose, c'est qu'on avait raison et que le sujet fédère. Mais je voulais te poser la question de c'est quoi les curiosités que toi, tu as pu voir dans cette étude ? Moi, par exemple, il y en a une dont je suis assez... Je ne sais pas encore si je sais dire agréablement surpris ou pas. C'est que dans les participations qu'on a d'habitude dans le public, on est plutôt 50-50 hommes-femmes. Là, quand on se regarde, il n'y a pas 50-50 hommes-femmes, il y a quand même une plus grosse majorité de femmes que d'hommes. Donc ça veut peut-être ou pas dire certaines choses de l'intérêt des hommes sur la santé mentale ou pas. Est-ce que toi, tu en as vu d'autres aussi au cours de cette étude ? Déjà, je vais répondre sur le dernier point. Moi, je trouve que ce n'est pas justement pas une bonne chose qu'il y ait une majorité de femmes ce soir parce que c'est un peu toujours le cas qu'on parle de santé mentale et du coup, les femmes viennent et en fait, c'est un sujet complètement global et il faut que les hommes apprennent à parler de leur santé mentale aussi. C'est important et ça nous ferait tous du bien, je pense très clairement. Dans les petites choses qu'on a vues, qui sont intéressantes dans l'étude, déjà, comme je le disais, la relation en management en tant que relation qui a le plus d'impact, pour moi, c'était une vraie surprise parce que mon pari personnel et un peu la manière dont j'avais fait la question, c'était plutôt pour valider le fait que c'était les équipes client-facing et les feedbacks qui avaient le plus d'impact sur la santé mentale et on m'a tous dit « apparemment non ». Du coup, j'ai trouvé ça assez intéressant. Il y a quelques axes aussi qui peuvent être intéressants. Le fait que les résultats des PMM, je regarde Pauline comme ça, les résultats pour les product marketing sont beaucoup plus mauvais que les autres. Je pense que si vous avez des PMM dans votre équipe, allez leur faire un petit câlin demain parce que, notamment sur la partie relation management, intensité et temps de travail, c'est beaucoup plus présent que dans d'autres équipes. Je pense que ça a peut-être plein d'explications qui est de se dire que c'est un métier qui est hyper nouveau. Aujourd'hui, souvent, quand on prend un PMM dans une équipe, c'est aussi des fois parce qu'il y avait vraiment besoin d'un PMM et déjà depuis un an, c'est complètement sous l'eau. Mais en même temps, je pense que c'est quand même un truc où il faut un peu s'alarmer sur le sujet et se dire que nos PMM aujourd'hui, on a envie qu'ils aillent bien, qu'ils aillent au moins aussi bien que les autres. Qu'est-ce qui est ressorti ? Ce qui est très cool, c'est que dans l'étude, on a 50-50 hommes-femmes, enfin 49, quelque chose, mais on est
à égalité. Et qu'est-ce qu'on apprend d'autre? Plein de trucs, j'ai le droit de garder des surprises, donc plein de choses qu'on va communiquer dans pas longtemps, la semaine prochaine en fait. Vous verrez ça la semaine prochaine et il y aura pas mal de trucs autour de l'étude aussi, je pense notamment il y aura sûrement un livre blanc avec les conseils que vous avez un peu déjà vu, mais il y aura aussi des petites newsletters assez intéressantes sur le sujet. Je suis pas le seul à être gêné avec un micro, c'est parfait. Déjà merci pour l'étude, t'as pas mal parlé de la gestion des stakeholders, du management, etc. On n'a pas forcément parlé de la charge mentale du product manager qui est au fond au moulin sur tous les sujets. Je ne sais pas si c'est ressorti dans ton étude. Ouais, si c'est un truc qui est ressorti et on n'a pas forcément énormément parlé en effet, déjà parce que je ne sais pas s'il y a une solution à ça. Le rôle de PM est aussi un moment de passer son temps et dans l'étude il y a un verbatim qui est assez intéressant justement, qui est de se dire que c'est hyper compliqué de passer son temps à bosser sur du passé et regarder derrière, gérer ce qu'on fait en ce moment et regarder le futur. Mais en même temps c'est notre taf. Donc je pense que si on arrive à gérer un peu tous les autres trucs autour finalement et à se mettre des limites, qui est quand même la meilleure moyen d'y répondre, on pourra peut-être y arriver, mais malheureusement ça sera toujours notre travail et c'est ce qui fait qu'il est très cool aussi parce que si toi tu bosses que sur le passé, c'est pas fou comme métier de PM de regarder ce qu'on fait tes autres copains PM pendant ce temps-là. Moi j'ai une question sur le point que tu as évoqué tout à l'heure sur les roadmaps, ça m'intéresse pas mal, je voulais savoir un peu comment tu fais pour manage expectations, est-ce que tu t'engages sur des deadlines, encore un autre sujet dont tu as parlé très précise, parce qu'on en a parlé rapidement avec le now, soon et later, mais concrètement comment ça se passe chez Mocha par exemple, est-ce que la roadmap est communiquée en interne, en externe ? Oui, hyper intéressant, alors on ne s'engage pas sur des deadlines justement, en fait ce qui est intéressant c'est que plus tu avances dans ta roadmap, dans le now tu es très certain et donc tu peux t'engager entre guillemets, moi aujourd'hui typiquement je peux m'engager sur les choses que je suis en train de travailler maintenant et les problématiques auxquelles je vais répondre maintenant, sur le soon déjà je peux beaucoup moins m'engager, c'est-à-dire je peux dire c'est des choses où je sais que je vais aller creuser, je vais aller faire de la discovery, par contre peut-être, et ça c'est un truc qui est en effet hyper intéressant dans la formation, nous qu'on a rappelé au sales il n'y a pas longtemps, c'est de se dire que quand on fait de la discovery en produit, peut-être qu'on va tout abandonner, et souvent les gens ne l'ont pas en tête forcément, et du coup ils nous entendent parler à certains moments de « tiens ce sujet-là » et ainsi de suite, puis après ils n'entendent plus parler, ils se demandent « pourquoi vous ne le faites pas ? » « ben oui parce qu'on s'est rendu compte que c'est une mauvaise idée, moi ça m'est arrivé il n'y a pas longtemps où on a fait des user interviews, on s'est rendu compte que tout ce qu'on avait prévu, littéralement tout ce qu'on avait prévu, personne ne le voulait, donc on s'est dit « bon ben on va faire autre chose sur ce thème », donc là-dessus tu peux t'engager un peu plus en disant c'est des choses qu'on expérimente, et après sur le later tu ne t'engages pas en fait, c'est de dire « aujourd'hui c'est nos axes » et je pense ce qui est intéressant c'est que cet engagement on te le demandera au tout début, quand tu as l'habitude des très très grosses roadmaps, mais après quand les gens voient le gain que tu as avec de la flexibilité, finalement on te le demandera beaucoup moins, parce que tu vois nous typiquement chez Mocha, personne nous a engueulé parce qu'on a changé tout ce qu'on avait prévu dans le later pour mettre Félix qui était le truc, vraiment le produit phare où on s'est dit « ah tiens on a envie d'investir là-dessus », et donc du coup c'est un peu ce truc-là quoi. Très clair, merci beaucoup. Merci beaucoup, moi j'avais une question sur les spécifications parce que j'en discutais avec mes collègues tout à l'heure, en deux jours moi j'ai fait 13 heures de tests à peu près, donc ça fait beaucoup de temps, et j'ai écrit des specs assez poussés, et du coup sur l'engagement de tes devs, comment tu as fait pour que le plus tôt possible ils soient impliqués dans ne pas avoir de spécifications, parce que moi les remarques souvent que j'ai c'est « si tu me fais pas de specs, je fais comme je veux et si ça ne va pas, t'as qu'à assumer quoi ». Merci. Je pense que ça vient déjà principalement de l'équipe tech de base, c'est eux qui ont été très demandeurs de ça, je regarde mon head of engineering derrière en parlant de ça, mais non je pense que ça vient vraiment d'eux aussi parce que justement on se rendait compte, à un moment on faisait les tickets par exemple, moi je faisais tous les tickets au début d'un thème en disant « voilà tu vas faire ça, ça, ça, ça », on se rendait compte que ça ne marchait pas. Pour moi c'était hyper frustrant parce que c'est quand même très très chiant et tu l'as vécu du coup de passer son temps à écrire ce qu'on va faire. Et en plus pour eux, ils étaient en mode « en fait quand je vais dans le code, ça ne correspond pas à ça, je vais faire trois PR là où tu as fait un ticket et là où tu as fait cinq tickets, je vais faire une PR, donc ça n'a aucun intérêt ». Du coup, c'est eux qui ont été très demandeurs et je pense que justement ça va avec ce truc-là de faire comprendre aussi à tes devs que oui, c'est à eux d'être force de proposition à un certain moment et qu'il y a des trucs où ce n'est pas toi qui vas inventer certaines choses parce que tu ne connais rien et tu ne sais pas et qu'en fait il y a plein de choses où oui, c'est à eux d'être force de proposition et de vraiment se dire qu'ils sont ingénieurs et ils sont tout autant responsables du produit que toi en fait à la fin. Et moi typiquement, je considère que mes devs sont même plus responsables du produit que moi. Moi, je peux leur donner des idées, je peux leur dire « tiens, il faut aller vers là ». Apparemment, les gens qui se sont dit comment on va le faire correctement techniquement et que ça marche, c'est eux finalement. Donc, je pense qu'il y a ça. Après pour passer beaucoup de temps à faire des tests, je pense qu'il faut aussi bosser avec tes devs pour plein de tests automatisés pour faciliter les choses. Ça, c'est mon côté tech là-dessus, mais je pense qu'il faut peut-être leur demander. Je pense que le moyen le plus simple, c'est de dire « est-ce que toi en fait, ça te plairait à ce moment-là ? ». Et il y a peut-être moyen que certains te disent « ben non ». Et ça, c'est une façon de fonctionner. Peut-être que tu en as d'autres par exemple et je pense que… Pardon. Vous avez des premiers résultats de l'étude, c'est bien. Mais je pense qu'il y en a d'autres avec qui ça va beaucoup plus leur plaire. Et dans ce cas-là, c'est un peu comme ce que je disais au tout début, se relativiser. Peut-être que tu as deux devs ou quand tu bosses avec eux, tu peux te permettre de faire des tickets beaucoup plus light, le tester. Et si ça marche bien, l'avantage que tu auras, c'est que quand un truc marche, tout le monde a envie de le faire. C'était ma tentative de réponse. Moi, j'ai une question plus sur l'alignement entre tech et produit. Est-ce que par exemple, la mise en place d'objectifs communs, c'était lié au fait qu'il y avait une divergence entre, on va dire par exemple, côté tech et produit, parce que ça arrive fréquemment. Et finalement, quels sont les objectifs finalement que vous arrivez à vous mettre en commun ? Hélo, tu m'arrêtes si je dis une bêtise, mais je ne pense pas justement… C'était justement la volonté de ne pas avoir de divergence qui a fait qu'il y a eu des objectifs en commun. On a la chance chez Moca d'avoir une équipe produit et tech. Enfin, on se considère comme une seule et même équipe d'ailleurs, mais d'avoir une équipe extrêmement proche. Donc justement, au contraire, c'était plutôt pour éviter qu'à un moment tu te retrouves dans cette situation où on n'aurait pas pu « s'entendre » parce qu'on a des objectifs séparés. Et sur quels objectifs en ce moment en commun, c'est vraiment l'ensemble, la totalité de nos OKR qu'on reporte, que Héloïse et Pierre qui sont là, reportent au Comex en soi. Donc, c'est vraiment tous les objectifs. Donc, ça peut très bien se dire qu'il faut booster encore plus la sécurité par exemple, qui est un truc où moi, en tant que produit, je ne peux pas faire grand-chose, comme il faut lancer la nouvelle feature typiquement de micro-formation à travers Slack. Et on va tous communiquer sur ces trucs-là qu'on est vraiment un travail à faire dessus ou pas. Merci beaucoup Alexia.