Tu Dinge, die nicht skalieren (2013)

 (paulgraham.com)
3 Punkte von GN⁺ 2025-08-17 | 1 Kommentare | Auf WhatsApp teilen
  • Y Combinator rät dazu, in der frühen Phase einer Gründung aktiv „Dinge zu tun, die nicht skalieren“
  • Erfolgreiche Startups wie Stripe und Airbnb wählten bei der Gewinnung der ersten Nutzer einen direkten und aggressiven Ansatz
  • Die meisten Startups sind am Anfang sehr fragil, und der persönliche Einsatz der Gründer ist der Schlüssel zum Wachstum
  • Es ist für langfristiges Wachstum entscheidend, den ersten Nutzern ein herausragendes Erlebnis und echte Zufriedenheit zu bieten
  • In der Anfangsphase sind Handarbeit statt Automatisierung, die Fokussierung auf Nischenmärkte und direkte Beratung oft wirksam

Einleitung: Die Realität des Startup-Wachstums

  • Viele angehende Gründer glauben, dass ein Startup von selbst wächst, doch in Wirklichkeit müssen die Gründer selbst aktiv den Funken des Wachstums entzünden
  • Wie beim alten Handkurbelstarter im Auto ist am Anfang oft ein arbeitsintensiver Prozess unverzichtbar

Nutzer direkt gewinnen (Recruit)

  • Die meisten Startups sollten nicht passiv darauf warten, dass Nutzer von selbst kommen, sondern aktiv auf sie zugehen
  • Auch Stripe nutzte anfangs eine aggressive Strategie zur Nutzergewinnung namens „Collison installation“: Wer eine Einführung in die Beta erhalten hatte, dem wurde der Laptop direkt abgenommen und die Software installiert
  • Dass Gründer solche Dinge meiden, liegt oft an Angst vor Ablehnung, Scham und der Geringschätzung kleiner Nutzerzahlen
  • Tatsächlich kann man durch den Effekt des exponentiellen Wachstums selbst mit nur 10 % Wochenwachstum in zwei Jahren mehrere Millionen Nutzer erreichen
  • Auch Airbnb war so aktiv, dass das Team in New York Gastgeber persönlich aufsuchte und ihnen bei der Registrierung half

Die Fragilität früher Startups (Fragile)

  • Fast alle Startups sind zu Beginn sehr instabil, und kurzfristige direkte Anstrengungen entscheiden oft über Erfolg oder Scheitern
  • Gefährlicher als das Desinteresse externer Kritiker oder Investoren ist, wenn man selbst den Wert des eigenen Unternehmens unterschätzt
  • In der Anfangsphase sollte man sich nicht fragen: „Wird diese Firma die Welt verändern?“, sondern eher: „Wie groß könnte sie werden, wenn wir die richtigen Anstrengungen unternehmen?“
  • Die frühen Phasen von Microsoft und Airbnb wirkten nach außen ebenfalls äußerst unbedeutend, waren aber dennoch der bestmögliche Weg
  • Die passenden Nutzer findet man oft zuerst unter Menschen, die einem selbst ähnlich sind, oder indem man unter den ersten Nutzern die leidenschaftlichste Gruppe identifiziert und gezielt auf sie setzt

Nutzer maximal begeistern (Delight)

  • Nicht nur die Gewinnung neuer Nutzer, sondern auch außergewöhnliche Anstrengungen, um bestehende Nutzer glücklich zu machen, sind nötig
  • Wufoo baute frühes Vertrauen auf, indem das Team jedem neuen Nutzer handgeschriebene Dankesbriefe schickte
  • Statt sich an den Standards des Kundendienstes großer Unternehmen zu orientieren, sollte man die personalisierte Erfahrung betonen, die nur ein junges Startup bieten kann
  • Wenn die Zahl der Dinge, die man tun muss, um frühe Nutzer zu begeistern, so groß wird, dass sie kaum noch zu bewältigen ist, ist das eher ein gutes Wachstumssignal
  • Ein Grund dafür, dass Gründer diesen Vorteil oft nicht voll ausschöpfen, ist ihre fehlende Erfahrung im Kundenservice, wodurch sie den Wettbewerbsvorteil kleiner Unternehmen nicht ausreichend nutzen

