Croissance & Stratégie

Pourquoi j'ai refusé un projet de plateforme à $XX,XXX (et ce que j'ai dit au client à la place)


Personas

SaaS et Startup

ROI

À court terme (< 3 mois)

L'année dernière, un client potentiel m'a approché avec ce qui semblait être un projet de rêve : un budget substantiel pour construire une plateforme de marché à deux faces. Le défi technique était excitant, l'argent était bon, et cela aurait été l'un de mes plus grands projets à ce jour.

J'ai dit non.

Non pas parce que je ne pouvais pas livrer, mais parce que je me suis rendu compte qu'ils étaient sur le point de commettre la même erreur coûteuse que j'ai vue tant de startups faire : confondre la construction de fonctionnalités avec la validation de la demande.

Le client est venu vers moi, excité par les outils d'IA et les plateformes sans code, convaincu qu'il pouvait "tester son idée" en construisant une plateforme complète. Ils n'avaient pas d'audience existante, pas de base de clients validée, pas de preuve de demande - juste de l'enthousiasme et un budget.

Voici ce que vous apprendrez de cette expérience :

  • Pourquoi votre premier MVP devrait prendre des jours, pas des mois, à construire

  • L'approche contre-intuitive de la priorisation des fonctionnalités qui fonctionne réellement

  • Comment valider la demande avant d'écrire une seule ligne de code

  • Le cadre que j'utilise pour aider les clients à éviter l'embonpoint coûteux des fonctionnalités

  • Des exemples réels de validation manuelle qui ont économisé des millions en coûts de développement

Il ne s'agit pas d'être anti-technologie ou anti-construction. Il s'agit d'être intelligent avec les ressources et de construire des choses que les gens veulent réellement.

Réalité de l'industrie

Ce que chaque fondateur de startup croit au sujet des MVPs

Entrez dans n'importe quel accélérateur de startup ou faites défiler Product Twitter, et vous entendrez les mêmes conseils répétés comme un évangile :

  • "Construisez rapidement, échouez rapidement" - Expédiez votre MVP rapidement pour obtenir des retours d'utilisateurs

  • "Commencez par les fonctionnalités essentielles" - Identifiez les 3 à 5 fonctionnalités essentielles et construisez celles-ci en premier

  • "Itérez en fonction des données" - Laissez le comportement des utilisateurs guider votre feuille de route des fonctionnalités

  • "La dette technique est acceptable" - Ne vous souciez pas de la scalabilité pour l'instant, concentrez-vous sur la validation du concept

  • "Utilisez des outils sans code/IA pour avancer plus vite" - Profitez des outils modernes pour construire sans développement approfondi

Ces conseils ne sont pas faux - ils sont juste incomplets. Le problème est que la plupart des fondateurs interprètent "construire rapidement" comme "construire immédiatement." Ils omettent l'étape cruciale de valider si quelqu'un veut réellement ce qu'ils prévoient de construire.

La sagesse conventionnelle suppose que vous avez déjà identifié un véritable problème et confirmé que les gens paieront pour le résoudre. Mais voici la réalité : la plupart des startups échouent non pas parce qu'elles ont construit les mauvaises fonctionnalités, mais parce qu'elles ont construit des fonctionnalités pour un problème que personne ne se souciait suffisamment pour payer.

Le résultat ? Les fondateurs passent des mois à construire des solutions élégantes à des problèmes qui n'existent pas, puis se demandent pourquoi leur MVP parfaitement exécuté n'a aucune traction. Le véritable problème n'est pas la priorisation des fonctionnalités - c'est la distribution et la validation de la demande.

Qui suis-je

Considérez-moi comme votre complice business.

7 ans d'expérience freelance avec des SaaS et Ecommerce.

Lorsque ce client potentiel m'a contacté pour construire leur marketplace à double sens, tout semblait parfait sur le papier. Ils avaient fait leurs devoirs - recherché le marché, identifié des points de douleur, même esquissé des flux d'utilisateurs. Le budget était substantiel, et ils étaient enthousiastes à l'idée d'utiliser des outils modernes d'IA et sans code pour construire rapidement.

Mais leur déclaration fondamentale révélait le problème de base : "Nous voulons voir si notre idée vaut la peine d'être poursuivie."

Ils n'avaient pas d'audience existante, pas de base de clients validée, pas de preuve que des gens recherchaient activement cette solution. Juste une idée et l'hypothèse que s'ils le construisaient suffisamment bien, les utilisateurs viendraient.

