Marc Vidal, Comment construire un SaaS B2B à partir de zéro

Transcription de l'épisode : "Marc Vidal, Comment construire un SaaS B2B à partir de zéro"

Terry : Salut Marc.

Marc : Bonjour Terry.

Terry : Merci du coup de me recevoir à Marseille. On va parler donc aujourd'hui de Product. Mais ce qui est intéressant avec ton parcours que tu vas nous partager, c'est un aspect très pragmatique en fait de comment tu fais pour développer à la fois le rôle de Product Manager, la culture produit dans une boîte qui est initialement pas spécialement créée par des personnes qui viennent du monde de la tech ou qui en tout cas ont tous les codes de ce monde-là. Et donc au travers d'une de tes expériences passées, tu vas un peu nous raconter tout ça et puis on va échanger sur les difficultés que tu as pu rencontrer et aussi voir un peu, du coup, en tirer des conseils pratiques pour des personnes qui pourraient être dans des situations similaires. Donc avant de rentrer dans ce sujet-là, je te propose de te présenter succinctement.

Marc : Ok, très bien. Merci Terry déjà de me recevoir. Tu me reçois chez moi, c'est particulier déjà, mais pas de souci. Me présenter, donc moi Marc Vidal, j'ai 38 ans. Ça fait quoi ? Ça fait depuis 2009 que je suis en activité. J'ai toujours travaillé chez des éditeurs de logiciels, j'ai fait 6-7 ans chez Dassault Systèmes et ensuite 6 ans chez NeoVacom, l'expérience sur laquelle on va revenir plus en détail dans ton podcast. où j'ai été recruté en tant que responsable d'innovation, un mot qui veut tout dire et rien dire. J'ai développé la culture produit dans cette boîte et depuis octobre de l'année dernière, je suis freelance produit. Je ne sais pas si tu veux savoir d'autres choses sur moi.

Terry : Je t'ai dit succinctement c'est parfait, on va rentrer dans le détail de cette expérience concrètement. Tu es recruté dans cette boîte à l'époque en tant que responsable d'innovation. Quand tu arrives, pour poser le décor, combien il y a de personnes autour de ce sujet ? Qu'est-ce qu'on te demande de faire ?

Marc : Alors, la boîte déjà, Neovacom, à la base c'est une, comment dire, c'est une entité d'une autre société qui s'appelle Enovacom, donc là déjà la subtilité, un éditeur de logiciels à Marseille dans le domaine de la santé et des échanges, on appelle ça les échanges EDI, EAI, de l'échange de données on va dire. Et en 2015, il y a une personne qui a fait une sorte d'audit de cette boîte et qui s'est aperçu que chez NovaCom il y avait une petite unité de 3 à 4 personnes qui n'avait rien à voir avec Enovacom en soi, en fait, et qui travaillait sur un vertical qui était complètement différent, qui était les bailleurs sociaux, mais avec la même solution d'échange de données, en fait. Et cette personne-là a finalement pu récupérer cette partie-là de la boîte. On a créé une société à part entière, Neovacom. Et donc, les 3-4 personnes qui travaillaient pour Enovacom sont devenues vraiment Neovacom, entité juridique à part entière. Et la société Neovacom est devenue un intégrateur des solutions Enovacom. Et c'est à cette période-là où j'ai rejoint la boîte, vraiment à la création. Je pense que quand j'ai intégré Neovacom, la boîte existait peut-être depuis un mois et demi réellement. Donc moi j'étais déjà dans le processus de recrutement pendant la séparation des deux boîtes. Et le souhait de mon dirigeant à l'époque, c'était vraiment de faire en sorte qu'on devienne éditeur de logiciel. Comment ? Quel type de logiciel ? Il n'y avait pas trop de sujets parce qu'on ne savait pas forcément vers où aller. Potentiellement, c'était remplacer le logiciel qu'on était en train de revendre ou trouver une autre opportunité. C'est pour ça qu'il m'a recruté en tant que responsable d'innovation. Avec l'expérience que j'avais d'un autre éditeur de logiciel, il s'est dit que ça allait le faire et on est parti de là.

Terry : Ok. Donc, vous étiez 3, 4, 5 ?

Marc : Pour faire simple, deux commerciaux.

Terry : Ok.

Marc : Une personne qui était là pour faire de l'intégration. On appelle ça chez Neobacom de la chefferie de projet, on va dire de l'intégration. Donc, vraiment mise en place du logiciel chez les clients. Là, c'est un logiciel qui est on-prem et le dirigeant. Et en fait, quand je suis arrivé, il y a un troisième commercial qui est arrivé et une personne qui était là plutôt pour l'administratif.

Terry : Ok, donc t'arrives toi en tant que responsable d'innovation, qu'est-ce qu'on te dit de faire concrètement ?

Marc : Alors, il y avait le souhait et après, il y avait l'émission. Le souhait, c'était vraiment être éditeur de logiciel. Quel logiciel ? À moi de trouver. Maintenant, au niveau d'émission, il fallait quand même être très concret. Il y a un salaire à payer, donc il y a des choses à apporter. J'ai beaucoup accompagné, énormément accompagné la personne qui était en charge de l'intégration au départ. Ce qui est complètement logique, ça m'a permis de connaître les clients. On avait une base de clients qui était quand même assez importante dès le départ. Les bailleurs sociaux, c'est un vrai marché de niche en France, j'en parle pas forcément, mais je crois qu'il y a 500 ou 600 bailleurs sociaux. Et plus de la moitié travaillent déjà avec NeovaCom sur de l'échange de données. L'échange de données, ça rentre dans les détails, mais pour tout ce qui est allocation ou gestion du numéro unique d'un locataire, on ne va pas rentrer plus dans les détails que ça. Donc, ça m'a permis de bien comprendre le contexte. J'ai installé la solution chez beaucoup de clients. Ça m'a permis aussi de comprendre le contexte et l'écosystème, c'est-à-dire quelles sont les particularités des bailleurs sociaux. Déjà, c'est un milieu qui est super intéressant dans le monde de la tech parce qu'en fait, ils ne sont pas forcément très en avance, mais On peut le dire, ils ont quand même du budget en fait. Ils ont du budget, pas forcément du budget alloué au niveau informatique, mais c'est des gestionnaires de patrimoine en fait. Ils ont du patrimoine, il y a de l'argent, il y a des subventions, donc il y a quand même de quoi mettre en place des vrais projets quand on arrive à montrer qu'il y a un intérêt, il y a de l'argent en fait. Donc ça c'est quand même assez intéressant. Ensuite, l'écosystème d'un secteur d'activité, c'est super important. Comprendre les acteurs, les différents, comment dire, les éditeurs de logiciels qui sont dans ce secteur-là par rapport à des logiciels administratifs, des logiciels métiers, ce genre de choses. Pendant, on va dire, 7-8 mois, beaucoup d'installations, de rencontres clients, j'ai fait beaucoup de déplacements. Je suis assez vite monté en compétence sur le produit. J'ai été autonome au bout de 3 mois. J'étais quand même objectivé. L'idée, c'était à chaque fois qu'on fait une installation, derrière, c'est là où on peut le facturer. J'avais un objectif de facturation. On restait une petite boîte, il fallait quand même faire rentrer du cash. Responsabilité d'innovation, c'est bien. Mais derrière, il fallait que j'arrive à ramener des sous dans la caisse. Donc, les premiers mois assez intenses et on va dire au bout de 6-7 mois, typiquement quand je commence à avoir fait rentrer assez de chiffres, on va dire, pour me libérer de la bande passante, j'ai pu diversifier un peu mon activité vraiment et me consacrer plus à l'écosystème, c'est-à-dire comprendre où il pouvait y avoir des opportunités. Donc ça c'est vraiment au niveau de l'externe on va dire, et au niveau de l'interne c'était avec mon DG, discuter sur ce qu'il fallait faire pour devenir éditeur de logiciels. Parce que c'est bien beau, mais il y a un chantier qui est assez énorme. la culture qu'il faut amener, et je ne parle même pas de culture produit, là je parle déjà d'être éditeur de logiciel, c'est-à-dire quels allaient être les besoins en interne, quand quelqu'un ne vient pas de ce domaine-là, ça peut paraître assez nébuleux, il faut bien appuyer sur les postes qui peuvent être stratégiques. Donc le premier sujet qu'on avait de fond, c'était potentiellement remplacer le logiciel qu'on était en train d'intégrer, sur de l'échange de données. Une opportunité sans en être vraiment une, c'est-à-dire pas vraiment d'analyse marché, on sait qu'il y en a forcément vu qu'on est en train d'installer un logiciel, et c'est plutôt que de reverser des parts des bénéfices, c'est tout avoir pour nous. Donc on a voulu quand même staffer une ERD par rapport à ça pour sortir un produit plus à jour sur de l'échange de données, J'ai accompagné mon DG au bout de cinq mois je pense pour recruter un CTO déjà. Pareil avec quand même un projet qui était assez vague au départ. Donc on a eu de la chance de tomber sur un CTO qui cartonnait quand même, quelqu'un qui est plutôt au top.

Terry : Donc CTO qui j'imagine, parce que là ce que tu es en train d'expliquer c'est que vous avez commencé donc en intégrant une solution, le premier truc que vous êtes dit c'est cette solution plutôt que l'intégrer on va redévelopper un compétiteur. Et donc pour faire ça, CTO, donc j'imagine très les mains dans le cambouis, c'est-à-dire un CTO qui code, j'imagine ?

Marc : Voilà, ouais, tout à fait. En fait, on est tombé sur une personne qui cochait tous les critères, c'est-à-dire un mec qui met les mains dans le cambouis, mais qui est capé. Et c'est pas forcément facile à trouver, il y en a, après il faut voir aussi les tarifs et compagnie. Et là on est tombé sur une personne qui avait une belle expérience, quelqu'un d'une cinquantaine d'années, qui avait été dans des startups, qui avait été également freelance, et là qui voulait revenir justement dans un livreur startup, CDI, qui mettait énormément les mains dans le cambouis, mais qui était à jour sur toutes les nouvelles technos, ultra curieux, vraiment un mec Moi, pour mon expérience perso, il m'a énormément aidé justement au niveau produit. Donc, super intéressant. On l'a recruté, pareil, avec une feuille de route qui n'était pas forcément très claire. Lui, son premier challenge, ça a été vraiment de comprendre le produit actuel, comment il marchait, quelles étaient les forces du produit actuel d'un point de vue technologique pour essayer d'imaginer une solution un peu équivalente. Donc en fait moi mon premier travail ça a été à insuffler un peu l'idée de devenir éditeur de logiciels, les postes à recruter, le CTO c'était quelque chose d'assez naturel. Derrière faire comprendre qu'un CTO c'est bien mais il y a quelques devs à recruter. Les devs tu les recrutes au final quand tu as un vrai projet et que tu veux avancer. Et toutes ces notions qu'on entend depuis quelques années au niveau produit, la discovery, le delivery et compagnie, pour moi, c'était nébuleux tout ça. Je ne connaissais pas forcément, je n'avais pas forcément ces termes-là. Et ça s'est fait au fil de l'eau pendant l'expérience NeovaCom. C'est-à-dire que là, on avait recruté le CTO, lui, il mettait les mains dans le cambouis sur le projet qu'on avait. Et moi, je commençais à m'intéresser beaucoup plus au contexte externe pour arriver à déceler une opportunité.

Terry : Du coup comment tu dis mettez les mains dans le combouis sur le projet enfin sur en gros pas dupliquer mais faire un compétiteur de ce que vous intégrer déjà c'était quoi en termes de specs en gros est-ce que lui tu lui fournissais un peu de specs à faire ?

Marc : On était même pas sur les specs c'est à dire que là on analysait le produit on essayait de comprendre ce que vous intégriez voilà exactement ce qu'on était en train d'intégrer J'en ai pas forcément parlé parce que je parle d'EDI, EAI, échange de données, mais pour faire simple, l'image que les commerciaux aiment bien donner de ce produit, c'est quand on est chez le bailleurs sociaux ou dans un établissement de santé, il y a les logiciels métiers. Et en fait, il y a des données qui ont besoin d'être synchronisées entre les logiciels métiers. Et ce type de solution, c'est là pour synchroniser tout ça. En fait, c'est le système sanguin et les logiciels métiers, c'est les organes vitaux, on va dire. Donc nous, on a apporté la donnée d'un logiciel patient, je ne sais pas, pour de l'administratif où il y a des données patients, par exemple. Je fais un parallèle avec la santé, sachant que nous, ce n'était pas le côté santé. mais donc un logiciel patient qui avait des données qu'on devait transférer à un logiciel par exemple pour le secrétariat ou un logiciel pour le labo. Dans ce type de société, il y a vraiment des solutions qui sont au cœur du SI et qui sont là pour transférer de la donnée, pour s'assurer justement de la synchronisation de celle-ci. Et après, ces données-là, elles sont également à échanger avec l'externe. Par exemple, nous, chez les bailleurs sociaux, on devait échanger avec l'État, par exemple, sur une notion de numéro unique. Quand on est demandeur auprès d'un bailleur social d'un logement, en fait, on se voit attribuer un numéro unique qui nous suit tout le long de notre demande. C'est avec une plateforme étatique. Pour échanger avec la plateforme étatique, il faut avoir certaines accréditations, le faire sur certains protocoles de communication, et c'est pour ça que c'est des logiciels comme celui-là qui sont en capacité de faire ces échanges-là. Donc l'idée c'est, quelque part ce que je viens de décrire, c'est le travail qu'a dû faire mon CTO. C'est-à-dire comprendre comment ces logiciels étaient utilisés chez les clients, quelles étaient les forces de ces outils-là. Donc c'est, en fait on parle principalement de protocoles de communication, de transformation de la donnée. C'est des outils qu'on appelle en général des ETL, Extract, Transform and Load. Donc voilà. Donc ça c'est à quoi servent ces outils et derrière la plus-value c'est comment ils sont utilisés par les utilisateurs, en quoi un ETL est meilleur qu'un autre sur le marché par rapport à une simplicité d'usage, par rapport à un système de notification, ce genre de choses.