Besessenheit vom Nutzererlebnis (Experience)

  • Wie Steve Jobs es mit „Insanely great“ ausdrückte, muss man am Anfang geradezu vom Nutzererlebnis besessen sein
  • Wichtiger als ein von Anfang an perfektes Produkt ist, auch ein noch unfertiges Produkt durch Interaktion mit Nutzern zu verbessern
  • Das Feedback, das man durch den direkten Austausch mit Nutzern erhält, hat den größten Einfluss auf das Wachstum

Mit einem engen Markt anfangen (Fire)

  • Wie Facebook und Airbnb sollte man bewusst in einem sehr kleinen Markt starten (z. B. Harvard-Studierende) und dort zunächst kritische Masse erreichen
  • Gerade am Anfang ist es effektiver, die Early-Adopter-Gruppe zu finden, die am schnellsten reagiert
  • Accelerator-Programme wie YC sind auch hilfreich, wenn man andere Startups als Kunden gewinnen will

Besondere Strategie für Hardware-Startups (Meraki)

  • Da bei Hardware-Startups die Anfangskosten für Massenproduktion hoch sind, montierten Gründer wie bei Meraki und Pebble die Produkte zunächst selbst
  • Durch dieses Selbermachen entstehen praktische Lerneffekte zu Designoptimierung, Teilebeschaffung und ähnlichen Fragen

Extreme Nutzerannäherung im Beratungsstil (Consult)

  • Bei B2B-Produkten kann man zunächst für einen ganz bestimmten Kunden etwas wie im Consulting maßschneidern und danach auf benachbarte Märkte ausweiten
  • Gerade im Prozess, sich vollständig an ein tatsächlich benötigtes Problem des Kunden anzupassen, findet man oft den Schlüssel zum Wachstum
  • In der Anfangszeit kann es auch sinnvoll sein, die Software stellvertretend für den Kunden selbst zu benutzen oder benötigte Funktionen sofort umzusetzen

Vollständig manuelle Strategie (Manual)

  • Solange es nur wenige Nutzer gibt, lassen sich viele Dinge manuell erledigen und später schrittweise automatisieren
  • Stripe bearbeitete anfangs die „sofortige Kontoeröffnung“ von Hand, um das gewünschte Nutzererlebnis zu liefern
  • Statt von Anfang an auf Automatisierung fixiert zu sein, sollte man zunächst durch Handarbeit die realen Probleme von Produkt und Kunden verstehen

Die Ineffizienz des „großen Launches“ (Big)

  • Eine große Markteinführung auf einen Schlag oder die Strategie, Wachstum an Partnerschaften mit Großunternehmen zu delegieren, scheitert meist
  • Am Anfang sollte man sich auf wenige Nutzer konzentrieren; intensive Anstrengung und direkte Methoden sind wichtiger
  • Nutzerinteresse wächst langsam, durch direkte Betreuung und das Schaffen von Zufriedenheit

