Nicolas Adam, Le rôle du premier Product Manager en startup

Transcription de l'épisode : "Nicolas Adam, Le rôle du premier Product Manager en startup"

Terry : Salut Nicolas, merci de prendre du temps aujourd'hui pour parler du rôle de First PM avec en trame de fond une grosse expérience entrepreneuriale et expérience par la suite en tant que First PM pour accompagner différentes entreprises. Donc ça va être le sujet dont on va parler aujourd'hui et avant de rentrer dans ce vif du sujet, je te propose tout d'abord de te présenter puis de nous présenter ce que tu fais aujourd'hui.

Nicolas : Ok. Moi c'est Nicolas, Nicolas Adam, j'ai 37 ans, 2 petites filles, 2 petites filles de 5 ans et une qui est née il y a 3 mois, voilà c'est tout jeune. Et qu'est-ce que je fais ? En fait j'étais entrepreneur 7 ans dans ma vie, à partir de là j'ai monté une boîte, on est monté à 25 personnes, on avait élevé 1,5 million à l'époque, on l'a mise de côté en sommet en 2017, on l'a revendu en 2019. Et moi, de 2017 à fin 2020, j'ai commencé à accompagner pas mal de startups qui n'avaient pas de PM dans leur boîte et savoir qu'est-ce qu'ils avaient envie de faire. Parce qu'il y avait vraiment une phase structurante quand le premier PM arrive dans les boîtes. Donc ça, j'ai pas mal accompagné dans à peu près 4 boîtes. Et par la suite, j'ai travaillé chez The Tribe, une boîte qui accompagnait d'autres boîtes à passer des phases structurantes dans leur vie. De « je viens de lever des fonds, je dois passer à l'échelle », des sujets comme ça où je dois lancer ma boîte. Pendant trois ans et depuis un mois, six mois exactement, j'ai lancé une autre boîte Simple Start pour aider les gens qui veulent se lancer dans l'entrepreneuriat.

Terry : Très, très clair. Donc, on va creuser petit à petit ces différents sujets. La première boîte que tu avais lancée en 2010, c'était du coup un produit tech ? C'était un produit tech.

Nicolas : De toute façon, quand tu montes une boîte, c'est un sujet très fort, c'est que tu tombes sur les problèmes que tu as eus dans ta vie plus tôt. Donc en fait, tu lances un sujet, un projet, c'est que tu as eu un problème. Moi, mon problème à l'époque, c'était quoi ? C'était de trouver une formation quand j'étais en école de commerce et je ne savais pas ce que je voulais faire dans la vie comme pas mal de gens. Et je me suis dit, mince, si moi, je n'arrive pas à savoir qu'est-ce que je veux faire, il y en a plein d'autres, c'est le cas. Donc, j'ai voulu créer une plateforme de mise en relation dans la formation entre les gens qui proposaient de la formation et les gens qui allaient la rechercher. On a lancé une boîte qui s'appelait FormaSearch. A la base, c'était un projet pendant mon alternance. Et en 2010, il y a quelqu'un qui m'a dit « Eh, c'est cool ce que tu fais ». Et il venait de revendre une boîte qui s'appelait Mister Good Deal, qui avait été vendue 66 millions à l'époque. Et il m'a dit « Tiens, j'ai envie d'investir dans des boîtes ». Je l'ai investi dans cette boîte-là et dans une autre qui s'appelle Sending Blue, un peu connue celle-là, qui s'appelle Brevo maintenant.

Terry : Ok, très clair. Donc ce qui est intéressant, là tu viens de toucher du doigt un des premiers problèmes qu'on peut avoir quand on lance un projet sans avoir potentiellement une approche produit. En tout cas, je ne vais pas dire sans avoir une approche produit, je vais dire un driver, une motivation pour lancer un projet qui parfois au départ est un problème que nous on a eu, mais qui n'est pas toujours la meilleure façon de lancer un projet parce que ce n'est pas parce que toi tu l'as eu, que tu as fait une étude de marché qui prouve qu'en fait c'est réplicable et que d'autres personnes ont le problème, même si ça peut aussi lever des sujets d'innovation hyper pertinents. Je suis curieux de savoir donc toi au lancement de ce projet un peu et maintenant au regard de ton expertise d'avoir accompagné des boîtes en tant que First PM, Est-ce qu'avec le recul, tu te dis qu'il y a des moments clés dans le développement du projet où l'arrivée d'un PM aurait été intéressante, pertinente ? Est-ce que vous en avez eu d'ailleurs et à partir de quand ?

Nicolas : On n'en a jamais eu à ce moment-là parce qu'en fait je faisais tout. On avait une équipe tech de 10 personnes. On avait des développeurs, on avait un designer, on avait market, on avait des gens qu'on fait des stages aussi, voilà, ça c'est le classique. Mais en fait, à ce moment-là, t'as pas besoin de PM. T'as juste besoin d'un partenaire, d'un sparring partner qui est là et qui te fait poser les bonnes questions au bon moment. T'es pas prêt à prendre un PM avec toi. D'ailleurs, c'est marrant parce qu'à l'époque, le métier de PM, il n'était pas connu du tout. Moi, je dis en 2015, 2015, 2016, je commence à découvrir les LPC. Je commence à découvrir le métier de PM. J'ai commencé en 2010. D'ailleurs, je ne sais même pas ce que je fais dans la vie comme métier. C'est très dur à comprendre. Je fais un peu de tech, un peu de market, j'essaie d'avoir des clients, je donne de quoi faire à développer pour les devs. Mais en fait, je ne sais pas ce que je suis en train de faire. Je découvre le métier qui parle de PM avec les LPC, je fais, ah mais en fait, il y a des gens qui parlent de ce sujet-là. Ah tiens, il y a de la littérature. Ah tiens, en fait, il y a des bonnes pratiques. Ah tiens, en fait. Donc vraiment, tu découvres le projet au fur et à mesure. En fait, c'est compliqué parce qu'à ce moment-là, tu es dans ta boîte, tu lances ta boîte, ta boîte apprend. On a eu plein de clients, on a fait un pivot, on a fait plein de trucs, on a signé des grands comptes. Mais en fait, tu as l'impression que tu dois te démerder par toi-même. Je ne peux pas expliquer, mais quand tu montes une boîte au début, même si tu lèves des fonds, c'est dur pour toi de lâcher les rênes parce qu'au début, tu étais là à fond, tu te donnes à fond dans le problème que tu veux résoudre. Et c'est comme si tu donnais ça à quelqu'un qui ne va pas comprendre ce que tu as dans ta tête. Donc, soit tu recrutes un assistant, soit tu vas surtout rechercher à recruter un assistant pour te déléguer des tâches que tu fais au quotidien.

Terry : Là-dessus donc hyper intéressant, ça va permettre de remonter le fil comme ça aussi sur le sujet du First PM, parce que le sujet du First PM au-delà de la personne qui peut rejoindre une boîte en tant que First PM, il y a avant ça évidemment l'équipe dirigeante d'accepter l'arrivée d'un First PM, parce que comme tu viens de le dire, ça c'est un gros sujet aussi émotionnel par rapport à ça du point de vue du dirigeant. Juste pour bien clarifier, vous étiez combien dans la boîte au lancement ?

Nicolas : On était trois cofondateurs. Il y a eu 25 personnes au maximum. Dans l'équipe tech, il y avait 10 personnes. Ça a été fluctuant. Ce sont les périodes. Et il y a eu des personnes côté commercial, côté recrutement parce qu'on a fait un pivot dans le recrutement en 2013. Il y a eu pas mal de changements.

Terry : Et sur les trois cofondateurs, la répartition un peu des tâches, de ce qu'on comprend, toi t'étais plus sur la partie produit.

Nicolas : Exactement. En fait, il y avait une personne qui allait faire plutôt la partie levée de fonds, structuration et commercial. Enfin, pas commercial mais recrutement. Une personne plus sur la partie commercial et moi qui étais plus sur la partie développer le produit.

Terry : Ok, très clair. Donc pour revenir sur ce sujet First PM et au départ donc au lancement du projet te dire en fait ce dont j'ai besoin c'est quelqu'un qui m'aide à décharger de tâches peut-être moins stratégiques pour l'entreprise versus faire venir quelqu'un qui va s'imprégner de ce que je veux construire parce que j'ai trop peur de déléguer ça on est trop tôt en phase assez... en face de bootstrap, enfin de création de la startup. Ce que tu as pu voir ensuite, toi par la suite, là je fais un accéléré, je reviens sur tes années 2017-2021, quand tu es venu accompagner des boîtes en tant que First PM et avec ce regard-là que tu avais toi en tant que fondateur, qu'est-ce que tu as pu voir comme bonne question à se poser en tant que fondateur qui voudrait intégrer un First PM et aussi en tant que fondateur pour faciliter l'intégration d'un First PM ?