Terry : Du coup, juste toujours sur ce premier outil sur lequel donc ton sitio a dû se mettre dedans pour comprendre comment il fonctionne et derrière pouvoir voir comment on peut du coup faire des choses similaires. Juste pour être sûr de bien comprendre, les clients c'était qui ? Les clients qui utilisaient en fait ce chef d'orchestre, on va dire, qui prend la donnée ?

Marc : Chez les bailleurs sociaux, là c'était la DSI. En général, c'est la DSI qui est en charge de, comment dire, d'installer ces logiciels qui ont en fait peu d'interfaces utilisateurs. C'est vraiment des logiciels qu'on va mettre en place, qu'on va configurer et après on est plutôt là pour superviser, voir s'il n'y a pas des alertes sur un transport de données qui ne s'est pas bien passé ou quelque chose comme ça. Donc les clients chez les bailleurs sociaux, c'est la DSI, vraiment ceux qui sont en charge du système d'information. Et par contre, ceux qui sont le plus impactés par ce logiciel-là, c'est les services métiers. Le service administratif, le service de gestion du patrimoine, parce que si sa donnée n'est pas correctement arrivée dans son logiciel, c'est lui qui va râler. Si on n'a pas réussi à déceler l'alerte en amont, les remontrances du client sont plutôt côté métier.

Terry : Ok, donc ça c'est clair. Toujours sur ce premier soft, est-ce que c'était quelque chose qui était installé sur les serveurs des systèmes d'information ?

Marc : On était sur du on-prem, donc quelque part ça c'est des choses qu'on a regardées sur l'évolution qu'on pouvait apporter. On a regardé les technologies qui étaient utilisées, justement le... la façon dont c'était installé, ça, Soundprem, la concurrence. Donc mon CTO était sur l'aspect technique, moi j'étais plutôt là pour regarder la concurrence et compagnie. Mais c'était pas vraiment la, comment dire, ça c'était l'opportunité simple, mais c'était pas forcément la bonne opportunité ou ce vers quoi mon DG voulait aller. Pour une raison simple, et la question que t'as posée juste avant en fait, elle répond aux attentes qu'avait mon DG à l'époque, C'était que ces logiciels-là, ils sont utilisés par la DSI. En fait, ils ont peu de visibilité. Ils sont critiques, mais avec peu de visibilité. Donc, on a l'impression qu'il y a peu de valeur ajoutée, de valeur métier. Et c'est des logiciels qu'on ne vend pas forcément du coup cher ou qui ne sont pas forcément à la vitrine. Donc, ils sont vitals, mais ce n'est pas la vitrine. Et mon DG préférait avoir quelque chose avec une solution métier plutôt finale, on va dire.

Terry : Quelque chose du coup où tu as une interface utilisateur à la fin et que tu peux pitcher à des gens qui sont pas du tout du monde de la technique.

Marc : C'est exactement ça. Et donc là, mon travail sur, comme je t'ai dit, à partir du cinquième, sixième mois, j'étais beaucoup plus au niveau de l'écosystème. Il y a plein d'opportunités qui sont tombées, il fallait les analyser, faire de la discovery, que je rappelais pas comme ça à l'époque. On creusait un peu tous les sujets.

Terry : Là justement, tu prenais comment pour analyser ces opportunités ? C'était quoi un peu ta démarche ?

Marc : Franchement, la démarche, ce n'était pas la bonne au départ. C'est pour moi qui a été génial, j'ai eu une grosse opportunité dans cette boîte-là, c'est de pouvoir évoluer rapidement, on va dire, dans le contexte produit, sur tous les aspects, que ce soit discovery et delivery. Au départ, j'étais peu au contact des utilisateurs, j'avais les clients, mais nos clients, Par contre sur des opportunités qu'on pouvait trouver, j'étais plus la petite souris qui allait chercher sur internet, de la documentation, dans des médias, ce genre de choses. Et j'étais peu au contact de ceux qui allaient vraiment être impactés.

Terry : C'est hyper intéressant justement que tu partages ça parce que c'est vrai que des fois, quand tu viens pas de ce milieu, du milieu produit, c'est un réflexe que tu peux avoir en te disant et puis d'un coup tu commences à... à on va dire dans ta tête construire tout un truc en disant j'ai l'idée de ouf juste basé sur la donnée que tu es allé chercher en fait sur Google mais sans vraiment aller parler à des vrais gens et vraiment voir les vrais problèmes et donc tu es tombé dans ce travers là au début.

Marc : Ouais complètement complètement mais ce qui n'était pas grave en fait parce que c'était des opportunités j'ai envie de dire qu'elle n'est pas forcément débouchée sur un produit mais plutôt sur... Comment le dire exactement ? On peut parler de... j'avais plus l'impression qu'on allait se transformer en société de service et on allait saisir ce type d'opportunité-là parce que peut-être un, deux prospects slash clients pouvaient demander ce besoin-là. Et quand on creusait, on s'apercevait que ce n'était pas quelque chose qui était derrière industrialisable et qu'on allait pouvoir… qu'on avait un marché en fait, tout simplement derrière. Et ce n'était pas les mots que je mettais dessus, mais on s'en rendait compte. Donc, il y avait plein d'opportunités comme ça qui tombaient. qu'on arrivait à analyser, pas forcément de la meilleure des manières ou de la manière la plus efficace. Mais petit à petit, j'ai fait mon expérience comme ça sur 3, 4, 5 mois. Et en fait, après, de manière assez simple, on a pris une opportunité qui était la plus logique à prendre. Les bailleurs sociaux sont une première moitié qui est publique et une seconde moitié qui est privée. Vraiment, c'est quasiment du 50-50. Il y a beaucoup de réformes dans le secteur public qui ont eu lieu ces dernières années sur l'administratif et notamment sur la gestion de la facturation. En 2017, toutes les entreprises du secteur public se sont vues imposer la réception au format électronique de factures, de factures électroniques. Et quand on parle de réception de factures électroniques, on ne parle pas de réception dans une boîte mail d'un PDF. Non, en 2014, il y a eu une réforme qui est passée et qui a pris effet en 2017, qui obligeait toutes les entreprises de la sphère publique à recevoir leurs factures via un portail qui s'appelle Chorus, sous format électronique avec de la donnée structurée. et ce qui allait obliger également tous les fournisseurs de la sphère publique, que ce soit un grand fournisseur d'énergie comme le plombier du coin qui vient réparer un appartement d'un bailleur. Tous ces fournisseurs-là allaient être obligés entre 2017 et 2020 d'envoyer leurs factures à la sphère publique via ce portail-là. C'est-à-dire soit se connecter à une interface et déposer manuellement les factures. Ça, c'est un service qui est utile pour un petit plombier. Maintenant, un fournisseur d'énergie qui envoie à une société qui gère du patrimoine 3 000 factures par mois. Je parle de 3 000, mais ça peut être 50 000 factures par mois. Là, il faut automatiser les choses, être sur certains protocoles de communication et compagnie. En 2017, la moitié de nos clients se sont vu imposer ce portail, ce qui veut dire que l'écosystème des buyers sociaux s'est adapté à cette réforme-là. Les éditeurs de logiciels côté ERP et buyers sociaux il n'y en a pas des masses, il y en a 3-4 vraiment qui représentent 85-90% du secteur d'activité et les 10% doivent rester 10-15 dans le secteur d'activité. Ils ont dû s'adapter à cette réforme-là, c'est-à-dire justement les formats de données, les protocoles et compagnie. Et tous les fournisseurs des bailleurs sociaux ont également dû s'adapter à cette réforme-là. Ce qui veut dire que dans l'écosystème des bailleurs sociaux, les fournisseurs, les éditeurs de logiciels se sont adaptés à la réforme. Tout ça, ça allait bénéficier à la sphère publique. Et par contre, il y avait toute une moitié, la sphère privée, qui n'allait pas en fait bénéficier de toute cette évolution-là parce que le portail n'existait pas pour eux.

Terry : C'est assez clair la réglementation qui est votée en 2014 et prend effet en 2017, la logique d'interfassage pour récupérer de la facture avec des formats structurés. Quand tu parles de formats structurés, ça peut être de l'XML, du JSON. C'est de l'XML, pour faire simple de l'XML. Pour un peu imager la chose, ça c'est assez clair. Donc les acteurs du secteur public, eux ils ont leurs solutions qui ont des adaptations pour permettre ça, mais ceux du secteur privé...

Marc : C'est les mêmes solutions en fait, ils ont les mêmes solutions. Tout l'écosystème s'est adapté au final à la réforme. Et les bailleurs sociaux qui étaient dans le secteur privé se sont vus avec des logiciels qui étaient faits pour cette réforme-là, avec des fondateurs qui avaient fait ce switch pour cette réforme-là. Ça aura un vrai gain pour la sphère publique quand on a de la donnée structurée, ça permet d'automatiser la réception des flux, du traitement, éviter des erreurs, donc il y a un gain qui est quand même assez énorme.

Terry : Oui, même aujourd'hui, là-dessus, ça me fait penser à tout ce dont on parle, l'open data, donc tout ce qui est l'accès à la donnée publique sur beaucoup de sujets qu'on peut aller explorer. D'ailleurs, il y a pas mal de docs là-dessus intéressantes.

Marc : Mais toute cette donnée structurée, c'est super important, ça automatise beaucoup de choses. Et la sphère privée n'avait pas ce portail au milieu de récupération, de transformation à un format attendu pour redescendre dans les solutions métiers. Donc, ils se retrouvaient avec tout un écosystème qui était prêt ils n'avaient pas la solution au milieu pour interfacer tout ce beau monde. Et l'opportunité, elle était assez simple à trouver. Nous, on a toujours travaillé dans l'échange de données, donc on s'est dit, pour faire simple, Neovacom va développer un portail de factures fournisseurs. Pour faire très simple, à la Corus. Donc là, l'opportunité, elle était facile à dimensionner, c'était la moitié du secteur. des bailleurs sociaux, donc on savait qu'on avait un marché cible adressable d'environ 300 bailleurs sociaux. On savait également que la fenêtre de tir, elle allait être assez courte pour arriver à vraiment s'implanter dans le marché, étant donné que ça, c'est une réforme entre 2017 et 2020 qui a été imposée à la sphère publique. Mais ce qui est imposé à la sphère publique, tôt ou tard, c'est imposé également à la sphère privée. Et c'est ce qui va se passer en 2024. Toutes les entreprises de France, le B2B domestique, en fait, va être obligé de faire de la facture électronique. On ne savait pas exactement l'échelle de temps qu'on avait en 2018 quand on a commencé à travailler sur le produit, mais on savait qu'on avait 3-4 ans où il fallait qu'on sorte le produit, qu'on prenne une place de marché assez forte chez les bailleurs sociaux pour arriver après à diversifier un peu la solution. Au niveau des specs, c'était super simple aussi, parce qu'en fait, le portail de l'État a communiqué, comment dire, toutes leurs documentations techniques pour faire des échanges API, pour faire leur format. Alors, je dis simple. On va dire que ce n'était pas forcément complexe à rédiger. Par contre, il fallait tout comprendre. C'était des documents de 350 pages qu'il a fallu prendre en long, en large, en travers, et extraire que ce qui pouvait être utile pour faire la même chose qu'eux, mais à une échelle plus petite et qui correspondait aux besoins vraiment primaires de nos clients qui allaient être les bailleurs sociaux. Donc là mon travail à moi on va dire de discovery a été plutôt prendre le cahier des charges, le parcourir dans tous les sens, arriver à comprendre quelles allaient être les fonctionnalités critiques pour nos clients Et en parallèle, étant donné que nous on travaillait autant avec la sphère publique que la sphère privée, échanger avec la sphère publique sur qu'est-ce qui était utile pour eux sur ce nouveau portail de facturation qui leur a été imposé, parce que ça leur a été imposé. Donc concernant l'expérience utilisateur, en quoi c'était bien, en quoi c'était pas bien. Et au niveau de cette discovery, j'ai commencé un peu à transformer mon discours, à comprendre comment on fallait échanger avec des clients, Avec des utilisateurs, on va plutôt parler d'utilisateurs. Les questions directes, ça ne marche jamais. Là, mon rôle plutôt produit a commencé à vraiment dériver. J'ai commencé à prendre un peu conscience de l'ampleur des choses qu'il y avait. Et là, ça a commencé à devenir kiffant.

Terry : Ouais alors beaucoup beaucoup d'informations c'est hyper intéressant ce que ça alors déjà je veux être sûr d'avoir bien compris donc je vais juste rephraser tu me dis si je suis dedans ou pas sur sur le produit du coup donc le portail donc Chorus c'est pour les acteurs publics, vous ce que vous envisagez, enfin ce que vous avez fait c'est la même chose pour que deux acteurs privés puissent échanger de la donnée ensemble ?

