Faites des choses qui ne passent pas à l’échelle (2013)

 (paulgraham.com)
3 points par GN⁺ 2025-08-17 | 1 commentaires | Partager sur WhatsApp
  • Y Combinator conseille aux fondateurs, au début, de faire activement des choses qui ne passent pas à l’échelle
  • Des startups à succès comme Stripe ou Airbnb ont choisi une approche directe et offensive pour recruter leurs premiers utilisateurs
  • La plupart des startups sont très fragiles au départ, et les efforts concrets des fondateurs sur le terrain sont au cœur de la croissance
  • Offrir aux premiers utilisateurs une expérience exceptionnelle et une grande satisfaction est essentiel pour la croissance à long terme
  • Au stade initial, le travail manuel, l’attaque d’un marché de niche et le conseil direct sont souvent plus efficaces que l’automatisation

Introduction : la réalité de la croissance d’une startup

  • Beaucoup de futurs fondateurs pensent qu’une startup croît d’elle-même, mais en réalité, les fondateurs doivent eux-mêmes allumer l’étincelle de la croissance
  • Comme avec les anciennes manivelles de démarrage des voitures, une phase très intensive en travail manuel est indispensable au début

Recruter directement des utilisateurs (Recruit)

  • La plupart des startups ne doivent pas attendre passivement que les utilisateurs arrivent, mais faire l’effort d’aller les chercher elles-mêmes
  • Dans le cas de Stripe, il y avait au début une méthode surnommée "Collison installation" : après avoir présenté la bêta à quelqu’un, ils prenaient directement son ordinateur portable pour y installer le produit, une stratégie agressive d’acquisition utilisateur
  • Si les fondateurs hésitent à faire ce genre de choses, c’est à cause de la peur du rejet, de la honte et de la tendance à sous-estimer un petit nombre d’utilisateurs
  • En réalité, avec l’effet de la croissance composée, même une croissance hebdomadaire de 10 % peut mener à plusieurs millions d’utilisateurs au bout de deux ans
  • Airbnb aussi a été assez proactive pour aller directement voir des hôtes à New York et les aider à s’inscrire

La fragilité des startups au début (Fragile)

  • Presque toutes les startups sont très instables au départ, et quelques efforts directs à court terme peuvent faire la différence entre réussite et échec
  • Plus que l’indifférence des commentateurs extérieurs ou des investisseurs, le vrai danger est de sous-estimer soi-même la valeur de son entreprise
  • Au début, il faut se demander non pas « cette entreprise va-t-elle changer le monde ? », mais « jusqu’où peut-elle grandir si nous faisons les bons efforts ? »
  • Les débuts de Microsoft et Airbnb, par exemple, paraissaient eux aussi très modestes en apparence, alors qu’ils étaient sur la meilleure trajectoire possible
  • Il faut partir d’utilisateurs qui vous ressemblent, ou identifier parmi les premiers utilisateurs le groupe le plus passionné et concentrer ses efforts sur lui

Maximiser la joie des utilisateurs (Delight)

  • Au-delà du recrutement, il faut fournir des efforts extraordinaires pour offrir une satisfaction exceptionnelle aux utilisateurs existants
  • Wufoo a construit la confiance de ses débuts avec un service spectaculaire, allant jusqu’à envoyer des lettres de remerciement manuscrites à chaque nouvel inscrit
  • Il ne faut pas se laisser enfermer par les standards du service client des grandes entreprises, mais mettre en avant une expérience personnalisée qu’une startup naissante est seule à pouvoir offrir
  • Si le fait de rendre les premiers utilisateurs heureux devient si fréquent qu’il est difficile de suivre, c’est au contraire un signe de croissance encourageant
  • Le manque d’expérience des fondateurs en service client est aussi l’une des raisons pour lesquelles ils n’exploitent pas pleinement l’avantage concurrentiel propre aux petites entreprises

L’obsession de l’expérience utilisateur (Experience)

  • Comme dans l’expression de Steve Jobs, « insanely great », il faut au début développer une véritable obsession pour l’expérience utilisateur
  • Plus que de viser d’emblée un produit parfaitement fini, il est plus important de l’améliorer à travers les interactions avec les utilisateurs, même s’il est encore imparfait
  • Le feedback obtenu au contact direct des utilisateurs a l’impact le plus fort sur la croissance