Nicolas : Alors en fait, pour les fondateurs c'est très drôle parce qu'en fait ils ne savent pas ce qu'ils recrutent. Et moi, je ne savais pas ce que j'aurais pu recruter, pourtant ça m'aurait été d'une aide monumentale. Donc à l'époque, j'avais un besoin, mais ce besoin, je ne savais pas l'exprimer moi en tant que tel dans l'équipe. Si j'aurais pris un PM, ça aurait été PO, PM, on s'en fiche parce qu'à l'époque, ça n'existait pas cette scission-là, j'aurais pris quelqu'un qui écrit les specs à ma place et qui va donner ce qu'il faut faire, d'accord ? Et d'ailleurs, la plupart des gens que j'ai rencontrés après dans les fondateurs, j'ai pu être avec un CEO et la deuxième fois avec un CTO, On était plutôt sur quelqu'un qui avait pour but de dire voilà, moi je sais où je veux aller. La relation avec les devs, c'est compliqué. Souvent d'ailleurs avant que j'arrive, il y a eu une petite tension dans l'équipe. Les devs remontaient des choses comme ça manque de vision, on ne sait pas où on va, qu'est-ce qui se passe, les tickets ne sont jamais complets, il manque ça, les maquettes ne sont jamais à jour, on ne sait pas ce qu'il faut mettre. Il y avait toujours ces informations-là. Et en fait, la plupart venaient avec « j'ai besoin de quelqu'un pour gérer ça ». D'ailleurs, dans la plupart des boîtes par lesquelles je suis passé et j'ai été recruté après, ils cherchaient quelqu'un à un salaire et moi, j'ai été recruté à un salaire bien supérieur à ce qui était proposé à ce moment-là. Parce qu'en fait, la plupart du temps, ils ne savent pas. Ils cherchent juste quelqu'un pour déléguer les tâches qu'ils n'aiment pas faire au quotidien. Ils ont une roadmap, mais leur roadmap, c'est un fichier Excel avec des mots passés dedans. Ça ressemblait un peu à ça.

Terry : Et donc par rapport à ça, toi comment tu prenais la problématique parce que est-ce que en gros cette attente d'un point de vue fondateur, ça te paraissait ok pour un first PM de dire ok je vais répondre à cette attente là ? Ou il y avait aussi ce travail peut-être d'acculturation, de faire prendre conscience aussi au fondateur que le PM va pouvoir peut-être faire autre, enfin le first PM va pouvoir faire autre chose que juste ça. comment un peu toi tu taclais ces problématiques ?

Nicolas : Alors en fait c'était très particulier, c'est... En fait comment dire, le sujet à partir de ça c'est de dire ils comprennent pas ce que je vais pouvoir faire mais moi-même à l'époque si je me parlais en 2010-2017 je n'aurais pas compris. Mais par contre il y avait un besoin. Ce besoin c'est de ne pas être tout seul parce qu'un fondateur, même s'il a d'autres cofondateurs avec lui, il se sent la plupart du temps tout seul. Il a des combats, Il n'a personne dans les équipes pour l'aider. Même son autre cofondateur, potentiellement, il est anti-tension. Si il y a un PM, c'est qu'il y a eu un problème. D'ailleurs, le first PM est un produit. Si on veut dérouler le truc, le first PM est la réponse à un problème de l'organisation.

Terry : C'est intéressant ça, comment tu le présentes ?

Nicolas : Ça veut dire que si on a lancé ce recrutement-là, si quelqu'un dans l'équipe a dit, moi je connais des gens, ils ont fait appel à un PM ou un PO, et je pense qu'il y a un truc à faire, et l'autre a dit, ouais c'est ça, on fait de l'agilité, tu vois ce genre de choses-là, il faut faire des scrums, des rituels, tout ça, et bien en fait souvent tu as la réponse à un problème de l'organisation. Ton sujet de prime abord c'est de te dire quel est le problème que je veux résoudre et de poser un ensemble de questions dans les entretiens pour pas te mettre au niveau de l'exécution que la personne attend en face de toi.

Terry : Ça je trouve que c'est hyper hyper pertinent ce que tu dis donc ça veut bien dire en tant que First PM candidat donc pour une boîte qui recrute sur First PM de se dire ok ils vont m'écrire une fiche de poste inattendue du coup de ce qu'ils ont en tête mais moi faut que j'arrive à aller derrière ça et comprendre vraiment en fait quel est le problème qui a généré cette fiche de poste de leur côté.

Nicolas : Exactement.

Terry : Et donc là-dessus, est-ce que tu as des tips un petit peu à donner sur comment poser les questions, à qui les poser ?

Nicolas : Alors en fait, la première des choses c'est de te dire que si on voit que c'est le premier PM dans la boîte, tu mets la fiche de poste, tu la mets de côté, et tu te dis je me concentre sur les discussions avec la personne. Bon, si tu as un peu d'expérience. Si tu n'as pas trop d'expérience, tu vas venir, mais le problème c'est que j'en ai connu des first PM et un an plus tard, ils sont en burnout. parce qu'ils se sont fait happer par l'organisation. Ils voulaient faire plein de choses avec tout le monde, mais en fait, ils se retrouvent dans le jus du quotidien. En fait, en First PM, tu ne dois pas rentrer dans le quotidien. Donc en fait, dès l'entretien de démarrage, tu dois te positionner avec la personne sur un niveau de discussion qui est assez haut niveau. Ça veut dire les questions, c'est les questions basiques. Si tu es en startup, très bien. C'est quoi ton stade de levée de fonds ? C'est quoi les prochaines étapes avec tes investisseurs ? C'est quoi là ce que vous êtes en train de montrer comme métrics pour faire votre prochaine levée de fonds ? C'est quoi ce qui vous en empêche aujourd'hui ? Qu'est-ce que je dois savoir que tu dois me donner sur la relation avec tes investisseurs ? Comment tu traites une évolution de future ? Qu'est-ce qui fait que tu es allé sur ce sujet-là ? C'est quoi les indicateurs de succès ? Spoiler alert, il y en a très peu la plupart du temps. Ils ne savent pas maîtriser cette partie-là et c'est ok. En fait, tu vas aller sur des questions très haut niveau sur, tu ne vas pas parler du produit en tant que tel, mais de ce qu'il y a autour du produit et qui sont ses vraies considérations. La question top, c'est il te reste combien de temps avant que tu n'aies plus de cash ?

Terry : Et ça, est-ce que c'est des questions sur lesquelles tu vas pouvoir avoir des réponses assez facilement ou au contraire potentiellement te prendre un bloquer par le founder qui dit en fait ce n'est pas ça le poste auquel tu as candidaté, tu n'as pas bien compris, je veux que tu répondes à cette fiche de poste.

Nicolas : Alors, si le mec te dit ça, il y a deux raisons. C'est soit la personne n'a pas créé l'empathie et la condition nécessaire pour créer une vraie discussion. Là, on est en train de faire un entretien utilisateur tu vois dans l'idée. C'est-à-dire que tu es là en face de la personne et tu lui poses des questions sans regard. C'est lui qui vient de te poser des questions de base. Il pense que c'est lui qui va maîtriser. Mais en fait, tu vas changer la donne et tu vas lui poser autant de questions, même plus, pour savoir parce que... En fait, pour un first PM dans une boîte, c'est aussi important que toi, tu comprennes la personne que tu as en face de toi, que lui comprenne qui tu es et ce que tu peux lui apporter, et lui ce qu'il peut apporter. Parce qu'en fait, un first PM, sa vraie relation se travaille avec le founder, pas avec la boîte. Si ça foire avec le fondateur, la relation va foirer dans le long terme en fait. Et ça, c'est les prémices de la collaboration, la première étape.

Terry : Hyper, hyper clair. Donc si on retourne, donc très, très clair pour cette première étape en tant que First PM de réponse à une offre et de comprendre du coup en fait qu'est-ce qui se cache derrière cette offre comme problématique à laquelle en tant que First PM tu vas devoir répondre le plus tôt possible. Donc maintenant si on revient toi donc à 2010, 2011, 2012, quand tu commences à structurer la boîte mais que tu connais pas spécialement cette notion de product manager, que tu fais un peu tout et que tu te dis que t'aurais besoin juste de personnes pour déléguer les choses, dans cette logique là, quelles sont les choses où avec le recul tu te dis c'était bien qu'en tant que founder je les fasse parce que ça m'a permis quand même d'apprendre sur certaines choses, de pouvoir avoir une vision beaucoup plus informée sur la stratégie vers laquelle je voulais emmener l'entreprise versus les choses sur lesquelles tu te dis maintenant effectivement ça, ça aurait pu être délégué. Parce que pourquoi je pose cette question ? Parce que quand tu es tout petit, évidemment tu as une idée, tu vas avoir fait une étude plus ou moins poussée du marché en fonction de est-ce que c'est mon problème ou un problème auquel J'ai quelques données quanti et quali sur lesquelles m'appuyer. Mais tu vas très généralement devoir pivoter plusieurs fois pour vraiment aller chercher le business nécessaire pour faire de ton entreprise quelque chose de solide. Et du coup, pour pouvoir pivoter et avoir cette vision informée du marché, tu vas devoir être dans l'opérationnel. Tu ne peux pas très vite t'en sortir et te mettre dans des strates hyper stratégiques. Donc voilà, avec ce recul-là, aujourd'hui qu'est-ce que tu dirais t'aurais pu plus facilement déléguer sur un rôle de First PM versus les choses qui en fait étaient un mal nécessaire en tant que fondateur ?