Marc : Des portails de factures frontières, il en existe déjà plein. Par contre au niveau de la sphère publique, des bailleurs sociaux, Cori s'est arrivé à imposer des standards sur des protocoles et des formats. Et nous en fait on a fait un outil qui était similaire, c'est-à-dire même protocole en entrée et même format en sortie. Comme ça l'écosystème, donc les ERP de nos clients, qui savaient digérer un format Chorus, savaient digérer un format Neovacom derrière, vu qu'on a fait la même chose.

Terry : Voilà, donc en fait, vous, le format Neovacom, qui était du réplica sur le format Chorus, permettait à vos buyers sociaux de pouvoir être prêts à l'échange de factures électroniques avec des fournisseurs privés.

Marc : Exactement, c'était pour faire du plug and play. Les fournisseurs privés qui avaient fait l'effort de s'interfacer avec Chorus, pareil, avec des protocoles et des formats obligatoires, nous, on a développé un outil qui permettait de se connecter avec les mêmes protocoles et les mêmes formats, mais vraiment les mêmes choses. C'était pas si simple que ça, mais nous, dans notre logique, on s'est dit bon ben voilà, le fournisseur s'est branché à Corus d'une telle manière. Il a juste à dupliquer ce qu'il a fait vers nous et on s'est dit c'est pas grand chose et on pourra y revenir après là dessus. Ce n'est pas grand chose, mais on s'est dit en fait, on lui a fait 99% du chemin. Il a juste à faire, à prendre la même prise et la brancher chez nous et ça va marcher.

Terry : Ok, et comme ça il anticipe le fait qu'après ça passe aussi, ça devient obligatoire de le faire dans le privé en fait ce type d'échange ?

Marc : Alors ouais, nous ça c'est quelque chose qu'on n'a pas trop mis en avant et les fournisseurs n'étaient pas forcément matures là-dessus, ils ne pensaient pas que ça allait arriver aussi vite sur la sphère privée donc ce qui va être mis en place là en 2024.

Terry : Du coup, pour comprendre la valeur pour les fournisseurs des bailleurs sociaux, dans le privé, l'intérêt d'utiliser cette plateforme, c'est pour les bailleurs sociaux, si ils ont cette plateforme, enfin si ils utilisent la plateforme NovaCom, ça leur permet direct de pousser tout ça sur Coius, c'est ça l'intérêt ?

Marc : Tu as dit un truc qui est super intéressant, je pense qu'on y reviendra après. Tu as dit la valeur pour les fournisseurs. En fait, on a vraiment négligé au départ les fournisseurs. Mais je pense que quand je t'expliquerai un peu plus comment on a avancé, ce sera un peu plus clair. Nous, on était focalisé sur nos clients, donc les buyers sociaux. Et nous, la valeur qu'on allait leur apporter, c'était vraiment vos fournisseurs, ils vont savoir faire. C'était un peu de manière naïve ce qu'on leur disait. Vos fournisseurs vont savoir faire, ils ont su faire avec Horus, donc ils sauront faire avec nous, parce que c'est la même chose.

Terry : D'accord, donc vos fournisseurs, désolé, je rephrase, mais c'est pour être sûr de bien contextualiser, vos fournisseurs type gros fournisseurs d'électricité qui sont déjà interfacés parce qu'ils ont besoin avec Corus, grâce à notre solution, ils sauront le faire hyper simplement.

Marc : Exactement.

Terry : Et donc, vous, vous aurez de la donnée directement structurée.

Marc : Exactement. Votre fournisseur, il va s'interfacer à nous de manière ultra rapide parce qu'il l'a fait avec Corus et que nous, on lui proposait la même chose. Et vous, vous allez bénéficier de la même donnée structurée qui est en sortie de Corus. que vous allez pouvoir intégrer dans vos logiciels, dans vos ERP, parce qu'en fait ces ERP-là, ils savent intégrer du Chorus, donc ils vont savoir intégrer du Neovacom. Donc de manière assez simple, on s'est dit là, le discours ça va marcher, nos clients vont comprendre le concept et ça va rouler.

Terry : Ok donc je pense que c'est bon je l'ai, je repasse du coup donc mon gros fournisseur par exemple d'énergie qui m'envoie de la facture grâce à la solution Novacom, je vais pouvoir donc récupérer ça de manière structurée et ensuite le pousser dans toutes mes suites de logiciels de gestion que j'ai déjà, mes ERP et du coup ajouter ça à mes dashboards, enfin peu importe.

Marc : Exactement, puis c'est pour le traitement des comptables, payer la facture et compagnie, voilà tout simplement de manière avec de la donnée sûre, automatisable.

Terry : Donc au départ c'est pour ça que tu dis le focus n'était pas mis sur le fait de dire après vous allez devoir aussi légalement entre privés jouer avec ce format, c'est plutôt de vous dire aujourd'hui le fait que vous bénéficiez de cet interfaçage là va vous permettre d'avoir de la donnée pour vous structurer qui va pouvoir vous simplifier vos tâches quotidiennes pour les comptables et tous les autres services administratifs.

Marc : C'est exactement ça. C'est exactement ça et donc c'est là où on va commencer à parler un peu de la série d'erreurs qui a été faite et plutôt on va parler de l'apprentissage parce que série d'erreurs, là je me flagelle, c'est pas beau. Mais tout l'apprentissage en fait, il a commencé vraiment je trouve à ce moment-là.

Terry : Parce que alors avant que tu rentres, je vais te laisser le dérouler. Là, j'essaie de me projeter à cette époque où tu es face à cette problématique. donc tu vois l'opportunité là dont on vient de parler et en même temps t'as aussi en fait une spéc qui est quasiment donnée qui est en fait la spéc chorus bon après faut savoir mettre le nez dedans mais donc moi j'essaie de mettre tu vois à ta place à cette époque je me dis ok on a ce produit là il existe on a des utilisateurs qui l'utilisent en plus dans la sphère publique donc on va pouvoir aller un peu sonder c'est ce que tu expliquais pour comprendre eux les problématiques qu'ils ont d'un point de vue usage de l'interface etc et en plus on a une spéc technique qui nous dit le protocole donc en gros Moi j'ai envie de dire, il n'y a plus qu'à. C'est-à-dire, le protocole on le calque, je dis à mon CTO tu m'implémentes tout ça, et puis en parallèle je parle un peu avec les utilisateurs pour comprendre... Ouais, clairement.

Marc : Mais clairement, on peut clairement le dire comme ça, et c'était pas plus mal parce qu'à cette époque-là, il y avait deux personnes qui étaient à l'intégration, moi qui étais là plutôt justement encore un peu à l'intégration et en recherche d'opportunités. notre CTO, trois commerciaux, une personne administrative et puis voilà. On était quand même autant parce qu'on avait l'activité intégration derrière.

Terry : Ce qu'ils vont s'y vivre quoi.

Marc : Voilà, exactement. Mais heureusement que l'opportunité, elle nous paraissait pas si, comment dire, importante à creuser parce qu'on savait que la fenêtre de tir de notre opportunité, elle était quand même assez courte parce que un jour ou l'autre la sphère privée allait être imposée également. Donc on s'est dit, on a peut-être 4, 5 ans vraiment, si on arrive à vite proposer notre solution, à prendre une place sur le marché et derrière arriver à diversifier notre offre. donc de manière assez simple. Ouais, mon travail, si on doit vulgariser les choses, on pourrait croire que c'était plutôt simple. La spec, elle était pondue, il fallait juste la retravailler. Les clients ou du retour utilisateur, c'était assez simple. Il y en avait, il fallait les interroger, il fallait quand même réussir à... comment dire... à les orienter... pas les orienter justement, à obtenir quelque chose de concret pour nous et qui avait de la valeur. Encore une fois, On parle d'entretien utilisateur, là je me suis aperçu que mener un entretien utilisateur, c'est pas forcément que c'était pas simple, parce qu'on peut être plus ou moins à l'aise là-dessus, mais on a tendance à vouloir lui faire dire des choses et c'est clairement ce qu'il faut éviter. Et ça, par contre, une grande chance que j'ai eue, c'est que j'ai su le faire bien assez rapidement. Là, je parle beaucoup parce que c'est ton podcast. C'est le format qui est le seul. Exactement. Mais pendant justement un entretien utilisateur, j'avais vraiment la capacité à beaucoup les faire parler. et les faire parler de la bonne manière, c'est-à-dire pas, j'arrivais pas à leur dire on va vous proposer une solution, je leur parlais jamais de la solution, c'était toujours c'est quoi vos problèmes, racontez-moi votre quotidien, comment vous faites ça, si vous avez une douleur à un endroit, comment vous arrivez à résoudre cette douleur, c'était tous les entretiens je les menais comme ça et sur l'usage du portail Chorus, c'était la même chose. C'était vraiment comprendre leur parcours utilisateur, où est-ce qu'il y avait une douleur, la fréquence à laquelle ils s'y connectaient, est-ce qu'ils s'y connectaient. C'était un peu la recherche utilisateur que j'ai commencé à faire.

Terry : Et du coup, donc là quand tu disais sur l'usage du portail Corus, juste pour aussi toujours bien être sûr de comprendre, les utilisateurs c'est à la fois, c'est les mêmes ceux qui utilisaient le portail Corus et ceux qui allaient utiliser votre solution ou tu avais deux pannels ?

Marc : Alors c'était les mêmes fonctions, mais pas les mêmes clients. Étant donné que le secteur public était imposé à Corus, ils ne pouvaient pas bénéficier de notre solution. Eux c'était Corus et c'est tout. Et le secteur privé qui n'avait pas Corus, eux ça serait notre solution.

Terry : Donc c'était pas les mêmes utilisateurs ?

Marc : C'Était pas les mêmes utilisateurs, mais c'était les mêmes fonctions. Et les fonctions avec qui je devais discuter, c'était les responsables, on va dire responsables financiers, DAF, ce genre de personnes, et comptables également, responsables comptables, c'était toutes ces personnes-là.

Terry : Pour bien comprendre c'est qu'il y avait deux poches d'utilisateurs, tu avais ceux qui utilisent Chorus dans le secteur public que tu allais interroger pour comprendre les pain points qu'ils avaient sur Chorus, et ceux que vous vous cibliez qui allaient avoir des mêmes fonctionnalités similaires à Chorus mais tu voulais faire mieux que Chorus. Ce qui m'intéresse du coup après pour continuer sur cette partie recherche utilisateur, c'est donc tu parlais là clairement de l'approche problème et pas d'arrivée solution. Toi, à l'époque, qu'est-ce qui t'a fait ? Est-ce que tu l'as eu naturellement ce déclic ? Est-ce que tu as eu des lectures ou des choses qui t'ont inspiré, des talks ou un truc qui t'a fait un peu le shift ?

Marc : Moi, ça, je l'ai eu naturellement.

Terry : D'accord.

Marc : Ça, je l'ai eu naturellement et tant mieux pour moi, j'ai envie de te le dire. Par contre, quelques années après, il y a un bouquin que j'ai trouvé génial. Si tu me donnes une seconde, peut-être quand on me le voit, je vais réussir à le trouver. C'était « The Mom Test ». Je n'ai plus le nom. Je crois que c'est Rob Fitzpatrick qui l'a écrit, je crois. Et il est génial, ce bouquin. Je l'ai trouvé vraiment génial. T'as une ressource.

Terry : En avance j'ai une ressource.

Marc : Vraiment j'ai adoré, très très bien. Et toujours pour continuer sur le travail que j'ai fait et l'apprentissage. Cette partie-là, très bien franchement, on compilait de la donnée, on arrivait à avancer, donc je vais bien expliquer quand même la time limit qu'on avait, c'est-à-dire que là je faisais cette recherche-là, en parallèle j'avais travaillé aussi le cahier des charges. Derrière il fallait mettre tout ça en musique aussi au niveau de l'entreprise et savoir comment on allait le développer parce que là on a pu aller assez vite quand même. Au final c'était peut-être sur 3-4 mois travailler le cahier des charges, faire ses entretiens utilisateurs et derrière en fait on a pu y aller, sachant que je faisais des maquettes mais à l'époque je faisais des maquettes sur Draw.io, sur du PowerPoint, des trucs qui étaient horribles, j'avais pas encore conscience que Figma ça pouvait être bien, mais ça c'est pas grave, enfin Figma ou autre. Et on va dire au bout de 3-4 mois j'avais une spec assez solide et on a plutôt voulu externaliser les développements.

Terry : Intéressant, ouais.

Marc : Étant donné que mon CTO, on ne voulait pas mettre tous nos œufs dans le même panier. Donc lui, il était sur l'aspect toujours échange de données, le côté ETL. Donc là, on a démarché 4-5 boîtes, je crois, de ESN, je crois qu'on appelle ça comme ça maintenant. Et c'est moi qui ai dû piloter tout ça, donc là pareil, c'était super intéressant. Comprendre par quelle boîte il fallait passer, alors on avait plein de problématiques là-dessus.

Terry : Quand tu dis externaliser les devs, en fait c'est pas tous les devs, c'est-à-dire que le cœur, donc l'ETL, le cœur qui réplique ce que Corus demande, la boîte noire qui est invisible, ça c'était votre CTO ?

Marc : Même pas.

Terry : Ah même pas, d'accord.

Marc : Non, non, non, en fait on avait toujours notre projet de remplacer le logiciel.

Terry : Que Ah, que vous intégriez ?

