Transcription de l'épisode : "Michael Ponrajah, Comment construire un produit et trouver son product-market fit en seulement 3 mois"
Terry : Salut Michael. Merci de me recevoir aujourd'hui pour parler d'orga dans une véritable startup que tu vas nous décrire juste après. Donc on va voir un peu comment fonctionner en mode produit quand on est vraiment dans une toute petite équipe et qu'on cherche son market fit, comment on itère, comment on essaie de se structurer. On va voir notamment aussi comment on fait potentiellement pas du shape-up, des choses qui peuvent s'y assimiler ou en tout cas en quoi l'orga est pertinente. Donc avant de rentrer dans tous ces détails, je te propose de te présenter et puis de nous présenter Lago.
Michael : Hello Terry, merci déjà pour l'invitation. Du coup, je vais commencer par me présenter. Je m'appelle Michael, j'ai 32 ans. Aujourd'hui, je suis Product Manager et Product Designer dans une boîte qui s'appelle Lago. Pour vous faire rapidement mon background, j'ai bossé dans une boîte qui s'appelle Conto. J'ai rejoint la boîte en 2017 en tant que Early Employee et là, mon expérience chez Conto était principalement du Product Design. Et avant Conto, je suis arrivé en 2007, je pense que je suis parti en 2021, j'ai vécu le scale de 35 personnes à à peu près 600, que ce soit d'un point de vue client, même d'un point de vue équipe design, d'un point de vue équipe produit, même d'un point de vue entreprise. Et avant Conto, j'étais dans une autre startup qui s'appelait Content Square, en alternance. J'ai fait moins d'un an là-bas pour rejoindre la boîte Conto. Et donc du coup, après l'expérience compto, j'ai rejoint une boîte qui s'appelle Lago. Et donc du coup, qu'est-ce que Lago fait ? Lago est un outil open source de mettering et de usage-based billing. On va rentrer dans le détail de ces deux termes en quelques mots. nos clients peuvent se plugger à Lago, faire un setup et nous envoyer tous les events de leurs utilisateurs. Et par rapport à ces events-là, on va s'occuper de la partie mettering, donc ça veut dire qu'on va agréger les événements et on va en sortir un usage bien précis en fonction des différentes features qui ont été setup dans Lago. Et après on a la partie usage based billing, ça veut dire que par rapport à cette agrégation d'événements d'usage, on va sortir du coup des factures et on va dire que tel utilisateur a consommé tant et qu'il doit tant à cette entreprise là, donc à nos clients. Et donc du coup on va générer des factures et ces factures là on va les envoyer du coup à des payment providers type Stripe ou autre pour du coup récupérer l'argent auprès de nos clients. Donc c'est les clients qui gèrent la récupération d'argent et nous on s'occupe vraiment de toute la partie logique de comment on agrège l'usage et comment on définit un modèle de facturation après.
Terry : Ok, donc merci pour cette pres. Donc pour contextualiser un petit peu, le but ça va pas être de rentrer dans le détail métier de ce que fait Lago. En revanche, arrête-moi si je me trompe, mais on est d'accord que vous êtes sur un produit qui est assez tech dans lequel il n'y a pas spécialement d'enjeux énormes sur la partie interface utilisateur comme on pourra voir sur des SaaS B2B où là tu vas avoir beaucoup.
Michael : C'est une très bonne question. Au tout début, je me suis fait cette remarque-là. Dans l'histoire de Lagom, on a pivoté, on a changé de produit entre-temps. Et il y avait une discussion où on se disait que ça allait être un produit très tech pour les développeurs. Au fil du temps, on s'est rendu compte que oui, c'est un produit très tech pour les développeurs, mais on touche aussi d'autres cibles qui sont potentiellement les équipes finance, les équipes ops, les équipes aussi des founders, donc les équipes stratégie, les équipes billing. Donc in fine, bien évidemment, on a cette partie très technique API qui va toucher du coup les développeurs, mais la user interface reste toujours quand même très importante.
Terry : D'accord, merci pour cette précision. Donc ensuite, pareil, pour contextualiser, donc de la taille plutôt un peu de votre équipe, de comment vous êtes répartis. Ensuite, on va pouvoir un peu rentrer dans le sujet de comment vous vous organisez.
Michael : Aujourd'hui, j'ai compté, on est à peu près une douzaine de personnes. Si on fait la répartition, côté produits, on est deux. Donc du coup, un des cofondateurs et moi. Côté tech, on va être à peu près 6 ou 7, je crois. principalement des back-end et en front-end et après c'est la partie un peu plus business, go-to-market. On va avoir une personne qui va se trouver entre les deux pôles qui va être la partie solution engineer donc qui va être le pont entre la partie produits et les customers et la partie aussi business, go-to-market. Donc on a une personne sur la partie go-to-market et après tout le reste c'est du go-to-market.
Terry : Ok, donc un gros pôle quand même tech et produits. Donc pour rentrer un peu maintenant dans... là ça pose un peu le cadre, donc on est sur un produit qui est fortement connecté tech mais sans pour autant négliger une partie aussi interface utilisateur et donc quelque chose de plus user-facing on va dire. Comment aujourd'hui vous testez quels sont un petit peu les enjeux ? Pareil, sans rentrer dans le détail de qui sont spécialement les clients ou comment vous allez les chercher, plutôt de comprendre comment est-ce que vous testez les fonctionnalités, comment vous cherchez du coup le fameux market fit, enfin comment vous itérez un petit peu là-dessus.
Michael : C'est une bonne question. Alors aujourd'hui j'estime qu'on commence à toucher un peu au product market fit. Pourquoi ? Parce qu'il y a des indices, il y a des signaux par exemple, si on change quelque chose sur notre doc et qu'on prévient personne par rapport à ça, du coup les gens râlent, ça veut dire que les gens utilisent notre produit. On commence à avoir des clients aussi qui ont signé chez Lago. Si demain on n'est plus là, du coup les gens ne peuvent plus biller leurs customers. Donc ça montre potentiellement qu'on a un début de product market fit. Maintenant on est plus à la course à aller chercher des clients. Mais du coup je peux te parler de comment ça s'est passé avant et aujourd'hui. Donc au tout début, on se posait vraiment la question de quel set de features on allait construire et quel va être le set de features et quel va être le set de problèmes qu'on veut résoudre qui va potentiellement pouvoir faire en sorte qu'une entreprise peut s'onboarder avec l'ago. On a commencé à se poser avec ça, on a réfléchi vraiment aux bases, aux fondamentaux un peu du produit qui sont comment on ingère des events, comment on définit un peu nos plans etc. Là je rentre un peu dans le détail mais Quelles sont les bases de ton produit ? Quelles sont les fondations de ton produit ? On a essayé de le construire le plus rapidement possible. Je pense qu'en trois mois, on a pu construire un MVP assez solide. Je n'ai pas envie de parler de MVP, c'est plus un produit qu'on a construit en trois mois. Et en vrai, le secret, je pense que c'est d'aller le plus vite possible sur le marché, d'aller se confronter aux customers. et essayer de comprendre du coup, avoir le maximum de retours utilisateurs. Et bien évidemment, tu vas avoir des retours de tous types d'utilisateurs. Le but après c'est d'essayer de comprendre quel est l'utilisateur que tu veux aller chercher. Quel est l'utilisateur qui va potentiellement te ramener de l'argent, lequel qui va te rapporter un peu moins d'argent, lequel utilisateur va faire du bruit, l'autre qui va faire moins de bruit, l'autre qui va vraiment utiliser ton produit, celui qui est juste là pour tester. Je ne sais pas si on a un vrai framework derrière ça, mais je pense qu'on s'est posé les questions de quels sont les fondamentaux de notre produit, le mettre le plus rapidement possible dans les mains des utilisateurs, de suivre un maximum les utilisateurs, c'est-à-dire qu'aujourd'hui on a réussi à créer une communauté et il y a à peu près 900 personnes dans cette communauté. et on est hyper proche de nos utilisateurs, c'est-à-dire qu'on leur parle quasiment tous les jours et dès qu'on bosse sur une feature, on ne réfléchit pas aux solutions, on réfléchit d'abord aux problèmes, donc du coup on fait des user interviews avec eux et même quand on réfléchit aux solutions, on partage les solutions avec eux, ils nous valident les solutions, on les fait tester aussi auprès de ces utilisateurs-là et après on commence le développement. Donc on est vraiment dans une notion aujourd'hui où on travaille main dans la main avec les users, on essaie de comprendre leurs problèmes. Ça engendre beaucoup de problématiques qui sont de priorisation ces choses là mais je.
Terry : Pense qu'on aura le temps de discuter. Top, on va y aller après. J'aimerais bien faire une première pause sur ça pour, comme tu disais, vous avez pas spécialement impliqué un framework particulier, moi pour le coup là sur cet épisode j'ai bien envie qu'on parle absolument pas de framework du coup et qu'on rentre plutôt sur de l'intérieur, comment vous l'avez vécu là ces trois mois tu vois pour sortir votre premier produit. vraiment au day-to-day, tu vois, à la semaine, comment vous avez organisé, au début vous vous êtes dit on va faire ça comme ça et puis ensuite vous vous êtes rendu compte bah ça ça marche pas trop, on ajuste, comment au niveau de toute l'équipe vous avez pris cette approche-là parce que c'est vrai que ça peut, enfin c'est compliqué d'avoir ce genre de retour du vraiment du début quoi, de 0 à 1 quoi, comment tu...
Michael : C'est une bonne question. Je me rappelle qu'au tout début déjà on se posait les questions de est-ce qu'on va aller sur le billing system, donc on a fait pas mal de user interviews déjà pour valider qu'il y avait un problème. À partir du moment où on a su qu'il y avait un problème, on l'avait déjà vécu aussi en interne chez Conto, donc ça veut dire qu'on a construit... Quand on était chez Conto, Conto a construit en interne son billing system et on voyait très bien où étaient les limites de la construction d'un billing system en interne, de pouvoir le maintenir, de le faire scaler. Et du coup on avait déjà quand même de premières billes sur comment architecturer tout ça.
Terry : Donc en partant, pour faire une pause là-dessus, vous saviez à peu près, donc grosse maille, un problème identifié et aussi grosse maille, du coup, une cible potentielle d'utilisateurs et de clients qui auraient ce problème.
Michael : Exact. Donc on s'est vraiment focalisé sur si demain on devait reconstruire le billing de compto ou d'une fintech, comment on aurait fait. Et c'est là où vraiment concrètement ce qu'on a fait, c'est qu'on s'est assis avec du coup les ingénieurs, donc des back-end, front-end, product management, product design aussi. et on a commencé à mapper vraiment tout le modèle de données. Donc on s'est dit on pourrait potentiellement avoir cet objet là, cet objet là, il faut qu'il fasse ça, ça, ça, ça. Donc du coup moi ça me permet aussi potentiellement, vu que j'ai la casquette aussi de product designer, de faire des wireframes très rapidement. Et du coup de ces wireframes là, faire des prototypes, et c'est ça qu'après on mettait dans les mains de nos utilisateurs, en tout cas les premières personnes avec qui on discutait, pour plus ou moins valider un peu le concept.
Terry : Sur cette partie donc hyper intéressante, la partie mapping du modèle donné, c'est quelque chose qu'on retrouve beaucoup côté tech, quand tu, du coup, tu as une app à sortir, il faut faire l'archi, donc tu commences à poser ces bases-là. Je suis curieux de voir, du coup, là tu viens de donner partiellement la réponse, c'est-à-dire qu'en tant que product design, ça t'a permis aussi de pouvoir commencer à concevoir la partie plus visuelle, les wireframes derrière. Toi, c'était quoi un peu les inputs que tu donnais, comment tu challengeais potentiellement du coup ces modèles qui étaient proposés par la partie tech à ce moment-là ?
Michael : La manière dont ça se faisait était plus dans l'autre sens, ça veut dire que côté produit, on définissait un peu les wireframes et un peu les datas qu'on voulait avoir, et à ce moment-là, après, on les faisait challenger au niveau des techs aussi, et les techs aussi avaient leurs idées, et en fait, chacun avançait de son côté, et après, c'était un moment où du coup, on se regroupe tous ensemble, et on voit du coup les deux manières de voir les choses, et là, on fait des trade-offs. Et je me rappelle qu'il y avait des choses que moi j'avais mises, qu'on a enlevées, En gros, les questions qu'on se posait, c'était, si on ne rajoute pas cette information-là aujourd'hui, est-ce que vraiment la boîte va couler ? Est-ce qu'on en a besoin pour demain ? Est-ce qu'on en a besoin aujourd'hui ? Et en fait, ça te permet de faire des choix très rapidement en te disant, si là aujourd'hui, les gens doutent sur cette information-là, c'est que potentiellement, s'il y a un doute, il n'y a pas de doute. Donc enlevons-le pour le moment, rajoutons-le si quelqu'un l'utilise et quelqu'un a le manque de cette information.
Terry : Ok, très clair. Donc ça, cette phase-là, de mettre à plat tout ce modèle de données, en faire les wireframes, et itérer entre ces deux parties, ça a pris à peu près combien de temps ? Un gros smile, tu vois, c'est du deux semaines, trois semaines ?
Michael : Un gros smile, j'aurais dit entre une et deux semaines.
Terry : Ok.
Michael : Entre une et deux semaines, sachant que, et on aura l'occasion de le voir, de l'entendre dans ce podcast, c'est qu'on se connaît tous depuis cinq, six ans, donc du coup on a déjà des réflexes de comment on peut bosser ensemble. Donc on est allé hyper vite dans le sens où en deux semaines la communication était hyper fluide et en deux semaines je pense qu'on avait déjà défini un peu comment l'app allait marcher.
Terry : Il n'y avait pas d'enjeu d'apprendre à travailler ensemble.
Michael : Non, c'est vraiment une des chances que j'ai eue moi en rejoignant l'AGO, c'est que principalement toutes les personnes qui font partie de l'AGO, je les connais toutes depuis 5-6 ans. Et tant bien même qu'on n'ait pas forcément tous bossé ensemble, on a au moins tous à peu près cette culture de comment tu travailles avec les autres, comment tu communiques un peu plus que d'habitude et comment tu fais l'extra mile pour que le travail de l'autre soit un peu plus plaisant que d'habitude.
Terry : Ok, très clair. Donc à peu près deux semaines là, sur ces deux semaines là, vous étiez tous dans le même bureau, éclaté dans le monde entier ? Enfin c'était...
Michael : On était... Je me rappelle qu'à ce moment là, donc c'était période Noël, on avait pris trois semaines de vacances, deux ou trois semaines de vacances et janvier on recommençait les discussions. On était tous en remote.
Terry : Ok, intéressant. Et niveau outils du coup pour gérer ça, pour gérer la partie brainstorming, vous étiez à utiliser quoi ?
Michael : On est resté très simple, Notion, Figma, Spreadsheet. Spreadsheet, j'ai souvent sous-estimé, mais c'est un outil hyper puissant pour l'idéation, parce que ça te permet vraiment de poser tes idées. Et donc du coup, je pense que ça a été principalement ces trois outils-là.
Terry : Ok, intéressant. Sur Spreadsheet, il y a quoi en particulier que tu trouves pertinent pour la phase d'idéation ?
Michael : En gros, il y a vraiment ce truc où, vu qu'on a un objet, on a un outil de billing, donc on est très lié à des calculs, et aussi des modèles de données où, je pense que dans toutes les boîtes, il y a des modèles de données où les choses s'indentent. Je trouve que Spreadsheet, ça marche assez bien, parce qu'en fait, tu as cette liberté de pouvoir avoir un canvas totalement libre, mais en même temps, rajouter des formules, et pouvoir faire en sorte que les choses soient dynamiques. Donc, je trouve que c'est là où la puissance de Spreadsheet découle. Bien évidemment, on n'a pas le côté un peu plus libre d'un Miro ou d'un Whimsy Call ou autre. D'ailleurs, je parle de Whimsy Call, mais on a beaucoup utilisé Whimsy Call et on l'utilise toujours. Donc ouais, je pense que c'est le mélange entre Figma, Notion, j'avais dit Slack, Whimsy Call et Spreadsheet.
Terry : Ok, très clair. Donc pour continuer à avancer, donc deux semaines, vous avez sorti le premier proto derrière que vous pouvez mettre dans la main de vos clients potentiels. Donc là, comment vous avez fonctionné ensuite ? Comment déjà vous êtes allé les contacter ?
Michael : Ce travail de contact s'est fait quand même en amont, ça veut dire que... on avait une conviction forte sur le fait qu'il y avait un vrai problème au niveau du billing, mais on voulait forcément le valider. Et donc du coup, ça passe par le réseau, ça passe par le réseau des fondateurs, le réseau aussi des premiers employés, mais principalement le réseau des fondateurs. Et il y a un autre sujet, c'est qu'on avait fait Y Combinator un an avant sur un autre produit. Donc du coup on a pu bénéficier aussi du réseau YC qui nous a ouvert quand même pas mal de portes et donc du coup on a discuté avec pas mal de boîtes, notamment des grosses boîtes, pour voir s'il y avait vraiment un problème. À partir du moment où tu commences à créer du lien avec ces premières personnes en user interview, t'arrives à vite capter si des gens sont vraiment intéressés pour continuer les discussions et du coup à ce moment-là nous n'avons pas hésité à les mobiliser pour valider des idées. Aussi, à côté de ça, on a essayé de se créer aussi un petit réseau de contributeurs individuels billing pour voir aussi quels sont les problèmes que ces gens-là ont vécu. Donc on commençait aussi à faire des user interviews sur des contributeurs individuels. Je me rappelle qu'on avait discuté avec des gens qui avaient construit des billings de grosses boîtes et on faisait des sessions avec eux, juste pour voir si le modèle qu'on avait tenait la route.
Terry : Donc quand tu parles de contributeurs individuels billing, c'est des personnes qui ont déjà mis en place ce type de système dans d'autres structures, pour voir vous, si vous êtes dans la bonne ligne pour essayer, enfin en gros pour leur créer le produit qu'ils auraient aimé avoir à l'époque.
Michael : Exact, sans forcément parler de devenir utilisateur. C'est plus cette notion de, ok on est en train de tacler ce problème là, t'as déjà bossé sur ce sujet là, est-ce que tu peux nous accorder du temps ? Potentiellement ça peut être du win-win parce que si nous on réussit à construire un produit, demain tu pourras l'utiliser. Je pense que les gens ont joué le jeu et c'est ça que j'ai trouvé aussi super cool.
Terry : Ok, hyper clair. Donc durant cette phase de validation, ça a pris à peu près combien de temps ? Et côté tech, qu'est-ce qui se passait ? Est-ce qu'ils commençaient du coup à rentrer plus, sortir un peu du cadre proto et commençaient à construire quelque chose ? Et combien de temps la validation a prise ? Comment les itérations, enfin les échanges se.
Michael : Faisaient aussi avec la tech pendant cette période ? Je ne pourrais pas trop te parler de délai parce que je ne l'ai plus trop en tête. Mais en tout et pour tout, je pense que notre produit, on l'a construit en trois mois. Et comment ça s'est fait ? Du coup, on a fait nos protos, on a commencé à les valider. En parallèle, ce qu'on a fait avec les ingénieurs, c'est qu'on a commencé à découper vraiment l'application en se disant, on va essayer de slicer au plus petit possible. Et en fonction de ce découpage-là, comment on peut faire pour délivrer des choses ? Et c'est là où en gros les techs commençaient avec ce premier, on va dire, contrat d'alignement à avancer sur un POC. Donc ils creusaient un peu les solutions, ils creusaient un peu comment ils allaient le faire. Bien évidemment, il fallait choisir aussi un peu les technos, toutes ces choses-là. Là, c'est plus les ingénieurs qui s'occupent de ça. Nous, en parallèle, ce qu'on commençait à faire, c'était que du coup, on validait les choses. En même temps, on avait une grosse conviction sur comment les choses devaient être construites, donc on prenait aussi de l'avance sur, par rapport à notre slicing, comment on a découpé les choses, comment on fait pour délivrer ces choses-là. Donc on a commencé à vraiment rentrer dans le détail du design, et après, sur chaque design, on avait des specs. Et du coup, je pense que j'aurai l'occasion d'en reparler un peu plus dans le détail sur après la validation du produit. Mais c'est comme ça qu'on marche encore aujourd'hui, c'est qu'on a toujours des designs, on a toujours des specs, ça veut dire que le design montre l'expérience globale d'un point de vue user interface, la spec te parle de la logique que les choses doivent avoir, donc la logique de calcul, la logique de back-end et la logique de front-end. Du coup, on met tout dans un document et c'est vraiment le document, la source of truth, la source de vérité, et c'est sur ce document-là que tout le monde se base. C'est là où toutes les discussions se font.
Terry : Ouais donc en fait vous n'êtes pas parti complètement aveugle en termes du besoin à résoudre, vous êtes parti avec quand même certaines comme tu disais convictions et l'idée c'était de dire de découper une première batch de travail et une roadmap comme tu disais, j'ai oublié le terme que tu as utilisé mais c'est pas un engagement hyper fort mais quand même pour donner à l'équipe Eutech et aux ingés à peu près l'ordre de priorité de comment construire. tout en parallèle en validant certains aspects sur lesquels vous aviez potentiellement plus de doutes mais c'était pas complètement opaque ce qu'il fallait construire, vous aviez quand même une vision assez claire sur la V1.
Michael : Exact. En gros, on s'était dit, le contrat c'est qu'il faut qu'on arrive à sortir un produit en trois mois. En gros, on avait quand même déjà un an et demi d'expérience dans les pattes. Quand je parle d'expérience, c'est qu'on avait construit un premier produit. Le produit n'avait pas forcément eu son succès. Du coup, ça a créé aussi un peu de la fatigue et ces choses-là. Donc, on se dit, OK, comment on fait pour re-jumper sur un nouveau produit ? sans que ça dure vraiment une éternité et qu'on passe six mois à construire un produit et qu'on soit dans le doute. Donc on s'est dit quel contrat, on a trois mois pour sortir un produit, qu'est-ce qu'on fait rentrer en trois mois et comment on fait en sorte que ce soit le plus petit possible pour qu'on puisse délivrer petit bout par petit bout.
Terry : Ok, très clair. Et du coup, durant ces trois mois, c'était des livraisons, je sais pas moi, tous les deux, trois jours, toutes les semaines, ou c'était trois mois de blocs que du dev et du design, et c'est au bout des trois mois que vous avez sorti vraiment la V1 ? Ou est-ce qu'il y avait des pré-V1 avant ?
Michael : Non, non, c'est vraiment au bout des trois mois qu'on a sorti une V1. Ça veut dire qu'en fait, vu qu'on est un outil open source, on ne pouvait pas se permettre de sortir brick par brick, parce qu'en fait, les gens ne pouvaient pas forcément toutes utiliser. En gros, si je te parle de l'AGO, si je rentre un peu dans le détail, on a une brique qui va te permettre de mesurer l'usage et une brique qui permet de faire les factures. Mais du coup, si tu sors la brique de mesure d'usage mais que tu n'as pas la brique de facturation, ça ne sert pas à grand-chose. Et si tu as la brique de facturation mais que tu n'as pas la brique de mesure d'usage, c'est parallèle, c'est dans l'autre sens, c'est que ça ne sert pas à grand-chose. on s'est dit en trois mois comment on fait pour sortir quelque chose et c'est au bout des trois mois qu'on a ouvert notre repo, notre repo GitHub et qu'on a commencé à dire ok, le projet est dispo, les gens peuvent le télécharger, maintenant vous pouvez commencer à builder vos users.
Terry : Ok, très clair. Donc après, avec cette sortie de V1, là c'est quoi les premiers retours que vous avez eus et comment vous avez ensuite ajusté les choses, comment ça s'est un peu présenté la suite ?
Michael : Comment ça s'est passé après la sortie de l'AVA ? Alors déjà, on était tous hyper contents de sortir notre produit. En plus, un produit open source, ça veut dire que les gens peuvent vraiment soulever le capot et voir ce qu'il y a dedans. Les retours ont été hyper positifs. On a eu beaucoup de retours positifs par rapport au travail qu'on a fait, la qualité qu'on avait mis dedans. Donc déjà, dans un premier temps, c'était satisfaisant. Mais ce n'était pas tout parce qu'en fait, en gros, on avait sorti un produit, mais on est une entreprise et il faut quand même qu'on gagne de l'argent aussi à un moment.
Terry : Ça me fait penser, désolé je te fais faire une pause, j'y pense quand tu commences à dérouler, la sortie effectivement, comment vous aviez un peu attiré les gens pour qu'au moment de la sortie les gens soient au courant ? Parce qu'effectivement on produit open source donc le code ouvert sur plateforme GitHub, derrière il faut quand même que les gens viennent voir parce que si tu as deux personnes qui passent, comment vous aviez un peu préparé ça en parallèle aussi ?
Michael : Ça fait partie un peu de la stratégie go-to-market que Anto avait mis en place. Je ne l'ai pas totalement en tête, mais je me rappelle qu'on avait déjà commencé à créer du contenu sur notre site internet, on avait commencé déjà à écrire des articles, des choses là. Donc en fait on arrivait déjà à créer un peu une communauté et du coup on a profité de ça quand on a sorti notre produit pour du coup en parler aux gens. Encore une fois, comme je te parlais tout à l'heure, c'est qu'on a fait des user interviews avec des boîtes, des user interviews avec des contributeurs individuels, donc on n'a pas hésité à leverager ça et on a aussi leveragé notre réseau. On a leveragé le réseau YC, on a leveragé le réseau même de tech à Paris. Et il y a un autre point aussi qui a fait qu'on a fait en sorte que quand on a sorti Lago, les gens ont pu voir Lago, c'est qu'on a profité pas mal d'un peu de hacker news. Donc en gros sur Hacker News, tu peux poser des topiques et en fonction de si ça intéresse les gens, les gens vont communiquer sur ce topique-là, ils vont débattre, ils peuvent obvoter aussi les topiques. Et je pense qu'avant la sortie de notre repo, je crois qu'on était top 1 sur Hacker News pendant 24 heures. sur un sujet qui était pourquoi construire un billing est un cauchemar pour les ingénieurs. Ça a créé beaucoup d'engouement sur Hacker News. Du coup, ça nous a déjà réussi à nous placer sur une map. Les gens se sont dit OK, il y a la map un peu du billing, il y a Lagos qui est sur cette map là, on ne sait pas encore ce qu'ils font. Mais ok, et du coup après on a sorti notre repo et on a continué cette stratégie hacker news où on a réussi à faire peut-être, je vais peut-être dire des conneries, mais entre peut-être 3, 5, 6 fois top hacker news. Du coup ça crée du contenu, ça crée du trafic, ça crée de l'engouement. Donc je pense qu'on a pas mal joué sur ça au tout début.
Terry : Ok, une tracée quand même assez complète quoi, c'est-à-dire un parti contenu, le réseau direct, le réseau de tes users avec lesquels tu as fait tes tests, et ça je pense que c'est pas à négliger effectivement. Et puis aussi voilà, comme tu viens de le dire, la partie Hacker News sur laquelle... Donc ok, très clair. Donc pour revenir du coup sur les premiers retours que vous avez eus à cette sortie.
Michael : Yes, du coup on a sorti le produit, il y a quand même de l'engouement, les gens étaient contents de la qualité, donc c'était hyper satisfaisant. Mais ce n'est pas fini, ça veut dire que tu sors ton produit, ok tu viens de terminer quelque chose, maintenant c'est quoi la next step ? Et la next step c'est de vendre. Du coup il faut que tu vendes ton produit. Il y avait beaucoup de discussions à cette époque-là parce qu'en fait on était open source. L'open source ça ne veut pas dire.
Terry : Que c'est forcément gratuit, Ouais, ça c'est un point important.
Michael : C'est un point important à dire, l'open source ça veut pas dire que c'est gratuit, l'open source ça veut dire que c'est ouvert, mais ça veut pas dire que c'est gratuit. Et on s'est pas mal posé cette question-là de comment nous on veut modéliser un peu notre business, et aujourd'hui on a plusieurs offres, c'est-à-dire qu'on a l'offre, et c'était comme ça dès le début, on a gardé tel quel aujourd'hui. c'est qu'on a une offre open source self-hosted, donc ça veut dire que les users peuvent l'héberger chez eux, et cette partie-là est gratuite, limitée en termes de features, et après si jamais tu veux avoir accès à des features un peu plus poussées, qui sont en dehors du core billing system, à ce moment-là tu payes une licence, et soit tu peux l'héberger chez toi, soit on l'héberge pour toi, et c'est là où les gens payent. et au début c'était un peu compliqué de vendre ce truc là parce qu'on avait un set de features quand même assez limité on avait sorti vraiment un produit MVP on va dire et je pense que la suite après le lancement du coup ça a été se confronter un maximum au marché et se rendre compte des features qui manquent se rendre compte des features qui manquent on savait qu'on avait fait le minimum maintenant il fallait chercher du coup tout ce qui manque et comment tu peux rattraper du coup tout ce qui manque au niveau.
Terry : De ton produit Et là du coup au niveau de la collecte de ce fonctionnalité qui manque, comment est-ce que vous avez collecté ça et derrière comment vous l'avez priorisé parce que c'est vrai que sur les projets open source tu peux avoir beaucoup de... tu peux avoir des communautés je pense très actives parce que tu as des gens qui sont passionnés aussi très tech et qui vont du coup proposer des choses etc. D'un autre côté, ce n'est pas potentiellement ceux que tu vas pouvoir derrière convertir en clients qui vont t'amener du business, mais il faut quand même les garder. Donc comment déjà vous avez collecté et priorisé un peu tout ça ?
Michael : C'est une très bonne question. Je pense qu'au début, on essaie d'être le plus proche possible des users open source qui ne payaient pas. Parce qu'on s'était dit que si quelqu'un l'utilise, même s'il ne le paye pas, c'est qu'il voit de la valeur. s'il voit de la valeur, c'est que potentiellement il peut voir aussi les choses qui manquent. Donc du coup on a été hyper proche de ces premiers users, on a réussi à signer des clients aussi, des petits contrats, et en fait on se disait peu importe l'argent qu'ils mettent dans le produit, essayons d'être le plus proche possible d'eux, et essayons de voir comment ils utilisent le produit, qu'est-ce qui manque, et après c'est assez simple en termes de structure, c'est qu'on listait vraiment tous les problèmes, Et on a gardé ce système-là. Aujourd'hui, on marche sous cycle de 6 semaines. On l'a pris un peu chez PUP. Mais du coup, ça nous permet de rabattre les cartes de la roadmap toutes les 6 semaines. Même pendant les cycles, on peut revoir la roadmap. Du coup on s'est dit, essayons d'être le plus proche possible des users, prenons un maximum de feedback, on les log, on les trie, on voit quels sont les users les plus importants et quels sont les users les moins importants, qui sont les personnes qui l'utilisent vraiment et les personnes qui l'utilisent moins, même ceux qui testent et qui n'utilisent pas, et après on faisait un peu notre arbre de priorisation et on délivrait les features que les gens avaient besoin, aussi en gardant la vision du produit et la vision de la tech. Ok, très clair.
Terry : Et du coup pour un petit peu rentrer dans le détail, quand tu dis un bloc de 6 semaines, donc c'est 6 semaines à la fin desquelles vous allez faire une nouvelle release sur le repo et vous allez potentiellement avoir une nouvelle feature disponible sur la partie payante.
Michael : C'est un cycle de six semaines où on rediscute un peu des priorités de la boîte, des priorités de la roadmap par rapport à tous les call sales qu'on a eus, par rapport à tous les user interviews qu'on a eus, par rapport à aussi les plaintes qu'on a sur la communauté et les améliorations. On ne release pas toutes les six semaines, on est en flux continu, c'est-à-dire que dès qu'une feature est prête, la documentation est faite, le front et le back est prêt, on release de suite sur notre repo cloud, enfin sur la partie cloud, et quelques jours après on release sur la partie OSS, donc open source. Pourquoi on fait ça et pourquoi on n'attend pas les six semaines ? Parce qu'en fait on s'est dit que si on attendait vraiment... Imaginons que tu termines une feature au bout de deux semaines et que tu es obligé d'attendre quatre semaines pour faire une release, en gros pendant quatre semaines ta feature est d'or et pendant quatre semaines les gens vont attendre du coup, vont vivre encore avec le problème. Et on préfère du coup release et dire aux gens que c'est prêt, vous pouvez l'utiliser et ils l'utilisent. S'il y a un problème, du coup on le tacle tout de suite et potentiellement ça peut être taclé dans les six semaines qui sont en cours. J'ai un exemple bien concret. ça s'est passé ce matin, on a release une feature très tôt ce matin et du coup j'annonce à l'utilisateur que le problème qu'il avait maintenant est résolu, il teste la feature et il se rend compte qu'en fait la feature ne marche pas. Et donc du coup il me ping, on rentre en call ensemble et on débug ensemble et en fait on s'est rendu compte qu'on avait un problème de déploiement sur notre instance européenne et en fait si on avait attendu six semaines ben en fait on l'aurait pas vu arriver et on serait déjà passé sur un autre sujet et là ça aurait créé beaucoup trop de stocks, beaucoup trop de problèmes.
Terry : Hyper pertinent, intéressant et effectivement ça rappelle l'un des gros intérêts de cette livraison continue pour relever des loups auxquels t'avais même pas pensé en fait, qui sont indirects, qui sont pas liés à la fonctionnalité de base au début mais qui sont mis en exergue parce que justement tu veux réaliser ta fonctionnalité donc ça c'est hyper hyper pertinent. Ce qui m'intéresse, ce à quoi ça me fait penser quand tu viens de dire, du coup là tu avais prévenu un des utilisateurs qui avait ce problème que c'était prêt, c'est toi aussi en tant que product designer, un peu dans cette organisation hyper dynamique et mouvante aussi, c'est quoi du coup les grandes missions par lesquelles tu es passé jusqu'à aujourd'hui, aujourd'hui là où tu en es, ce que tu fais, pour aussi peut-être donner un peu de contexte sur ce que ça veut dire qu'être product designer dans une startup, je pense que c'est intéressant.
Michael : C'est une très bonne question. Au tout début de Lago, on avait fait un peu ce pari fou d'un point de vue design. En gros, quand je suis arrivé chez Lago, je suis arrivé au tout début et il y avait une discussion avec les founders et je trouve ça hyper cool qu'il m'ait fait confiance à ce moment-là. C'est la première brique, le premier travail que j'ai mis en place, en dehors de comprendre les wireframes, le produit, etc., c'est de construire un design system. C'est vraiment une des premières briques qu'on a mis en place avec une développeur front qui nous a quitté il y a peu de temps. On a mis en place un design system. Je savais pertinemment qu'en fait j'allais faire du product design et du product management. La question que je me suis posée c'est comment je peux faciliter le travail product design d'un point de vue création d'interface comment je peux à minima l'industrialiser pour que ce soit le plus rapide possible, pour que moi je passe plus de temps sur de la recherche utilisateur, sur comment les choses doivent marcher et pas forcément l'interface.
Terry : Ouais et ça c'est, tu fais bien de le préciser parce qu'effectivement d'autres auditeurs qui pourraient être dans des structures beaucoup plus grosses, ils pourraient se dire what the fuck, 10 systèmes, ils sont même pas 10, nous on le met en place on était 500 et en fait ce que tu viens de détailler c'est hyper pertinent c'est à dire que vu que tu as un nombre de personnes limité pour aussi bosser sur la partie plus produit et pas design si tu veux derrière réussir à construire quelque chose d'assez cohérent et assez homogène le design system il est hyper important En gros.
Michael : Le sujet c'était pas forcément comment on fait pour faire scaler une équipe, comment on fait pour avoir les standards alignés sur toutes les personnes qui vont bosser côté tech, côté design, côté entreprise. Le sujet là c'était plus comment on fait pour communiquer, pour bien communiquer et perdre le moins de temps possible. En gros, j'ai mes vues formulaires. Du coup, mes vues formulaires sont tout le temps dans ce layout-là. En responsive, c'est tout le temps comme ça. Et j'ai toujours un bouton qui se trouve en bas. Et voici les règles de mes formulaires. Mais avant de faire ça, il fallait quand même que je rentre vraiment dans le détail de comment une page peut être structurée, quels sont les layouts, quelles sont les informations qu'on veut mettre dedans, pour en fait voir l'étendue vraiment de l'expérience et après commencer à rationaliser. On ne peut pas faire un design system sans avoir cette vue un peu globale et à la fin, même encore aujourd'hui, une feature qui nécessite du back-end et du front-end, si je fais un peu le ratio, sur 100% du temps, le back-end va prendre 80% et le front va prendre 20%. Parce qu'en fait, le front va hyper vite, ce qui nous permet d'avoir aujourd'hui plus de back-end que de front-end, parce que du coup, on peut les paralléliser et on peut les mettre sur différentes features, et l'ingénieur front-end qu'on a aujourd'hui, Alex, Lui ça lui permet du coup d'épiler très rapidement des features et tacler peut-être deux features par semaine ou trois quatre features en deux semaines.
Terry : Oui, hyper intéressant. Est-ce que vous êtes allé jusqu'à, effectivement, dans le design system, construire des composants front, dans la techno front que vous utilisiez ?
Michael : Oui, on a pris trois semaines à le mettre en place. Je t'avoue que ces trois semaines-là ont été dures au tout début parce que je me posais toutes les questions du monde. Et en fait, tu peux lire tout plein d'articles qui disent qu'il faut construire des choses qui ne scalent pas. Un design system, au début d'une entreprise, il ne faut surtout pas le mettre en place. Et nous, on a fait totalement quelque chose qui était à l'inverse. Et en fait aujourd'hui je ne regrette pas du tout.
Terry : Ouais, c'est pour ça, merci pour ce partage parce que je trouve ça hyper intéressant justement de voir des trucs un peu à contre-courant mais aussi pourquoi vous l'avez fait. Et donc pour continuer sur l'émission du coup par laquelle t'es passé, donc t'as commencé de focus sur ça en sachant qu'il fallait te dégager du temps sur le reste après. Donc après le reste c'est quoi, ça représentait quoi un peu ?
Michael : Le reste, c'est quoi ? Du coup, si on occulte un peu cette notion de user interface, ça m'a permis de prendre du temps sur suivre les customers, suivre les discussions de comment les gens utilisent les produits, suivre les besoins, et à côté de ça, passer un peu plus de temps sur la réflexion de solution. Quand je parle de réflexion de solution, c'est comment les choses marchent dans la logique pure. Ça veut dire les calculs, comment les calculs marchent, comment les choses sont imbriquées entre différents services, entre différents objets, et même des fois aussi réfléchir à comment d'un point de vue méta, l'application doit ressembler d'un point de vue UI. Donc du coup, ça me permet de creuser un peu ces sujets de fond, de passer un peu plus de temps. Et quand on bosse sur une feature aussi, ça veut dire que j'ai le temps pour faire ces choses-là, donc comment les choses marchent. Et du coup, d'un point de vue UI, ça me prend très peu de temps à construire les écrans, parce que les standards sont déjà posés. Donc ça me permet de creuser un peu plus de choses, on va dire la partie avant de commencer le design. Quand je dis design, je parle de design d'interface.
Terry : Ouais, ok, très clair. Si du coup là tu devais un peu regarder derrière, tel que tu l'expliques, ça a l'air assez smooth le passage du MVP jusqu'à là où vous en êtes aujourd'hui. Alors je ne te demande pas de dire spécialement le plus gros échec par lequel vous êtes passé, mais en tout cas des gros apprentissages que tu as eu en regardant un peu dans le rétroviseur. te dire si ça on devrait le refaire peut-être qu'on le ferait différemment ou au contraire toutes les choses que vous avez faites que tu trouves qui ont bien fonctionné et qui sont aussi peut-être le résultat de l'expérience passée chez YC et puis de l'année et demie aussi à bosser sur un autre produit.
Michael : C'est inhérent à toutes les entreprises. Il y a forcément quelque chose que je regrette, moi, c'est de ne pas avoir anticipé les choses qui se passent maintenant. En gros, on a fait des choix au tout début de l'AGO qui nous ont permis d'avancer. Aujourd'hui, on se rend compte qu'il y a certains choix qui auraient pu être faits différemment, mais tu ne peux pas forcément prévoir et prédire le futur. Donc ces choses-là, je les mentionne, mais en gros, on peut rien y faire. Après, je pense qu'il y a des choses qu'on avait mal faites au début et on s'est amélioré. Je pense que c'est de la communication avec la communauté. En gros, pour moi qui ai un passé très product design, application SaaS et pas du tout open source, c'était totalement nouveau ces notions un peu de breaking change, de tu changes quelque chose sur un produit open source, quelqu'un l'utilise, si tu le changes complètement, il y a des champs qui ne sont plus là, du coup ça casse lui son instance. Avant chez Conto, en fait, tout était hosté chez Conto et donc du coup si tu changes quelque chose, les gens en fait s'en fichent un peu parce qu'en fait ils utilisent un produit SaaS.
Terry : Oui, au pire ça tombe côté support qui va expliquer comment l'utiliser.
Michael : Exact. Et donc du coup je pense que ce truc-là c'est de ne pas avoir été... J'ai pas eu ce dynamisme au début de vraiment m'intéresser à comment les choses marchent en open source. Du coup on a fait quelques erreurs, on a fait des breaking changes et il y a des users qui sont pas mal pleins, on ne les avait pas communiqués, toutes ces choses-là. Et je pense que c'est comme ça aussi qu'on apprend. C'est en faisant ces choses-là qu'on apprend, on s'est vu hier soir, on en avait discuté. C'est comme ça qu'on apprend, c'est qu'il faut y aller, il faut se lancer et c'est en se confrontant du coup au marché que tu sais ce qui est bien, ce qui est pas bien. Et je pense que la chose la plus importante après c'est du coup d'être conscient que les choses ont mal été faites et du coup de pouvoir les corriger. Du coup, nous, on a compris aussi que sur notre communication de breaking change, il fallait qu'on soit un peu plus avenant, qu'on fasse preuve de dynamisme et qu'on aille pinger les gens et non pas qu'on fasse une annonce globale, qu'on aille vraiment coller au corps nos customers. Et aussi, on a compris aussi qu'en gros, faire des breaking change, on va essayer de faire un minimum de breaking change possible. Ça veut dire que dans les solutions qu'on réfléchit, on réfléchit maintenant à comment on construit notre solution et comment on fait en sorte que ce qui s'est passé avant cette solution soit toujours là. Ou pas que ça casse du coup l'expérience pour les premiers clients et ceux qui ont des versions différentes.
Terry : Une véritable rétro-compatibilité que tu peux retrouver par contre dans le monde des API, des boîtes qui construisent que des API, c'est pour ça que tu as des v1, v0, enfin v1, v0, v1, v2, v3, mais effectivement quand tu as ton instance qui tourne et du jour au lendemain nouvelle release ça pète tout, parce que tous ne sont pas en mode SaaS, Hosted, c'est... un point hyper intéressant et qui est spécifique au contexte de l'open source.
Michael : Exactement. On a vite tendance à penser que ok, c'est un changement, les gens vont faire le changement et voilà, on n'en parle plus. Sauf que quand tu commences à discuter avec tes clients, tu te rends compte qu'en fait, ils ne sont pas là pour bosser sur l'ago toute la journée. Ils ont d'autres choses à faire, il faut qu'ils s'occupent de leur entreprise. Donc du coup, à chaque fois que tu fais un changement et qu'ils nécessitent quelque chose à maintenir de leur côté ou à changer, en fait tu leur fais plonger dans un sujet qu'ils avaient potentiellement mis down. Donc ouais, aujourd'hui c'est vraiment un sujet, c'est comment on fait en sorte d'avoir la compatibilité, la rétro-compatibilité.
Terry : Ok, très très clair. Donc avant, il y a un petit point que je voudrais aborder, auquel je pense, c'est sur votre organisation. Est-ce que vous êtes full asynchrone ? Comment vous fonctionnez à ce niveau-là ? Comment vous fonctionnez à ce niveau-là ?
Michael : C'est une bonne question. Je ne sais pas si je pourrais dire qu'on est synchrone ou full asynchrone, je pense qu'on est hybride entre les deux. Pour te donner un peu plus de contexte, je suis revenu la semaine dernière, j'ai passé deux mois en Amérique du Sud. J'ai fait un mois à Rio, donc du coup je crois que Rio c'était moins 5 heures par rapport à la France. Et après j'ai fait un mois en Colombie où là c'était moins 7 heures. Et il y avait une partie de l'entreprise aussi qui était avec moi, on était ensemble en Amérique du Sud. Donc du coup, par défaut, on était asynchrone côté produits avec les équipes tech. Là, maintenant que je suis revenu en France, on va dire que je suis un peu plus synchrone. Mais du coup, on a un de nos fondateurs qui est à Bogotá, en Colombie. Donc lui, il est asynchrone. Donc on est un peu dans un modèle hybride. Et qu'on soit synchrone ou asynchrone, on avait fait le pari dès le début de tout mettre à l'écrit. Donc on met vraiment tout à l'écrit, et c'est un peu cette notion que je te disais par rapport à la spec, donc les spécifications, on met tout à l'écrit, les designs doivent montrer tous les écrans, tous les états, le moindre over avec un tooltip, du coup il faut mettre le tooltip avec le contenu dedans. on essaie de faire un maximum de choses posées, et bien évidemment on a des choses qui se sont dites aussi à l'oral, je pense que c'est un peu le problème qu'il y a avec la synchrone, c'est que quand tu es à la synchrone, tu mets toi à l'écrit, mais que tu prends des décisions à l'oral, en synchrone, tu penses jamais à les remettre sur la synchrone, ça ça nous a déjà joué des tours. Mais aujourd'hui on est dans un modèle hybride où on synchronise le matin, avec les équipes pour parler des bugs, parler des priorités de la journée. On a un héritage des deux mois en Amérique du Sud où on synchronise vers 14h aussi. Parce qu'en fait quand il est 14h à Paris, il est 7h à Bogotá et c'est l'heure à laquelle Rafi commence. Donc du coup comme ça on fait un catch-up aussi l'après-midi à 14h et après sinon chacun avance sur ses sujets et quand les gens ont de la dispo, du coup on synchronise.
Terry : Hyper intéressant, du coup ça me lève une autre question, souvent quand on a vraiment des petites boîtes qui commencent à démarrer, on a envie d'être au même endroit pour créer du lien, pour apprendre à travailler ensemble, alors j'imagine que vu que vous vous connaissiez comme tu le dis d'avant, ça aide aussi à ne pas avoir besoin de faire ça, mais ma question du coup c'est comment est-ce que vous gardez cet esprit de, on bosse sur un projet commun ensemble et on maintient cette... sans même parler d'alignement du produit mais plutôt la cohérence, la cohésion d'équipe.
Michael : Alors comme tu l'as dit, on se connaissait tous parce qu'on avait plus ou moins tous fait conto avant. Donc on s'était rencontré à conto, donc bien évidemment ça aide énormément, donc on a quand même un non-fair advantage par rapport à d'autres boîtes qui se créent et où les gens ne se connaissent pas. Mais après, ce qu'on a quand même essayé de faire, c'est de l'alignement d'un point de vue travail, d'un point de vue comment on s'aligne avec les gens, comment on travaille sur les bons sujets. C'est de l'alignement le matin, c'est de l'alignement sur pourquoi on bosse sur ces sujets-là. Pourquoi ce sujet-là et pas un autre ? Un peu cette notion de la priorisation se fait d'un point de vue entreprise et pas d'un point de vue individuel. C'est qu'on a les objectifs d'entreprise. Donc ça veut dire que tous les quarters, même tous les mois, on se définit les objectifs d'entreprise. Et en fait, ces objectifs-là, on fait en sorte de tendre vers ces objectifs. Donc ça, c'est le premier point. Deuxième point, c'est qu'on essaie de se voir le plus souvent possible dans la mesure du possible. Ça veut dire que ceux qui sont à Paris se voient à Paris. Ceux qui sont un peu dans d'autres villes, on essaie de créer aussi ces moments de vie. Soit c'est des moments online, donc du coup on se retrouve le soir et on avait un peu ce concept qui s'appelait les lags opéraux, où du coup le soir on jouait à des jeux ensemble, ou sinon on fait des retraites, donc là par exemple la semaine prochaine on va à Ausgore, et toutes les personnes de l'entreprise sont invitées, et donc du coup on passe une semaine tous ensemble. Alors bien évidemment pendant cette semaine là le rythme de travail va un peu diminuer mais en fait on gagne au change parce qu'en fait on crée du lien, on passe des moments de vie ensemble et ça permet aussi de créer un peu cette cohésion et ça permet de tacler aussi des sujets d'entreprise un peu plus global que telle feature ou telle feature.
Terry : Ok ouais, très clair. Et du coup, je pense que ça répond bien à la question. C'est assez intéressant de voir ces modes d'organisation et puis ça a l'air de bien fonctionner, donc je trouve ça cool comme retour d'expérience. Avant d'aller vers mes deux questions phares de fin d'épisode, est-ce qu'il y a un point en particulier sur votre orgasme, sur ce dont on vient parler, que tu voudrais mettre en avant ou dont on n'a pas touché du doigt ?
Michael : En ayant discuté avec pas mal de personnes qui font du produit ou même du design, je pense que c'est le sujet maître qu'on a aujourd'hui chez Lago et je trouve ça super cool qu'on soit un produit pour les techs. Pourquoi ? Parce qu'en fait les textes sont impliqués dès le début dans les réflexions. Et je pense que ça, ça change vraiment la donne. J'avais compris ça chez Conto, mais je le comprends encore plus maintenant ici chez Lago, parce qu'en fait, comme je t'avais dit au début, on avait défini le modèle de données, toutes ces choses-là, mais en tant que produit, t'as pas la vision entière de comment les choses marchent. Et donc du coup, les personnes qui vont te dire comment les choses marchent sont les personnes qui ont construit cette chose-là. Ce sont les ingénieurs. Et je vais mettre un mot hyper fin. C'est un peu le mot de la fin pour moi. Tout est une question d'alignement et de communication avec les gens. Et si t'arrives à laisser assez d'espace aux gens pour qu'ils puissent collaborer sur un projet, ça ne peut qu'aller bien.
Terry : Ça me va bien là-dessus, donc pas complètement mot de la fin parce que je pars sur les deux dernières questions, mais mot de la fin de ton retour d'expérience avec grand plaisir de prendre ça parce que je partage totalement cette conviction. Donc pour aller sur les deux dernières questions, la première c'est est-ce que tu aurais une conviction forte avec laquelle en général tu te retrouves en désaccord avec tes pairs quand tu la partages ? Ouais, avec mes pairs... Ou des métiers connexes.
Michael : Ouais, je pense que je t'en avais partagé une, c'était un peu cette notion de design system. Alors je vais quand même mettre de la nuance aussi parce que ça peut... En gros, il y avait un énorme risque dans ce qu'on avait fait. En gros, moi je conseillerais à n'importe quelle boîte d'avoir un design system dès le début. Si et seulement si, les gens savent le faire très rapidement. Ça veut dire que ça va pas forcément... En gros, si tu mets en place un design system, ça va pas donner le produit marqué de suite. Ça ne va pas te dire que les gens aiment ton produit. Par contre, ça va te permettre d'aller plus vite pour aller trouver ton produit Marketfit si seulement tu sais le faire. Si tu ne sais pas le faire et que tu mets trois mois à le mettre en place, ça ne sert à rien. Je pense que c'est ma première conviction, c'est comment tu mets en place un cadre où tu as de la qualité dès le début. Et la deuxième, je pense que je te l'ai partagée juste avant, c'est impliquer un maximum les gens qui construisent les choses dans les réflexions. Il n'y a rien de plus frustrant de... On t'envoie des specs, on t'envoie des designs, on te dit « bon bah faut que tu développes ça », et la personne n'a pas du tout le contexte, la personne n'a jamais discuté avec les users. Donc je pense que je dirais ça, ouais.
Terry : Hyper clair, c'est vrai que tu fais bien de rappeler quand même le contexte du design system, pourquoi vous l'avez mis en place et que tu savais le faire vite. Et ça me permet aussi de rebondir là-dessus juste pour préciser que quand on a tendance, quand tu démarres pour chercher du coup ton market fit, c'est l'approche lean, de bootstrapper, de faire des choses, de bricoler des choses. En revanche, quand on a cette approche-là, Ça ne signifie pas que... Enfin, avoir cette approche ne veut pas dire ne pas faire bien les choses là où tu sais bien les faire déjà en fait. Et je pense que c'est important quand même de se le rappeler, c'est-à-dire que s'il y a des choses où t'es très bon, même si t'es plus tech, tu peux déjà mettre une archi, tu sais qui va plutôt scaler ou parce que t'as posé certaines choses, fais-le. Si ça te prend pas beaucoup de temps, ça te le fera gagner plus tard. Donc faut pas tout mettre à la poubelle, dire on fait que des trucs dégueux et puis on verra après quoi.
Michael : Il y a un autre point par rapport à ça et je pense que ça va être controversé, c'est qu'en gros le modèle où on te dit en trois semaines tu sors quelque chose de bootstrap et c'est du no code et c'est de la tuyauterie, si tu veux construire un produit aujourd'hui, j'ai l'impression que ce modèle-là n'existe plus trop parce qu'en fait le niveau de qualité global monte à chaque fois. Par exemple, hier je te parlais de Arc, qui est un browser, le niveau de qualité dès la sortie était incroyable. T'as Lineart, ils sont sortis, ils ont sorti leurs produits, le niveau de qualité était incroyable. En fait, t'as des produits qui sortent, t'as Raycast qui est sorti, le niveau de qualité était incroyable. En gros, il y a des boîtes qui sortent aujourd'hui, qui répondent à un problème, et le niveau de qualité est quand même... ils mettent en place un standard qui est quand même assez haut. Donc, dans un monde où le niveau de qualité monte, Est-ce que tu peux te permettre du coup de répondre à un problème et ton interface est pétée, il y a des bugs de partout, et qu'à côté il y a peut-être un autre produit qui fait la même chose que toi, et eux ils ont une interface qui est clean, il n'y a pas de bug. Dans un monde comme ça tu réponds à un problème, mais en fait il faut voir tout le reste qu'il y a à côté, et c'est pour ça que j'en parlais avec des gens de The Product Crew, j'ai l'impression que cette notion de MVP où tu fais du no code, quand tu fais un produit et que tu réponds à un vrai problème, je ne sais pas si tu peux vraiment le faire.
Terry : Ouais, c'est plutôt une approche... J'ai des épisodes qui vont sortir, qui ne sont pas encore sortis, autour du no-code et c'est vrai qu'on parle plutôt d'une approche POC, ça peut avoir intérêt à ce niveau-là. Donc pour tester des preuves de concept très très vite en une semaine, même dans des gros orgas avant de... Mais ensuite pouvoir passer sur un mode plus industriel et passer sur du code quand tu veux faire ton MVP. Donc là-dessus je te rejoins au moins en partie clairement. Donc pour aller vers la dernière question de notre échange, c'est un peu les ressources, les choses qui toi te nourrissent intellectuellement, que ça soit des lectures ou autre, peu importe, qu'est-ce qui t'inspire ?
Michael : J'avais écouté un podcast il n'y a pas longtemps d'une designer qui bossait chez Google. J'avais trouvé ce podcast hyper intéressant. J'avais fait le podcast aussi, c'était « Design journey » de Gauthier Zimmermann. Et en gros, dans ce podcast-là, la personne parlait un peu de son histoire de vie en tant que personne et des choses qu'elle avait vécues qui fait que ça lui a permis de devenir ce type de designer-là. Et en gros, pour être totalement honnête avec toi, aujourd'hui, je ne lis plus d'articles sur le design. Je lis de temps en temps des articles sur du product management ou même sur de la stratégie d'entreprise, de business, ces choses-là. Mais je pense que ce qui me permet aujourd'hui de pouvoir faire mon travail comme je le fais, c'est les expériences de vie. Comme je t'ai dit, pendant deux mois j'étais parti au Brésil et en Colombie. J'ai rencontré des gens là-bas, j'ai vu une manière de vivre, j'ai vu une situation politique, j'ai vu beaucoup de choses qui font que... Vu que moi je sais que je suis une éponge, ça me nourrit aussi. Et ça me permet aussi d'avoir un œil un peu plus critique, d'avoir une sensibilité à l'accessibilité. Mais pas de l'accessibilité... Les vieux, il faut qu'ils puissent lire... Enfin, les vieux, les personnes âgées doivent pouvoir lire ton application. C'est plus de l'accessibilité de... Tu as ton téléphone dehors ou je ne sais quoi. Enfin, l'accessibilité d'un point de vue usage. Et je pense que c'est ça qui me nourrit, moi, au quotidien, c'est les expériences de vie.
Terry : Ok, top. Bah, je partage aussi. T'es loin d'être le seul à me partager ce retour-là en termes de choses qui te nourrissent. Souvent, quelque chose qui revient dans les épisodes, c'est le fait que les gens échangent avec d'autres personnes, des pairs. Et c'est vrai que la communication, ça reste... Enfin, l'échange avec les personnes, ça reste quand même, je pense, un clé dans son apprentissage, peu importe le domaine.
Michael : Ouais, c'est ce que j'aime bien faire, c'est que ça m'arrive aussi, même moi des fois, de passer du temps avec des designers ou des product managers, mais totalement gratuitement en gros. Je leur dis, si vous voulez qu'on discute pendant 15 minutes, on peut le faire. Et moi, j'ai discuté avec eux, j'ai essayé de les débloquer, mais en même temps, en fait, moi, ils m'apprennent aussi beaucoup de choses sur des challenges qu'eux, ils vivent au quotidien, et potentiellement, ça me permet d'anticiper aussi potentiellement ces challenges-là dans le futur. Et je pense aussi que je suis une personne qui lit pas énormément, parce qu'en fait, en lisant, j'ai l'impression que je m'ancre dans ce cadre de lecture et j'arrive pas à réfléchir au-delà.
Terry : C'est un peu appliqué by the book, quoi. Yes. En tout cas, j'espère que cet échange sera utile pour d'autres et puis je te remercie encore pour ton temps, Michael.
Michael : Merci beaucoup Terry, pour l'invitation et j'espère que les gens vont apprécier.