Nicolas : En fait, ça va être très paradoxal, mais tu te mets en tête de faire plein de choses. Alors bon, déjà, la première des choses, c'est que dans l'histoire, il y a eu un petit burn-out au passage. Donc petit burn-out, t'es en colère contre tout le monde, t'en veux à la terre entière, tu penses que ta vie, c'est de la merde. Bon bref, on passe tous cette partie-là. Mais au-delà de ça, c'est de te dire, tu penses qu'il y a plein de choses que c'est à toi de le faire. tu passes des journées. Moi, je finissais mes journées, il était 2-3 heures du matin, je travaillais jusqu'à pas d'heure, je revenais chez moi, j'allais à ma compagne en plus, on parlait, on faisait la soirée, je continuais après, etc. Je codais en plus, chose horrible, voilà. Et en fait, le sujet parmi ça, c'est de me dire le plus gros apprentissage, ça a été... Oui, j'ai donné de l'effort pour le faire, mais en fait, plus je le faisais, plus je déresponsabilisais l'équipe. Et donc quand je déresponsabilisais l'équipe, c'est-à-dire que je m'infligeais des tâches très fortes dans le delivery de la boîte et le delivery des équipes. Le problème, c'est que plus j'étais dans le delivery, moins j'étais dans des choses qui ouvraient des propositions de valeur et allaient tester des choses très rapidement. Et j'étais trop axé delivery. Et en fait, d'avoir vécu cette phase très delivery, ça m'a fait dire, en fait, il faut que je me dégage de la partie delivery et que j'autonomise les équipes pour qu'ils aient le contexte nécessaire et qu'ils puissent être autonomes sur cette réalisation. Et moi, je veux avoir un espace pour être sur la partie discovery. Et ça, c'est quelque chose que j'ai mis en place dans les étapes d'après, dans First PM, parce qu'en fait, tu ne peux pas être à fond sur le delivery et faire du discovery. Tu dois alimenter les deux. Et oui, sur le coup, quand j'étais dans mes soirées, je me disais oui, c'est super important ce que je fais, c'est super, j'écris mes tickets jusqu'à pas d'heure du matin, je les envoie, on arrive le lundi matin, les devs ils arrivent, ils me disent, ils me challengent tous les tickets qui sont là en mode putain, je vais passer mon week-end à écrire ça et tu me dis que ce n'est pas bien ce que j'écris. Ça, au-delà d'un fondateur, ça parle aussi à des PM normalement, voilà, qui écrivent leurs tickets pendant très longtemps. les équipes à Challenge 2, je me suis dit en fait, tu vois, l'apprentissage de cette étape-là, c'est de te dire, en fait, il faut que je gagne du temps, il faut que j'économise mon énergie et ma motivation pour me focaliser là où il y a de la valeur. Et à l'époque, j'aurais été incapable de déléguer tout ça, mais en fait, il y avait des moyens de le déléguer sans avoir de PM à ce moment-là. Et ça a été de se dire, ok, j'économise ce temps de manière très lean, mais en fait, je dois donner, accepter de perdre un peu le contrôle.

Terry : Et donc si tu creuses un peu là pour donner des exemples sur les moyens que t'aurais pu faire, que t'aurais pu utiliser pour déléguer ces phases par exemple de rédaction des US ou autre, qu'est-ce que...

Nicolas : Alors ce qui est paradoxal c'est que quand j'étais fondateur j'ai écrit énormément d'US, quand j'ai été premier PM dans les boîtes j'ai presque pas écrit d'US.

Terry : Et donc quelle est la méthode, les choses que tu mettais en place en tant que first PM pour éviter justement l'écriture des US ?

Nicolas : Alors, en fait, c'est qu'il n'y en avait pas besoin tout simplement, et je vais expliquer pourquoi. En fait, des gens qui viennent dans une startup, c'est des gens ultra motivés. D'ailleurs, dans ma boîte que j'ai montée, dans les autres boîtes que j'ai pu rejoindre, à chaque fois, j'étais en face de gens motivés. Alors, quand ça fait 2-3 ans, il y a toujours des gens qui ne sont plus aussi motivés qu'avant, mais ils ont tous une flamme intérieure. Ils sont venus, c'est pour aller dans une startup, pour être plus impacté dans les décisions, pour changer le monde, etc. Donc, les employés sont aménagés aussi, c'est des gens très impliqués dans la boîte. Souvent, la plupart du temps, les fondateurs ne sont pas prêts à déléguer la charge et donner des décisions aux employés. Ils leur font croire qu'ils leur donnent des décisions, mais ils leur donnent peu, très peu. Retour d'expérience de moi-même, retour d'expérience d'autres expériences où j'ai été. En fait, le sujet le principal et qui peut être des multiplicateurs en termes de puissance dans ces boîtes-là, c'est de dire En fait, quand on est fondateur, comment expliquer ? Dans l'état d'esprit, c'est j'avais une idée, des gens ont cru dans mon idée, j'ai levé des fonds grâce à mon idée. Même si je n'ai pas trouvé mon marché vraiment, je n'en vis pas, je ne suis pas rentable. Dans ma tête, c'est comme si on avait cru dans mon idée et que des gens payaient pour ça. Ça veut dire que je pense que toutes mes idées sont bien parce que c'est potentiellement une idée. Je me dis, j'ai des bonnes idées en fait parce qu'on aime tous avoir des bonnes idées et des nouvelles choses. Et de se dire, quand tu montes ta boîte, tu as pensé à toutes les ramifications et quelqu'un de ton entreprise te dit, ça serait intéressant de faire ce test-là. C'était cette idée-là. Alors, soit tu y as pensé, mais toi tu as pensé que ce n'était pas possible et tu vas la freiner cette opportunité, soit tu vas dire « mince, il a une idée, alors que c'est ma boîte, c'est moi qui aurais dû avoir cette idée-là ». Ça paraît très bizarre quand je dis ça.

Terry : Non, ça s'entend parfaitement et je pense qu'après il y a des typologies on va dire d'entrepreneur aussi et de façon de faire mais je comprends totalement ce que tu dis et du coup je suis curieux de savoir là-dessus effectivement comment tu arrives à passer de cette phase très protectrice de ton idée, de la boîte que tu veux créer, à savoir petit à petit justement, ce n'est même plus seulement déléguer, c'est ce qu'on appelle l'empowerment, c'est donner la capacité à tes premiers employés à aussi co-créer avec toi la boîte que tu es en train de monter.

Nicolas : C'est tout le sujet en fait, parce que de base, on va dire que je t'ai... En fait, c'est comment tu peux multiplier des petits paris pour montrer que tu es dans le bon chemin. Donc, on parle de discovery contenu, mais on ne va pas utiliser ces mots-là parce que ce n'est pas le sujet. Globalement, c'est quelqu'un a une idée, comment je crash-test cette idée le plus rapidement possible pour savoir s'il y a un potentiel et si on peut la déployer étape par étape. Eh bien ça en fait, je ne le faisais pas assez. Ce qui fait que si une idée venait à moi, je devais la maturer très longtemps dans mon coin. Extrêmement longtemps. Voir tous les tenants aboutissants. Et si je n'avais pas trouvé de solution, on ne la faisait pas. On essayait de faire un découpage qui n'était pas vraiment un découpage de on test quelque chose.

Terry : Ouais, c'était plus en mode on le livre.

Nicolas : En mode on livre étape par étape, on fait une V1, V2, V3, V4, V5, on le fait un peu en zoom zoom dans un coin, on crée sur une branche ce système-là, au final le business prend le pas sur la réalité, on met cette branche dans un coin, on revient dessus, un mois plus tard tout le monde a oublié ce qu'on voulait faire, on refait le mois plus tard, on revient dessus, à la fin la branche ça fait six fois que quelqu'un dit on la supprime ou pas. Bon bref, il y a à peu près ce genre de choses-là.

Terry : Très très clair et donc pour revenir plutôt à ce que tu as pu faire ensuite donc en accompagnant en tant que First PM donc tu mentionnais le fait très peu de rédaction de user story on comprend bien du coup pousser à l'empowerment à la capacité aussi à tester très vite du coup des idées diverses mais être capable du coup de de les confronter à la réalité du marché, de les crash tester pour voir si oui ou non cette idée on va la poursuivre ou pas, mais de pas la freiner, de dire ok bah idée qui mérite d'être testée, on met les efforts et on y va. Comment dans un premier temps déjà tu arrives dans une boîte d'une petite taille, en tant que First PM à mettre en place, on va dire une culture ou en tout cas à commencer à insuffler ce type de réflexion parce que si on prend l'exemple d'autres boîtes qui auraient pu être dans la même situation que la tienne en 2010, les collaborateurs de l'entreprise, ils vont déjà être habitués au mode de fonctionnement des fondateurs. Donc c'est-à-dire qu'ils vont être habitués à ce qu'on leur dise « non, non, on ne teste pas ça » ou ce que tu expliquais que le fondateur revienne six mois plus tard pour dire « ok, on va le mettre en œuvre mais comme ça, comme ça, comme ça ». Donc déjà dans un premier temps, avant même de générer ces idées et de savoir comment aller les crash tester, comment tu fais pour accompagner en fait un changement de petite structure vers cette façon de penser et l'insuffler à l'ensemble des collaborateurs même s'il n'y a que cinq ou dix personnes.