Marc : Voilà, ce logiciel-là qu'on a intégré. On avait toujours comme projet de le remplacer, le CTO était là-dessus. Et par contre, sur le portail de facture fournisseur, on a voulu tout externaliser dans un premier temps. Et là, ce qui était super intéressant, c'était de mener tous les entretiens avec les ESN. Ça, c'était génial, ça aussi. On avait plusieurs problématiques. Bon, il y a une problématique financière déjà, il y avait un budget à gérer. Donc ça pareil, ça m'a été mis dans les mains pour de la montée en compétence, c'était top. Fallait avoir le fit, fallait voir qui allait proposer la meilleure expérience utilisateur, parce qu'en fait moi j'arrivais avec un peu des drafts, mais fallait voir qui comprenait le mieux le sujet, allait nous proposer quelque chose de mieux au final. Une problématique qu'on a eue, qui était super intéressante parce que maintenant qu'il y a eu le Covid, on ne se serait pas forcément posé cette question là, mais il y avait la proximité. Mon DG vraiment pour lui c'était au final le critère numéro un et ça je ne m'en suis pas forcément rendu compte à l'époque. On en a shortlisté trois, moi j'ai recommandé une société, finalement c'est pas celle-là qui a été prise. On a fait un retour d'expérience après et on a conclu qu'effectivement il va mieux prendre la société que j'avais que j'avais sélectionné moi. Peut-être qu'on aurait rencontré des problèmes aussi, mais le prestat par lequel on est passé, ça a été très compliqué. Et pareil, là, au niveau de l'apprentissage, super bien. Donc, en gros, la position que j'ai eue par rapport aux prestataires, en gros, j'étais le PO. On va dire j'étais le PO, j'arrivais avec la SPEC. Dans le projet, on a eu... Donc, c'était au plateau, ils n'étaient pas chez nous. 3 Devs, 1 Scrum et 2 Archis, qui étaient là vraiment de manière ponctuelle, un Archifront, un Archiback.

Terry : Et donc là t'arrives du coup avec ta spec en demandant quand est-ce que ça va être prêt ou une approche produit avec toi ? Parce que c'est compliqué justement quand t'as un prestat.

Marc : Là j'arrive avec ma spec et l'idée c'était de fonctionner d'une manière agile, sur de la méthode au scrum vu qu'on avait un scrum, là on était vraiment sur des daily, des rétros, des démarrages de sprint, tout ce que tu veux. Donc la spec, il a fallu que je la découpe moi en feature pour arriver à jalonner ce qui allait être fait dans quel sprint, on va dire. Donc là l'idée c'était plutôt d'être sur une approche à faire du scrum, c'est pas forcément faire du produit, mais l'idée derrière c'était ça.

Terry : Mais du coup, vous en tant que client, tu as acheté juste une obligation de moyen ou de résultat ?

Marc : Exactement, de moyen. En fait, c'est super compliqué et c'était mon CTO qui militait pour ça. Moi, j'étais plutôt d'accord avec lui. Obligation de résultat, ça voulait dire que l'aspect, il fallait qu'elle soit parfaite à la base. Et je ne dis pas qu'elle n'était pas bonne, elle était franchement bien. C'est moi qui l'ai fait, elle était franchement bien. Non, c'est plus que le produit, il allait devoir vivre. Parce qu'en fait, là, on avait besoin d'eux et on avait le budget pour les avoir sur 4 mois. Donc on avait besoin de quelque chose qui aille le plus loin possible mais qu'on puisse bien reprendre les choses derrière et avoir la main dessus lorsqu'on allait réinternaliser pour faire justement le delta qu'ils n'allaient pas réussir à couvrir.

Terry : Mais du coup avant d'aller, ça je trouve ça hyper intéressant, du coup vous avez eu cette approche, enfin moyen c'est-à-dire, bah vélocité, enfin en gros on achète des sprints et puis au bout de 4 mois on reprend tout ça. Hyper pertinent, mais d'un autre côté, toi quelles sont les questions que tu t'es posées en te disant, parce que quand tu vas dire à ton DG et ton DG te dit je sais pas moi, on a 400k pour faire ça, et il faut que ça sorte dans 6 mois. Toi t'es là, tu dis ok bon bah je vais dire à ma boîte de Presta, bon bah on verra dans un mois et puis on continue. Comment t'as géré ça toi ?

Marc : C'est toujours pareil, c'est là où tu t'aperçois que t'es toujours obligé de... T'as du troc, t'as plus ou moins ton MVP que tu sais que tu dois tenir. Quelque part au départ, j'avais déjà l'idée du must have et nice to have dans ce que je proposais à mon prestat. Et l'idée, ça n'a pas été simple, ça a été d'arriver à faire en sorte qu'ils s'engagent sans vraiment s'engager. Là-dessus, par contre, c'est mon DG qui a géré. Il était plutôt assez incroyable en négociation. C'est-à-dire qu'ils étaient sur une obligation de moyens. avec un périmètre minimal sur lequel on a convergé avec eux, sur lequel ils devaient s'engager par contre. Donc c'était quand même assez intéressant. Obligation de moyens, mais avec... S'il n'y a pas ça, par contre, ça ne va pas le faire. Voilà. Et c'était pas un MVP non plus, le « s'il n'y a pas ça ». C'est pour ça qu'on peut pas dire sur un engagement de résultat, parce que le scope sur lequel ils se sont engagés, c'était impossible à mettre en prod. Mais pour nous, c'était vital pour arriver à continuer derrière. On a réussi à avancer des deux manières. Par contre, la qualité a été fortement dégradée. Cette période-là, elle était quand même assez particulière quand j'ai joué le rôle de PO avec ce prestataire. Ça ne s'est pas bien passé. Ça ne s'est pas bien passé, le prestataire le reconnaît aussi, des deux côtés. On n'a pas bien géré le projet pour plein de raisons. Déjà la première, franchement faire un projet dans l'été c'est pas mal. Non mais vraiment. C'est-à-dire qu'il y avait les congés au milieu.

Terry : Encore plus dans le sud de la France.

Marc : Ouais, ouais, je sais pas, je sais pas. Moi j'aime pas cette image qu'on peut avoir dans le sud de la France.

Terry : Non mais l'été il fait hyper chaud, tout le monde est à la plage.

Marc : Mais ça a été très compliqué. Donc on l'a fait dans l'été. Forcément c'est toujours pareil, on a voulu peut-être trop charger la mule, ils nous ont dit oui mais c'était peut-être infaisable. Je vais pas dire qu'on les a pas assez bien qualifiés, parce qu'au final c'était pas notre premier choix, donc je pense qu'on les avait assez bien qualifiés. Mais d'un point de vue expertise architecture, on n'a pas du tout été satisfait.

Terry : Là on a en premier apprentissage ne pas faire ce type de projet durant l'été.

Marc : Ouais, et je pense que ça peut être faisable. Mais disons, c'est faisable quand on a plus de garanties. On n'a pas assez de garanties, donc le faire dans l'été, ce n'était pas malin. Un truc, donc justement, je vais rentrer dans les détails. De toute manière, je ne suis pas là à donner des noms ou quoi que ce soit, donc je peux me permettre de rentrer dans les détails.

Terry : Le but, c'est vraiment d'avoir des apprentissages.

Marc : Justement sur l'apprentissage, un truc qu'on n'a pas eu conscience au départ et en fait, on aurait dû. On a eu deux archis sur le projet qui étaient là de manière ponctuelle, un bac, un front. Et en fait, il s'avère que l'archi bac, qui était sur une partie qui était critique pour nous, il n'appartenait pas à la seule société. Alors attention, je ne critique pas les freelance, moi je suis même freelance maintenant. Mais en fait, cette société-là a pris pour gagner le projet, a trouvé vite un freelance sur justement le type de techno qu'on voulait implémenter, en mode je suis expert de ça, et c'était l'archi de notre projet. ils avaient déjà dû travailler quelques fois avec lui mais franchement en fait il faisait pas l'affaire et nous on s'en est pas rendu compte donc l'expertise n'était pas là clairement et parce que tous les problèmes ne viennent pas que d'un côté moi je pense que Je me suis trop sorti du projet en me disant qu'ils allaient être vraiment à même, avec la spec qui avait été rédigée, qui était quand même assez précise, d'avancer vite. Et je ne me suis pas assez rendu compte d'un truc, c'est que moi, en ayant le nez dedans, le métier, je le connaissais. Par contre, un prestat qui arrive, aussi bon qu'il peut être, les problématiques métiers, il ne les comprend pas forcément. Et je me suis trop éloigné au départ, je pense, du prestataire. J'étais disponible, mais je pense que j'aurais dû être beaucoup plus présent au départ pour faire comprendre les enjeux métiers qu'il y avait. Et ça, ça a créé des problèmes au départ qu'on a dû rattraper par la suite. Et ça engendre de la dette technique et compagnie. Donc je pense que l'une des erreurs que j'ai faites c'est d'être trop loin de mon prestat au départ et j'aurais dû être beaucoup plus présent sur peut-être les deux premiers sprints. Il y a plein de raisons qui ont expliqué mon manque de présence, parce qu'il y avait d'autres choses à gérer, mais pour la réussite du projet ça a été quand même assez critique.

Terry : Ça c'est intéressant parce que souvent tu vois sur des rôles de dev interne versus freelance la question qui se pose c'est est-ce que du coup la complexité de ce que je fais nécessite que mes devs soient internalisés pour qu'ils soient bercés dans les problématiques métiers ? là toi ce que tu dis en gros c'est pas tant un problème externe interne parce que là vous avez externalisé c'est plus de toi dédier du temps en tant que responsable du coup fonctionnel métier de ce que tu as écrit pour en fait vraiment faire enfin pousser toute cette connaissance et faire en sorte que tes devs puissent prendre ça comme des éponges assez tôt et à ton avis enfin avec le retour d'expérience deux sprints ça aurait pu suffire pour pour limiter la casse à ce niveau là.

Marc : Alors ça va dépendre du projet sur Paris mais nous sur le projet qu'on.

Terry : Avait ouais Sur 4 mois, ouais.

Marc : Franchement, sur 2 sprints, ça l'aurait fait. Vraiment, ça l'aurait fait.

Terry : Des sprints de combien, du coup ?

Marc : On était sur des sprints de 2 semaines. Mais ils étaient bien câblés, les gens qu'on avait en face. Donc ouais, 2 sprints, ça l'aurait fait.

Terry : Donc un mois sur les 4 où t'es vraiment immergé avec eux pour être là et leur partager toute ta connaissance ?

Marc : Complètement. Ça aurait pas résolu 100% des problèmes. Mais franchement, ça aurait permis d'avancer beaucoup mieux. Et donc, on n'est pas obligé de rentrer que dans cette expérience-là, mais on va dire qu'au bout de 4-5 mois, on a eu la solution qui est sortie, qui nous a été livrée, le périmètre minimum a été couvert, quelques trucs autour ont été faits, on a tout réinternalisé et on leur a pris encore, par contre pas au plateau, mais il y a un dev qui est resté avec nous sur de l'AT, pour nous accompagner sur le travail qu'ils avaient pu faire et comment on pouvait réintégrer tout ça chez nous. Parce qu'en fait, un truc que je n'ai pas dit, l'autre produit sur lequel on était en train de travailler pour remplacer la solution d'échange de données, On avait un squelette qui était déjà fait sur de la gestion des utilisateurs, sur un socle technique, Docker User, du Kubernetes et compagnie. En fait, on s'est dit tout ce que la société de service vient de faire, nous on veut l'intégrer dans ce socle technique. Donc, on les avait driver de manière technique pour que ça puisse être faisable. Et la personne qu'on a pris sur un mois et demi daté supplémentaire, c'était pour finaliser quelques trucs et nous aider à intégrer tout ça, accompagner notre CTO sur l'intégration de tout ça.

Terry : Ok, du coup je fais un petit récap sur l'échelle de temps juste pour me remettre aussi dans ma tête où on en est. à peu près trois mois au départ entre le moment où on identifie cette opportunité de faire un équivalent de chorus pour le privé. Je vais aller creuser le sujet avec mes deux types d'utilisateurs qui sont les gens du privé qu'on a déjà, les gens du public qui utilisent chorus pour comprendre ce qui marche moins bien et aussi faire une spec au bout de trois mois qui est mieux que ce qui existe déjà. Donc au bout de trois mois t'arrives avec cette spec, vous faites la recherche du coup de boîte de prestat qui va vous développer ça, donc quatre mois de développement. Donc là on est à peu près à sept mois de... Là au bout de sept mois du coup est-ce que tu as un produit déjà que tu mets dans les mains d'utilisateurs ou pas encore ?

Marc : Quasiment, quasiment. On va dire c'était au bout de huit mois on l'a eu. Au bout de huit mois on l'a eu avec sur pareil à la fin il y a toujours des trucs à finaliser un peu à droite à gauche mais en fait si c'était C'était commercialisable, en expliquant justement que derrière nous, on allait faire vivre les choses.

Terry : Et t'es en SaaS du coup ?

Marc : Ouais, SaaS, tout à fait, j'aurais pu le préciser, SaaS. Et en parallèle, ce qu'on a fait, c'est qu'on a commencé à recruter aussi des devs en interne. C'est-à-dire que là, on avait notre CTO et un dev à l'époque, et quand on a réinternalisé, on a pris deux autres devs. Donc, on était avec une équipe, un CTO, trois devs, et après, c'était eux que j'alimentais. Oui. À ce moment-là, justement, si on reprend la timeline, là, on a quelque chose de commercialisable. Forcément, nos commerciaux, ils avaient travaillé quand même aussi en amont. Et c'est là où la culture produit, c'est là où le gap a été le plus gros, c'est à partir de là pour moi. Parce que tout s'est enchaîné. C'est-à-dire que là, quand même, je t'ai parlé de développer un produit avec de la recherche utilisateur, plus ou moins. Et là, je te dis déjà, on le commercialise. Je ne te parle même pas de marketing. Donc déjà, gros trou dans la raquette. Le marché, on le connaît, mais en vrai, on va s'apercevoir qu'on a fait plein d'erreurs. La proposition de valeur, en fait, on ne la connaît pas. On dit juste, on fait comme Chorus, mais on n'a pas défini une proposition de valeur. On a des commerciaux qui arrivent en fait et qui n'ont pas un vrai discours commercial derrière, vu que le travail de marketing n'est pas fait. On a de la chance.

