Product-market fit : arrête de construire ce dont personne n'a besoin

Imagine un fondateur assis face à un client potentiel.

Le produit fonctionne. La démo est soignée. Les fonctions d'IA font ce qu'elles promettent. Le client acquiesce, pose quelques questions pertinentes et dit une phrase que tout fondateur a déjà entendue :

« C'est vraiment intéressant. Envoyez-moi quelques informations. »

Encore une réunion prometteuse. Encore une opportunité dans le CRM. Trois semaines plus tard, rien.

Le fondateur ajoute une fonctionnalité, améliore l'onboarding et réécrit le pitch commercial. Peut-être que le produit doit juste être un peu meilleur. Ou peut-être que personne n'en avait besoin au départ.

C'est un scénario illustratif, mais la plupart des fondateurs le reconnaîtront. On confond l'intérêt du client avec l'intention d'achat, l'usage du produit avec le product-market fit, et l'activité avec le progrès. C'est la même confusion qui transforme les MQL en théâtre de leads.

L'IA rend cette confusion plus chère. Construire est devenu bon marché, donc on peut maintenant construire beaucoup avant que quiconque ait pris un engagement réel.

Dans un épisode récent de Lenny's Podcast, Rob Snyder, auteur de The Power of Pull, a détaillé son framework pour trouver le product-market fit. Lenny le présente comme quelqu'un qui a aidé plus de 50 startups à passer de zéro à 1 million de dollars d'ARR.

Son idée centrale tient en deux phrases. Trouve des gens qui doivent déjà faire bouger quelque chose et n'y arrivent pas avec leurs options actuelles. Puis regarde s'ils essaient vraiment d'acheter.

Je pense que ça dépasse largement les startups en phase de démarrage. Ça change la façon dont on devrait aborder le product management, le go-to-market et les systèmes d'IA qui les relient.

Ton plus grand concurrent, c'est la to-do list du client

La plupart des équipes produit partent des problèmes. Elles mènent des interviews clients, identifient des points de douleur, estiment des opportunités de marché et construisent des solutions. Ensuite, le marketing traduit ces solutions en propositions de valeur, et les ventes essaient de convaincre les prospects que ça les concerne.

Le processus paraît logique. Il manque juste une variable : la priorité.

Un client peut avoir un vrai problème, reconnaître que ton produit le résout et admettre qu'il offre une excellente valeur. Et n'avoir quand même aucune intention d'acheter.

Il a quinze autres choses à boucler ce trimestre. Son contournement actuel est acceptable. Le patron a exigé autre chose. Ou le problème est agaçant mais sans conséquence réelle.

Dans le framework de Snyder, la différence entre l'intérêt et une vraie demande, c'est le pull. Le pull apparaît quand une personne précise essaie déjà d'accomplir quelque chose d'important, doit le faire maintenant et trouve ses options actuelles insuffisantes.

Cette personne essaie déjà de changer. Personne n'a besoin de la convaincre que le changement est nécessaire.

Cette distinction renverse l'approche du product-market fit. La question n'est plus comment persuader plus de gens d'acheter, mais où des gens essaient déjà d'acheter quelque chose qui n'existe pas encore tout à fait.

Le framework PULL : quatre conditions pour une vraie demande

Snyder le décompose en quatre éléments.