Nicolas : Alors, il y a deux niveaux de réponses. Il y a « qu'est-ce que tu fais ? » et « comment tu permets de le faire ? » qui sont deux réponses différentes. Alors, globalement, on va dire que quoi qu'il se passe, quand je parlais de quelqu'un avec ses idées, on parle d'intuition. On parle d'intuition, une start-up et des fondateurs, c'est rempli d'intuition. Ils ont des intuitions surtout. D'ailleurs, si tu vas les voir dans leur tête, même si leur produit, ça ne fait pas grand-chose, ils imaginent les trucs dans 5-10 ans qu'ils vont avoir. Voilà, ils ont vraiment toute la panoplie de ce qui existe. Et en fait, quand tu vas leur dire « Ah, on pourrait avoir cette idée », ils l'ont déjà eu cette idée. Ils l'ont déjà eu un coin dans leur tête d'une certaine manière, etc. Tu pourras pas leur tirer ce truc-là. Par contre, la chose en tant que First PM, c'est ta capacité à prendre l'intuition des gens. Il ne faut pas que toi tu aies d'idées. Tu prends l'intuition des gens, que ce soit les fondateurs, les personnes du terrain, les commerciaux, les développeurs, un peu moins les développeurs mais même les développeurs. Le support client, le service client, peu importe tout ça. J'étais dans des boîtes où il y avait après 20, j'ai eu 70 personnes. Enfin, ça c'est les boîtes d'après où j'ai été force PM. En fait, il faut que tu puisses dire, ok, on a de l'intuition et la deuxième chose, je respecte ton intuition. J'essaye de comprendre pourquoi tu as cette intuition-là. Je reviens à la source, je ne te dis pas non c'est de la merde, ça c'est important. Un first PM ne doit pas dire non c'est de la merde ce que tu penses, il doit juste comprendre pourquoi le fondateur a ça en tête. Parce que s'il ne le suit pas, il va se faire imposer les choses par la suite le first PM.

Terry : Donc comprendre, je referai juste ce que tu dis, c'est vraiment comprendre le chemin de pensée du fondateur qui l'a mené à avoir cette intuition.

Nicolas : Exactement. Parce que ce fondateur il arrive avec une idée, mais cette idée il la sort pas du chapeau comme ça. Surtout c'est une idée super importante, il la sort parce que... À un moment, il a fait « Ah, on pourrait faire ça ! » À un moment, ils ont parlé, ils ont fait un resto avec les autres et ils ont dit « Ah ben, on pourrait faire ça ! » Et à un moment, il a passé des nuits entières à se dire « Comment on pourrait faire ça ? » Il passait, il faisait son trajet tous les matins, il a réfléchi à ça, il arrivait à une solution finale. Et il arrive avec cette solution finale, il faut revenir sur tout le cheminement que lui a vécu. Et ça, c'est la première des choses parce que les équipes, quand tu parles des équipes en place actuellement, ils n'ont pas l'habitude de faire ça. Ils ont l'habitude d'avoir ce fondateur, ça dépend lesquels, qui peut arriver, qui dit « Tiens, j'ai fait un barbecue ce week-end avec mes copains là et quelqu'un m'a dit, tiens, cette idée-là ». Le mec arrive, il dit « faites-le ». Seulement, les développeurs, ça fait longtemps qu'ils sont sur un autre sujet. Ils vont devoir abandonner ce sujet-là. Pour répondre à ta question, qu'est-ce que tu apportes aux développeurs et aux fondateurs, fondateurs, quelqu'un qui comprend ta pensée et qui essaye de comprendre pourquoi tu as eu ça et de diguer là-dedans. Aux développeurs, tu leur apportes une structuration de l'idée comme elle vient à eux.

Terry : Ouais, donc en fait, une fois que tu as compris comment le fondateur avait construit son idée, tu vas aller réexpliquer ça aux développeurs pour qu'eux aient ce cheminement de pensée et ne pensent pas que ce soit juste une idée qui est sortie du week-end dernier et qu'ils comprennent du coup le... Et en fait.

Nicolas : À partir de ça, tu refais le chemin arrière, enfin là on parle de questions avec les 5 pourquoi, par exemple pourquoi t'as fait ça, pourquoi t'as fait ci, ok, enfin je sais pas si ça te parle les 5 pourquoi.

Terry : Oui bien sûr, de Simon Sinek, les 5 why's.

Nicolas : On parle du cercle doré, moi j'appelle ça la méthode de l'artichaut, l'artichaut c'est quelque chose de beau mais il n'y a que le cœur qui est intéressant et pourtant tu vois que 90% de feuilles à la fin, donc en fait c'est toi en tant que first PM comment tu vas éplucher toutes les feuilles pour revenir au cœur, voilà. Et à partir de ce cœur-là, en fait, tu reviens voir l'équipe et tu ne donnes pas la solution, mais tu dis comment on peut permettre d'obtenir ce résultat-là. Et là, tu construis avec tout le monde.

Terry : Hyper intéressant, je trouve que tu l'expliques très bien. Et à mon sens, j'espère que les first PM qui écouteront ça, ils trouveront aussi la valeur que j'envoie de tout ce que tu dis jusqu'à présent, parce que c'est vraiment des points très concrets. parce qu'on comprend aussi l'impact stratégique du rôle de First PM, la nécessité d'avoir quand même des personnes avec un minimum de séniorité, parce que comme tu le dis sinon tu te fais happer par un quotidien et tu vas pas aller challenger les bonnes choses. Et en même temps cette humilité nécessaire, c'est-à-dire de pas arriver à dire non c'est de la merde, mais d'aller vraiment recomprendre tout le cheminement de pensée du fondateur, le savoir le traduire. Ça couvre aussi, je trouve, pas mal d'aspects du rôle de quelqu'un qui fait du product, c'est-à-dire à Discovery, tu vas comprendre un peu comment il a fonctionné ton fondateur. Ensuite, tu vas aller communiquer du coup pour expliquer ça de manière plus ou moins différente à l'équipe opérationnelle en charge de mettre en œuvre cette vision ou en tout cas d'aller la challenger. Et donc pour rentrer plutôt sur la seconde partie, ensuite une fois que tu as réussi à faire comprendre le pourquoi du comment sur cette idée, comment tu vas aller la crash tester sur le marché ?

Nicolas : Alors ça, c'est la partie la plus importante parce qu'en fait, c'est la deuxième chose que tu apportes alors au fondateur et qui est très important pour lui, c'est la vitesse d'exécution. En fait, l'idée derrière tout ça, c'est de lui montrer à quel point tu es remonté un niveau au-dessus. Et vu que t'es remonté à ce niveau au-dessus, toi t'as en capacité d'aller dix fois plus vite que n'importe qui et de générer des apprentissages par rapport à ça. Et en First PM, tant que t'as pas ce premier succès, tu ne vaux rien auprès du fondateur. Ok, je lui ai parlé à lui, il a compris qui j'étais, mais grâce à ça, on arrive à aller dix fois plus vite. En fait, j'ai intérêt à me confier à cette personne-là. En fait, avec ce fondateur, il y en a forcément un avec qui tu as plus d'affinité. Il y en a un qui t'a recruté et dans celui qui t'a recruté, potentiellement, il voulait faire passer un message à un autre fondateur. Alors, il faut oublier de penser que les fondateurs sont en ligne et ça, c'est encore autre chose, d'accord ? Mais souvent, moi, quand j'étais recruté, il y en avait un qui devait passer un message à quelqu'un. Il devait passer un message à l'équipe, il devait passer un message à l'autre, l'associé. Il y a un CTO qui m'a recruté et qui m'a dit, c'est simple, le CEO ne comprend pas ce qu'on peut apporter. Il arrive toujours avec les solutions. J'ai envie qu'on prenne plus de recul ensemble. Une fois que tu as ça, en fait, ça passe aussi par des moments informels avec lui. En fait, ça passe par des moments où, vas-y, vous prenez un temps ensemble, vous discutez, mais vous ne discutez pas en mode j'ai des revendications à te faire. Vas-y, on prend un temps. Voilà ce que j'ai appris dans mon moment de downboarding. Tiens, toi, qu'est-ce que tu voulais faire en fait avec ta boîte ? C'est quoi ce que tu as envie de faire avec les salariés ? C'est quoi le truc qui te saoule avec les salariés, que tu en as marre d'entendre, etc. ? En fait, il faut créer des moments d'empathie avec lui.

Terry : Très clair là-dessus. Et ensuite, comment tu vas... Une fois que tu as gagné cette... Je voudrais revenir sur un point.

Nicolas : Sur l'exécution.

Terry : Sur l'exécution et sur le fait, avant même, avant d'arriver à ce niveau de confiance entre le fondateur qui t'a recruté et toi en tant que first PM, comme tu expliques, il faut que tu prouves la preuve de succès. Celle-ci, du coup, là, par rapport à ce qu'on disait un petit peu plus tôt, une fiche de poste où il y avait des attendus, tu pourrais dire ma preuve de succès, il faut que du coup, je coche 2-3 cases là sur la fiche de poste très rapidement et non pas que j'aille challenger tout ce que tu viens d'expliquer. Comment tu la vois toi cette preuve de succès rapide ?