Terry : Donc ils n'ont pas encore le discours que tu me disais au début d'expliquer comment ça simplifie après le passage dans les autres outils de gestion ?

Marc : Si, ça en a. Mais quelque part, ça, ce n'est pas un discours produit. Ça, c'est un discours, comment dire, suivant l'interlocuteur qu'on a en face, ça va être compris. Mais ce n'est pas ce qu'on va mettre par exemple sur notre site web. Ce n'est pas le pitch qu'on peut avoir d'un produit. Pitcher un produit, ce n'est pas possible. Ce n'est pas ça. Ce n'est pas ça tout simplement. Et quelque part, on n'avait même pas de vision d'entreprise parce qu'en fait, on a fait ça et derrière en fait, c'est ça qui est super intéressant dans cette expérience, c'est que l'entreprise s'est transformée par rapport à l'opportunité qu'on a trouvée. Vu que nous, ce n'était pas j'arrive, j'ai une vision, je veux qu'on soit ça et on y va. C'était plutôt, il y a eu cette opportunité et comment l'entreprise va devenir vraiment ce qu'on veut par rapport à l'opportunité qu'on a eue. Et donc là, vraiment, sur les 4 ans qui ont suivi, 4 ans, 4 ans et demi, la culture produit, elle s'est envolée. Mais franchement, avec plein d'apprentissages, mais assez incroyable. On a commercialisé le produit et la chance qu'on avait, c'est d'être connu chez les bailleurs sociaux et donc d'avoir un ou deux early adopters qui ont dit « Ok, très bien ». Et donc là, vraiment le second travail, celui qui représente le plus le vrai travail, on va dire PM, CPU que j'ai eu à faire, c'est à partir de là. On a signé deux clients qui étaient sur un périmètre assez simple. Je remets le contexte. un logiciel de gestion de factures fournisseurs. Donc un client va nous prendre et va se servir de cette plateforme pour collecter ses factures. On peut les collecter de plusieurs manières, soit c'est un portail et c'est le fournisseur qui va la déposer, soit c'est de manière automatisée, ça peut être du scan de boîte mail, il y a plein de possibilités. Pour collecter des factures, il faut que les fournisseurs jouent le jeu en fait quelque part. Et quand on arrivait chez des clients et qu'on leur disait « bon ben voilà, on vous propose le portail de Frids, la solution s'appelle Frids, on vous propose le portail Frids pour collecter vos factures fournisseurs. » Première question, c'est ça, c'est tout. Vous avez combien de fournisseurs sur la plateforme ? Zéro. Là on en est arrivé, on pouvait leur dire, bon, les fournisseurs, en fait, tous ceux qui sont sur Chorus, ils peuvent être chez nous. Ouais, mais est-ce que vous les avez ? Non. Donc là, c'était les premiers gros doutes. Les premières semaines, l'anneau con s'est dit, mon Dieu, est-ce qu'on n'a pas fait une erreur ? On a eu de la chance. Donc, on a eu deux premiers clients, Early Adopter, qui nous ont dit, bon ben voilà, on prend votre portail et on va faire au moins la démate de nos fournisseurs d'énergie. Il s'avère que les fournisseurs d'énergie, on savait déjà dématérialiser avec eux sur l'échange de données. Donc ça, on savait faire. En fait, ça, on a pu l'implémenter rapidement. Donc rapidement, on a eu, on va dire, une dizaine de fournisseurs qui sont des gros facturiers. Chez les bailleurs sociaux, en général, c'est plusieurs centaines de fournisseurs. Ça peut aller de 200 à 2000 fournisseurs, suivant la taille du bailleur social. Donc quand on arrive et qu'on leur dit qu'on en a 10, même si ça représentait peut-être 10 à 15% de leur volume de factures annuelles, ça reste que 10, ce n'est pas assez. Donc là, sur les premières semaines, on s'est vraiment dit, est-ce qu'on n'a pas fait une bêtise ? Là, il y a eu beaucoup de stress et c'est là où j'ai commencé à travailler vraiment différemment. À cette époque-là, on a recruté un responsable marketing qui n'était pas forcément là pour le produit Fritz. mais qui était là pour faire le marketing, communication de la boîte. Et pareil, on a pris quelqu'un qui bosse super bien, qui fait un podcast aussi, le Café du Market, je t'ai parlé de lui je crois, la dernière fois. Donc, un mec qui était super bien câblé en fait, et qui a endossé la casquette finalement de Responsable Marketing, PMM, avec qui j'ai beaucoup bossé. J'en parlerai après. Mais là je me suis dit bon faut qu'on fasse quelque chose, maintenant faut qu'on soit au contact plutôt des fournisseurs parce que l'erreur qui a été faite, l'erreur fondamentale, t'as un portail de factures fournisseurs, t'es allé voir tes clients qui allaient t'acheter ton portail, très bien, mais t'es pas allé voir les vrais utilisateurs du portail, les fournisseurs qui vont l'alimenter. Et là, pendant on va dire un mois et demi, je me suis rapproché de quelques clients qu'on avait sur d'autres solutions, récupérer leur parc fournisseur, les contacts qu'ils pouvaient avoir. Et là, je suis allé à la pêche aux infos en leur demandant comment ça marchait le Chorus, les problématiques qu'ils pouvaient avoir. Et ce qui était intéressant, c'est que vu qu'ils ont été impactés par Chorus avant, ils ont été super réceptifs, c'est-à-dire qu'ils étaient là pour discuter avec moi. et m'expliquer en quoi Corusca les a impactés, qu'est-ce qui pouvait être mieux. Donc j'ai eu beaucoup de chance là-dessus, mais j'ai fait un très très gros travail, j'en ai eu plusieurs centaines au final. Au départ je parlais pas à Fritz, et à la fin avec quelques-uns, quelques dizaines, j'ai pu commencer à parler à Fritz, leur expliquer, c'était certains fournisseurs qui qui étaient des fournisseurs des deux clients qu'on avait. Donc, j'ai pu faire migrer sur la plateforme avec qui j'ai eu beaucoup d'échanges pour améliorer aussi le produit. Donc, super intéressant. Et en parallèle, j'ai beaucoup travaillé avec la personne du market. On s'est rendu compte qu'un fournisseur, il n'allait pas utiliser notre produit parce qu'en fait, notre produit était moche. Mais vraiment, il était moche. On avait fait un truc fonctionnel, mais moche. Et on a tout rebrandé, l'achat de graphique, le nom du produit qui est devenu Fritz, le message qu'on voulait faire passer derrière. Et j'ai eu beaucoup de chance parce que j'ai beaucoup travaillé avec lui, il m'a inclus dans tout ce travail-là. Donc, j'ai beaucoup évolué sur le côté marketing.

Terry : Oui parce que là ce point que tu dis ça pourrait paraître anodin de dire le produit était moche mais en fait ce qu'il faut bien se dire c'est que les fournisseurs du coup, je referai si tu me dis si je dis une bêtise, mais les fournisseurs donc qui pourraient être du coup amenés à utiliser Freeds, eux ils n'avaient aucune obligation de le faire. Et donc si tu leur apportes aucune valeur et qu'en plus tu leur ajoutes de la friction, il n'y a aucune raison qu'ils le fassent. C'est un peu toujours ce problème quand tu veux d'un côté de la chaîne automatiser des choses pour faciliter le travail de tes clients, Mais en fait, si pour les fournisseurs, ils ont une autre manière de faire qui leur va bien.

Marc : Pourquoi ils iraient ? C'était exactement ça. Alors, il y avait plusieurs leviers. Le premier levier, c'est quand un bailleur social contractualisé avec un prestataire, potentiellement, il pouvait le mettre dans son contrat. Voilà, tu auras obligation de me facturer par le portail Freeds. Ok, très bien. Mais ça, c'est quelque chose qu'on a découvert après et qu'on a mis en place après. Au départ, comme tu dis, le fournisseur, il n'avait aucun intérêt à passer sur notre plateforme. Donc déjà, c'était un effort supplémentaire. Et la plateforme, en plus, c'était moche et franchement pas agréable à utiliser. Il faut le reconnaître. On s'était trop axé sur des gros fournisseurs qui allaient faire de l'automatisation, donc qui allaient peu aller sur le portail. Et on a négligé le pan des petits fournisseurs qui faisaient peut-être une, dix factures par mois, mais qui représentaient en fait le plus de fournisseurs à atteindre. Pour faire simple, chez les buyers sociaux, j'ai parlé de plusieurs centaines. On va dire que tu avais 20 fournisseurs peut-être qui représentaient 30 à 40 % de la volumétrie de facture totale. Et après, tu avais quelques centaines qui étaient par-ci, par-là. Mais ces petits fournisseurs-là, on va rentrer dans des Ce n'est même pas des détails, c'était vraiment un peu le cœur de mon métier après. C'était vraiment comprendre comment arriver à enrôler du fournisseur. Ça, c'était vraiment la problématique qu'on s'était rendu compte. Et là où au départ, on s'était dit, on prend les gros facturiers et de toute manière, les petits fournisseurs derrière seront obligés de suivre, ce n'est pas vrai. Comme tu l'as dit, on ne peut pas leur imposer. Et j'ai rapidement fait le switch en me disant, il faut prendre les deux bouts. J'avais réussi à identifier, on va dire, trois typologies de fournisseurs. Les gros facturiers qui veulent automatiser, qui savent automatiser et qui seront moteurs là-dessus. Attention pour les... Comment dire ? Prenons un exemple de EDF. EDF ne fait pas son automatisation lui-même. EDF passe par un prestataire qui lui fait. Donc quand un fournisseur automatise, ça engendre des frais quand même. Mais bon, ça c'est un détail vu la valeur que le client peut avoir derrière en automatisant. Mais donc les gros fournisseurs, eux, ils étaient d'accord pour automatiser. Et je me suis dit, dans les trois catégories que j'avais vues, les petits fournisseurs, eux, si on leur propose vraiment une expérience qui est intuitive et qui leur fait gagner au final du temps, parce que leur facture sera payée plus rapidement s'ils font ça, ils vont jouer le jeu. Et la troisième gamme de fournisseurs qu'il y avait, c'était les fournisseurs intermédiaires qui faisaient beaucoup de factures, mais pas assez pour automatiser et trop pour passer par le portail. Et bien ceux-là, au départ, on s'est dit on va les mettre pour l'instant de côté et on va trouver un moyen d'aller les convaincre différemment derrière. Et donc on a pris les... Enfin, c'est ce que j'ai dû faire, j'ai pris ces deux boulots, je me suis rapproché des fournisseurs, automatisé, on avait bien fait le travail en amont, et sur l'autre partie, on a donc amélioré l'expérience utilisateur et leur montré qu'il y avait une valeur ajoutée en appuyant en fait sur le fait que s'ils passaient par la solution, ils allaient être payés. Ils allaient être payés plus rapidement. Les chiffres qu'on peut avoir là-dessus, je crois qu'il y a des pubs à la télé là-dessus d'ailleurs, je crois que c'est dans les petites entreprises, dans les TPE, c'est une entreprise sur quatre qui fait faillite, c'est pour des problèmes de trésorerie. Quand tu arrives et que tu dis à un prestataire là tu t'assures d'être payé rapidement, en fait il joue le jeu. Et derrière quand il s'aperçoit que l'expérience utilisateur elle est bien, en fait on a eu des retours au bout de 3-4 mois, on a eu des retours de dizaines de fournisseurs qui nous disaient en fait votre produit il est génial.

Terry : Et là, ce qui est hyper intéressant dans ce que tu dis, c'est qu'il y a deux choses. C'est qu'il y a le fait du coup de retravailler l'expérience utilisateur pour qu'elle soit adaptée à ses fournisseurs. Mais par contre, le premier point de comment t'arrives à les convertir, pour prendre les termes un peu marketing, sur l'utilisation de cette solution, c'est pas cette expérience utilisateur au début. L'expérience utilisateur, c'est comment tu les maintiens, comment tu fais ton retain. Par contre, comment tu les convertis, c'est en leur disant qu'en gros, ils vont être payés.