Élément	La question
P: Project (projet)	Qu'est-ce que cette personne essaie activement d'accomplir ?
U: Unavoidable (inévitable)	Pourquoi doit-elle l'accomplir maintenant ?
L: List of options (liste d'options)	Quelles alternatives envisage-t-elle ou utilise-t-elle déjà ?
L: Limitations (limites)	Pourquoi ces alternatives ne font-elles pas le travail ?

Les quatre comptent. Un projet sans urgence devient une belle idée pour l'année prochaine. Une urgence sans limites signifie que le client peut probablement régler ça lui-même. Un meilleur produit sans projet important n'est qu'un outil de plus dont on n'a pas besoin.

Snyder donne l'exemple de Jump, un produit de prise de notes de réunion par IA pour conseillers financiers.

Les conseillers financiers doivent documenter leurs réunions clients et tenir des dossiers dans leur CRM. Snyder explique que les obligations de conformité rendent ce travail inévitable. Les outils génériques de prise de notes par IA produisent peut-être de bons résumés, mais ils ne s'intègrent pas forcément aux systèmes requis et ne répondent pas forcément aux exigences de conformité. Jump comble précisément cette lacune.

Compare maintenant avec les agents d'assurance. Eux aussi passent du temps en réunion avec des clients, et eux aussi n'aiment peut-être pas rédiger des notes. Mais dans l'exemple que décrit Snyder, ils n'ont pas la même obligation de tenir ces dossiers dans le CRM. Ne rien faire est une alternative acceptable.

Même douleur dans les grandes lignes. Workflow similaire. Comportement d'achat très différent.

C'est une leçon importante pour quiconque définit un profil client idéal.

Un secteur n'est pas ton client. Une entreprise n'est pas ton client. Une personne avec un projet inévitable est ton client.

Et les priorités actuelles de cette personne comptent plus que ta proposition de valeur soigneusement peaufinée.

L'IA a changé l'économie d'un product-market fit raté

C'est ici que je prolongerais l'argument de Snyder.

Pendant des années, construire du logiciel coûtait assez cher pour imposer une certaine discipline. Une fonctionnalité majeure demandait des développeurs, de la planification, des tests et des mois de capacité d'ingénierie.

Aujourd'hui, un fondateur compétent peut s'appuyer sur le développement assisté par IA pour produire un prototype fonctionnel en quelques jours. C'est un vrai progrès, et ça crée un nouveau piège : on commence à prendre la vitesse d'exécution pour une preuve de progrès.

Une équipe construit dix fonctionnalités, lance trois landing pages, automatise l'outbound et crée une démo soignée. La revue hebdomadaire a l'air productive. Pourtant, la question la plus importante reste sans réponse.

Qui essaie d'acheter ça, et pourquoi maintenant ?

Coder est devenu rapide. Arriver sur le marché, non. Plus précisément, le goulot d'étranglement s'est déplacé. Quand construire devient bon marché, décider de ce qui mérite d'être construit prend relativement plus de valeur. Quand j'ai écrit sur construire un produit SaaS en 90 jours, la partie difficile n'a jamais été le code. C'était de couper.

Le product-market fit ne peut plus être traité comme une phase qui vient après le développement produit. Il doit façonner le développement dès le début.

Ça veut dire que les conversations clients sont plus que des données de recherche pour les product managers. Ce sont des expériences commerciales qui testent si le client va agir. Et le signal le plus fort, c'est un achat.

Arrête d'interroger les gens sur ton idée. Teste s'ils essaient d'acheter.

Snyder recommande de commencer par ce qu'il appelle une hypothèse de pull. Avant de construire le produit, écris noir sur blanc ce que tu supposes de la situation de l'acheteur.

Voici un exemple hypothétique tiré du développement de logiciels B2B. Une VP Product est sous pression pour livrer une release majeure ce trimestre. Son équipe utilise Jira, des outils de documentation et des assistants de code IA, mais les décisions produit importantes ne se retrouvent pas toujours dans le travail d'implémentation. La release est menacée, et ajouter des développeurs ne réglera pas forcément le problème de coordination.

L'hypothèse devient :

• Projet : Livrer une release promise sans perdre d'exigences critiques entre produit et ingénierie.
• Inévitable : La release a une échéance promise à l'extérieur.
• Options : Plus de réunions, plus de product managers, une meilleure documentation, les intégrations Jira existantes et les outils de code IA.
• Limites : Ces options peuvent améliorer des tâches isolées sans garder de façon fiable décisions, tickets et implémentation alignés.

Remarque ce qui manque. Pas de liste de fonctionnalités, pas de grande vision produit, pas de pitch sur la magie de l'IA. Juste une personne précise, un projet important et une raison pour laquelle les méthodes existantes ne marchent pas.

C'est le genre d'hypothèse qui vaut la peine d'être testée pour un produit comme Teklens, que j'ai cofondé : un Product Brain partagé, une mémoire unique pour les humains et les agents IA, qui relie conversations produit, Jira et code.

Mais ça reste une hypothèse. L'acheteur concerné ne considère peut-être pas le problème comme urgent. L'équipe le gère peut-être déjà assez bien. Ou le vrai acheteur est un CTO qui prépare un audit, plutôt qu'une VP Product qui pilote une release.

La discovery sert justement à le vérifier.

Snyder recommande de montrer aux clients potentiels une description simple du projet, de l'urgence et des limites, suivie d'une explication conceptuelle de la façon dont tu pourrais aider. Puis observe ce qu'ils font.

Certains demandent un plan de mise en œuvre, font venir un collègue, lancent les achats ou demandent quand ils peuvent commencer. D'autres te félicitent pour ta vision et promettent de rester en contact. Ce sont des signaux très différents.

Une promesse d'achat orale est encourageante. Un engagement payant est plus fort. Une adoption et une rétention réelles le sont encore plus.

Cinq conversations de vente peuvent t'apprendre plus que cinq semaines de développement

L'une des recommandations les plus utiles de Snyder est de travailler en petits cycles de discovery. Pars d'une hypothèse. Trouve les bonnes personnes. Mène environ cinq conversations. Fais le point sur ce que tu as appris.

Si personne n'essaie d'avancer, ne réserve pas automatiquement cinquante réunions de plus. Change l'hypothèse. Peut-être que le problème est réel mais pas urgent. Peut-être qu'il appartient à la mauvaise personne. Peut-être que les outils existants suffisent déjà. Ou peut-être que tu as découvert un autre projet qui compte bien plus.

Snyder appelle l'une des façons de le découvrir la question Hail Mary :

« Y a-t-il sur ta to-do list une tâche dont tu paierais quelqu'un pour te débarrasser tout de suite ? »

C'est une question simple, et bien plus utile que de demander quelles fonctionnalités quelqu'un aimerait voir. Elle fait passer la conversation des opinions sur le produit aux vraies priorités.

Les gens sont généreux en feedback sur des produits qu'ils n'ont aucune intention d'acheter. Ils passeront volontiers une heure à dessiner ta roadmap. Ils ne la financeront simplement pas.

Snyder est particulièrement sceptique envers les partenariats avec des design partners qui génèrent beaucoup de feedback mais peu d'engagement commercial.

Je n'écarterais pas complètement les design partners. Dans des environnements B2B complexes, le co-développement peut révéler des contraintes d'intégration, des réalités de workflow et des exigences organisationnelles qui resteraient sinon invisibles. Mais le test commercial compte toujours. Un design partner devrait avoir un vrai projet, un critère de succès défini et un chemin crédible pour devenir client payant. Sinon, tu as peut-être recruté un conseiller produit serviable plutôt qu'un acheteur.

Vends le résultat avant de construire la plateforme

Il y a une autre implication que l'IA rend particulièrement intéressante. Tu n'as pas toujours besoin d'un logiciel fini pour tester la demande. Si un client a besoin qu'un travail précis soit fait, tu peux parfois livrer le résultat avec un mélange de personnes, de logiciels existants et d'automatisation.

Snyder décrit des fondateurs qui commencent par des offres en forme de service avant de développer le logiciel sous-jacent.

Imagine une entreprise qui doit réduire son cycle d'études de marché de plusieurs semaines à quelques jours. La première version pourrait combiner des chercheurs équipés d'outils d'IA, des contrôles qualité manuels et une interface de reporting simple. L'acheteur obtient le résultat. Le prestataire apprend quelles étapes se répètent. Ensuite, l'équipe automatise ces étapes. C'est l'ordre dans lequel travaille un forward deployed engineer : cartographier d'abord le vrai processus, puis automatiser ce qui se répète.

Ça inverse la séquence traditionnelle. L'ancienne : construire le logiciel, trouver des clients, espérer qu'ils l'utilisent. La nouvelle : trouver un travail urgent, vendre le résultat, le livrer, apprendre le workflow, puis automatiser ce qui se répète.

C'est particulièrement pertinent pour les entreprises B2B nativement IA. Mais il y a un risque. Si chaque client exige une implémentation différente, tu n'as pas forcément trouvé un produit scalable. Tu as peut-être construit une société de conseil avec un excellent outillage. J'ai écrit sur l'endroit où passe cette ligne, et sur la voie médiane honnête du produit plus services, dans agence de services vs business de produit logiciel.

La discipline consiste à séparer le cœur reproductible du travail sur mesure qui l'entoure. Facture le résultat tôt. Apprends ce qui est réutilisable. Transforme le travail récurrent en produit. Ne confonds pas cinq projets clients sans lien avec le product-market fit.

Le product-market fit ne s'arrête pas quand les clients achètent

Un client qui veut acheter d'urgence peut quand même partir. Peut-être que le produit ne marche pas comme promis. Peut-être que l'implémentation est trop compliquée. Peut-être que le projet immédiat de l'acheteur se termine, et que le produit n'est plus nécessaire.

Snyder propose de penser le parcours client en deux étapes. Avant l'achat, tu dois trouver quelqu'un pour qui acheter est une évidence. Après l'achat, tu dois identifier le moment où partir n'aurait plus de sens.

Ce deuxième moment est plus utile que de fêter des taux d'activation. Une connexion ne prouve pas grand-chose. Un client qui accomplit une tâche qui bloquait autrefois son activité est un bien meilleur signal.

Pour un produit qui relie exigences, tickets et code, ce moment pourrait être une équipe qui repère un écart important avant qu'il n'arrive en production, puis le résout avec le bon contexte. Pour un système GTM, ce pourrait être un commercial qui reçoit un signal d'achat exploitable qui se serait sinon perdu entre le CRM, les réunions et les e-mails.

Ce sont des hypothèses à tester, pas des métriques d'activation universelles. La question opérationnelle est :

Que doit vivre un client avant que le produit lui manque vraiment s'il disparaissait ?

Ensuite, construis l'onboarding à rebours à partir de ce moment.

Dirige ton entreprise comme une usine à études de cas

Vers la fin de l'interview, Snyder introduit une idée que je trouve plus utile que l'acronyme PULL lui-même : vois ton entreprise comme une usine qui produit des histoires de réussite client reproductibles.

Il parle de résultats clients qui se répètent, client après client. Les études de cas marketing avec des logos léchés et des pourcentages suspects, c'est autre chose.

Chaque client qui réussit suit à peu près le même schéma. Une personne précise a un projet urgent. Ses options actuelles ne suffisent pas. Elle achète quelque chose qui aide. Elle obtient le résultat voulu. Elle reste parce que la solution garde sa valeur.

Ton entreprise devient un système pour répéter ce schéma :

1. Trouver le bon acheteur.
2. Comprendre le projet urgent.
3. Prouver une solution crédible.
4. Obtenir un engagement commercial.
5. Livrer le résultat promis.
6. Atteindre une valeur durable.
7. Retenir, apprendre et recommencer.

Ce modèle mental relie product management, ventes, marketing et customer success autour d'une seule définition du succès. Il change aussi ta façon de penser la croissance.

Si le pipeline est le goulot d'étranglement, améliore ta façon de trouver des acheteurs similaires. Si les clients ont des projets urgents mais n'achètent pas, examine l'offre, la crédibilité, le processus commercial ou les contraintes d'achat. S'ils achètent mais ne restent pas, améliore la livraison et le time to value, ou vérifie si la demande initiale est reproductible.

Le focus change avec la contrainte. C'est bien plus utile que de demander à chaque département d'améliorer tous ses KPI en même temps.

Là où le contexte commun devient l'infrastructure manquante

C'est là que je vois un lien avec les systèmes que nous construisons autour du produit, du GTM et de l'IA.

Imagine qu'un client dise aux ventes que sa plus grande priorité est de réduire les retards de release. La discussion produit des éléments utiles sur l'urgence, les solutions existantes, les blocages, le budget et les personnes impliquées.

Dans beaucoup d'organisations, cette information reste dans un enregistrement d'appel ou une note CRM. Le produit reçoit une demande de fonctionnalité privée de son contexte d'origine. Le marketing crée un message générique sur les points de douleur. Le customer success reçoit une checklist d'onboarding, mais pas le résultat business que le client attend. Puis on demande à un agent IA de préparer une relance à partir des fragments qu'il arrive à récupérer.

Tout le monde travaille. Chacun a des informations différentes.

L'usine à études de cas de Snyder exige quelque chose de plus cohérent. Les mêmes éléments clients devraient nourrir la décision produit, la promesse commerciale, le plan de mise en œuvre et le jalon de rétention. Personne n'a besoin de lire un document énorme pour ça. Chaque personne et chaque agent a besoin des éléments pertinents au moment où il décide.

C'est le principe derrière Get Multiplayer : Les humains fixent les objectifs, décident et valident. Les agents préparent et prennent en charge les tâches répétitives. Objectifs communs et contexte commun tiennent le travail ensemble.

Par exemple, un agent peut extraire d'une conversation de vente le projet en cours d'un client et ses alternatives. Un autre peut comparer ces exigences avec le backlog produit. Un troisième peut préparer un plan d'onboarding basé sur le résultat promis.

Mais les humains doivent toujours vérifier les éléments et décider de ce qu'ils signifient. Sinon, tu automatises simplement des suppositions. Plus vite. À grande échelle.

Là où je ne suis pas d'accord : le pull seul ne garantit pas une belle entreprise

Le framework de Snyder est particulièrement utile parce qu'il force l'honnêteté commerciale. Mais ce n'est pas une théorie complète de la construction d'entreprise.

Un client peut avoir une vraie urgence et représenter quand même un très mauvais marché. Peut-être que le projet n'arrive qu'une fois tous les cinq ans. Peut-être que l'acheteur n'a aucun pouvoir de dépense. Peut-être que la livraison coûte plus que le contrat. Peut-être que le problème a énormément de valeur mais ne se pose que dans trop peu d'organisations.

Un pull fort valide une opportunité précise. Il ne valide pas automatiquement la taille du marché, des marges attractives, une distribution reproductible ou la capacité à se défendre.

En B2B enterprise, la distinction entre une personne qui veut la solution et une organisation qui peut l'acheter est particulièrement importante. Le champion a peut-être du pull. La sécurité, le juridique et les achats ont quand même leurs propres exigences.

C'est pourquoi je vois le framework PULL comme un complément à un processus de vente enterprise bien mené, pas comme un remplacement. Et c'est pourquoi la rétention compte autant que l'intention d'achat initiale.

Tu as besoin de trois niveaux de preuve :

• Demande : Les gens essaient-ils d'acheter en urgence ?
• Valeur : La solution produit-elle un résultat qui compte pour eux ?
• Économie : Peux-tu répéter ce résultat de façon rentable chez assez de clients ?

C'est seulement quand ces trois niveaux se renforcent mutuellement qu'une opportunité excitante commence à ressembler à une entreprise scalable.

Un playbook pratique pour le product-market fit

Si je lançais un nouveau produit B2B lundi prochain, j'organiserais le premier cycle autour de sept activités.

1. Choisis une personne, pas un marché. Identifie le rôle, la responsabilité et la situation où le besoin a des chances d'être urgent. « SaaS mid-market » est trop vague.
2. Écris une hypothèse PULL. Documente le projet, le pourquoi maintenant, les options existantes et pourquoi ces options échouent. Distingue clairement les suppositions des preuves clients confirmées.
3. Rapproche-toi du travail. Observe les vrais workflows, les réunions clients, les outils et les passations. Les interviews aident, mais regarder quelqu'un se débattre avec une vraie tâche peut révéler ce qu'il oublie de mentionner.
4. Mène cinq conversations commerciales. Pose des questions sur les projets en cours, les échéances, les solutions déjà tentées et les étapes d'achat. Montre juste assez d'une solution proposée pour tester s'ils avanceraient.
5. Cherche l'action, pas l'enthousiasme. Un diagnostic payant, une commande signée, un engagement commercial ou un processus d'achat lancé par le client sont des preuves plus fortes qu'un retour positif.
6. Livre le résultat et trouve le moment de rétention. Travaille au plus près des premiers clients. Identifie l'événement qui prouve une valeur durable, puis place cet événement au centre de l'onboarding.
7. Transforme l'apprentissage en système reproductible. Injecte les preuves validées dans le positionnement, les priorités produit, la qualification commerciale et l'onboarding. Trouve le prochain goulot d'étranglement et améliore-le.

L'IA peut aider à chaque étape. Elle peut analyser des appels, regrouper des schémas, comparer des options, produire des prototypes, préparer des propositions, documenter les apprentissages et automatiser le travail de livraison répétable.

Ce qu'elle ne peut pas faire, c'est fabriquer une priorité client urgente là où il n'y en a pas. C'est pourquoi le rôle humain reste essentiel : décider si les preuves justifient le prochain investissement.

Construis moins. Apprends ce qui mérite d'être construit.

J'ai commencé avec un fondateur qui avait une démo soignée et un prospect qui avait promis de revenir vers lui.

La réaction typique, c'est d'améliorer le produit, d'envoyer une relance de plus et d'augmenter le volume de prospection. Parfois, c'est exactement ce qu'il faut. Parfois, la prochaine étape la plus précieuse, c'est d'admettre que tu essaies de vendre quelque chose que personne n'essaie d'acheter en urgence.

Rob Snyder nous donne un moyen pratique de faire la différence. L'IA nous donne la capacité d'agir sur cet apprentissage beaucoup plus vite. La combinaison fonctionne, à condition d'utiliser la technologie dans le bon ordre.

Trouve le projet urgent. Prouve que le client va agir. Livre le résultat. Rends-le reproductible.

Trouve d'abord les clients pour qui ça vaut la peine de construire. Ensuite, laisse l'IA te rendre rapide.

Si tu veux une note d'opérateur par semaine sur le produit, le GTM et l'IA, abonne-toi à la newsletter The Science of GTM.

D'après la conversation de Rob Snyder avec Lenny Rachitsky dans Lenny's Podcast, An 86-minute guide to finding PMF, publiée le 25 octobre 2026 (écouter sur Snipd). Le livre de Rob Snyder : The Power of Pull, John Murray Business, 2026. Le framework PULL, la question Hail Mary et l'usine à études de cas viennent de Snyder. La lecture pour le produit, le GTM et l'IA ainsi que les prolongements pratiques sont les miens.