Cela m'a rappelé un schéma que j'avais vu à plusieurs reprises dans mon travail de consultant. Les clients arrivaient avec des spécifications détaillées, convaincus que le principal défi était l'exécution technique. Ils passaient des semaines à débattre pour savoir s'il fallait inclure une fonctionnalité de chat, combien de types d'utilisateurs soutenir, ou quelles intégrations de paiement construire.

La conversation allait toujours dans le même sens : "Nous devons tester si notre idée de marketplace fonctionne. Pouvez-vous nous construire un MVP avec des profils d'utilisateurs, de la messagerie, des paiements, des filtres de recherche et un système de notation ? Nous voulons lancer dans 3 mois et voir si nous obtenons de l'adhésion."

J'avais appris de projets précédents que cette approche était à l'envers. La plateforme la plus belle et la plus riche en fonctionnalités au monde est inutile si vous ne parvenez pas à obtenir des utilisateurs des deux côtés de la marketplace. Et vous ne pouvez pas résoudre le défi d'acquisition d'utilisateurs en ajoutant plus de fonctionnalités.

C'est à ce moment-là que j'ai réalisé : ils n'essayaient pas de construire un MVP, ils essayaient de construire un produit entièrement fonctionnel et l'appelaient un MVP. La vraie validation ne nécessite pas de fonctionnalités complexes - elle nécessite d'abord de prouver qu'une demande existe.

Mes expériences

Voici mon Playbooks

Ce que j'ai fini par faire et les résultats.

Au lieu de prendre leur argent et de construire ce qu'ils demandaient, j'ai partagé quelque chose qui les a initialement choqués : "Si vous testez vraiment la demande du marché, votre MVP devrait prendre un jour à construire - pas trois mois."

Voici le cadre que j'ai recommandé à la place :

Jour 1 : Créez votre "MVP"
Au lieu de construire une plateforme, créez une simple page de destination ou un document Notion expliquant votre proposition de valeur. Incluez un moyen pour les gens d'exprimer leur intérêt ou de s'inscrire pour un accès anticipé. Cela teste si votre message résonne.

Semaine 1 : Contact manuel
Commencez à contacter des utilisateurs potentiels des deux côtés de votre marketplace. Ne demandez pas s'ils utiliseraient "théoriquement" votre produit. Demandez s'ils ont ce problème en ce moment et ce qu'ils font actuellement pour le résoudre.

Semaine 2-4 : Mise en relation manuelle
Lorsque vous trouvez des personnes ayant le problème et des personnes pouvant le résoudre, connectez-les manuellement par email ou WhatsApp. Facilitez la transaction vous-même. Cela prouve que l'échange de valeur est possible et vous aide à comprendre les vrais points de friction.

Moins 2 : Élargir le processus manuel
Ce n'est qu'après avoir prouvé la demande et réalisé plusieurs transactions manuelles que vous devriez envisager de construire de l'automatisation. Maintenant, vous savez exactement quelles fonctionnalités sont importantes parce que vous avez fait le processus manuellement.

L'insight clé : Votre MVP devrait être votre processus marketing et de vente, pas votre produit.

Je leur ai expliqué comment les marketplaces réussies ont réellement commencé. Les fondateurs d'Airbnb prenaient manuellement des photos des annonces et géraient le service client. Uber a commencé avec un simple système SMS. Ce n'étaient pas des limitations techniques - c'étaient des stratégies de validation intelligentes.

Pour leur idée spécifique de marketplace, j'ai tracé un plan de validation sur 30 jours :

  1. Créer une simple page "Bientôt disponible" avec leur proposition de valeur

  2. Trouver 20 fournisseurs potentiels et 20 acheteurs potentiels

  3. Faciliter manuellement 5 transactions réussies

  4. Documenter chaque point de friction et chaque plainte d'utilisateur

  5. Ce n'est qu'alors que vous déciderez quelles fonctionnalités construire en premier

Cette approche répond aux vraies questions : Les gens en veulent-ils ? Vont-ils payer pour cela ? Quels sont les vrais obstacles au succès ? Et surtout, pouvez-vous acquérir des utilisateurs avant de construire des fonctionnalités complexes ?

Demander d'abord

Validez que les gens veulent réellement votre solution avant de construire des fonctionnalités. Les processus manuels révèlent le comportement réel des utilisateurs.

Réalisme de Distribution