Nicolas : Alors en fait, c'est simple, il y a deux succès à trouver. En fait, si on a un premier, c'est un succès très rapide qui ne demande pas trop d'efforts mais qui va montrer que tu vas aller vite en prod. En fait, souvent dans ces étapes-là, dans First PM, souvent dans les problèmes d'organisation, il y a aussi le temps de passage en prod qui est très long. Parce que lui, il a beaucoup de charge mentale et il veut tout valider et donc il prend beaucoup de temps pour tout valider. En fait, il faut aussi qu'il ait confiance dans ta capacité à dire, il arrive à retranscrire tout ce que moi j'ai comme objectif et à me comprendre. Donc en fait, tu as un premier succès. On va prendre une matrice d'Eisenhower, c'est ça ? Non pas Eisenhower, attends, qu'est-ce que je raconte ? On parle d'une matrice de important, enfin complexité, complexe, valeur complexité. Donc tu as dans l'équation, tu arrives à mapper globalement ce qui a de la valeur pour l'organisation et tu sais auprès la complexité. Ton succès se trouve dans un truc qui a beaucoup de valeur et peu de complexité et un truc qui a beaucoup de valeur et énormément de complexité. Ton succès rapide qui va montrer l'intérêt se trouve là, valeur et faible complexité, parce que tu vas le faire aller rapidement en prod. Par contre, tu vas montrer comment tu vas dégrossir le sujet qui est très complexe pour le rendre ultra simple et le faire passer en prod. Donc en faisant ça, par exemple dans une des boîtes, c'est appelé ChronoTruck, On a pris un sujet qui est estimé à 6 mois, qui avait un potentiel business de dingue, dont tout le monde parlait depuis très longtemps au Codir. D'ailleurs, ça, c'est une bonne question. Quel est le sujet que le Codir aborde tous les mois et on revient sans cesse dessus et on se pose la question quand est-ce qu'on travaille dessus ? Tu prends ce sujet-là. Ce sujet-là qui est estimé à 6 mois, on a déployé un truc en deux semaines pour le crash tester et générer de la donnée à partir de ça. Quand tu fais ça, tu as converti pas mal de gens dans l'organisation.

Terry : Donc ça, c'est la partie preuve de delivery, de capacité à délivrer.

Nicolas : Exactement.

Terry : Et donc sur l'autre angle, si tu devais prendre, je ne sais pas s'il y avait un autre exemple chez eux, sur la partie plus de dégrossir le sujet, parce que ça s'intègre aussi avec ça.

Nicolas : En fait, ce qu'on a délivré n'était pas du pur delivery, mais c'était une étape de discovery qu'allait apprendre et prioriser plus tard la feature. Parce que le sujet principal qui vient derrière tout ça, c'est la donnée. Dans les startups, la data est souvent... En fait, il y a plein de signes avec ça. Souvent, il y a pas mal de gens qui commencent à parler de data. Donc souvent, quand j'arrive dans les boîtes et startups, il y a un Matomo, Mixpanel, Metabase, Amplitude, il y a quelque chose mis en place. Quelqu'un a voulu le mettre en place. Pourquoi elle a voulu le mettre en place la plupart du temps ? Parce que les devs travaillent, mais ils ont envie de montrer l'impact de ce qu'ils font. Et aujourd'hui, le fondateur, il est persuadé de ses idées. Il est persuadé qu'il a les bonnes réponses à tout ça. Et donc, un chantier, mais s'il a une idée en tête, les devs vont la réaliser telle que le mec l'a pensée. Et ça peut durer 3 mois, 4 mois, 5 mois. La data a ce pouvoir de mettre en place le chantier de manière minimaliste et de la valider sans faire tous les développements. Ce que tu apportes dans la vitesse d'exécution et comment je fais gagner du temps 6 mois de temps, la plupart du temps, c'est qu'en fait la data on va l'utiliser sur un parcours très précis, on va lancer une initiative et si ça prend, on déploie la suite. Est-ce que ça va dire comme ça ?

Terry : Oui, oui, très clair. C'est très, très clair sur la partie données. Après, effectivement, ça, on l'aura compris depuis le début, on parle quand même de produits très, très tech.

Nicolas : On est très tech.

Terry : Voilà. Pour eux, c'est des plateformes SaaS, ce genre de choses, puisque pour être capable ou en tout cas qui font partie de la proposition de valeur complète de l'entreprise, il y a un côté très, très logiciel qui permettra de collecter toute cette donnée.

Nicolas : De base, oui. On est sur un mode delivery. Par contre, par la suite et aujourd'hui, ce que je donnerais comme conseil, quand j'étais First PM dans ces boîtes-là, je maîtrisais peu la partie pure discovery sans dev. Aujourd'hui, j'ai fait un truc comme depuis 3 ans, 30 design sprints. Design sprint égal, t'arrives avec un problème, à la fin de la semaine, tu l'as testé auprès de 5 utilisateurs.

Terry : Yes, épisode pour ceux qui nous écoutent, hyper intéressant que j'ai fait le numéro, si je ne dis pas de bêtises, 22 avec Marie, sur qu'est-ce que c'est que le design sprint.

Nicolas : Marie Glondus ?

Terry : Marie Glondus.

Nicolas : Ok, on a fait un recueil recroisé en webinar LinkedIn. Ok, cool. Très intéressant, on a pas mal parlé ensemble. Ok.

Terry : Donc, pardon, tu disais par rapport à….

Nicolas : Et c'est exactement ça en fait. On est arrivé… Maintenant, aujourd'hui, je te dirais ça, mais à l'époque, on était dans un run quotidien. Donc, c'était une plateforme B2C et une autre B2B. Globalement, si tu as un minimum d'utilisateurs, tu peux tester vite des opportunités avec eux. Et dans les deux boîtes où j'ai été, on était en capacité de le faire. Si tu n'as pas encore d'utilisateur, les design sprint, ça fonctionne parce que tu vas tester très rapidement. En fait, la data, comment elle est formalisée avec les fondateurs, c'est comment tu arrives à tester quelque chose, et si tu es sur de la data pure, tu es sur du quantitatif. Si tu es en design sprint, tu es sur du qualitatif, tu en fais 5, mais c'est ultra quali les retours qu'ils vont te donner. Sur les autres, tu sais, est-ce qu'ils vont utiliser la fonctionnalité ou pas.

Terry : Voilà, très clair. Maintenant qu'on a bien posé le décor et donné surtout des conseils assez concrets je trouve sur ce rôle de First PM, Si on accélère un peu dans la croissance de l'entreprise et on va partir du principe que ça se passe bien et que du coup le first PM a réussi à bien convaincre, les équipes sont alignées, ça commence à délivrer. Comment ensuite tu passes peut-être à l'étape d'après, c'est-à-dire recruter le first second PM et puis petit à petit créer une équipe produit. Est-ce que ça c'est quelque chose sur lequel tu as pu travailler dans tes différents accompagnants ?

Nicolas : En fait, le SIGON First PM vient à partir du moment où il y a une deuxième levée de fond. Voilà. Ou il y a autre chose qui se passe, enfin... En fait, le First PM vient créer une dynamique et souvent, il ne reste pas le premier First PM. Par contre, il y a souvent un deuxième First PM. Parce qu'en fait dans... Enfin moi je parle pour ma part. Moi en fait dans ma démarche, je suis plutôt quelqu'un qui vient acculturer des équipes et une entreprise à la démarche produit. C'est ce que je fais chez The Tribe, c'est ce que j'ai fait dans mes boîtes avant, enfin dans les First PM, etc. Mais c'est tu crées un déclic et une nouvelle manière de faire. Tu crées du changement, mais ce changement il est assez fort. En fait, dans ce changement, tu vas avoir plein de succès, mais tu vas te cramer aussi. Parce qu'en fait, tu vas essayer... Enfin, je vais essayer de parler, donc ça va être difficile à montrer à l'oral. Mais globalement, t'es à un endroit, à un niveau. Toi, tu veux aller à un niveau très haut, mais en fait, tu ne vas pas pouvoir prendre un ascenseur. Tu vas devoir prendre une toute petite marche. Et cette petite marche, tu vois très bien où tu vas emmener les équipes. Tu vois là où tu te trouves. eh ben en fait, tu vas chercher à aller plus loin et la pire des choses, c'est de chercher à aller plus loin. Parce qu'en fait, dans cette petite marche d'évolution, de changement que tu as apporté, le but, c'est de la stabiliser au maximum au sein des équipes plutôt que de changer.

Terry : Assez intéressant comme réflexion là-dessus. Donc c'est plutôt que de courir pour aller tout en haut là où tu voulais aller, de rester à cette première étape, mais pour qu'en fait ça soit la métaphore d'une pyramide, des fondations très très solides qui vont permettre ensuite, dès que le déclic est passé, à faire effet boule de neige et à aller gravir beaucoup plus vite les marches restantes.

Nicolas : Exactement.

Terry : Et donc sur ce point-là, j'ai repensé à une autre question avant de parler, enfin c'est en lien je pense avec le second first PM aussi, Tu parlais tout à l'heure du fait que tu as très peu écrit de user story lors de tes missions en tant que first PM et c'est vrai qu'on n'a pas expliqué comment tu en étais arrivé vraiment concrètement à des équipes qui sont complètement autonomes du coup sur la partie besoin ou en tout cas des situations où tu arrives à ne plus avoir à écrire les détails de tes tickets Jira.

