Product Inbox 📬 Focus #16 - Comment faire du Produit en pré-Product/Market Fit (vs post-Product/Market Fit)
Par des top PMs d'Intercom, Comet, June, Younited, Matcha & co
Après avoir lu cette édition, ce serait super que tu prennes 30 secondes pour me dire ce que tu en as pensé :)
👉 Comment as tu trouvé cette édition ?
Hello 👋, bienvenue dans cette 16ème édition Focus de Product Inbox ! On est désormais 8759 sur cette newsletter. Merci pour ta lecture et ton soutien 💛.
Je m’appelle Timothé et si ce n’est pas déjà fait, tu peux :
Améliorer ta visibilité en sponsorisant la newsletter Product Inbox
Trouver ton prochain job Product avec notre programme Stellar
Faire décoller ta progression via notre programme de mentoring
Écouter mon podcast Clef de voûte
Me suivre sur Linkedin
🚨 Je donne désormais la possibilité à des produits et services de sponsoriser Product Inbox pour continuer à la faire vivre. Pour découvrir les offres, ça se passe ici :
Introduction
En mai dernier, j’ai été invité à animer un talk au plus gros événement Product FR : LaProductConf.
Pour ma 1ère venue en tant qu’animateur, j’ai voulu mettre en avant un sujet aussi complexe que clivant - faire du Produit dans une boîte pré-Product/Market Fit (pré-PMF) vs dans une boîte post-Product/Market Fit (post-PMF).
Et je n’ai pas choisir ce thème par hasard.
J’ai remarqué que les Product Managers sont constamment à l’affût de nouvelles méthodes et frameworks.
Et si certains PM n’utilisaient pas les bonnes ?
En janvier dernier, un post Linkedin de Enzo Avigo m’a mis la puce à l’oreille. Je réalise que la plupart des bonnes pratiques Product ne s’appliquent pas correctement aux boîtes pré-PMF.
Ni une, ni deux, j’ai tout de suite voulu en parler. Et le talk de la LPC était l’opportunité parfaite (encore merci aux orga de la LPC 💛).
En 45 minutes de talk, on a poncé le sujet avec mes 3 invités :
Et je vais te confier quelque chose :
Ce talk m’a mis une claque (encore une). Car mes 3 invités ont dégainé une tonne d’apprentissages. Forcément, après avoir jonglé entre des boîtes pré-PMF et post-PMF (et pour certains des expériences entrepreneuriales), ils ont enchaîné les erreurs. De quoi en faire un échange riche en conseils concrets que je suis trop content de te partager aujourd’hui.
Speakers
Valentine Ducharme, Senior Product Manager chez Soil Capital. Elle a notamment été 1ère Product Manager de MiiMOSA (post-PMF) et Matcha (pré-PMF).
Enzo Avigo, CEO de June. Il a été PM post PMF dans des entreprises comme Intercom, N26 et Zalando.
Olivier Courtois, cofondateur de Beep (pré-PMF). Olivier a été VP Product de Comet, qui a atteint une phase de PMF et l’a reperdu par la suite. Il a aussi été 3ème PM de ManoMano jusqu'au poste de Directeur Produit (post-PMF). Olivier est également le créateur de la newsletter Productverse (que je vous recommande vivement).
Et pour couronner le tout, 150 passionnés ont rempli les gradins des Folies Bergères à Paris pour suivre ce talk. 🥹
Comme le nombre de places de cet événement était limité (et que je suis contre le cloisonnement de la connaissance), j’ai décidé de te partager l’intégralité de l’échange dans cette nouvelle édition Focus.
J’y ai même intégré les questions de l’audience (et les réponses qui vont avec).
Tout ça dans une édition costaud.
Un conseil : parcours d’abord les questions du sommaire ci-dessous pour repérer celles qui t’intéressent. Et prends le temps de dévorer les réponses à tes challenges :)
J’en profite pour remercier Valentine, Olivier, Enzo, tous les organisateurs de la LPC (Amandine, Céline, Hugo) et les participants. 💛
NB : pour une lecture simplifiée, je me suis permis de retravailler les échanges en essayant rester le plus proche possible des réponses originales de mes invités.
Si tu préfères, tu peux directement regarder le talk sur Youtube 📺 :
Lors de cet événement, on a creusé le sujet via 4 questions :
Quelle est la différence entre faire du Produit pré-PMF et post-PMF ?
Quels sont les pièges à éviter en pré-PMF ?
Comment adapter sa manière de faire du produit pour lancer des nouveaux produits dans une boîte mature ?
Quel profil doit s’occuper du Produit en pré-PMF ?
Et l’audience en a posé 5 :
Une fois le PMF atteint, qu'est-ce qu'on doit changer ?
En pré-PMF, si on ne fait pas de roadmap, comment fait-on pour se donner un cap ?
A quel moment faut-il s’atteler à réduire la dette technique ?
Comment on peut activer le No-code dans une boîte post-PMF ?
A partir de quand faut-il impliquer un Product Marketer pour trouver le PMF ?
Les points principaux à retenir 🧠
En pré-PMF → peu d’utilisateurs. Il faut prendre des paris risqués et fréquents. Les techniques de boîtes post-PMF ne marchent pas en pré-PMF. En post-PMF, le PM est “dérisqueur”.
En pré-PMF → création de dette technique pour plus tard. En post-PMF → nettoyage de la dette technique créée en pré-PMF.
Pièges à éviter en pré-PMF : se poser trop de questions ; trop écouter ses utilisateurs ; ne pas faire confiance à son intuition ; pivoter trop souvent ; figer trop longtemps sa roadmap dans le temps ; sortir trop de fonctionnalités ; vouloir trop préserver le temps des développeurs.
Pour lancer un nouveau produit en post-PMF : créer du storytelling autour du produit ; négocier de l’autonomie ; pouvoir prendre des risques ; pouvoir exécuter rapidement ; commencer avec une mini squad ; éviter les roadmap ; éviter la politique.
Il faut éviter d’être PM en pré-PMF. Mieux vaut laisser les founders chercher le PMF. Mieux vaut être 2nd PM que 1er PM.
Une fois PMF trouvé → bosser la rétention. Les metrics initiales se dégradent car le produit passe des early-adopters au marché mainstream. Nécessaire de booster l’acquisition.
En pré-PMF, sans roadmap → on peut documenter un mission statement ou des principes pour garder le cap.
Réduire la dette technique progressivement. Imposer un rythme mensuel.
No-code est pratique pour vérifier une value prop. A éviter pour scaler un produit.
Beaucoup de produits gagnent via la distribution → PMM grosse valeur early-stage.
A. Les questions du talk 🎙️
1/ Quelle est la différence entre faire du Produit pré-PMF et post-PMF ?
Valentine Ducharme
1ère différence : quand tu es pré-PMF, tu as peu ou pas d'utilisateurs. En tant que PM, on a l'habitude de se poser des questions et d'itérer avec nos utilisateurs. Parfois ils ne sont simplement pas là. Donc il faut faire sans.
2ème différence : quand tu es pré-PMF, tu crées de la dette pour les autres plus tard. Et quand tu es post-PMF, c'est toi qui la nettoie. En tant que PM, on a tous pensé à un moment “mais qu'est-ce qu'ils ont foutu, pourquoi ils ont fait ça comme ça ?”
Mais quand tu es pré-PMF, tu crées de la dette technique et c'est incompressible. Parce que tu prends des décisions en faisant du mieux que tu peux. Avec les informations que tu as à ce moment-là.
Olivier Courtois
En pré-PMF, on ne sait pas encore si ça va marcher. Une fois sur deux, on ne sait pas ce qu'on fait. La différence majeure c’est : “on a tout à gagner et rien à perdre”.
Puisqu'on part de zéro, on n'a pas le temps. Il faut mettre le peu de temps d'engineering et d'exécution qu'on a à profit pour débloquer des hypothèses. Puis faire des paris forts pour essayer d'avoir les signaux les plus clairs possibles. Le but ? S’assurer qu’on va dans la bonne direction. Le corollaire de ne pas avoir d'utilisateurs, c'est de ne pas avoir des signaux clairs. Il faut prendre les paris les plus audacieux en allant le plus vite possible. Et oublier le product management traditionnel.
Enzo Avigo
A titre personnel, je suis d’abord passé dans des boîtes post-PMF. Ensuite, j'ai trouvé un problème et je me suis dit “ça va être super de monter ma boîte”.
Et là, quand tu crées ta boîte, le premier truc qu'on te demande, c'est d'apporter une compétence spécifique. J’avais cette vision parfaite du Product Management et je considérais que je savais le faire. Du coup, j'allais apporter cette compétence à ma boîte. Et je me suis pris mur après mur.
Ça faisait 7 ans que j'étais à fond dans les lectures. À apprendre tout ce qui existe sur le product management. Très vite, je me suis rendu compte que mes techniques ne marchaient pas.
Si vous me suivez sur LinkedIn, je tape assez fort là-dessus pour faire passer le message (ndlr : un exemple de post d’Enzo ici). En réalité, je vais être un peu plus nuancé, il y a plein de choses à apprendre dans les méthodes post-PMF, pré-PMF et vice versa. Par contre, il y a des différences fondamentales.
La notion de risque est très intéressante. Dans une boîte post-PMF (qui a un business model, une clientèle, une production de valeur et des canaux de distribution identifiés), le plus gros risque qui puisse arriver, c'est de perdre les utilisateurs de vue. Dans ce type d’environnement, le PM va s’assurer que les feedbacks utilisateurs remontent. Il va aussi s’assurer de ne pas les perdre de vue en continuant à leur parler. En fait, le PM a pour rôle de “dérisquer” dans les boîtes post-PMF.
Alors que dans les boîtes pré-PMF, c'est lui qui doit prendre les risques. Si on dépile juste la roadmap qu'on a définie il y a 6 mois, c'est très compliqué d'atteindre le PMF. Il faut plutôt prendre des grands paris de manière fréquente pour aller trouver sa proposition de valeur.
2/ Quels sont les pièges à éviter en pré-PMF ?
Valentine Ducharme
Avant de rejoindre Matcha (pré-PMF), ma façon de penser en tant que PM était de me poser la question « what should happen ? » (ndlr : “vers quoi on devrait aller ?”).
En parlant avec les fondateurs, je me suis rendue compte que ce n’est pas la bonne question à se poser. D'ailleurs ce n'est pas même une question. C’est une affirmation. À la place, il faut se dire “make it happen”. Car la dynamique à suivre est plutôt, “vas-y, fonce, essaie quelque chose, fais-le vraiment”.
Il faut arrêter de se poser trop de questions. Le piège du produit, c'est qu'on se pose tout le temps des questions du type “quel est ton problème ?” C'est trop bien de se poser ces questions-là, mais ce n'est pas le bon moment.
Mon conseil en pré-PMF : quand tu as une idée (ndlr : une grosse idée), suis-la. Parfois, ton idée ne provient même pas des discussions avec les utilisateurs.
Par exemple, chez Matcha (ndlr : où Valentine a été la 1st PM), on n'a pas trouvé notre PMF et on a décidé d'arrêter l'aventure. On est tombé dans ce piège où, au début, on avait un design partner (ndlr : un premier client pour co-construire la solution). On l'écoutait vachement. Et à chaque rendez-vous commercial, on réécoutait tout puis on remettait tout en question. Du coup, on n'arrêtait pas de faire de petits pivots. Au final, on a fini par se perdre. Et on n'arrivait pas à voir si ce qu’on faisait marchait ou pas. C’est pour ça qu’on a mis 6 mois à arrêter. Ça aurait dû durer beaucoup moins longtemps.
Olivier Courtois
6 mois à l’échelle d’une vie de start-up en pré-PMF, c’est énorme. Il faut aller très vite.
Personnellement, le piège dans lequel je tombais, c'était d'aller parler aux utilisateurs trop tôt. J’ai pris conscience que c’est une pratique à suivre dans les boîtes post-PMF mais moins dans les boîtes pre-PMF. On a aussi un peu perdu l'habitude de faire confiance à son intuition. D’essayer de trouver son angle et de se dire “Ok, on a une intuition, il faut aller la chercher”.
Pour amener du contexte, j’ai monté une start-up qui développe une application sociale de communication pour les teenagers. Donc, on est moins dans l'idée d'aller chercher un problème précis, comme pour June. On n’a pas de problème précis où on se dit “Comment on l'analyse et comment on va travailler dessus pour trouver de la plue-value ?” On est plus dans quelque-chose qui est de l'ordre d'une “vibe”, d'un truc qui doit résonner. Évidemment qu'il y a une utilité et que ça doit résoudre des problèmes. Mais ça va bien au-delà. En ce sens, je me suis rendu compte qu’on ne pouvait pas aller voir les utilisateurs sans quelque-chose à leur faire tester. Donc, je leur parle mais uniquement quand on exécute. D'où l'importance d'exécuter et d'être plus rapide qu'une période de 6 mois parce que sinon, on n’apprend rien de très intéressant. Donc un des pièges que j’évite à présent, c'est de parler aux utilisateurs avant d’avoir quelque chose à leur faire tester.
Enzo Avigo
En B2B, le grand learning, c’est qu’il n'y a pas besoin d'être un visionnaire. Tu parles à tes utilisateurs et tu demandes s'ils sont prêts à payer pour régler le problème. S'ils disent oui, tu le vérifies en le construisant. Si c'est un marché intéressant, tu y vas.
Par exemple, les frères Collison (ndlr : les fondateurs de Stripe) ne se positionnent pas comme des visionnaires mais comme des problem-solvers. Et nous, pour le coup, on suit beaucoup plus cette approche.
Le risque principal que je vois en pré-PMF, c'est de figer trop longtemps dans le temps ta roadmap. Je questionne même d’avoir une roadmap à ce stade (ndlr : Olivier et Valentine n’ont pas utilisé de roadmap en pré-PMF non plus). Nous n’avons pas de roadmap chez June. Ça fait flipper tout le monde et les investisseurs en premier. Parfois les clients nous regardent en nous demandant “vous savez où vous allez au moins ?”. Il faut apprendre à maîtriser ta communication.
Il y a ce symptôme en pré-PMF de penser qu'il vous manque une fonctionnalité pour avoir une bonne rétention et un début de Market/Fit. Ce n’est pas tout à fait faux. Car un produit est un ensemble de features et en les assemblant, tu peux avoir un bon produit.
Mais il y a la tentation de rajouter toujours plus de choses. Ce qui te fait tourner autour du problème. Une manière de déconstruire ça, c’est d'être capable de se re-challenger de manière fréquente sur ce que vous êtes en train de construire. Et donc, ça peut passer encore une fois par des actes un peu extrêmes. Typiquement, ne plus avoir de roadmap (ou alors des roadmaps à la semaine). Nous, on fait des cycles au mois. On prend les cycles de 6 semaines ShapeUp, on les amène à 4 semaines. Donc, clairement, c'est le chaos.
Refaire une priorisation toutes les 4 semaines, c'est beaucoup de boulot. Les plannings/sprints sont à la semaine. Ça marche pour nous mais ça ne marche pas pour tout le monde. Comme toutes les règles en Product.
C'est important d'être capable de ne pas avoir un document qu’on ne peut pas toucher (type roadmap ou stratégie). Parce que c'est souvent ça qui coûte très cher. Mais ne rien documenter fait extrêmement peur. Parce que se rechallenger en permanence, ça crée un déséquilibre dans la boîte. Les gens qui bossent en start-up ont souvent l'impression de ne jamais avoir pied. C'est pour ça que tout le monde n'est pas fait pour ces métiers-là.
Valentine Ducharme
Un autre piège à éviter est relatif au développement. Parfois, je me suis rendue compte que ça coûtait moins cher de développer. Quand tu viens du post-PMF, tu essaies tout le temps de faire gagner du temps à tes développeurs. C’est la ressource rare. Alors qu’en pré-PMF, c’est le PM qui fait perdre du temps et qui coûte le plus cher.
A un moment chez Matcha, on voulait tester d'intégrer notre solution dans Salesforce via un plug-in. Le développeur m'a dit : “on prend 2h, on le fait ensemble et c'est fini. Il n'y a pas besoin que tu fasses un wireframe ou quoi que ce soit”. Et ça, pour moi, ça a été un vrai changement de mentalité. Je me suis rendue compte que ça coûtait moins cher de développer directement.
Enzo Avigo
Ce truc de “Le PM accélère l'équipe de développement versus il la ralentit”, c’est hyper vrai. En pré-PMF, tu dois justifier pourquoi tu es là. Certains disent qu'il faut même attendre le PMF avant de recruter son premier PM.
Valentine Ducharme
Je pense que quand tu es PM, la tentation va être d'essayer de se substituer au founder. En fait, avant même le PMF, c'est le Founder/Market Fit qu'il faut trouver.
Personnellement, je préfère à présent rejoindre des entreprises qui ont trouvé leur PMF, mais qui sont toujours early-stage. Pour pouvoir au moins se dire qu’on parvient à attirer des gens. Maintenant, qu'est-ce qu'on fait de ça ? Comment on leur apporte de la valeur ? Comment on les retient ?” Et ça, c'est passionnant pour un PM.
3/ Comment adapter sa manière de faire du produit pour lancer des nouveaux produits dans une boîte mature ?
Valentin Ducharme
Je conseillerais d'avoir un espace dédié. Parce que lancer de nouveaux produits en restant au sein de l'organisation actuelle, c’est dur. Ça met des mois et des mois. Ce n'est pas du tout la bonne approche, on n'est pas capable de foncer comme ça. Il faut essayer de négocier une petite équipe dédiée, une équipe en mode commando. Idéalement, il faut même des gens du métier. Pas juste des ingénieurs, des PM et designers. On avait quelqu'un du marketing qui était dédié avec nous chez Younited (pour lancer un produit de coaching budgétaire) et ça nous a énormément aidé.
Dans une entreprise existante, c'est important de créer un storytelling autour de ce nouveau produit. Parce qu’en chiffre d'affaires, ça ne rapporte rien au début. Donc, il faut réussir à générer de l'enthousiasme en interne. Le revers de la médaille, c'est que tu peux un peu trop t'attacher à ta solution. C'est aussi un piège à éviter.
Olivier Courtois
Chez ManoMano, je l’ai fait à quelques reprises. Si je devais le refaire, je m'assurerais d’avoir de l’autonomie, d'être complètement hors process. Il faut s’assurer d’utiliser la stack qu'on veut, s’assurer qu’on ne veut pas utiliser l’issue tracker commun à toutes les équipes.
Pour contraster, pendant très longtemps chez Beep, on n'avait même pas de tickets. Car on considérait que c'était une perte de temps. On préférait faire ce que tu as décrit, de dire qu’on prend deux heures, on parle, on se met dans la même pièce et on avance.
Quand on est dans une organisation plus mature, c'est compliqué de justifier que l’on ne va pas utiliser les mêmes outils. On ne va pas non plus mesurer la performance de la même manière. Et donc en fait, si vous êtes dans la position de lancer un nouveau produit dans une organisation plus mature, je vous conseillerais de :
Négocier de l'autonomie
Négocier de la latitude pour prendre des risques et être encouragé à aller vers ça (puisque tout le reste de l'organisation est averse au risque)
Commencer à être dans une exécution hyper rapide.
Le petit défaut que je vois dans ces organisations-là (ndlr : les entreprises matures), c'est qu'on a trop de moyens.
Quand vous êtes PM et que vous avez 5-6 développeurs, vous êtes en train de les occuper. Vous n'êtes plus en train de vous poser des questions profondes.
Vous devriez commencer avec 2 ou 3 personnes : une mini squad. Parce que c'est comme ça que vous allez aller vite. Pas de roadmap ni tous les trucs qui ne sont pas utiles à cette étape-là. Et ça, il faut le négocier en amont. Parce que si ça ne l’est pas, plein de problèmes vont naître.
En startup early-stage, on a un unfair advantage : notre calendrier est vide. On n'a pas de meeting. Perso, je n'en ai pas un seul par semaine. Alors que dans une boîte établie, vous n'allez pas réussir à négocier ça. Vous allez forcément avoir des points d'alignement ou d’autres meetings. Il faut négocier au moins le reste. Sinon, ça va être très compliqué.
Enzo Avigo
Chez Zalando (un gros e-commerce fashion), ils ont plein de cellules d'innovation. Ils vont créer ces petites squads. Toute la boîte est en micro-services. Donc, globalement, des dizaines d'APIs dans lesquelles vous pouvez taper. C'est assez pratique. Si vous voulez être une petite équipe et innover, il y a toute l'infrastructure derrière. Ça fonctionne bien.
Le truc que j'ai vu dans ces boîtes, c'est plutôt une espèce d'alignement stratégique. Au-dessus de nous on avait un bouclier. On avait quelqu'un qui était là depuis 10 ans, qui était super implanté dans la boîte et qui avait un peu serré toutes les mains dans l’entreprise en disant « Bon, laissez-nous 3 ans, ça va prendre du temps. Si on perd, on aura perdu quelques millions. Si on y arrive, on va révolutionner la manière dont les gens font du commerce avec les points de collecte.” Et je pense que c'est vraiment ça l'apprentissage.
Si tu dois exécuter, parler à des clients, avoir des inspirations, délivrer, faire en sorte qu'il n'y ait pas trop de blocages avec les autres équipes et qu’en plus, tu dois faire de la politique, ça devient très compliqué.
4/ Quel profil doit s’occuper du Produit en pré-PMF ?
Olivier Courtois
Si tu veux faire du pré-PMF dans une startup, je pense qu’il ne faut pas y aller en tant que PM. C’est trop tôt. Les PM, on va les embaucher plus tard. Il vaut mieux être fondateur. Car en tant que PM, généralement, tu n'as pas les mains libres, tu n'as pas toute la capacité à décider. Et tu vas probablement ralentir l'effort.
Enzo Avigo
Je suis d'accord à 90% sur ce que vient de dire Olivier. Je pense qu'il y a quand même une condition pour laquelle il faut un PM en pré-PMF : si les founders ne sont pas capables de faire du Product. Il y a des superbes équipes avec un rôle très commercial et un rôle beaucoup plus tech et personne ne sait vraiment faire du produit. Souvent, ils l'admettent. Ils lèvent un peu plus d’argent et ils paient le salaire d’un PM. Parce qu’admettre qu’il n’y a pas la compétence du tout en interne et prendre quelqu’un pour rafistoler plutôt que de ne rien avoir, ça peut être un moindre mal.
Olivier Courtois
J’ajoute juste un bémol : pour moi, c'est valable si les fondateurs ont été au combat, ont souffert et s’ils ont fait l'effort de faire la user research. Parce que dès lors qu'on met des interfaces, on se déconnecte du terrain en tant que founder. Et c'est important d'essayer de se former, voire d'être accompagné avant le recrutement d’un 1er PM. Il existe aujourd’hui plein de freelance fractionnés ou de coach comme moi. Uniquement dans ce cas là, le recrutement d’un PM va être hyper bénéfique.
Valentine Ducharme
L’article « Why you want to be the second first PM » résonne exactement avec cela. On n'a pas envie d'être le premier PM. Parce qu’en tant que 1er PM, tu fais les frais de toutes les questions des fondateurs. Tu as plutôt envie d'être le deuxième premier PM quand le premier est parti ou qu’il s’est fait viré (haha).
B. Les questions de l’audience 👨👨👦
1/ Quand on a atteint le Product/Market Fit, qu'est-ce qu'on doit changer ?
Valentin Ducharme
Une fois que tu as trouvé ton PMF, la question à se poser c'est la rétention. C'est là où tu vas changer ton regard. Tu as ce potentiel de valeur qui marche, qui excite les gens. Et il faut le concrétiser. Tu peux commencer par poser la question qui a été théorisée par Superhuman : “si on vous enlevait l'accès à ce produit, est-ce que vous seriez hyper déçu, pas déçu ?” Et regarder l'usage, la fréquence de l'usage, etc.
Enzo Avigo
Après le PMF, c'est là où tu commences à bourriner sur l'acquisition. C'est le moment que les américains appellent “cross the chasm” (ndlr : “traverser le gouffre” en anglais). Tu quittes ton marché d'early-adopter pour basculer sur ton marché mainstream. Et c'est là que toutes tes métriques se pètent la gueule, parce que ton marché d'early-adopter t’aime beaucoup plus que ton marché de late-adopter. C'est le moment où il faut retravailler tes fondamentaux.
Un exemple, c'est Facebook et Instagram : la différence est énorme entre le produit qu’on a utilisé et le produit que nos parents utilisent. Aujourd'hui, chez Facebook ou Insta, il y a des équipes qui repensent tout le produit pour les utilisateurs plus seniors. Parce que le produit de base avait une rétention mauvaise chez les adultes plus seniors.
Il y a aussi l'expansion de revenus. Il faut vraiment se dire “à quel moment je rajoute une culture ? Est-ce que je la monétise ? Est-ce que je rajoute des lignes de business ?” C'est là que tu crées des business unit, qu’interviennent les coûts de overhead. Et je pense que c'est une question d'essayer jusqu'à ce que tu trouves la bonne sauce pour toi, il y a plein de littérature là-dessus. (ndlr : un exemple par Enzo)
2/ En pré-PMF, si on ne fait pas de roadmap, comment fait-on pour se donner un cap ?
Enzo Avigo
Tu peux donner de la liberté aux gens que s’il y a des guidelines et une direction. C'est comme tes enfants, les enfants bien éduqués, tu t'en fiches de ce qu'ils font le week-end, tu leur fais confiance. Tu n'es pas obligé de planifier à six mois, d'avoir une roadmap stricte. Par contre, il faut un cadre. Je pense que le minimum, c’est un mission statement, un vision statement ou un semblant de product strategy (décrite sur une page Google Docs ou autre). Nous, c'est ce qu'on fait et ça marche bien parce que du coup, les gens restent dans le carcan.
Olivier Courtois
On avait écrit un document sous forme de principes (Building Principles document de Beep). On s’était dit que c’était plus simple de raisonner en suivant les principes auxquels on croit. Ce document-là, je l'avais écrit au tout début mais il est déjà complètement caduc. Et les principes, c'était à la fois les Do’s et les Dont’s. Dans les Dont’s, on indiquait les trucs qui ne nous intéressent pas et les trucs qui pourraient être trop cool, mais qu'on ne fera pas.
Ça nous permet de donner ces fameuses guidelines pour travailler avec efficacité. A présent, on l’utilise beaucoup plus à l'oral qu'à l'écrit pour être honnête.
3/ A quel moment faut-il s’atteler à réduire la dette technique ?
Valentine Ducharme
Je vais surtout parler de dette produit. À un moment donné, tu prends la décision comme tu peux la prendre. Si tu sais sciemment que tu es en train de créer de la dette, ce n'est pas bon.
Chez Matcha, on se posait toutes les quatre semaines (ndlr : pour revoir la dette produit). À partir du moment où on ajoutait plusieurs features, on se demanda it s’il y avait un besoin de product refactoring.
Le bon moment c’est quand tu commences à sentir que tu as un patchwork plutôt qu'un produit. Quand cette sensation arrive, il faut s’y atteler, même si ça prend un peu de temps.
La dette technique, c'est un autre sujet. Chez Matcha, le cofondateur et CTO ne transigeait pas sur l'architecture. Encore moins sur la data. Dans des stades très early comme ça, tu as besoin d'un tech lead qui a un lead très fort.
Olivier Courtois
Et ce tech lead doit savoir faire la part des choses entre les problèmes du présent et ceux du futur. Clairement, tu crées beaucoup de dettes et c'est bien. Il faut le faire parce que ce serait complètement absurde de surinvestir quand on va cutter tous les trucs qu’on vient de passer un mois à mettre dans les mains des gens.
4/ Comment on peut activer le “No-code” sur du post-PMF ?
Valentine Ducharme
La question que tu te poses avec l’utilisation du No-code est différente selon la phase. Quand tu es en pré-PMF, tu vas essayer de chercher quelle la valeur tu peux délivrer. En post-PMF, si tu veux utiliser ces outils, tu peux le faire en te posant la question “comment je peux mieux connecter les utilisateurs à la valeur que j’apporte ?”
Et là, le No-code prend énormément de sens parce que ce sont des cycles d'expérimentation hyper rapides.
Enzo Avigo
Pour vérifier une proposition de valeur, le No-code est une super idée. Il ne faut juste pas que le No-code te mette dans un cul de sac, qu’il t'empêche de passer à l'étape d'après.
Si tu dois tout refaire, il faut plutôt commencer avec un prototype full code tout petit pour avoir une première pièce. Puis construire plutôt que de devoir déconstruire pour reconstruire.
C’est un problème que j’ai vu plein de fois chez des startups qui commencent avec des apps type Bubble. Ce sont de super outils. Mais c’est compliqué d’aller très loin avec ces outils-là. À un moment il faut tout reconstruire en code.
Olivier Courtois
Je crée une social app, donc c'est ultra expérientiel. Il y a zéro No-code. On est obligé d'avoir une qualité d'expérience. Les gens n'ont aucune patience. Pour une app mobile, ne serait-ce qu'une milliseconde d’attente, les gens, ils se barrent. Le No-code, on l’utilise à côté de l’app. Par exemple, pour notre système d'information où on utilise beaucoup Zapier.
5/ A partir de quand faut-il impliquer un Product Marketer pour trouver le PMF ?
Olivier Courtois
La plupart des produits aujourd'hui gagnent par la distribution. Donc par le positionnement, la distribution, le growth. Si tu as la chance d’avoir un PMM avec toi, implique-le le plus tôt possible.
Par exemple, on fait des apps mobiles, et ça prend du temps à développer. Du coup, on fait des vidéos TikTok pour tester le Message Market/Fit. Ce n’est pas aussi bien que tester le vrai produit, mais cela nous aide à voir les impasses super vite. J’aurais été heureux d'avoir un Product Marketeux le plus tôt possible.
Enzo Avigo
Chez Intercom où je travallais avant, le Product Marketing fait partie de l'équipe produit. Il intervient sur la phase de brainstorming, de scoping et de messaging. C'était dingue. parce que dans la salle, il y a quelqu'un qui dit “OK, c'est bien ce cahier des charges avec toutes les fonctionnalités, mais moi, je ne sais pas comment celle-ci, je vais la marketer. Et celle-ci, vous êtes en train d'enlever du scope. D'accord, elle règle un peu moins un problème pour l'utilisateur, mais moi, celle-ci, je peux vraiment la marketer.” Et ça crée des discussions hyper pertinentes. C’est un des secrets d’Intercom, d’intégrer le Product Marketing dans l’équipe Produit. Dans les faits, ce n’est pas courant. En Europe, on a toujours un coup en retard sur les US. Je pense que c’est une bonne chose à faire.
🪐 Pour aller plus loin
Mon talk dont est extraite cette édition sur Youtube
How to find Product Market Fit - Product Dave
Product Inbox 📬 Focus #4 - Etre 1er Product Manager d'une boite
💫 Qu'est-ce que Stellar ?
J’ai cofondé Stellar pour accompagner les dirigeants de startups à faire de leur Produit un moteur de croissance inarrêtable.
Et pour activer cette croissance, on a créé :
Un collectif de 12 CPO des meilleures boîtes tech (Zenly, Yousign, BlaBlaCar)
Des formats d’intervention rapides (moins d’une semaine)
Des solutions concrètes à actionner dans la foulée.
Résultats : vous améliorez vos metrics business, votre vitesse d’exécution et la qualité de votre Produit.
Nous avons accompagné 40 clients depuis notre lancement (Zeliq, Edusign, Predict4health, Jaji,…).
Notre ambition : vous faire atteindre vos objectifs business et positionner votre produit en leader de son marché.
Envie de travailler ensemble ?
Pour me soutenir :
Si l’édition t’a plu, ce serait super que tu la partages 🙏
Timothé