La plupart des startups échouent en matière d'acquisition d'utilisateurs, et non des fonctionnalités du produit. Résolvez d'abord manuellement le problème de "l'obtention d'utilisateurs".

Validation Manuelle

Utilisez le courrier électronique, WhatsApp ou des outils simples pour faciliter l'échange de valeur fondamental. Cela révèle les fonctionnalités qui comptent réellement.

Minimalisme Fonctionnel

Construisez la chose la plus petite possible qui prouve votre hypothèse de base. Tout le reste est une optimisation pour un problème que vous n'avez pas encore validé.

Le client a d'abord résisté, préoccupé par le fait que les processus manuels ne pourraient pas "s'adapter" et que les concurrents pourraient avancer plus rapidement avec une plateforme complète. Mais j'ai partagé des exemples d'entreprises réussies qui avaient utilisé cette approche.

La Réalité : Trois mois plus tard, ils ont découvert par validation manuelle que leur marché cible initial n'était pas prêt à payer suffisamment pour rendre l'entreprise viable. Mais ils ont également découvert un segment de marché adjacent qui avait un point de douleur beaucoup plus fort.

Au lieu de passer des mois à construire des fonctionnalités pour le mauvais marché, ils ont pivoté rapidement et trouvé l'adéquation produit-marché dans une niche complètement différente. Le processus manuel leur a coûté quelques semaines au lieu de mois de développement.

Cela a renforcé ma croyance fondamentale : À l'âge de l'IA et du no-code, la contrainte n'est pas de construire - c'est de savoir quoi construire et pour qui. Les outils ont rendu le développement plus facile, mais ils ont également rendu plus facile de construire rapidement la mauvaise chose.

Les fondateurs les plus réussis avec lesquels je travaille passent maintenant 80 % de leur temps à valider et 20 % à construire, et non l'inverse. Ils traitent chaque décision de fonctionnalité comme une hypothèse à tester, pas comme une exigence à mettre en œuvre.

Learnings

Ce que j'ai appris et les erreurs que j'ai commises.

Pour que vous ne les fassiez pas.

  1. La validation manuelle révèle la demande réelle - Vous ne pouvez pas feindre l'enthousiasme lorsque les gens doivent agir réellement

  2. Les défis de distribution apparaissent tôt - Vous découvrirez des problèmes d'acquisition d'utilisateurs avant d'investir dans des fonctionnalités

  3. Les points de friction réels deviennent évidents - Les utilisateurs vous diront ce qui compte réellement lorsqu'ils essaient d'accomplir des tâches

  4. Les priorités des fonctionnalités se clarifient naturellement - Lorsque vous facilitez les transactions manuellement, les fonctionnalités essentielles deviennent évidentes

  5. Les coûts de pivotement chutent dramatiquement - Changer de direction coûte des semaines au lieu de mois lorsque vous n'avez pas construit de systèmes complexes

  6. Le retour du marché se produit immédiatement - Vous obtenez des données de comportement utilisateur réelles, pas des réponses à des sondages ou des opinions de groupes de discussion

  7. L'allocation des ressources s'améliore - Vous investissez du temps de développement dans des fonctionnalités qui impactent directement les besoins validés des utilisateurs

La plus grande leçon : La priorisation des fonctionnalités est un symptôme d'un problème plus profond. Si vous débattez sur les fonctionnalités à développer en premier, vous n'avez probablement pas validé la demande correctement. Commencez par le marché, pas par les fonctionnalités.

Comment vous pouvez adapter cela à votre entreprise

Mon playbook, condensé pour votre cas.

Pour votre SaaS / Startup

Pour les startups SaaS qui mettent en œuvre cette approche :

  • Créez une solution « alimentée par » qui livre manuellement votre valeur essentielle

  • Utilisez des outils existants (Zapier, Airtable, email) pour simuler votre plateforme

  • Concentrez-vous sur la preuve d'un flux de travail clé avant de construire l'automatisation

  • Validez les prix en demandant des engagements de paiement à l'avance

Pour votre boutique Ecommerce

Pour les entreprises de commerce électronique appliquant ce cadre :

  • Tester la demande avec des précommandes ou des listes d'attente avant de créer des fonctionnalités complexes

  • Utiliser des outils simples pour valider les concepts de marché ou de plateforme

  • Curater manuellement des recommandations de produits avant de construire des systèmes d'IA

  • Valider les modèles d'abonnement via la facturation manuelle avant l'automatisation

Obtenez plus de Playbooks comme celui-ci dans ma newsletter