Zweidimensionaler Ansatz für Startup-Ideen (Vector)

  • Erfolgreiche Startups sollte man als Vektor denken: Produkt (was man baut) + Nicht-Skalierungs-Strategie (welche Dinge man anfangs direkt selbst tut)
  • Dieses frühe direkte Handeln hinterlässt positive Spuren in der DNA des Produkts
  • Frühe direkte Anstrengungen verwandeln sich mit der Zeit in Produkt- und Organisationskultur und werden so zum Motor für nachhaltiges Wachstum

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-17
Hacker-News-Diskussion

  • Ich habe kürzlich in einem Podcast eine Aussage gehört, der ich wirklich sehr zustimme: Das größte Problem für Startups ist Trägheit. Die Welt mag uns nicht besonders und hat auch nicht das Gefühl, uns zu brauchen ... wir müssen das umkehren. Wir müssen von Grund auf selbst Momentum erzeugen, und die wirklich wichtige Aufgabe von Gründern ist es, Handlungen zu setzen, die diese Trägheit umkehren. Das passiert sogar ganz real im physikalischen Sinn. Die Welt steht still, und wir müssen dieses Momentum selbst erzeugen, so wie man einen Motor zum ersten Mal startet. Aus dieser Perspektive ist es am Anfang überhaupt nicht seltsam, Dinge zu tun, die nicht skalieren. Es geht nicht darum, eine bereits laufende Maschine zu optimieren, sondern darum, den Motor Stück für Stück überhaupt erst zum Laufen zu bringen. Paul Grahams Punkt ist, dass skalierbares Wachstum oder Automatisierung erst das Problem danach ist. Man muss Nutzer einzeln und direkt treffen, um wirklich zu lernen, was funktioniert. Dabei sammelt man Belege dafür, dass Nutzer einen als notwendig ansehen, und beweist zugleich, was es überhaupt wert ist, skaliert zu werden

    • Meiner Meinung nach liegt der eigentliche Wert von Handarbeit darin, dass man direkt lernt. Einer meiner Kunden stellte wöchentlich eine kuratierte Liste wichtiger Finanz- und Wertpapiernachrichten zusammen, die er selbst auswählte. Es war eine Nische innerhalb einer kleinen Nische, aber die Nutzer liebten es. Irgendwann wollte er dann alles automatisieren, und dadurch wurde der Inhalt unselektiver, es kam mehr Spam-artige Information hinein, der Wert verschwand und am Ende ging auch das Produkt selbst denselben Weg. Es enthielt zwar mehr Nachrichten, aber ohne direkte Auswahl und Redaktion wurde das Verhältnis von Signal zu Rauschen schlechter. Tatsächlich war die Handarbeit trotz ihres begrenzten Umfangs viel wertvoller. Viele Unternehmen verstehen das nicht und versteifen sich viel zu früh nur auf Automatisierung. Ein anderes Beispiel: Ich hatte einen Kunden, der die Preise der Konkurrenz manuell überprüfte. Er wollte Automatisierung, also baute ich einen einfachen Excel-basierten Scraper. Anfangs war er zufrieden, merkte später aber, dass ihm durch das fehlende direkte Durchstöbern der Konkurrenzseiten Chancen entgingen, Neues über Produkte, Katalogtrends usw. zu lernen. Schließlich kehrte er wieder zur manuellen Recherche zurück und nutzte den Scraper nur noch für einfache Preisanalysen. Die meisten meiner anderen Kunden achten jedoch weiter nur auf Automatisierung statt auf das Wesen des Produkts und des Problems und verpassen dadurch immer wieder wichtige Lernchancen

    • Deshalb ist „Baue etwas, das die Leute wollen“ so ein berühmter Satz in der Startup-Welt

    • Der Ausdruck „die Trägheit umkehren“ gefällt mir wirklich sehr, aber dieser Ansatz gilt nicht für alle Startups. Laut Sequoias Arc-Framework gibt es drei Arten: Hair on Fire (dringender Schmerz, Momentum ist entscheidend), Hard Fact (es gibt Schmerz, aber Gewohnheiten müssen geändert werden) und Future Vision (die Leute glauben noch nicht, dass so etwas überhaupt möglich ist, deshalb muss zuerst Vertrauen aufgebaut werden). Dinge, die nicht skalieren, selbst zu tun und damit Ergebnisse zu erzielen, ist im Bereich Hair on Fire unverzichtbar, aber bei den anderen muss man eher die Realität selbst neu rahmen oder zuerst Glaubwürdigkeit aufbauen

  • Meine Theorie lässt sich in drei Phasen einteilen: Not Scaling (vor der Skalierung), Scaling (Skalierung) und Antiscaling (die Unsympathie-Phase). Not Scaling ist die Phase, in der man am Markt seinen eigenen moat aufbaut. Scaling ist der Zeitpunkt, an dem das Produkt genug Zuspruch hat, dass Kunden neue Kunden bringen und man im Grunde nur noch mit mehr Servern oder Datenbank-Sharding die wachsende Nachfrage bewältigen muss. Antiscaling ist dann erreicht, wenn man sich zu einem Unternehmen entwickelt, das die Probleme des modernen Web verkörpert. Geheimdienste melden sich wegen terroristischer Nutzung, Städte oder Regierungen schaffen gezielt Lizenzen oder Regulierungen, um einen ins Visier zu nehmen. Der Gründer wird so bekannt, dass Memes über ihn kursieren und sogar sein Standort verfolgt werden kann. Man muss nicht die Welt beherrschen, man muss nur Geld verdienen. Wer behauptet, die Welt verändern zu wollen, bringt nur selten tatsächlich gute Ergebnisse hervor; wichtig ist, einfach etwas Brauchbares zu bauen

    • „Man muss einfach Geld verdienen“ erinnert mich an Goodhart’s Law: Sobald eine Kennzahl, etwa Umsatz, zum Ziel wird, ist sie keine gute Messgröße mehr

    • Diese Sichtweise wirkt auf mich zu einseitig. Die extreme Gleichgültigkeit, die entsteht, wenn man etwas baut, das niemand will, wird hier nicht behandelt. Und noch häufiger ist in Wahrheit der ganz gewöhnliche Fall von ein bisschen Erfolg. Niemand hasst es, aber auch niemand liebt es leidenschaftlich. Es ist leicht positiv, aber ohne Hype oder monopolartige Wettbewerbsstärke interessiert es letztlich niemanden wirklich – genau dieser Fall ist am häufigsten

  • Ich lasse unten ein paar Links da, weil ich gern mehr ähnliche Beispiele sammeln würde

  • Ich wollte etwas teilen, das ich allen frühen Gründern und auch allen Mitarbeitern empfehlen würde, die sehr früh zu einem Startup dazustoßen. Wir sind inzwischen auf mehr als 15 Leute gewachsen und rufen trotzdem jeden neuen Anmelder direkt an. Warum? 1) um zu erfahren, wie er auf uns aufmerksam geworden ist, 2) um zu sehen, ob er Hilfe beim Einstieg braucht, und 3) um implizit zu vermitteln, dass sich unser Team persönlich kümmert. Unser Service ist eine B2B-Plattform, deshalb funktioniert es vermutlich noch besser, und obwohl die Zielgruppe aus Entwicklern besteht, merkt man am Telefon nach dem ersten „Nein, das soll kein Verkaufsgespräch sein“, dass dann wirklich viele ehrliche und gute Gespräche zustande kommen

  • Es gibt viele Stimmen, die Paul Graham kritisieren, aber dieser Text lässt sich im Kern als „keine premature optimization“ zusammenfassen. Also: Tut nicht so, als wärt ihr schon ein Großunternehmen. Wenn Gründer selbst operativ arbeiten, sammeln sie auch dann praktische Erfahrung und Feedback, wenn es ineffizient ist, und gerade dadurch, dass sie nicht von Anfang an schnell eine skalierbare Lösung einführen, bekommen sie oft sogar schneller Rückmeldungen. Außerdem hilft es, eine eigene Differenzierung aufzubauen. Ich glaube, es ist gut, sich den Satz „Do Things That Don’t Scale“ wörtlich einzuprägen

    • Oft werden übermäßig skalierbare Systeme schon in einer Phase gebaut, in der sie in Wirklichkeit noch gar nicht gebraucht werden – einfach aus Angst, der Dienst könne unter zu viel Popularität oder Nachfrage zusammenbrechen. Ich habe aber den Eindruck, dass vertikale Skalierung (also einfach mehr Ressourcen hinzufügen) stark unterschätzt wird. Schon dadurch, dass man einem bestehenden monolithischen Backend mehr Ressourcen gibt, gewinnt man Zeit, den Dienst wirklich zu verstehen. Vor allem zwingt es einen dazu, noch einmal zu überdenken, worin der „Kernwert“ liegt, den Nutzer an unserem Produkt mögen. Und wenn Nutzer ein Produkt wirklich lieben, verzeihen sie am Anfang auch etwas schwächere Performance. Bei Twitter erschien früher oft der „fail whale“, aber weil die gewünschte Funktion da war, konnte es trotzdem explosionsartig wachsen. In der Frühphase geht es nur um schnelles Feedback, Iteration und Kundenzufriedenheit. Vor der Skalierung kommen Experimente, Gespräche mit Nutzern und Beobachtung. Über Skalierung sollte man erst dann nachdenken, wenn der richtige Moment spürbar da ist – und wann das sein wird, lässt sich nicht vorhersagen. Technologie ist nur ein Werkzeug; selbst wenn man eine edle Violine hat, muss man vor allem zuerst „gute Musik“ machen

    • Man sollte sich vor Augen halten, dass nicht jedes erfolgreiche Geschäft auf Hunderte Millionen oder Milliarden Nutzer abzielt. Ich arbeite an internen Tools, und die Größenordnung unserer Umgebung ist bereits festgelegt, sie ist nicht besonders performancekritisch und hat auch keinen unregelmäßigen Traffic. Trotzdem gab es bei uns jemanden im Team, der regelrecht davon besessen war, den gesamten Code in eine Sprache umzuschreiben, die nur er beherrschte, nur um ein paar Millisekunden einzusparen. Es interessierte niemanden, und was er gebaut hatte, hinterließ nur Wartungsrisiken. Als er das Unternehmen verließ, wurde das Ganze auf Entscheidung des Managements komplett verworfen; mit einem einfacheren und langsameren Design wäre die Übergabe an andere viel leichter gewesen

    • „Premature optimization“ und „Do Things That Don’t Scale“ sind subtil verschieden. Ersteres setzt voraus, dass die skalierbare Version die „optimale“ ist, während Letzteres andeutet, dass die nicht skalierbare Vorgehensweise sogar die beste sein kann. Zum Beispiel kann es viel besser sein, wenn der CEO selbst die eingehenden Kontakte übernimmt, statt dass alles über eine geteilte Inbox läuft. Die skalierende Variante (Kontaktformular) ist nicht von Anfang an die optimale, sondern in Wirklichkeit eine Verschlechterung der Prozessqualität. Skalierung an sich ist nicht böse, aber die unvermeidlich mitkommende Komplexität und Distanz zum Kunden sind groß. Man muss anerkennen, dass Prozesse je nach Situation schlechter werden können. Für mich geht die Botschaft eher in Richtung „Verhindere vorzeitige Prozessverschlechterung“

    • Am Ende lässt sich das auf „Löse keine Probleme im Voraus, die es noch gar nicht gibt“ herunterbrechen

    • Der Rat „Verhalte dich nicht wie ein Großunternehmen“ gilt ehrlich gesagt für Organisationen jeder Größe. Als Berater verbringe ich viel Zeit damit, Startups oder KMU davon abzuhalten, nur deshalb Regeln und Richtlinien großer Organisationen einzuführen, weil sie eine Firma sind. Solche Richtlinien braucht man vielleicht bei Hunderten Mitarbeitern, aber in kleinen Organisationen bremsen sie eher. Beispiele sind k8s, NoSQL oder unnötig strenge Sicherheitsrichtlinien. Auch der interne Kulturleitfaden von Netflix zeigt das gut. Wenn eine Organisation klein ist, sollte man – vorausgesetzt, man hat gut eingestellt – echte Verantwortung übertragen und jedem Teammitglied eigenes Urteilsvermögen zugestehen. Solange Probleme oder Risiken nicht wirklich groß werden, muss man nicht alles in Regeln einsperren

  • Stripe ist eines der erfolgreichsten Unternehmen im YC-Portfolio, und das Problem, das Stripe gelöst hat, war wirklich akut und dringend. In einer Situation, in der fast jeder wahrscheinlich einfach darauf gewartet hätte, dass Nutzer schon kommen, war Stripe im Gegenteil für sehr aggressive Nutzergewinnung bekannt. Das ist jetzt 12 Jahre her, und ich hätte damals nie gedacht, dass es so groß werden würde. Wenn ich damals hätte investieren können, wäre das großartig gewesen

  • Natürlich gibt es survivor bias. Aber dem Punkt, dass die Phase wichtig ist, in der man die Arbeit selbst macht und nicht automatisiert, stimme ich vollkommen zu. Nur so prägt sich der gesamte Prozess oder das gesamte System wirklich detailliert im Kopf ein – mit ein paar Slides oder Dokumenten geht das nicht. Im heutigen Sprachgebrauch könnte man sagen, dass man dabei „Taste“ entwickelt. Man bekommt ein Gefühl dafür, was gut ist und warum, und entwickelt an Entscheidungspunkten, über die andere nicht einmal nachdenken, eine klare Perspektive. Heute wollen viele wegen AI zu schnell zur Automatisierung springen, aber bei www.socratify.com erstellen wir die Inhalte weiterhin von Hand. Alle sagen, man müsse alles mit AI machen, aber unser Hauptziel ist es, Kontext und Qualität richtig zu kuratieren. Den Prüfprozess kann man später teilweise automatisieren, aber wir erleben immer wieder indirekt, dass menschliches Denken und menschliche Einsicht sich nicht vollständig ersetzen lassen

  • YC hat das Spielfeld verändert, weil Seed-Finanzierung dadurch viel leichter wurde. Ich bin überzeugt, dass Paul Graham, Jessica Livingston und das YC-Team die Probleme des bestehenden Systems klar erkannt und behoben haben. Vor YC war Seed-Finanzierung fast unmöglich. Es war ungerecht und fühlte sich an, als müsste man acht wütenden Partnern in einem altmodischen Bankbüro präsentieren. Wenn jemand Anerkennung verdient, dann sie – sie haben diesen Markt repariert

    • Ich halte diesen Punkt für umstritten. Selbst wenn Finanzierung für mehr Menschen geöffnet wurde, war Seed-Funding in Wahrheit sowohl vor als auch nach YC weiterhin schwierig. Der Unterschied ist, dass mit einem großen Player wie YC die Position von Bootstrapping-Gründern schwächer geworden ist. Irgendwann entstand eine Situation, in der Gründer nicht mehr dem folgten, was sie wirklich wollten, sondern den Themen, die YC auswählte. Die Gelegenheit, an etwas zu arbeiten, in dem man selbst Meisterschaft entwickeln will, ist kleiner geworden

  • Ich wünschte, große Unternehmen wie OpenAI würden „Do Things That Don’t Scale“ ernsthaft lesen und sich tatsächlich daran orientieren. Mit so viel Kapital hätten sie die nötigen Datenlizenzen auch ganz legitim kaufen können. Stattdessen haben sie nur den skalierenden Weg gewählt (scraping, stealing) und offenbar gehofft, dass es am Ende niemand merkt oder Beschwerden erst spät kommen. Sie haben also darauf gesetzt, dass die heutigen Content-Ersteller stillschweigend keinen Cent dafür bekommen, dass ihre Werke ohne ihr Wissen als Trainingsdaten für AI verwendet wurden

    • Das ist meines Erachtens weniger ein Skalierungsproblem als vielmehr eng mit dem im Kapitalismus unvermeidlichen Drang verbunden, kein Geld ausgeben zu wollen

  • Das war der erste Artikel, den ich auf Hacker News gesehen habe. Jedes Mal, wenn er gelegentlich wieder hochkommt, werden alte Erinnerungen wach