Nicolas : Alors en fait la question par rapport à ça c'est comment tu gagnes du temps ? En fait, et pour aller sur la question de comment tu gagnes du temps, il faut surtout aller dans la phase où quand est-ce que tu perds du temps. Les moments où tu perds du temps quand tu travailles avec une équipe de dev, c'est quand tu passes du temps à écrire tes specs, tes user stories, peu importe, parle ça comme tu veux, c'est la même chose. Le week-end, tu passes à les revoir. C'est le temps que tu as quand tu les envoies aux devs et qu'ils disent je ne comprends pas ce que tu as écrit. C'est quand le dev commence à aller à mettre en développement, qu'il t'a dit qu'il y en avait pour une semaine mais qu'en fait il y en a pour quatre semaines et qu'il ne te dit absolument pas dans quel état il est et tout ce qu'il est en train de faire. C'est le moment où il te livre la feature, que cette feature ne correspond absolument pas à ce que tu avais défini avec lui dans tes specs. Le temps de test, le temps de remise à jour de ça, de resynchronisation, et bien là tu as perdu au moins énormément de temps. Au contraire, il y a un truc qu'on sous-estime au maximum, c'est de parler avec les gens. En fait, moi je suis dans une démarche par rapport à gagner du temps. Plus tu mets en relation les gens qui utilisent la solution et les gens qui la conçoivent, plus tu es efficace. Donc, qu'est-ce que j'ai fait concrètement ? En fait, dans ma boîte quand j'étais, j'étais plutôt en mode top-down. Je donnais les specs, faites ça. Après, on se challengeait, on s'envoyait des skeu, un petit peu j'ai rien compris, on revenait, on réexpliquait, on passait du temps. En fait, là j'étais en mode essayer de convaincre les gens absolument, c'était horrible. Je pense plus à des moments où certains me disaient je comprends pas le problème, pourquoi on fait ça, qu'est-ce qu'il y a derrière, qu'est-ce qui se cache derrière. Dans cette phase de First PM dans les autres boîtes, en fait j'ai plutôt développé des skills de facilitation. Facilitation égale je suis sûr du problème qu'on va résoudre parce que j'ai créé la condition nécessaire de savoir quel était le problème de base qu'on voulait résoudre. Je crée un atelier d'une heure où je dis comment permettre d'accomplir cet objectif qu'on a défini ensemble. Et je lançais toutes les équipes, souvent pluridisciplinaires, ça dépendait des boîtes, des devs, des commerciaux, des support clients, peu importe qui, un ensemble de gens, même des designers, même souvent le fondateur aussi. Comment on pourrait faire ça ? On faisait un story mapping. Moi, je structurais ce story mapping, je leur demandais de prioriser comment on pouvait y aller encore plus rapidement. Et je mettais une contrainte très forte de si on doit y aller dans moins de deux semaines et sortir quelque chose, qu'est-ce qu'on doit faire ? Si je dois faire une métaphore, c'est un peu comme si tu faisais ta morning routine du matin. La morning routine du matin, c'est, ben écoute, tu te lèves, tu fais du yoga. Fais genre, fais genre que tu fais des trucs sympas, ok ? Tu fais du yoga, tu vas scroller sur les réseaux sociaux, tu vas prendre ton petit déj.

Terry : C'est pas sympa scroller sur les réseaux sociaux.

Nicolas : C'est pas sympa. Tu vas prendre ta douche, tu vas t'habiller, tu vas repasser ta chemise, tu vas faire plein de trucs, etc. Ça c'est ta routine parfaite, ça dure une heure. Tu mets combien de temps le matin pour te lever ?

Terry : Ouais, on est autour d'une heure ouais. Bon temps pour déjeuner aussi.

Nicolas : Et en fait tu vois, pour déjeuner, et en fait tu mets les équipes dans, voilà le problème, voilà tout ce qu'on pourrait faire. Tout ce qu'on pourrait faire dans les moindres détails. Ok, maintenant on imagine que là on se réveille un matin et qu'en fait on a un rendez-vous super important et qu'on n'a que cinq minutes pour se préparer. Et bien, je peux te dire que là, à ce moment-là, tu vas rentrer dans un mode où tu vas peut-être pas te laver, tu vas peut-être mettre du déodorant et du parfum, ce n'est pas cool, mais au moins tu vas respecter ton timing, tu vas peut-être prendre un chewing-gum sur le trajet, tu vas prendre des trucs à manger, la chemise, tu vas essayer de la repasser, mais tu vas la secouer dans tous les sens, tu vois. Ce ne sera pas très propre, voilà. Mais en fait, on se mettait en ce mode de voilà, on va sur les cinq minutes. On va regarder tout ce qu'on pourrait faire grâce à cette feature, mais on va sur les cinq minutes, qu'est-ce qu'on pourrait faire en moins de deux semaines. Ensuite on allait sur, maintenant qu'on va avoir les 5 minutes, on va avoir les 15 minutes. Si ça, ça fonctionne, qu'est-ce qu'on ferait les 10 minutes supplémentaires ? Tout ce qui est en dessous des 10 minutes, on s'en fout, on met ça à la poubelle pour l'instant, on met ça de côté. On se focalise sur les 5 minutes, on sait ce qu'on doit faire si les 5 minutes sont validées. Et à partir de là, je demandais, ok, comment on validerait qu'il faut qu'on passe des 5 minutes aux 15 minutes ? Et donc là, tu avais tes indicateurs de succès qui montraient comment tu allais valider. Et donc, on avait tout. Les gens, on refaisait un atelier de détail avec le design, etc. On faisait les maquettes ensemble, on les posait, on les confrontait. On arrivait à déterminer ce qu'on allait faire. J'avais juste à prendre le contenu des ateliers, le transformer en ticket. mettre le mot, le découpage qu'ils avaient décidé, parce qu'ils avaient découpé ensemble, de mettre les personnes, parce qu'en fait le design devait compléter les maquettes, mais c'était engagé dans les ateliers à le faire, et les devs s'étaient engagés sur ce qu'ils allaient faire. J'avais juste à formaliser ce qui avait été dit dans la discussion.

Terry : Et ça, et après est-ce que tu ne tombais pas du coup très inspirant et ça donne envie de mettre en place ce genre d'approche dans des structures, après dans des petites équipes évidemment, pour pouvoir faire ce genre d'atelier assez pluridisciplinaire, tu le fais à petite échelle aussi parce que tu ne peux pas mettre dix devs ensemble avec… Oui, tu fais.

Nicolas : Sur les personnes qui peuvent.

Terry : Qui sont pertinentes aussi pour les ateliers. Hyper intéressant, ma question qui vient par la suite, c'est est-ce que tu rencontrais pas des problèmes par exemple de cas où effectivement on sort des wireframes sur Figma plutôt bien faites, avec une spec plus ou moins dessinée à grosse maille lors de ces discussions, mais en phase de livraison, de mise en œuvre par la partie technique, par le développement, Parfois des grosses questions sur justement, là ce n'est pas détaillé ce qu'il faut faire ici, comment je fais ? Ou est-ce qu'au final grâce à ces ateliers, les décisions étaient prises de manière.

Nicolas : Autonome par l'équipe de dev ? En fait, une US normalement ça sert à donner aux devs l'orientation qu'on va prendre. Quand tu fais ces ateliers-là, tu donnes pourquoi on le fait, tu les aides, tu définis un peu comment on va le faire avec eux et ils sont responsables du quoi. Et tu leur mets une contrainte de temps de toutes les deux semaines. On doit livrer un truc toutes les deux semaines. Peu importe et on a des manières de valider qu'on est dans le bon chemin ou pas. C'est quoi le minimum qui nous permet de nous dire qu'on est dans le bon chemin et qu'on doit déployer la suite ?

Terry : Et donc ça a donc très clair et ça me fait rebondir sur des manières effectivement de mesurer parce que ça enfin tu peux pas te permettre de faire ce genre de choses sans mesurer l'impact. de ce que tu livres, et donc sur cette logique de mesure et de collecte de métriques, là, comment tu travaillais là-dessus, comment tu travaillais là-dessus, notamment dans, voilà, des petites structures en mode First PM, quoi.

Nicolas : Alors, souvent, il y avait des initiatives qui avaient été prises, un mix panel, tout ça, etc. Le problème de la data, c'est que quand on met en place la data, c'est un bourbier sans nom. J'ai même été dans des boîtes où il y avait des départements entiers de data, même une boîte de 60 personnes où il y avait 5 personnes à la data. C'est énorme. ils mesuraient absolument pas l'impact des fonctionnalités qu'ils produisaient. Eh ben en fait, cette logique que je te dis des 5, 10, 15 minutes etc, en fait tu dois l'appliquer de la même manière à la data. Quel est le minimum qu'on a besoin de faire pour mesurer qu'on est dans le bon chemin ? Et si c'est passé par la base de données ? parce que c'est une manière de prendre de la data, parce qu'il n'y a pas de matomo ou tout ça qui sont mis en place, eh bien tu le fais par la base de données. Et moi, dès au moins dans les premiers temps, je prenais des fichiers Excel, je prenais l'info, je faisais des exports des infos, je les mettais quelque part, je faisais des tunnels de conversion, je regardais s'il y avait eu un changement dans l'histoire. Si il n'y en avait pas, enfin comme ça, ça me donnait une réponse à ma question en fait.

Terry : Là-dessus, donc sur la partie mise en œuvre, très clair, c'est-à-dire s'il n'y a pas toute une stack data, une équipe product analytics ou autre, on va trouver des moyens d'aller chercher cette donnée, que ce soit en tapant en direct dans les bases du produit ou autre. Ma question, en plus de ça, elle porte aussi sur l'aspect comment tu définis en fait ces métriques-là, c'est-à-dire comment tu vas les choisir que pour mesurer l'outcome de telle fonctionnalité à la fin des deux semaines, on a décidé de prendre ces deux métriques-là et de les fusionner, d'en faire une moyenne. Peu importe les métriques, comment tu arrives en fait à la qualification de ces métriques et comment tu alignes les équipes, parce que c'est ça aussi derrière le sujet, que ces métriques-là sont les métriques pertinentes à mesurer pour le succès ou non de ce qu'on va livrer.