Marc : Exactement. Tout ce travail-là, c'est ce que je te dis, c'est avec la personne de marketing qui est arrivée, on a fait tout ce travail-là. Je ne sais même pas par quel bout le prendre, mais comme je te dis, que ce soit le design de la solution, l'expérience utilisateur n'était pas mauvaise. C'est-à-dire les parcours utilisateurs étaient cohérents, mais c'était vraiment sur du design qu'il fallait améliorer les choses. Derrière, on a dû faire... Comment dire ? On a dû créer beaucoup de contenus autour de notre produit. C'est-à-dire faire un site avec des tutos, des tutos vidéo, de la communication type PDF, tout ce que tu veux, du PowerPoint que tu peux communiquer. On a créé un welcome pack pour que nos clients puissent en interne expliquer le produit et en externe à ses fournisseurs communiquer sur les contacts privilégiés qu'ils pouvaient avoir avec NeoVacom, la valeur ajoutée, la référence justement avec tout ce qu'on avait mis en place avec le responsable marketing. Et ça, c'était franchement, ça s'est fait sur plusieurs mois, mais c'était génial. C'est-à-dire, je me rappelle tous les tutos utilisateurs qu'on a faits, Franchement, on a fait un truc qui tenait vraiment la route et pourtant on l'a fait, j'avais l'impression qu'on le faisait dans un garage. C'est-à-dire qu'on s'est dit, on va devoir faire des captures d'écran, plutôt une vidéo sur comment utiliser le produit, comment s'enregistrer, comment déposer une facture sur l'interface, ce genre de trucs. On a pris un plugin Chrome, on a fait les vidéos. Derrière, on a fait le texte et compagnie. Quand on a vu le résultat, on était fier. Le truc est resté quatre ans dans la boîte. Cela n'a pas été modifié parce que cela nous tenait tellement à cœur. On commençait à plonger dans le produit et on s'éclatait tellement. le truc était franchement plutôt bien fait. Et on avait des super bons retours des utilisateurs, des fournisseurs. Donc là, ça a commencé à être plutôt sympa. Et donc, si on prend un peu de hauteur maintenant sur le produit, on a compris que l'erreur qu'on avait faite, c'était de ne pas aller chercher assez de fournisseurs. On a fait un gros travail d'automatisation auprès des gros fournisseurs et moi j'ai continué à les démarcher pour continuer à avoir cette automatisation de faite. On est arrivé à en avoir un, deux, tous les deux, trois mois, mais ça représente des beaux volumes de factures. Sur les petits fournisseurs, on a fait ce welcome pack. On a fait beaucoup de campagnes avec nos clients pour les convaincre. On a amélioré l'expérience. J'ai échangé avec énormément de fournisseurs et on a commencé à avoir quelque chose sur quelques mois de beaucoup plus fiable. Et on va dire sur la première année, l'année où on s'est aperçu qu'on avait fait une erreur et qu'on a dû transformer les choses, on a fini l'année peut-être avec 200 250 fournisseurs donc là où on s'est dit franchement si on en a 50 c'est bien on a fait du x4 au x5 donc on était super satisfait et là où on s'est dit Franchement, peut-être qu'on a fait une erreur sur le produit. Début d'année, c'était deux clients. Fin d'année, je ne sais plus, peut-être 13, 14. Sachant qu'on est sur des clients, on n'est pas sur de la PME, TPE ou de l'expert comptable. Nous, c'était vraiment plutôt de l'OTI, les bailleurs sociaux. Donc, c'est des beaux clients.

Terry : Du coup là dessus, sur vos clients, comment tu définissais la politique de pricing en fait ? Est-ce que ça c'était plus côté ton DG qui s'en est occupé ?

Marc : Le DG avait des choses à faire dedans, les commerciaux, mais c'était on va dire responsable marketing, moi, commerciaux et DG qui tranchait à la fin. Et là, on s'est cherché longtemps. On a vu un peu ce que faisait le marché. En fait, quand on parle de facture électronique, on pense tout de suite au coût facture. Peu importe le pricing que tu vas faire, il faut que tu le ramènes au coût facture. C'est-à-dire, tu peux faire un abonnement plus un coût facture plus un setup d'initialisation. A la fin, le client, ce qu'il va faire, c'est qu'il va prendre tout ce que tu lui factures, il va faire son calcul, il va dire le coût facture à l'unité ces temps. Donc voilà, quelque part, peu importe comment tu t'y prends, il fallait arriver à rester dans des coûts factures assez logiques par rapport à ce que faisait le marché. Ça, c'est pareil. C'est moi et mon responsable marketing. On est allé voir ce que faisait la concurrence. On a eu beaucoup de documentation. On a eu accès à des documentations. Je ne me rappelle plus exactement. Il y a un site qui référence. Comment dire ? On peut avoir des brochures qui sont assez folles sur des études marketing. Donc, on a réussi à avoir beaucoup d'infos comme ça. Et derrière, on a proposé plusieurs pricing à l'époque. On a fait des trucs. On s'est un peu cherché au départ. On faisait que du coût facture, pas d'abonnement, mais avec des factures par palier.

Terry : Donc quand tu dis que du coût facture, c'est-à-dire que c'est à la commission ?

Marc : À la consommation. Et en fait, le client nous achetait 5 000 factures, un pack de 5 000 factures. Et si jamais il n'en faisait pas 5 000 mais 7 000, soit on le passait au pack au-dessus, soit on lui faisait du surcoût. Au départ, on s'est cherché un peu comme ça parce qu'on avait vu que la concurrence faisait des choses comme ça et compagnie. Rapidement, on s'est aperçu que ce n'était pas intelligent pour nous. Tout simplement parce qu'en fait, là encore une fois sur le produit, d'autres problématiques, mais ces formateurs, c'est génial.

Terry : Avant d'aller sur l'autre, je résume un petit peu sur celle que tu viens d'expliquer qu'il y a un vrai problème de poulet l'œuf comme on dit au début parce que tu as tes clients qui vont payer du coup au coût facturé. Enfin là on en est au coût facturé, après tu vas expliquer comment le pricing a évolué. Mais en fait ces clients ils ont intérêt à avoir ta solution s'il y a aussi des fournisseurs dessus. Et les fournisseurs en fait, eux au départ, il faut les faire venir dessus. Donc tu as ce problème quand même de poulet d'œufs. Tu disais du coup qu'au début, vous aviez eu quand même la chance de pouvoir partir avec deux clients qui ont dit ok. Et donc c'est là que vous avez vu ce problème, vous avez commencé à travailler dessus. En un an, tu dis que vous passez à peu près à 13 clients, quelque chose comme ça, une grosse dizaine.

Marc : Oui, plusieurs centaines de fournisseurs derrière.

Terry : Mais déjà, comment tu as fait cette bascule de clients ? On arrive à une grosse dizaine. Ça a été de manière assez organique ou en gros, tu commençais à réussir à convaincre des fournisseurs ?

Marc : C'était plutôt le travail marketing qu'on a fait. C'est-à-dire que le discours a changé. Au départ, on parlait de plateforme, facture, fournisseurs. Ça en était toujours une. Mais on ne cherchait plus à la vendre comme ça à nos clients et on a beaucoup changé la proposition de valeur. Au départ, on s'est dit en fait, on a les gros facturiers. Les bailleurs sociaux, c'est des gros consommateurs de factures, de fournisseurs d'énergie. Donc en fait, la solution au départ, on va leur vendre pour ça. On va leur dire au moins, vous allez faire la démate de vos factures d'énergie par ça. Et on n'était plus là à vendre quelque chose de bullshit parce qu'effectivement, quand tu as zéro fournisseur, à leur dire tu vas faire la démat de tes fournisseurs, la crédibilité n'était pas là. Mais on leur disait, vous avez trois gros fournisseurs d'énergie, ça tombe bien, on les a. Instantanément, vous allez pouvoir avoir toutes vos factures sur notre plateforme et vous allez pouvoir les automatiser. Là, c'était cohérent. Après, du coup, c'était un produit qui était très limité, mais c'était cohérent et ça nous a permis de glaner du client comme ça. Et en parallèle, moi, je faisais cette recherche sur des petits fournisseurs. Déjà pour augmenter ne serait-ce que le nombre. C'est-à-dire que là on pouvait dire de manière réelle, on en a 250, on en a 300, on en a 400. Et c'était les petits que j'allais chercher, petits et moyens. Et voilà, fin d'année on arrivait à convaincre d'autres clients par ce discours-là. Les clients qu'on a convaincus qui étaient sur la plateforme, ils nous ont aidés, ils m'ont aidé à aller chercher quelques autres fournisseurs. Et en parallèle, moi, je faisais un travail sur des fournisseurs, un travail de fond qui a fait qu'on est arrivé à ce pool de, on va dire, je te dis 250, mais je pense qu'on était près des 400 au bout d'un an, 400 fournisseurs. Donc, on commençait à avoir quelque chose de, comment dire, plus concret et plus facile à vendre.

Terry : C'est hyper intéressant ce que tu viens de m'expliquer parce que du coup on pourrait, sans prendre trop de recul, se dire ils ont réussi à passer de 0 à 400 fournisseurs en un an. Mais en fait il y avait une vraie stratégie, c'est de 1, il faut vendre la solution au client. Là donc il y a un pitch qui est différent qui est celui de l'automatisation avec les fournisseurs d'énergie, très clair, valeur gagnée, très clair et donc à vendre ensuite, discours commercial assez rodé. mais en parallèle tout ce travail de, on travaille sur l'UX, sur l'onboarding des fournisseurs, sur leur faire comprendre que grâce à ça ils vont être payés de manière certaine, etc. Et ça te permet du coup de faire rentrer tes fournisseurs tout en continuant à vendre aussi à tes clients et ensuite de pouvoir, après je te laisse continuer.

Marc : Mais ça faisait un effet levier, c'est-à-dire qu'après quand on allait voir un prospect, on lui disait ben là on a 400 fournisseurs, c'était pas pareil. Et après on faisait matcher les parcs fournisseurs pour se rendre compte que Dans les 400, il y en avait peut-être 200 qui étaient communs. Il y a eu un bel effet levier comme ça. Et derrière, on ne parlait plus de dématérialisation des factures d'énergie. On pouvait vraiment parler de leurs factures fournisseurs. Et au niveau du pricing, là, pareil, en fait, quelque chose qu'on a changé sur l'année et qui a permis également d'accumuler plus de fournisseurs, le pricing y a joué. Au départ, on était sur des packs de factures, 5 000, 10 000 par exemple. Ce n'était clairement pas intelligent au départ parce que ça voulait dire quoi ? Ça voulait dire que si un client n'utilisait pas notre solution, il payait zéro en fait quelque part. Et vu qu'au départ, il fallait nous convaincre d'aller chercher du fournisseur, certains étaient très matures et on a réussi à avancer, et pour la plupart, ce n'était pas le cas. Donc, on se retrouvait à avoir vendu quelque chose et à ne pas pouvoir facturer. Et donc, on a vite revu un peu notre stratégie, on est parti sur de l'abonnement, plus un coup facture à la facture, et donc pas sur des packs facture, avec un petit setup d'initialisation et là, Quand le client se retrouve à payer plusieurs milliers d'euros en amont, il est forcément beaucoup plus motivé pour nous accompagner pour aller chercher du fournisseur. Donc ça s'est construit aussi comme ça.

Terry : Hyper intéressant sur ce point là aussi. J'avais un point dans ma tête qui est parti, mais il va revenir après.

Marc : Ouais, ça revient. Mais du coup, pour moi, là sur cette année-là, là où je suis monté en compétence de manière assez incroyable, j'avais beaucoup bossé avec des utilisateurs, donc pas de problème. Au final, je n'ai pas mis ces mots là, mais le delivery avec tout le travail que j'ai pu faire avec notre prestataire et l'équipe en interne, en fait, je ne suis pas du tout passé sur les questions de delivery, mais j'en ai bouffé, on va dire. On a automatisé plein de choses. On a fait un travail assez monstrueux, notamment grâce au CTO. Par contre là, sur cette année-là, le travail avec le marketing, ça va aller de l'or. Et je le sens maintenant par rapport à des missions que j'arrive à avoir moi en tant que freelance. Cette connaissance du marketing que j'ai pu acquérir là, en fait, elle fait beaucoup de différence avec d'autres personnes quand j'essaie de choper une mission. C'est assez incroyable. C'est pour ça que j'étais plutôt CPO. La compréhension du business, elle est super importante. Et j'ai pu vraiment acquérir ça sur cette année-là. Et franchement, ça pour moi, c'était de l'or. J'ai continué à beaucoup travailler sur ce point-là derrière. continuer à générer beaucoup de contenu. Et en fait, oui, la transition, elle est plutôt pas mal. On commençait à avoir quelque chose de beaucoup plus solide. On avait du fournisseur, on avait du client, on avait une vision produit. Là, l'entreprise, on l'a vraiment transformée. C'est-à-dire qu'en faisant ça, la R&D, elle est passée de 3 à 6. On avait une personne qui était là juste pour intégrer le produit. Les commerciaux, il a fallu les former sur le produit et c'est moi qui les ai formés également sur le discours qu'il pouvait y avoir derrière. Et quand on est arrivé là, on s'est dit bon ben maintenant, mon travail à moi a beaucoup évolué et je me retrouvais énormément en contact fournisseur, au contact client, je faisais tous les démarrages de clients. J'étais plus assez présent pour l'équipe donc là j'ai recruté un PO slash PM que j'ai commencé à chapeauter et par contre tout mon temps était pris par les clients casio. C'est bien mais il fallait que je fasse d'autres trucs en fait parce que l'idée c'était quand même de voir quelles allaient être les autres opportunités sur notre produit pour arriver à le faire grandir.

Terry : Du coup, ça m'est revenu ce que je voulais te poser comme question, mais j'en ai une autre même qui vient de venir, c'est au niveau de cette année de Pivot, comment vous l'avez financé ? Parce que c'est vrai que là, on a clairement vu comment vous avez réussi à récupérer du fournisseur tout en signant des clients. Là, tu parles de l'équipe Agrosy, comment ça a été financé ?

Marc : La chance qu'on a vraiment dans cette boîte, c'est qu'on était, enfin on est toujours, c'est une boîte qui est toujours sur fond propre, qui a, donc la partie intégration marche très très bien et donc tout était financé par ça.

Terry : D'accord, donc vous n'aviez pas du tout encore breakeven ou rentable sur la partie produits SaaS, mais vous financiez ça grâce à l'activité de base pour laquelle tu avais été au départ.

Marc : Oui, tout à fait, mais comment dire ? Je te donne des chiffres clients et compagnie par contre sur chiffre d'affaires.

