Tipps für technische Startup-Gründer | Startup School
Technische Gründer können technische Exzellenz leicht mit Startup-Fortschritt verwechseln. Eine ausgefeilte Architektur, eine sorgfältig polierte Codebasis oder ein ehrgeiziger Infrastrukturplan mögen produktiv wirken, doch nichts davon beweist, dass Kunden das Produkt brauchen. In diesem Vortrag der Startup School greift Diana Hu auf ihren Weg von der CTO eines Augmented-Reality-Startups zur Director of Engineering bei Niantic zurück und verbindet ihn mit Erkenntnissen anderer Y-Combinator-Gründer, um zu erläutern, was die Rolle tatsächlich erfordert.
Ihr zentrales Argument lautet, dass technische Gründer auf Lernen optimieren müssen. In der Ideenphase bedeutet das, etwas zu schaffen, worauf Nutzer reagieren können. In der MVP-Phase bedeutet es, ein eng umrissenes, aber funktionierendes Produkt zu liefern und echte Verbindlichkeit zu suchen. Nach dem Launch bedeutet es, Analysen mit direkten Gesprächen zu verbinden, das Produkt rasch zu verbessern und technische Kompromisse zu akzeptieren, wenn sie dem Unternehmen helfen, einen tragfähigen Markt zu entdecken.
Ein technischer Gründer baut das Unternehmen mit auf
Der technische Mitgründer ist nicht einfach die Person, die die Pläne eines anderen Gründers umsetzt. Hu beschreibt die Rolle als tief engagierte Partnerschaft, in der der technische Gründer Verantwortung für das Produkt, die Kunden und das Überleben des Unternehmens mitträgt.
Diese Verantwortung führt zu einem ungewöhnlich breiten Arbeitsspektrum. In einem frühen Startup kann ein technischer Gründer in derselben Woche Anwendungscode schreiben, Cloud-Dienste konfigurieren, Support-Nachrichten beantworten, die Bürokonnektivität reparieren, Nutzer interviewen und Produktentscheidungen treffen. Eng abgegrenzte Stellenbeschreibungen gehören zu größeren Organisationen; Gründer arbeiten dort, wo die dringendste Ungewissheit des Unternehmens liegt.
Deshalb lautet das richtige frühe Engineering-Ziel nicht maximale technische Raffinesse. Es ist die geringste Menge an Technologie, die Vorwärtsbewegung ermöglicht. Gründer brauchen genug Produkt, um die nächste wichtige Annahme zu testen – nicht ein idealisiertes System, das auf jede hypothetische Zukunft vorbereitet ist.
Die Idee prototypisieren, bevor das Unternehmen aufgebaut wird
In der Ideenphase besteht das unmittelbare Ziel darin, einen abstrakten Vorschlag greifbar zu machen. Ein Prototyp gibt potenziellen Nutzern etwas, das sie sehen, ausprobieren oder besprechen können, und erzeugt damit verlässlicheres Feedback als ein rein verbaler Pitch.
Der Prototyp benötigt nicht unbedingt funktionierenden Produktionscode. Ein Softwareteam könnte Figma oder ein anderes Designwerkzeug nutzen, um das Erlebnis zu simulieren. Ein Hardware-Startup könnte ein 3D-Rendering präsentieren. Wenn die technische Machbarkeit selbst ungewiss ist, kann eine fokussierte Demonstration der zugrunde liegenden Technologie das nützlichste Artefakt sein.
Hu verweist auf frühe Arbeiten hinter Unternehmen wie Optimizely und Azure Reality, um unterschiedliche Formen der Validierung zu veranschaulichen. Ein Prototyp kann eine visuelle Interaktion zeigen, die den Nutzen des Produkts vermittelt, oder beweisen, dass eine schwierige Augmented-Reality-Technik möglich ist. Entscheidend ist, dass er ein relevantes Risiko adressiert.
Der häufige Fehler besteht darin, weiterzubauen, nachdem der Prototyp bereits gut genug ist, um ein Gespräch zu beginnen. Gründer fügen Bildschirme, Sonderfälle und Infrastruktur hinzu, weil sich die Umsetzung kontrollierbarer anfühlt, als Nutzern unfertige Arbeit zu zeigen. Diese Verzögerung ist kostspielig: Sie erhöht den Einsatz, bevor das Team gelernt hat, ob es das richtige Problem löst.
Ein MVP auf Verbindlichkeit statt Vollständigkeit ausrichten
Ein Prototyp hilft dabei, eine Idee zu bewerten; ein MVP ist ein nutzbares Produkt, das für die Veröffentlichung bestimmt ist. Hu argumentiert, dass Gründer beim Übergang zu dieser Phase normalerweise in Wochen statt in langen Entwicklungszyklen denken sollten.
Der Zweck des MVP besteht darin, stärkere Belege als Interesse oder Komplimente zu erhalten. Idealerweise zeigen Nutzer Verbindlichkeit, indem sie bezahlen. Je nach Markt kann auch eine andere kostspielige Handlung – etwa Zeit zu investieren, operative Daten bereitzustellen oder das Produkt in einen Arbeitsablauf zu integrieren – aussagekräftig sein. Der entscheidende Unterschied liegt zwischen jemandem, der sagt, ein Konzept klinge attraktiv, und jemandem, der einen echten Kompromiss eingeht, um es zu nutzen.
Gründer sollten diesem Prozess eng verbunden bleiben. Ein großes Engineering-Team zu früh einzustellen, kann die Distanz zwischen Entscheidungsträgern und Nutzern vergrößern und zugleich die Koordinationskosten erhöhen. Das frühe Team von Justin.tv, aus dem schließlich Twitch hervorging, teilte wichtige Teile des ersten Systems unter den Gründern selbst auf. Die direkte Arbeit am Produkt ermöglichte es ihnen, seine Einschränkungen zu verstehen, während das Unternehmen noch Gestalt annahm.
Frühe praktische Beteiligung dient nicht dazu zu beweisen, dass Gründer für immer alles selbst erledigen können. Sie dient dazu, den Weg zwischen Kundenerkenntnissen und Produktentscheidungen kurz zu halten, wenn jede neue Einsicht die Richtung des Unternehmens verändern könnte.
Das Produkt konsequent eingrenzen
Eines der nützlichsten Prinzipien der Startup School lautet, Dinge zu tun, die nicht skalieren. Technische Gründer werden häufig darin geschult, manuelle Arbeit zu eliminieren, doch vorübergehende manuelle Prozesse können genau das sein, was ein frühes Produkt braucht. Kunden persönlich einzuarbeiten oder einen Vorgang im Hintergrund auszuführen, kann dem Team ermöglichen, zu starten, bevor Automatisierung gerechtfertigt ist.
Hu stellt außerdem die Idee einer „90/10-Lösung“ vor: eine eingeschränkte Umsetzung liefern, die den Kernanwendungsfall abdeckt, statt den gesamten Problemraum lösen zu wollen. Der Umfang kann in mehreren Dimensionen reduziert werden:
Nur einen primären Nutzertyp unterstützen.
Nur das wichtigste Datenformat akzeptieren.
Einen einzelnen Standort oder Markt bedienen.
Den dominanten Arbeitsablauf abdecken und Sonderfälle verschieben.
Verfrühte Automatisierung durch einen manuellen Prozess ersetzen.
Das früheste DoorDash-Produkt ist ein einprägsames Beispiel. Es begann mit einer einfachen Website, schlanken operativen Werkzeugen und einem auf ein kleines geografisches Gebiet begrenzten Service. Es ähnelte nicht der ausgereiften Logistikplattform, zu der das Unternehmen später werden sollte, war jedoch ausreichend, um zu testen, ob Kunden den Dienst wollten.
Große Unternehmen sind häufig durch bestehende Systeme, Prüfprozesse und weitreichende Kundenerwartungen eingeschränkt. Der Vorteil eines Startups liegt in seiner Fähigkeit, ein kleineres Problem zu definieren und schnell zu handeln. Technische Gründer geben diesen Vorteil auf, wenn sie bauen, als würden sie bereits im Maßstab eines Großunternehmens arbeiten.
Technologie für schnelle Iteration auswählen
Die Wahl des Stacks kann zu einer ablenkenden Identitätsdebatte werden. Hu empfiehlt, die tatsächlichen Anforderungen des Produkts mit den vorhandenen Fähigkeiten des Teams abzuwägen und dann die einfachste Kombination zu wählen, die schnell ausgeliefert und verändert werden kann.
Vertrautheit hat praktischen Wert. Ein Gründer, der gut verstandene Werkzeuge nutzt, kann Probleme schneller diagnostizieren und mehr Aufmerksamkeit auf Nutzer richten. Neue Technologie kann angemessen sein, wenn sie einen echten Produktvorteil schafft, doch Neuartigkeit allein hilft einem Startup nicht beim Lernen.
Derselbe pragmatische Maßstab gilt für Dienste von Drittanbietern. Authentifizierung, Zahlungen, Hosting, Kommunikation und andere gängige Funktionen können oft über APIs oder etablierte Frameworks bezogen werden. Sie von Grund auf neu zu bauen, kostet Zeit, ohne das Produkt notwendigerweise zu differenzieren.
Gründer wehren sich manchmal gegen externe Dienste, weil sie zukünftige Gebühren, Einschränkungen oder Migrationsaufwand fürchten. Diese Bedenken können berechtigt sein, müssen jedoch gegen das unmittelbare Risiko abgewogen werden, sich zu langsam zu bewegen. Ein Unternehmen mit starker Nutzung kann Ingenieure einstellen, Komponenten ersetzen und Infrastruktur optimieren. Ein technisch reines Produkt ohne Kunden hat deutlich weniger Möglichkeiten.
Mit dem Launch den eigentlichen Lernzyklus beginnen
Die Veröffentlichung eines MVP ist nicht das Ende der Produktentwicklung. Sie ist der Zeitpunkt, an dem das Unternehmen Zugang zu besseren Belegen erhält und sich in Richtung Product-Market-Fit bewegen kann.
Hu empfiehlt, sowohl quantitative als auch qualitative Signale zu nutzen. Ein einfaches Analytics-Dashboard kann Akzeptanz, Bindung, Konversion und die Punkte sichtbar machen, an denen Nutzer einen Arbeitsablauf abbrechen. Gespräche und Support-Interaktionen erklären Beweggründe, die aggregierte Zahlen nicht erfassen können. Keine der beiden Evidenzformen reicht für sich allein aus.
Die Entwicklung von WePay hin zu einem API-orientierten Angebot zeigt, wie beobachtetes Verhalten und Kundenfeedback ein Unternehmen neu ausrichten können. Die wiederholten Launches von Segment zeigen ein weiteres Muster: Häufige Veröffentlichungen schaffen mehr Gelegenheiten, Annahmen zu testen, Nachfrage zu entdecken und von dem auszugehen, was funktioniert.
Die Konsequenz ist, dass der Launch nicht als einmaliges zeremonielles Ereignis behandelt werden sollte. Er ist ein wiederkehrender Arbeitsrhythmus. Jede Veröffentlichung erzeugt Belege; das Team interpretiert sie und entscheidet, was als Nächstes verbessert, entfernt oder getestet wird.
Technische Schulden im Dienst des Product-Market-Fit managen
Sobald Kunden das Produkt nutzen, stehen Gründer vor konkurrierenden Anforderungen. Sie müssen Fehler beheben, gewünschte Funktionen liefern, das System am Laufen halten und die während des ersten Aufbaus angesammelten Abkürzungen angehen.
Hu behauptet nicht, dass technische Schulden harmlos seien. Stattdessen ordnet sie sie als Abwägung ein. Schulden aufzunehmen kann rational sein, wenn dies das Lernen wesentlich beschleunigt oder das Unternehmen dem Product-Market-Fit näherbringt. Der Fehler besteht darin, dass technisches Aufräumen sich von den geschäftlichen Prioritäten löst – oder Zuverlässigkeitsprobleme zu ignorieren, die Nutzer daran hindern, Wert aus dem Produkt zu ziehen.
Pokémon Go veranschaulicht in extremer Form, wie Nachfrage zusammen mit erheblicher technischer Belastung auftreten kann. Die Probleme beim Launch waren wichtig, doch sie löschten nicht die Stärke der zugrunde liegenden Nutzerreaktion aus. Für ein Startup ist das meist eine bessere Problemklasse, als ein robustes System zu bauen, das niemand dringend haben möchte.
Engineering sollte außerdem eng mit Vertrieb und Wachstum zusammenarbeiten. Kundennah arbeitende Teams erkennen aufkommende Bedürfnisse häufig zuerst, während Ingenieure verstehen, was sich kostengünstig testen lässt. Die Zusammenarbeit kann Marktbeobachtungen in fokussierte Experimente verwandeln, ohne die schwerfälligen Prozesse eines reifen Konzerns zu übernehmen.
Vom primären Entwickler zur Engineering-Führungskraft entwickeln
Die Rolle des technischen Gründers verändert sich nach dem Product-Market-Fit. Zuvor setzt der Gründer möglicherweise den Großteil des Produkts persönlich um. Mit wachsender Nutzung und einem größeren Engineering-Team erweitert sich die Arbeit um Einstellung, Kommunikation, technische Ausrichtung und Kultur.
Dieser Übergang verringert die ununterbrochene Zeit zum Programmieren. Mehr Menschen schaffen mehr Abhängigkeiten, Entscheidungen und Kommunikationswege. Der Gründer muss sicherstellen, dass Ingenieure nicht nur verstehen, was sie bauen sollen, sondern auch, wie das Unternehmen Abwägungen trifft und welche Standards zählen.
Irgendwann müssen technische Gründer möglicherweise zwischen zwei groben Wegen wählen. Der eine besteht darin, als Architekt tief eingebunden zu bleiben und die folgenreichsten technischen Entscheidungen des Systems zu leiten. Der andere besteht darin, sich auf die Führung von Menschen und den Aufbau der Organisation zu konzentrieren. Die passende Wahl hängt vom Unternehmen und den Stärken des Gründers ab, doch die Entscheidung zu vermeiden kann dazu führen, dass beide Verantwortlichkeiten zu kurz kommen.
Die übergeordnete Erkenntnis ist, dass sich die Rolle mit dem Unternehmen weiterentwickeln sollte. Am Anfang entsteht Geschwindigkeit durch das Schreiben von Code und direkte Gespräche mit Nutzern. Später entsteht Geschwindigkeit zunehmend dadurch, ein Team zu schaffen, das fundierte Entscheidungen treffen kann, ohne jedes Detail über einen einzelnen Gründer leiten zu müssen.
Das Leitprinzip: Bauen, um zu lernen
Über Prototyping, MVP-Entwicklung, Launch und Skalierung hinweg kehrt Hu zu einer beständigen Priorität zurück: die Distanz zwischen einer Annahme und verlässlichen Belegen zu verkürzen.
Bauen Sie den ersten Prototyp schnell genug, um die Idee Nutzern zugänglich zu machen. Veröffentlichen Sie ein eng eingegrenztes MVP, das echte Verbindlichkeit gewinnen kann. Wählen Sie Technologie, die schnelle Iteration unterstützt, selbst wenn die erste Umsetzung nicht dauerhaft ist. Interpretieren Sie nach dem Launch sowohl Verhaltensdaten als auch menschliches Feedback. Akzeptieren Sie bewusst technische Schulden, wenn sie Erkenntnisse voranbringen, und gehen Sie sie an, sobald Zuverlässigkeit und Wachstum diese Arbeit erforderlich machen.
Für technische Gründer besteht die schwierigste Disziplin möglicherweise darin zu erkennen, dass der Code nicht das Unternehmen ist. Technologie ist das Instrument, mit dem das Team einen Markt testet, Kunden bedient und seine Erkenntnisse vervielfacht. Das beste frühe System ist daher nicht dasjenige, das für jede mögliche Zukunft entworfen wurde. Es ist dasjenige, das dem Startup hilft, seine nächste wichtige Wahrheit zu erreichen.