Nicolas : Alors, première des choses, il faut accepter qu'il y a un peu de pifomètres. C'est la première des choses. Mais dire si tout le monde globalement est plutôt d'accord, en fait, il faut aussi croire un peu en l'intelligence collective. C'est-à-dire que globalement, je disais à tout le monde, souvent on tombait d'accord sur un chiffre. On se disait si 20% des gens cliquent sur ce bouton-là, Toujours parler en pourcentage d'ailleurs, j'insiste dessus, jamais de valeur brute. Il y a un tunnel de conversion, on définit les étapes du tunnel. La personne vient, fait cette info-là, tant de personnes vont sur cette page, tant de personnes voient cet encart-là, cliquent dessus, passent à l'étape d'après. Ça, c'est un tunnel de conversion et qui n'est pas mal. Et en fait, on définissait si 20% des gens cliquent dessus, on est content. Après, à quel moment on ouvre le champagne, tu vois ? Après, il faut un peu gamifier le truc, tu vois, genre à quel moment tu ouvres le champagne, à quel moment tu es content, à quel moment on se dit on passe à l'étape d'après. Tiens, si je dis 10%, ah non, ce ne serait pas top. Tu vois, on est un peu là-dedans. Tu as toujours un fondateur qui veut pousser encore plus haut, tu as quelqu'un qui le ramène à la raison, qui lui dit non, attends, c'est quand même beaucoup si on fait ça. Souvent, c'est un peu du pifomètre. Par contre, le plus important, c'est de montrer qu'une fois que tu l'as mis en… Tu mets autant de temps à mettre en prod qu'à mesurer ce que tu fais. Parce qu'en fait ça marche cette dynamique là, si par la suite quand tu vas faire une démo tu vas montrer à l'ensemble de la boîte voilà ce qu'on a produit, mais dans deux démos d'après tu reviens en disant voilà ce qu'on a appris de la fonctionnalité qu'on a mis en prod avec ce qu'on avait défini ensemble à ce moment là.

Terry : Là, excuse-moi, ça a déconnecté dans mon cerveau juste sur la dernière phrase que tu viens de dire. Voilà ce qu'on a appris de là où je ne trouve plus mes mots.

Nicolas : Si tu peux juste le rephraser, vas-y. En fait, cette partie-là est la plus importante. En fait, c'est surtout ça. En fait, on s'en fiche de faire du Delivery et du Discovery. Globalement, quand on est en startup, on n'a pas l'argent pour faire le truc parfait et on est limité par le temps. Par contre, la seule chose qu'on peut montrer, c'est la courbe d'apprentissage de ce qu'on montre. C'est-à-dire que comment des chantiers qui pourraient partir... On oublie en fait que les devs ça coûte de l'argent. Quand tu mets six mois à travailler sur une fonctionnalité, tu prends le salaire de tes six devs. Imaginons, enfin, sur six mois, tu as le coût que ça t'a coûté. Tu prends ton salaire aussi, tu prends tout ce que tu n'as pas fait, tu prends tous les gens qui sont concernés et tu regardes combien ça t'a coûté cette fonctionnalité. Ton but, c'est de passer d'un truc où tu as une idée, tu délivres, à un but où tu as une idée, tu la dérisques très rapidement en deux semaines, tu la laisses tourner, tu apprends, À partir de ça, tu régénères des apprentissages, vous refaites un lot de deux semaines, vous laissez tourner, vous réapprenez, etc. Parce qu'en fait, tu dois dérisquer et dire à chaque instant, toutes les deux semaines, tu dois pouvoir te dire, ce truc sur lequel on a travaillé, ça ne sert à rien, on le met à la poubelle. Et on l'oublie, on le supprime, on retire de nos têtes, on n'en parle plus, ça ne fonctionne pas. On a des preuves, il ne faut pas investir plus dedans. Ça par contre, ce truc-là, il a pris, il faut le développer plus loin.

Terry : Très, très clair, ouais. Donc merci pour la précision. Effectivement, alors après ce qui peut être, pour challenger un peu ça, ce qui peut être complexe parfois, c'est certaines idées n'ont pas pu trouver leur validation en deux semaines, enfin leur preuve de pertinence en deux semaines, et parfois il faut plus de temps, mais ça peut aussi se discuter de manière collégiale et de dire, ok, ben là on n'a pas atteint ce qu'on avait pensé comme métrique, mais collectivement on se dit, faudrait qu'on pousse quand même parce qu'il y a d'autres indicateurs qui nous incitent à penser que, et du coup à un peu faire tirer sur plusieurs sprints avant de vraiment sortir l'idée.

Nicolas : C'est un peu ça, et je vais même aller plus loin. C'est aussi de dire, tu vois, un design sprint te dérisque un truc en moins de deux semaines. Quelqu'un qui sait gérer un design sprint, si tu n'as jamais fait design sprint de ta vie, c'est très dur à mettre en place. Mais si tu en as déjà fait un, en une semaine tu arrives à dérisquer un sujet sans même faire de code. Donc ça, c'est un stade extrême. Si tu as une validation de ça, il faut créer un plan qui va, avec ce que je t'ai dit, les ateliers où tu séquences avec tout le monde, tu fais la première version, mais cette première version, vous allez chercher à l'atteindre en deux semaines. Et par expérience, c'est toujours possible. Il n'y a que dans des industries où ce n'est pas possible, c'est dans de la deep tech. Mais dans ce cas-là, tu vas faire plusieurs design sprints d'affilée pour t'assurer du retour sur insistement de ce que tu fais. Et en fait, tu vois dans cette démarche-là que je te décris, en fait tu fais deux semaines quelque chose, mais pendant que tu délivres, tu fais de délivery pendant deux semaines, tu fais du discovery sur un autre sujet pendant deux semaines. Et en fait, en faisant ça, tu arrives à cumuler trois initiatives en même temps que tu dérisques. Et en fait, on arrivait à pivoter très fortement toutes les semaines ou deux semaines.

Terry : C'est hyper intéressant, ça montre aussi la vitesse à laquelle ça peut aller sur cette maturité d'entreprise. Je pense qu'on a fait un bon tour du rôle de First PM, de comment emmener les choses quand tu viens d'arriver, de bien comprendre les problèmes que tu vas résoudre, et puis ensuite dans la partie plus pratico-pratique, la mise en œuvre, le quotidien. Pour revenir un petit peu juste sur le sujet second PM, je ne sais pas si tu voulais ajouter des choses quand tu parlais du first second PM, du coup souvent parce que comme tu le disais, tu montes cette première marche mais il y en a beaucoup beaucoup d'autres à suivre, mais en fait ton rôle toi en tant que first PM c'est plutôt de faire en sorte que cette première marche, tout le monde soit bien monté dessus, ne regarde pas derrière et soit assez stabilisé plutôt que de chercher à monter toutes les autres. Je ne sais pas si tu veux compléter des choses par rapport à ça, et ce rôle du first second PM aussi.

Nicolas : En fait le first PM il va souvent un peu se cramer. Je me suis cramé, enfin pas cramé, mais c'est dans le sens où tu vas de deux, enfin pour ma part un first PM il se donne à fond s'il veut réussir sa mission. et il va donner pas mal d'efforts, etc. Je sais que moi, dans les deux missions que j'ai pu faire, enfin les deux entre 2017 et 2020, il n'y a vraiment eu, je ne sais pas, ça n'a pas duré plus d'un an et demi. Parce qu'en fait, tu vas aller sur des sujets, ça va être long, c'est une acculturation assez forte. En fait, tu crées un électrochoc pour les fondateurs. Après, tu as plein de succès, mais en fait, c'est très long. Ça dépend de l'orgueil que tu as en face de toi aussi. Pour ma part, la deuxième avait été rachetée par un grand groupe. Tu as d'autres personnes à convaincre dans leur gars et c'est beaucoup plus long. Mais souvent, tu peux avoir une sensation de te cramer et après, on va recruter quelqu'un d'autre qui va continuer dans cette vague-là et qui va prendre les reigns là-dessus. Et ce n'est pas du tout la même démarche.

Terry : Oui, d'où le first second PM.

Nicolas : C'est ça. Tu as l'évangélisateur et le stabilisateur.

Terry : Assez clair. Avant d'aller vers mes questions de fin d'épisode, est-ce qu'il y a un point en particulier sur ce sujet de First PM que tu aimerais mettre en avant ?

Nicolas : Il y a peut-être un truc que je n'ai pas assez discuté, c'est à quel point quand tu arrives en tant que premier PM dans une boîte, qu'il y a déjà un existant, qu'il y a déjà une manière de fonctionner et qu'il ne t'attend absolument pas. Parce qu'en fait, quelqu'un t'a recruté, mais dans les équipes, certains t'attendent, d'autres ne savent même pas à quoi tu sers. Genre même, ils ont même peur. C'est quelqu'un qui va nous mettre plus de bâtons dans les roues, on ne va pas comprendre ce qu'il va nous faire, ça va être un mini-chef, on va avoir un management intermédiaire. Il y a plein de sujets comme ça. Moi, ce que j'ai d'habitude à dire, c'est quand j'arrive dans une boîte, par exemple j'étais arrivé dans une boîte de 20 personnes, en deux semaines, le tour était fait et j'avais une vue d'ensemble. Mais en fait, dans la boîte où je suis arrivé, il y avait 60 personnes. En fait, de dire à la personne qui te recrute, mais laisse-moi un mois. Pendant ce mois, je ne fais rien du tout. Je ne fais strictement rien. Tu me laisses prendre les efforts nécessaires, je prends toute l'info nécessaire. Et donc là, en fait, par rapport à ce retour d'expérience, pendant deux semaines, pendant ce mois, deux premières semaines, j'ai parlé avec tout le monde dans la boîte. J'ai parlé avec les 60 personnes. Et quand je dis parler dans la boîte, ça veut dire, salut, qu'est-ce que tu fais ? Explique-moi ton job. Qu'est-ce que tu fais au quotidien ? Toi, comment tu vois la relation avec la partie tech ? Tu as entendu parler. Tiens, qu'est-ce que tu verrais que je pourrais apporter à la boîte ? C'est quoi ce que tu verrais comme amélioration à faire dans cette boîte ? Tiens, c'est quoi le truc que tu te dis mince, on a vraiment des efforts à faire là-dessus ? Qu'est-ce que tu dis que c'est dommage qu'on ne fait pas ? Tu vois le genre de questions ? Parce que ton sujet à ce moment-là, c'est de comprendre le fonctionnement interne, de comprendre le métier de chacun, de trouver tes potentiels alliés dans la boîte parce que tu as des alliés dans tous les métiers de la boîte et de trouver quel est le levier d'activation de la personne et d'engagement que tu vas pouvoir faire pour t'aider dans ton quotidien.