Terry : Non, pas besoin de donner des chiffres.

Marc : Là-dessus, je ne vais pas aller là-dessus, mais à la fin, on va dire la première année et demie, Le chiffre d'affaires commençait à ne pas être déconnant du tout sur le produit, avec surtout un ARR qui était super intéressant. Pour un produit qui vient de démarrer, l'ARR était franchement pas déconnant, donc là ça commence à être beau. Mais ce qui nous a permis d'être quand même sûr que ça a fait, on va dire, c'est grâce à l'autre activité qu'il y avait à côté.

Terry : Je trouve ça hyper intéressant parce qu'en fait souvent quand tu veux sortir un produit SaaS, tu définis bien comment je vais avoir mes utilisateurs, comment je vais les faire venir dessus, ensuite combien ça va me coûter pour le développer, etc. Et en fait toute l'histoire jusqu'à présent que tu me racontes, c'est quelque chose de très organique. Tu as un premier business qui est l'intégration d'une solution ou tu as un tech lead, un CTO que tu recrutes pour en gros faire la même chose et plus devoir intégrer mais revendre ta propre solution. Ce CTO va aussi bosser sur le corps d'un produit qui va être créé après par opportunisme. Et derrière, tout ça c'est très organique et je trouve ça hyper intéressant. parce que ça donne aussi un autre regard en fait sur comment tu sors un produit SaaS à partir de... c'est pas from scratch complètement parce que c'est à coup d'opportunité mais après je te laisse répondre. Donc ma question que j'avais tout à l'heure c'était, tu disais on s'est rendu compte au début qu'on... enfin il y avait une erreur qui était de ne pas avoir regardé les fournisseurs au début. Mais d'un autre côté, comme tu l'as expliqué, sur la première année où vous alliez chercher du fournisseur, ce qui vous permettait de vendre à du client la solution, c'était quand même d'avoir la partie automatisation, qui est quand même, les 4 mois que tu as fait de delivery avec la boîte de Presta, il y a une grosse partie automatisation. Donc est-ce que, avec maintenant un regard rétrospectif, tu dirais, tu changerais quelque chose par rapport à ça en fait, tu vois ?

Marc : Oui, quand même.

Terry : Alors qu'est-ce que tu changerais ? Comment tu prendrais les choses différemment maintenant que tu sais comment ça s'est passé ? Qu'est-ce que tu adapterais ?

Marc : En fait, il y a plusieurs façons. On aurait pu faire de plusieurs façons, c'est-à-dire on aurait pu développer le produit exactement comme on l'a fait, par contre avoir un discours différent qui est le discours final qu'on a eu mais au bout de quelques mois après en disant on automatise les factures qu'on appelle factures de fluide, donc les factures d'énergie. on aurait pu fonctionner, donc développer comme on l'a fait et par contre avoir un discours différent. C'est-à-dire, voilà, notre produit c'est ça, ou on aurait pu être sur un développement plus orienté utilisateur et moins automatisation pour couvrir un nombre de fournisseurs plus large au départ et satisfaire une autre typologie de clients. Franchement, je ne te dis pas qu'il y en a une qui est meilleure que l'autre parce que la problématique du secteur d'activité qu'on avait, les bailleurs sociaux, les factures de fluide, ça répondait bien parce qu'en fait, il y a d'autres problématiques autour de la facture de fluide qui faisait que ça répondait déjà bien. Sur un autre secteur d'activité, je ne suis pas convaincu que ça aurait été la bonne. Un autre secteur d'activité, peut-être qu'il aurait fallu toucher le plus de fournisseurs possible au départ. Ça dépend vraiment du contexte. Et c'est là où on voit qu'on l'a quand même plutôt bien fait. On aurait pu gagner, à mon avis, au moins 6 mois. Mais sur l'année plutôt orientée marketing, quand on a changé notre discours et qu'on a parlé de ça, c'est là qu'on s'aperçoit qu'on n'a pas mal fait les choses. Je dirais que c'est plus qu'on n'est pas allé assez vite, on aurait pu aller plus vite. Et ça, on pourra en parler encore après. Et juste avant, tu disais, on a fait les choses de manière très organique par rapport à d'autres boîtes, comment dire, où c'est beaucoup plus carré d'entrée. C'est parce qu'en général, une boîte de la tech qui fait un produit, en général, il y a toujours pareil. Il y a le storytelling et compagnie où on te dit « ouais, j'ai eu la vision, j'ai pensé à ça du jour au… ». Ça a mis trois mois, trois ans et on a sorti ça. Ça peut être vrai comme pas vrai, ce genre de choses, mais en général, la vision, elle est portée par le DG. Une vision... Comment dire ? Un endroit où on veut aller. Nous, on n'avait pas ça, en fait. Nous, on ne savait pas où on voulait aller. On voulait être éditeur de logiciels, mais on ne savait pas quelle solution. C'est pour ça qu'on l'a fait de manière beaucoup plus organique. Si on avait eu cette vision au départ, on aurait eu une idée de quel type de produit faire, combien il fallait être staffé, donc ça aurait été beaucoup plus carré. Nous, ça a été l'inverse. Ça a été « Ah, il y a cette opportunité-là. Ok, on passe par la société de service, très bien. Maintenant, pour arriver à faire le produit, il faudrait peut-être qu'on recrute une ou deux personnes. Ok, très bien. Ce produit-là, au final, qu'on a sorti, le discours n'est pas bon. Nous, on s'est adapté par rapport à l'opportunité qu'on a eue, qu'on a transformée en produit, au lieu d'avoir une vision qu'on a transformée en produit. C'est vraiment, je pense, pour ça que l'histoire est quand même assez différente.

Terry : Ouais hyper intéressant et je pense que c'est ça que j'apprécie là avec ton partage et qu'on n'est pas du tout bah du coup déjà t'es pas dans cette boîte maintenant et puis on n'est pas du tout dans du storytelling, on est au contraire dans le concret donc ça je trouve ça hyper pertinent. Donc avant que je te fasse revenir là en arrière, t'étais en train d'expliquer en quoi ton rôle de CPO quand t'as commencé à grossir, vous avez un IRR qui commence à être pas déconnant et tu te retrouves toi à devoir, tu passes beaucoup de temps avec le client mais faut que tu fasses aussi autre chose.

Marc : Ouais et là du coup là globalement Ce qu'il fallait mettre en place et qu'on a identifié assez rapidement, c'est qu'il fallait créer des nouveaux postes. Et un poste qui était indispensable, c'était le poste de CSM. Donc là, moi j'ai proposé ça assez rapidement à mon DG, on va dire.

Terry : Donc Customer Success Manager, pour ceux qui ne sont pas du milieu SaaS ou qui connaissent un peu moins, c'est vraiment cette casquette à la fois de connaissances très profondes de comment utiliser ton produit, mais en même temps aussi une casquette un peu commerciale qui savent aussi démontrer, pitcher des...

Marc : Tout à fait, et qui sont vraiment là pour accompagner le client. Et nous, en plus, le CSM, poste pas simple chez Neovacom, c'était... CSM, on parle de customer, sauf que les plus gros utilisateurs du produit, c'était pas des clients. C'était des fournisseurs qui n'étaient pas des clients. Donc, je ne sais pas si USR ça existe, enfin USM, je ne sais pas si ça existe, mais on va dire qu'on était plutôt nous là-dessus. Et donc on s'est staffé, on a recruté une première CSM. Au bout de quoi, je ne sais pas, le produit avait peut-être deux ans, quelque chose comme ça. Et donc le temps de former la personne, lui passer les billets et compagnie. Donc globalement, elle n'était pas dans mon équipe. Ça, ça a été une erreur qu'on a corrigée au bout d'un an. Elle n'était pas dans mon équipe, mais elle ne travaillait qu'avec moi. Chez Neovacom, on était structuré de manière un peu particulière, vu que le gros des revenus venait de l'activité d'intégration. Cette personne a été rattachée à l'activité d'intégration et pas à l'activité produit, et ça, ça a été une erreur. Ça, ça a été une erreur qui a généré un peu de friction, on va dire, sur cette année-là, étant donné que la personne ne travaillait quasiment qu'avec moi. mais était monopolisé sur d'autres tâches et d'autres contraintes sur la partie intégration. Il y a eu pas mal de frictions, mais je passe très très vite sur ce pan là, mais ce qui est intéressant c'est de voir par contre le gain qu'il y a eu. En fait on a fait x10 au niveau des fournisseurs, donc on est passé de je sais pas de 400 à 4000 en fait grâce à ce poste là et au travail qui a été fourni par la personne. Et les clients, je crois que globalement avant que la personne arrive, on était peut-être à 20 clients et après on est passé à 80, quelque chose comme ça. Donc sur cette année-là, ça a été vraiment l'année de l'essor du produit où on a pris une vraie place dans le paysage des bailleurs sociaux. Donc en gros, le marché cible chez les bailleurs sociaux, c'était 300. et on en avait un tiers. Au bout de deux ans et demi, quelque chose comme ça, je n'ai plus exactement les dates, mais deux ans et demi, peut-être trois ans, on avait un tiers du marché adressable, 0% de churn, 4000 fournisseurs, un taux de satisfaction assez fort. Et là, ce qui était intéressant, c'est que le travail que j'ai fait moi cette année-là, c'était beaucoup avec cette personne-là côté CSM. J'étais beaucoup sur l'aspect utilisateur et toujours sur l'aspect market. Et avec la personne au CSM, ça a été donc mise en place de webinars, mise en place de loadboarding utilisateur. Donc là, on s'est beaucoup plus structuré pour avoir quelque chose d'ultra carré en fait. Et donc au bout de deux ans et demi, peut-être trois ans, là le résultat c'était plusieurs dizaines de clients, plusieurs milliers de fournisseurs. Le discours n'était plus du tout le même. Là on n'arrivait pas en disant, avec un client qui nous disait, vous avez combien de fournisseurs ? Il n'y avait plus de sujet. En fait c'était, très bien, c'est quoi les prochaines évolutions ? Quelle est la vision de votre produit sur les cinq prochaines années pour savoir où on va aller ? Donc là on était sur quelque chose de complètement différent et c'était top là.

Terry : Et du coup, avant d'en arriver là, côté dev, vous étiez staffé comment ? Parce que quand vous récupérez le projet, ou en gros ce que je comprends de ce que tu as expliqué sur cette première année où vous cherchez avec le responsable marketing, c'était quand même beaucoup de travail en fait, plus de storytelling pour le coup, et de comment tu pitches le produit à ton client. Et donc pas tant de pousser de la nouvelle feature, c'est plus de raconter notre histoire. En parallèle quand même d'aller donc chercher tes fournisseurs et donc un peu d'améliorer ton UX, donc tu as quand même besoin aussi là de développement. Mais jusqu'à arriver à ce x10 avec la personne CSM, au niveau de l'équipe.

Marc : Tech c'était quoi à peu près ? On était 3 ou 4 au départ, j'ai plus exactement les chiffres, mais là après c'était 8 personnes au niveau de l'équipe Tech. avec des inputs qui arrivaient dans tous les sens. Il y avait vraiment les fournisseurs qui nous demandaient des évolutions, les clients, moi qui arrivais à déterminer des opportunités marché pour faire évoluer le produit sur d'autres typologies de documents, ce genre de choses. Donc là il fallait forcément être staffé et sur l'année on est 4 à 8 personnes, alors dans les 8 personnes t'avais peut-être 6 CDI, 2 alternances, ça tournait comme ça, t'avais 2 départs, 3 arrivées, c'est pour ça que le chiffre fixe c'est toujours un peu compliqué. Les équipes de dev, il y a beaucoup de turnover je trouve dans ces équipes là, donc c'est compliqué aussi d'avoir un flux continu, tu sais que c'est 8 personnes comme ça. Mais ouais, une équipe de 8 personnes, très compliqué pour eux, c'est vrai que si je dois faire un petit aparté, Travailler avec eux, là où ça a été complexe, c'est qu'en fait, ils devaient travailler sur deux produits. Un produit qui ne sortait pas, le fameux produit sur remplacer le logiciel d'échange de données, et l'autre produit qui sortait, où on mettait les billes. Et donc, on avançait à deux vitesses, c'était compliqué. En fait, j'étais CPO, si tu veux, parce qu'en fait, on est une petite boîte, donc j'étais CPO. je chapeautais deux produits dont un qui sortait pas. On investissait pas dessus. Mais à chaque fin d'année, on nous disait où vous en êtes.

Terry : C'est vrai que je l'ai oublié moi. Mais en fait, vous continuez. Pour ceux qui, comme moi, l'auraient oublié, tu parlais au tout début de ce produit où vous essayez de remplacer le système que vous intégreriez même avec donc les succès que vous aviez sur le sas de chorus bis vous continuiez d'un point de vue vision de la boîte il y avait quand même toujours cette volonté d'essayer de remplacer ce que vous intégriez.