Commencer par un marché étroit (Fire)

  • Comme Facebook ou Airbnb, il peut être stratégique de commencer délibérément sur un marché minuscule (par exemple les étudiants de Harvard) afin d’atteindre une masse critique à l’intérieur de ce groupe
  • Au début, il est souvent plus efficace de trouver le groupe d’early adopters qui réagit le plus vite
  • Des programmes d’accélération comme YC peuvent aussi être utiles pour aborder un marché où les autres startups deviennent les clients

Stratégies particulières des startups hardware (Meraki)

  • Les startups hardware ont des coûts initiaux élevés de production en série ; c’est pourquoi, comme Meraki ou Pebble, les fondateurs assemblent eux-mêmes les produits au début
  • En fabriquant directement, ils apprennent de manière empirique à optimiser le design et à se procurer les composants

Une approche extrême des utilisateurs comme du conseil (Consult)

  • Pour un produit B2B, on peut le concevoir sur mesure pour un seul client, comme dans une mission de conseil, puis s’étendre ensuite aux marchés adjacents
  • C’est en s’alignant complètement sur le problème dont le client a réellement besoin qu’on trouve souvent le début d’une trajectoire de croissance
  • Au début, on peut aussi utiliser soi-même le logiciel à la place du client ou intégrer immédiatement les fonctionnalités nécessaires

La stratégie du tout manuel (Manual)

  • Tant que le nombre d’utilisateurs est faible, il est possible de traiter le travail manuellement, puis de passer progressivement à l’automatisation
  • Stripe a d’abord géré l’« ouverture instantanée de compte » à la main pour transmettre cette expérience utilisateur
  • Au lieu de s’obséder d’emblée sur l’automatisation, il faut d’abord comprendre les vrais problèmes du produit et des clients par le travail manuel

L’inefficacité du « grand lancement » (Big)

  • Les stratégies qui consistent à faire un lancement massif d’un seul coup ou à confier sa croissance à un partenariat avec une grande entreprise échouent généralement
  • Au début, il faut se concentrer sur l’acquisition d’un petit nombre d’utilisateurs, et les efforts intenses ainsi que les méthodes directes comptent davantage
  • L’attention des utilisateurs se construit lentement, et la croissance vient d’un suivi direct et d’une forte satisfaction fournie aux utilisateurs

Une approche bidimensionnelle de l’idée de startup (Vector)

  • Une startup qui réussit doit être pensée comme un vecteur : le produit (que construire) + la stratégie non scalable (quelles actions faire soi-même au début)
  • Cette action directe des débuts laisse une influence positive dans l’ADN du produit
  • Les efforts directs du départ se transforment avec le temps en produit et en culture d’entreprise, devenant le moteur d’une croissance durable

À lire aussi