Terry : C'est hyper intéressant et tu fais bien de le mentionner parce qu'effectivement c'est un rôle très central en termes de... un rôle où la communication est juste primordiale et la capacité à aussi s'adapter en fonction des différentes personnes et donc pour s'adapter il faut les comprendre, les connaître, savoir comment elles travaillent dans cet environnement-là et pas arriver avec... avec ses grands chapeaux et faire... Ça c'est peut-être le.

Nicolas : Plus grand sujet d'un first PM. Si t'arrives avec tes grands sabots, t'inquiète pas que tu vas te faire... Oui.

Terry : Sabots plutôt que chapeaux.

Nicolas : Non mais tu vas te faire, tu vas clairement te faire allumer à un moment et tu vas avoir des résistances. Et en fait, tu dois pas être pour le fondateur, tu dois pas être pour les équipes, tu dois être entre les deux. Tu dois avoir autant d'empathie pour le fondateur que pour les équipes. Et j'insiste aussi dessus, tu vois quand je te parle de toutes ces manières de construire ensemble, tu viens pour apporter une démarche, une structuration de la manière de travailler ensemble. Cette structuration a se construit avec les équipes en place. Oui, tu as des retours d'expérience à donner parce que tu as vécu plein de moments différents, mais en fait, tu vois par exemple le truc de la morning routine, Quand je suis arrivé, j'ai fait des petits jeux en mode tiens, moi je connais ce genre de trucs-là. On a fait un jeu, chacun a expliqué sa morning routine, on a mis en commun, on a expliqué voilà ce que c'est le produit et voilà comment on peut le mettre en place. Qu'est-ce que vous avez envie de faire avec ça ? Et ça se construit. Le pire des moments, c'est quand j'ai eu des moments où ça a très bien fonctionné, des méthodes parfaites dans une boîte, j'arrive dans une autre boîte, ça a complètement foiré. Et vu que ça a complètement foiré, celle d'après, ça a été un succès.

Terry : Donc il n'y a pas de règle ultime, c'est plus après comprendre le contexte de la boîte pour appliquer ensuite, essayer de trouver si avec d'autres expériences tu peux aussi apporter effectivement des choses qui te semblent pertinentes ou adapter et en trouver d'autres. Là-dessus, très clair. Du coup, pour aller vers mes deux questions de fin d'échange, la première c'est est-ce que tu as une conviction ? Déjà, merci encore pour ces partages que je les trouve très concrets, très proches du terrain pour tous les first PM ou même second first PM qui nous écoutent ou les fondateurs évidemment ou ceux qui font partie de startups qui ne soient pas directement liés aux produits mais qui seront confrontés d'une manière ou d'une autre pour comprendre un peu mieux les enjeux, les challenges. un échange très très très très pertinent donc déjà merci pour ça Nicolas et donc pour aller vers mes deux questions de fin donc la première c'est ce que tu as des convictions fortes ou en général tu te retrouves en désaccord avec tes pairs lorsque tu les partages ?

Nicolas : Alors une conviction forte la première encore plus en tant que first pia Mais en fait, pour moi, c'est même un truc que je ne comprends pas, c'est que... Mais peut-être que j'ai été entrepreneur avant d'être product. En fait, tu n'as pas besoin... Alors déjà, les PO qui font des tickets, je ne comprends absolument pas. Parce qu'en fait, quand tu as compris la capacité que tu as quand tu utilises le... Tu mènes des ateliers de cette manière-là, En fait, il y a des rôles qui n'existent pas. Tu n'as pas besoin de ça. Les gens prennent l'autonomie, écrivent l'étiquette tout seul, complète de leur côté, savent où il faut aller, on n'a pas besoin d'écrire plein de choses. En fait, la première des choses, c'est qu'en tant que first PM, tu dois être au temps. Tu ne dois pas faire beaucoup de délivery, mais par contre, tu dois donner un cadre où le delivery a le bon cadre dans lequel il interagit. Et en tant que first PM, ton produit, tu n'en as rien à faire. Ton rôle, c'est de faire passer une équipe avec un fondateur et une équipe qui ne savent pas forcément bien travailler ensemble à un process qui est bien huilé et c'est ça ton principal enjeu. Et dans ce rôle-là, le first PM, ce n'est pas vraiment un PM. C'est plutôt une sorte de coach.

Terry : Hyper intéressant comme point de vue. Je pense que de toute façon, ça.

Nicolas : Fait le lien avec tout ce que.

Terry : Tu viens de partager comme retour. Moi, je dois dire que sur ces expériences-là que tu as partagées et les conseils, je suis plutôt aligné. Après, sur cette conviction forte, tu m'as convaincu sur ce qu'il faut faire en tant que First PM. Après, je pense qu'évidemment il n'y a pas de vérité absolue et il faut adapter en fonction des contextes, mais l'aspect facilitateur, là-dessus je te rejoins à 100% et donc effectivement les compétences nécessaires pour ça sont beaucoup plus sur les aspects humains, psychologie et savoir s'adapter et comprendre les problématiques des uns et des autres et les traduire parce que même s'ils parlent la même langue, ils l'interprètent de manière différente. Donc là-dessus, je te rejoins. Après, peut-être que certaines boîtes vont quand même avoir des besoins au départ pour faire ses preuves, comme tu le disais, de quand même aller mettre les mains dans la délivrer.

Nicolas : Il faut montrer que tu connais la manière de faire, c'est bien d'avoir un background technique quelque chose. En fait, derrière tout ça, c'est-à-dire les soft skills en premier. Mais pour les personnes qui sont plus dans un lead et qui veulent créer du changement, Si tu aimes travailler sur un produit que ça te fait kiffer, on s'en fiche. C'est de travailler sur ce produit, tu veux donner tes idées là-dessus. Si tu aimes le changement et créer des changements dans les équipes, je parle de lead, je parle de head of product, je parle de CPO, des premiers CPO aussi parce que les first PM sont des futurs CPO en fait des boîtes. En fait, il faut que tu aies une démarche d'empower les équipes. Pour ça, ne sois pas dans l'équation, on n'a pas besoin de toi.

Terry : Hyper, hyper clair. Et donc pour aller vers ma dernière question, c'est quelles sont les choses qui t'inspirent, te nourrissent intellectuellement, les ponts que tu peux trouver du coup pour ton activité professionnelle ?

Nicolas : Alors, je n'ai pas parlé des frameworks, ça, c'est peut-être une autre conviction. Les frameworks, j'en ai beaucoup appris. J'ai beaucoup lu dans cette période de transition entre j'étais entrepreneur et je n'apprenais pas de ce que je faisais. J'ai changé, je suis sorti et j'ai énormément appris. Beaucoup de littérature, on s'en fout des Marty Kagan, c'est nul ce qu'il dit. Enfin, c'est globalement intéressant, mais en fait, vous n'allez rien apprendre d'actionnable dedans. mais lisez-le juste pour comprendre l'essence même, mais il y a des outils autres. Savoir faire un story mapping, il y a des outils, un impact mapping, des outils comme ça. Comprenez l'essence derrière le truc parce qu'en fait, il y a énormément de lecture là-dessus. J'ai une liste de lecture que je pourrais te partager si tu veux le mettre dans le truc du podcast, c'est un très long avec plein de choses. Mais en fait, dans cette démarche de changement, des choses comme l'écoute active, développer les parties coaching, développer la capacité à savoir mener des conversations dures, cruciales, ou même limite tu te sens attaqué, si tu te prends un peu personnellement. Toutes ces étapes-là m'ont énormément servi. En fait, c'est beaucoup plus du développement personnel, de la compréhension des besoins des gens. Je vais me dire autrement, dans pas mal de ces livres-là, développement personnel, ça a été sur la partie Considère, toi, tes interactions comme un produit. Tes personnes sont des utilisateurs des solutions que tu as proposées. Apprends à parler avec eux, à comprendre leurs besoins et de ne pas aller direct dans la solution. Parce qu'en produit, ce qu'on prône, c'est dire remonter au problème pour ne pas aller direct dans les solutions. Donc, apprends surtout à remonter au problème avec toutes les personnes avec qui tu es.

Terry : Très clair. Et bien encore merci pour ton temps Nicolas. Et puis avant de te laisser, si les personnes sont intéressées à échanger avec toi, quel est le meilleur moyen de te contacter ?

Nicolas : Par LinkedIn où LinkedIn est le bon canal en tout cas. Top.

Terry : Et bien merci encore Nicolas.

Nicolas : Merci à toi Terry.