Marc : Pas mettre tous les oeufs dans le même panier tout simplement et on savait qu'on avait un super beau récurrent avec ça et si on pouvait le faire migrer sur une solution à nous c'était mieux. La stratégie là-dessus, elle est bonne. Ce qui est compliqué, par contre, c'est bien structurer les équipes techniques là-dessus. On ne s'y est pas bien pris. On ne s'y est pas bien pris. Attention, je ne dis pas qu'on fait tout mal, on a fait des très belles choses. Mais là-dessus, je pense qu'on aurait pu faire mieux. Mais c'est complexe, là-dessus c'est complexe. Là je t'ai parlé du poste de CSM, donc j'avais également un PO avec moi. Et donc là le PO était beaucoup plus en contact avec les équipes techniques. Il m'a enlevé 80% de ma recherche du delivery. J'étais plutôt sur de la recherche d'opportunités pour l'évolution produit. C'est un produit de facture fournisseur, voir comment on allait gérer la comptabilité, la compta générale comme la compta analytique, comment on allait pouvoir traiter d'autres typologies de documents. je te parle de facture très bien mais il peut y avoir la commande comme il peut y avoir des documents intermédiaires qu'on appelle des situations ce genre de choses donc moi j'étais j'ai complètement dérivé ensuite sur ce travail là aller trouver des nouvelles opportunités voir le marché qui était adressable et en fait à partir de ce moment là c'est comment dire On était bien implanté chez les bailleurs sociaux. On savait qu'il fallait s'ouvrir à d'autres marchés. Et donc là, le travail, ça a été chercher chez Nova, comme on disait, chercher hors bailleurs. Il faudrait être un peu plus précis, mais voilà. Là, l'idée, maintenant, c'était d'ouvrir le produit qui pouvait correspondre à n'importe quel service financier, trouver un autre vecteur où le produit pouvait être proposé. Donc là, c'était une des missions que je pouvais avoir à côté.

Terry : Ok et du coup ça, là on a fait je pense déjà un bon tour de la genèche jusqu'à un produit qui commence à être utilisé pour peut-être accélérer un peu sur la suite fin de cette histoire là. Est-ce que ensuite là t'as d'autres retours à partager sur cette phase ?

Marc : Le dernier truc que j'ai dû mettre en place, franchement j'ai fait un truc ultra transverse. C'est une fois qu'on a mis tout ça en place, il y a un truc qu'on n'a pas parlé c'est la data. C'est bien d'avoir un produit, c'est bien d'avoir des clients, des fournisseurs, des utilisateurs, mais il faut analyser un peu les comportements. Pareil, j'ai dû gérer ça, je me suis pris une formation pour comprendre un peu comment ça marchait, la data vise et compagnie, et j'ai mis en place des dashboards d'entreprise où j'allais récupérer de la donnée dans le CRM, de la donnée dans la base de données opérationnelle, de la donnée dans le logiciel de ticketing et compagnie, pour tout mettre en forme et pour avoir des dashboards d'entreprise sur l'évolution de nos clients, les périodes, le temps de mise en preuve moyen, le nombre de factures par mois, le nombre de fournisseurs, l'évolution des fournisseurs, pour avoir vraiment des dashboards de pilotage d'entreprise pour aller plus loin en fait. Et donc ça c'est quelque chose qui m'a pris 3-4 mois à mettre en place avec de l'automatisation un peu dans tous les sens, mais ça c'était... comment dire, tu joues en fait, c'est génial. Faut mettre un peu les mains dedans, c'est pas simple, mais après quand t'as des dashboards dans tous les sens et que tu pilotes toutes tes réunions avec ça, c'est génial.

Terry : Ouais hyper, c'est vrai que là sur plus l'évolution de ton rôle j'imagine aussi que c'est venu avec le besoin, enfin le besoin d'évolution, enfin le fait que ton rôle évolue aussi à prendre un peu plus de recul, toi t'as besoin aussi de ces données là pour aussi construire des stratégies plus long terme quoi. Donc ok hyper intéressant. Du coup, avant d'aller vers la fin de l'échange, est-ce qu'il y a un sujet en particulier sur lequel tu voudrais accentuer ou qu'on n'a pas abordé ? Et moi j'ai quand même une question sur globalement... Enfin déjà, je te laisse répondre, est-ce qu'il y a un point... Non, pas forcément.

Marc : En fait, ce qui est marrant, c'est que moi, le produit, j'en ai toujours fait parce que chez Dassault, j'étais plutôt en R&D, mais c'est un éditeur de logiciels qui a une belle façon de travailler. Mais j'ai découvert le métier de PM. Après, on m'a positionné comme CPO. Mais il y avait tout un langage que je n'avais pas. C'est des métiers qui sont assez neufs, je ne sais pas, 5, 6, 8 ans, mais qui arrivent des États-Unis. Et donc, à un moment, j'ai dû quand même me mettre à jour, on va dire, plutôt sur du vocabulaire. Et je me suis aperçu, on va dire, quand le Responsable Market est arrivé. Là, j'ai commencé à écouter plus de podcasts, à acheter quelques bouquins pour essayer de voir ce qui se faisait. J'entendais les gens qui disaient « Marty Kagan, c'est… » Ok, très bien, j'en ai un, je vais être honnête avec toi, je l'ai acheté, je ne l'ai même pas lu parce que je me suis, je vais me mettre à le lire et j'ai trois personnes avec qui j'ai échangé à des meetup produits qui m'ont dit non mais vu le travail que tu as fait, ce que tu as mis en place, tu ne vas rien apprendre dans celui-là. Peut-être dans un autre de Morty Kagan, mais dans celui-là, tu ne vas rien apprendre. Donc, j'ai commencé un peu à m'ouvrir aux ressources qu'il y avait autour du product management. Et c'était un plus pour la culture d'entreprise. Au départ, j'arrivais avec des compétences, j'ai mis des belles choses en place. Par contre, pour arriver à faire un switch de culture d'entreprise pour mon DG et compagnie, il a fallu que j'arrive avec les bons termes. plus, comment dire, écouter plus de podcasts, lire différents bouquins sur le product management et arriver avec des termes un peu plus précis, ça a vraiment changé la culture d'entreprise.

Terry : Ouais et ça du coup hyper intéressant comme retour parce que c'est aussi ce que j'allais te poser en fait, la question un peu du coup toi avec tout ce que t'as construit et par rapport à ce que tu vois aujourd'hui, bah des podcasts comme celui-ci, des contenus autour du product management, en quoi, enfin, quelle est un peu ta position par rapport à ça ? Moi ce que là je retire de ce que tu viens de dire et tu me diras si c'est une bêtise mais en tout cas, moi en tout cas ce que je le partage en tout cas c'est le fait de dire tout ce contenu qui est créé en fait il a un intérêt pas tant sur, enfin pour ceux qui connaissent absolument pas bien sûr sur comprendre les méthodes, les pratiques, mais quand tu as le nez dedans en fait tu vas trouver ces pratiques, ces méthodes de manière organique comme tu l'as fait, en revanche en termes de communication à d'autres parties prenantes, en termes d'alignement sur on parle de telle chose, telle chose, telle chose, C'est là, moi, où je trouve qu'il y a un intérêt, tu vois, d'un peu formaliser les choses, d'avoir des terminologies comme on parle de discovery, delivery, pour un peu, on va dire, structurer un discours et que tout le monde, plus ou moins, parle des mêmes choses.

Marc : Complètement. En plus, dans toutes ces documentations-là, il y a certains qui proposent certains templates. pour justement arriver à synthétiser les idées qu'on peut avoir et qu'on ne formalise pas de la bonne manière, d'une manière qui peut être optimisée. Dans ces ressources-là, on peut avoir plein d'informations de gens qui sont cassés les dents comme nous et qui ont proposé un template qui marche, ce genre de choses. C'est super intéressant pour ça. Déjà, ça permet de se rassurer aussi, soi. Et oui, ça amène des éléments et un discours qui, pour les gens qui ne sont pas du produit, vont vraiment arriver à les intégrer là-dedans.

Terry : Yes, top. Du coup, merci pour tous ces partages, c'est hyper intéressant Marc. Et donc pour aller vers les deux questions type de fin épisode, je vais te la rappeler. La première c'est est-ce que tu as une conviction forte avec laquelle en général tu es en désaccord avec tes pairs ?

Marc : Alors, je n'ai pas une conviction forte avec laquelle je suis en désaccord. Par contre, j'en ai un peu parlé tout à l'heure sur cet aspect marketing, je m'aperçois que je participe à beaucoup de meet-up, produits et tout, j'adore ça, rencontrer des personnes là-dessus, c'est génial. Et souvent, on parle produit, on parle framework, on va parler équipe de design, on va parler UX et compagnie. Et on parle peu de marketing et de l'importance justement d'avoir, ce n'est pas forcément un PMM, mais des gens qui arrivent à recentrer le fait qu'il y a quand même un business derrière et c'est important. Et globalement, les gens que je côtoie au niveau produit, C'est souvent le retour que je leur fais, tu n'as pas parlé de l'aspect marketing qu'il y a derrière et compagnie. Et je sais que moi, la vision marketing que j'ai au niveau produit, c'est une belle plus-value que je peux avoir. Je ne vais pas te dire que je suis en conflit avec les pères là-dessus, mais je trouve que c'est quelque chose qu'on néglige un peu.

Terry : Hyper intéressant sur ce qu'on appelle maintenant le PMM, le Product Marketing Management.

Marc : Tout à fait. Tu travailles main dans la main et franchement c'est super important d'avoir cette vue business qu'il ne faut jamais négliger.

Terry : Yes, bon là-dessus je partage totalement. De toute façon on construit des choses pour les vendre in fine, donc il faut bien sûr avoir ça en vue. C'est vrai que parfois on peut un peu se perdre dans les méandres de la conception sans en oublier un peu la partie, bah qu'est-ce qui fait que tu peux manger le soir quoi. Ouais, tout à fait. Top, top. Et du coup, bah la dernière question c'est les ressources, recodes, lectures, enfin alors du coup, ou podcast, ou même personnes avec lesquelles... En fait comment, là tu vois je vais la poser peut-être un petit peu différemment mais sur tout le parcours que tu viens de nous raconter et en fait cet apprentissage un peu de manière très organique ou très... comment dire... très itérative. Toi quels ont été un peu tes trucs qui t'ont aidé au fur et à mesure le long de ton évolution pendant ces six années si je dis pas de bêtises ?

Marc : Franchement au niveau des ressources c'est arrivé vers la fin on va plutôt dire.

Terry : C'est pour ça que moi ça m'intéresse aussi de comprendre durant toutes ces parcours, même si c'est pas des ressources de lecture, je sais pas, toi comment tu.

Marc : T'Es... Moi mon métier, j'ai beaucoup appris au départ du CTO sur le poste de PO. Avec le CTO j'ai eu beaucoup de chance de tomber sur une personne qui était ultra bien accablée là-dessus et qui m'a bien accompagné sur justement le travail à faire d'un PO là-dessus. parce qu'il m'a apporté quelque chose qui était assez génial, c'est que, en général, la relation entre un PO et l'équipe technique, le PO parle produit, l'équipe technique parle technique, et des fois, on s'écarte un peu du sujet, et lui, en tant que CTO, il aurait pu être tenté de m'arrêter très technique, et il a eu cette intelligence, justement, d'arriver à chaque fois à me dire, ça, c'est mes problématiques, toi, tes produits, concentre-toi là-dessus, donc c'était super intéressant. J'ai beaucoup appris de mon site IO, le responsable marketing pareil, énormément. Et après au niveau des ressources, c'est là où j'ai commencé justement à développer ma propre culture en participant à beaucoup de meet-up. Donc ça, c'est top pour échanger avec tes pairs. Génial. Au départ, tu arrives un peu sur la pointe des pieds et tu as l'impression qu'il n'y a que des avions de chasse autour de toi et tu t'aperçois que tu n'es pas mauvais non plus aussi et que chacun a des choses à apprendre aux autres, donc c'est super intéressant. Au niveau des ressources, je te dis donc beaucoup de meet-up, les podcasts. J'ai écouté un peu des podcasts, un peu tout et n'importe quoi, c'est-à-dire des podcasts produits. Au départ, tu entends beaucoup parler de Product Squad, donc je l'ai pas mal écouté. des podcasts de freelance aussi parce que ça m'intéressait avant même de le devenir là, celui d'Alexis Minshala c'est Tribune D. Des podcasts aussi un peu plus... celui de Matthieu Stefani, je sais plus comment il s'appelle là.

Terry : Génération Do It Yourself.

Marc : Celui-là je le trouve intéressant parce que ça parle un peu de tout et n'importe quoi, alors pas tous les épisodes. Chacun trouve son compte, mais je trouvais ça intéressant, la façon de réfléchir en fait. Il y en avait un autre, c'est dans la tête d'un CEO, je l'ai trouvé super intéressant. Ça me permettait, moi en tant que PM ou CPO, de mieux comprendre mon DG aussi, sa façon de réfléchir et tout, donc je l'ai trouvé très très intéressant. C'est bien de comprendre ce qu'on fait nous, mais savoir les problématiques des gens avec qui on travaille, et notamment le CEO, je trouvais ça super intéressant. Dans la tête d'un CEO, il m'a beaucoup aidé. Et après au niveau des lectures, je te disais, The Mom Test, je suis plutôt très très bien. Qu'est-ce que j'ai eu d'autre ? Dernièrement, je me suis fait Discovery Discipline, je l'ai trouvé bien. Je n'ai pas eu encore l'occasion vraiment de l'appliquer, mais je l'ai trouvé plutôt pas mal. J'ai essayé de l'appliquer dans un contexte perso, je ne suis pas arrivé au bout, mais je l'ai trouvé plutôt pas mal. Et il y a un livre qu'on vient de me donner, je ne l'ai pas encore lu, je n'ai plus le nom, c'est celui du CEO de, je crois que c'est Lemlist, Guillaume Moubeche. Il faut que je le commence, je ne peux pas dire s'il va me servir, mais il faut que je le commence.

Terry : Ok, top. Merci pour tous ces partages Marc, et puis à bientôt sur un event Product.

Marc : Ça marche, à bientôt, merci.