1 commentaires

 
GN⁺ 2025-08-17
Avis Hacker News

  • Il y a une idée entendue récemment dans un podcast qui m’a vraiment parlé : le plus gros problème des startups, c’est l’inertie. Le monde ne nous aime pas particulièrement et ne ressent pas vraiment le besoin de nous... c’est à nous d’inverser ça. Il faut créer l’élan entièrement à partir de zéro, et le vrai travail important du fondateur consiste à mener des actions qui renversent cette inertie. C’est presque littéralement un phénomène physique. Le monde est à l’arrêt, et nous devons produire nous-mêmes l’élan initial, comme lorsqu’on démarre un moteur. Vu sous cet angle, il n’a rien d’étrange à faire au début des choses qui ne passent pas à l’échelle. On n’est pas en train d’optimiser une machine déjà en marche ; on en est au stade où l’on fait tourner les pièces une par une pour que le moteur démarre vraiment. Le point de Paul Graham, c’est que la croissance scalable ou l’automatisation viennent après. En allant voir les utilisateurs un par un, de façon manuelle, on apprend réellement ce qui fonctionne. C’est un processus qui accumule des preuves que les utilisateurs nous considèrent comme nécessaires, tout en démontrant ce qui mérite d’être mis à l’échelle

    • À mon avis, la vraie valeur du travail manuel, c’est l’apprentissage direct. L’un de mes clients sélectionnait lui-même chaque semaine les actualités financières et boursières importantes pour en faire une liste éditorialisée. C’était une niche dans une niche, et les utilisateurs adoraient ça. Puis, à un moment, il a voulu tout automatiser ; le contenu est devenu plus abondant mais moins sélectif, des informations de type spam ont commencé à s’accumuler, la valeur s’est évaporée, et finalement le produit lui-même a suivi la même pente. Il y avait plus d’actualités, mais sans sélection ni édition humaine, le ratio signal/bruit s’est dégradé. En pratique, le travail manuel avait bien plus de valeur, même avec un périmètre limité. Beaucoup d’entreprises ne le comprennent pas et s’obsèdent trop tôt avec l’automatisation. Autre exemple : j’avais un client qui vérifiait manuellement les prix de ses concurrents. Il voulait automatiser ça, donc je lui ai créé un petit scraper basé sur Excel. Au début, il était satisfait, mais il a fini par se rendre compte qu’en n’explorant plus directement les sites concurrents, il passait à côté d’apprentissages sur les nouveaux produits, les tendances de catalogue, etc. Il a finalement recommencé à faire cette exploration à la main, et n’a gardé le scraper que pour une analyse simple des prix. Pourtant, la plupart de mes autres clients continuent de se concentrer davantage sur l’automatisation que sur l’essence du produit et du problème, et ratent ainsi des occasions d’apprentissage essentielles

    • C’est pour ça que « fabriquez quelque chose que les gens veulent » est devenu un adage du monde des startups

    • J’aime beaucoup l’expression « renverser l’inertie », mais cette approche ne s’applique pas à toutes les startups. D’après le framework Arc de Sequoia, il existe trois approches : Hair on Fire (douleur urgente, où l’élan est décisif), Hard Fact (la douleur existe, mais il faut changer des habitudes), et Future Vision (les gens ne croient pas encore que la chose soit possible, il faut donc d’abord bâtir la confiance). Obtenir des résultats en faisant soi-même des choses non scalables est indispensable dans les domaines Hair on Fire, mais pour les autres, il faut plutôt reconfigurer la réalité elle-même ou construire d’abord une crédibilité forte

  • Ma théorie se divise en trois étapes : Not Scaling (avant l’échelle), Scaling (mise à l’échelle) et Antiscaling (phase où l’on devient détestable). Not Scaling, c’est la phase où l’on construit son propre moat sur le marché. Scaling, c’est le moment où le produit est devenu assez populaire pour que les clients en amènent d’autres, et où il ne reste plus qu’à absorber la demande croissante avec des serveurs supplémentaires ou du sharding de base de données. Antiscaling, c’est quand on se transforme en entreprise symptomatique des problèmes du web moderne. Les services de renseignement vous contactent à cause de l’usage de votre plateforme par des terroristes, et les mairies ou les gouvernements créent directement des licences ou des lois de régulation pour vous cibler. Le fondateur devient célèbre, fait l’objet de mèmes, et on peut même suivre ses déplacements. Pas besoin de dominer le monde ; il suffit de gagner de l’argent. Ceux qui prétendent vouloir changer le monde produisent rarement de bons résultats, donc l’important est simplement de fabriquer quelque chose d’utile

    • « Il suffit de gagner de l’argent » me fait penser à la loi de Goodhart : quand une métrique (par exemple le revenu) devient l’objectif, elle cesse d’être une bonne mesure

    • Cette vision me paraît trop biaisée. Elle ne traite pas de l’indifférence extrême qu’on rencontre lorsqu’on fabrique quelque chose que personne ne veut. Et en réalité, le cas le plus fréquent est plutôt celui d’un petit succès très ordinaire : personne ne déteste, mais personne n’adore non plus. C’est légèrement positif, mais sans hype ni avantage concurrentiel exclusif, et au fond personne n’y prête vraiment attention

  • Je laisse ci-dessous quelques liens parce que j’aimerais rassembler davantage d’exemples similaires

  • Je partage ce texte parce que j’aimerais le recommander à tous les fondateurs en phase de démarrage et à tous ceux qui rejoignent très tôt une startup. Nous avons dépassé les 15 personnes et nous continuons pourtant à appeler directement chaque nouvel inscrit. Les raisons sont : 1) comprendre comment il nous a découverts, 2) voir s’il a besoin d’aide pour démarrer, 3) faire passer, implicitement, l’idée que notre équipe s’en occupe personnellement. Notre service est une plateforme B2B, donc ça fonctionne probablement encore mieux, et même si notre public est composé de développeurs, dès qu’ils comprennent que « non, ce n’est pas un appel commercial », on reçoit souvent des retours très francs et très utiles

  • Beaucoup critiquent Paul Graham, mais ce texte peut en substance se résumer à : n’optimisez pas trop tôt. Autrement dit, ne vous comportez pas comme une grande entreprise. Quand le fondateur fait lui-même l’opérationnel, même de façon inefficace, il accumule de l’expérience concrète et du feedback ; et en n’adoptant pas immédiatement une solution scalable, il peut aussi obtenir plus vite des retours. C’est également efficace pour construire une différenciation propre. Je pense que ça vaut la peine de garder littéralement en tête cette idée de « faire des choses qui ne passent pas à l’échelle »

    • Il arrive souvent qu’on construise très tôt des systèmes excessivement scalables, par peur que le service ne s’effondre sous un surcroît de popularité ou de demande, alors qu’à ce stade il n’y a en réalité aucun besoin. J’ai pourtant l’impression que le scale vertical (ajouter simplement plus de ressources) est très sous-estimé. Injecter davantage de ressources dans un backend monolithique existant peut déjà donner le temps de mieux comprendre son service. Surtout, cela pousse à reconsidérer quelle est la « valeur cœur » que les utilisateurs aiment réellement dans le produit. Et si les utilisateurs aiment vraiment le produit, ils tolèrent au début quelques limites de performance. Aux débuts de Twitter, le « fail whale » apparaissait souvent, mais le service a quand même connu une croissance explosive parce que la fonctionnalité désirée était bien là. Au départ, tout repose sur le feedback rapide, l’itération et la satisfaction client. Avant la scalabilité viennent l’expérimentation, la discussion avec les utilisateurs et l’observation. On se préoccupe de scaling quand le moment semble venu, et ce moment est imprévisible. La technologie n’est qu’un outil ; même avec un violon d’exception, il faut d’abord faire de la bonne musique

    • Il faut aussi se souvenir que toutes les entreprises qui réussissent ne ciblent pas des centaines de millions ou des milliards d’utilisateurs. Je travaille sur des outils internes, et l’échelle de notre environnement est déjà connue, peu sensible aux performances, sans trafic irrégulier. Pourtant, un membre de l’équipe s’est un jour obstiné à réécrire tout le code dans un langage que lui seul connaissait pour gagner seulement quelques millisecondes. Personne ne s’en souciait, et tout ce qu’il avait construit ne laissait qu’un risque de maintenance. Quand il est parti, son travail a été intégralement abandonné sur décision du management ; avec une conception plus simple et plus lente, la reprise par d’autres aurait été bien plus facile

    • « Optimisation prématurée » et « Do Things That Don’t Scale » sont légèrement différents. La première suppose qu’une version scalable est « optimale », tandis que le second suggère qu’une manière non scalable peut au contraire être la meilleure. Par exemple, le fait que le CEO gère lui-même les prises de contact peut être bien meilleur qu’une boîte de réception partagée qui traite tout indistinctement. La méthode scalable (le formulaire de contact) n’est pas optimale dès le départ ; en réalité, c’est une dégradation de la qualité du processus. Le scaling n’est pas mauvais en soi, mais il apporte inévitablement complexité et distance avec le client. Il faut reconnaître qu’en fonction du contexte, un processus peut empirer. À mes yeux, le message se rapproche davantage d’une « prévention de la dégradation prématurée des processus »

    • Au fond, cela se résume à : « n’essayez pas de résoudre à l’avance des problèmes qui n’existent pas encore »

    • Le conseil « n’agissez pas comme une grande entreprise » s’applique franchement à des organisations de toute taille. En tant que consultant, je passe beaucoup de temps à empêcher des startups ou des PME d’adopter des règles et des politiques de grandes structures simplement parce qu’elles sont constituées en société. Ces politiques ne deviennent nécessaires qu’à l’échelle de plusieurs centaines de personnes ; dans une petite organisation, elles sont au contraire un frein. On peut citer par exemple k8s, nosql ou des politiques de sécurité plus strictes que nécessaire. Le guide de culture interne de Netflix l’illustre bien aussi. Dans une petite organisation, à condition d’avoir bien recruté, il faut déléguer de manière réelle et permettre à chacun de juger par lui-même. Tant que les problèmes ou les risques n’ont pas réellement grandi, il n’est pas nécessaire d’enfermer chaque chose dans des règles

  • Stripe est l’une des entreprises les plus prospères du portefeuille YC, et le problème qu’elle a résolu était réellement pressant et urgent. Là où beaucoup auraient attendu que les utilisateurs viennent à eux, Stripe est au contraire devenue célèbre pour une acquisition utilisateur très agressive. C’était il y a 12 ans, et je n’imaginais pas qu’elle grandirait autant. J’aurais vraiment aimé pouvoir investir à l’époque

  • Bien sûr, il y a un biais du survivant. Mais j’adhère totalement à l’idée qu’il est important de faire soi-même le travail pendant un temps sans tout automatiser. C’est comme ça qu’on grave de manière beaucoup plus fine dans sa tête l’ensemble du processus ou du système, ce qu’aucune slide ni aucun document ne permet. En termes actuels, on pourrait dire que c’est la phase où l’on construit son « taste ». On développe une sensibilité concrète à ce qui est bon et à pourquoi ça l’est, et on acquiert un point de vue net sur des décisions que les autres n’envisagent même pas. Aujourd’hui, avec l’IA, beaucoup veulent passer trop vite à l’automatisation, mais chez www.socratify.com, nous créons encore le contenu manuellement. Tout le monde dit qu’il faut tout produire avec l’IA, mais notre objectif principal est de bien contextualiser et de bien curer la qualité. Une partie du processus de vérification pourra être automatisée plus tard, mais l’expérience indirecte répétée nous montre qu’il est difficile de remplacer complètement le cerveau humain et l’intuition

  • YC a changé la donne en rendant le seed funding beaucoup plus accessible. Je suis convaincu que Paul Graham, Jessica Livingston et l’équipe YC ont bien vu les défauts du système existant et les ont corrigés. Avant YC, obtenir un seed était presque impossible. C’était inégalitaire, et on avait l’impression de pitcher devant huit partenaires irrités dans un vieux bureau de banque. Quand quelqu’un a un mérite, il faut le reconnaître : ce sont eux qui ont réparé ce marché

    • Je pense que ce point est discutable. Même si l’accès au financement s’est élargi, l’amorçage restait difficile avant YC et l’est resté après. La différence, c’est qu’avec l’arrivée d’un acteur aussi grand que YC, la position des fondateurs en bootstrapping s’est affaiblie. À partir d’un certain moment, les fondateurs se sont mis à suivre les sujets que YC sélectionnait plutôt que ce qu’ils voulaient vraiment faire. Ils ont eu moins d’occasions de travailler sur ce qu’ils souhaitaient réellement maîtriser

  • J’aimerais que de grandes entreprises comme OpenAI lisent sérieusement “Do Things That Don’t Scale” et s’en inspirent réellement. Avec un tel capital, elles auraient pu acheter proprement les licences de données nécessaires. Mais elles n’ont choisi que l’approche scalable (scraping, stealing), en semblant espérer qu’en prenant beaucoup discrètement, personne ne s’en apercevrait, ou que les objections n’arriveraient que plus tard. En clair, elles comptaient sur le fait que les créateurs de contenu actuels ne découvrent pas qu’ils étaient utilisés pour l’entraînement de l’IA sans recevoir le moindre centime

    • À mon sens, c’est moins un problème de scaling qu’une manifestation du réflexe capitaliste consistant inévitablement à vouloir éviter de dépenser de l’argent

  • C’était le premier texte que j’ai vu sur Hacker News. Chaque fois qu’il remonte de temps en temps, cela ravive une certaine nostalgie