CB Insights veröffentlicht jährlich eine Auswertung, warum Startups scheitern. Seit Jahren ist der häufigste Grund derselbe: „kein Marktbedarf." Nicht schlechte Umsetzung. Nicht fehlendes Kapital. Nicht ein schlechtes Team. Das Produkt löste einfach kein Problem, das den Menschen wichtig genug war, ihr Verhalten zu ändern.
Diese Statistik ist erschreckend, wenn man bedenkt, wie viel Aufwand in die Produktentwicklung fließt. Teams verbringen Monate – manchmal Jahre – damit, Systeme zu entwerfen, Code zu schreiben, über Architektur zu streiten und Abläufe zu perfektionieren. Und der häufigste Grund für ihr Scheitern ist, dass niemand gefragt hat, ob das alles ein echtes Problem löst.
Produkte zu bauen, die Menschen wirklich wollen, ist kein Talent. Es ist eine Disziplin. Es gibt eine Methode dafür, und diese Methode kann erlernt werden.
Der häufigste Produktfehler ist, sich in eine Lösung zu verlieben, bevor man das Problem wirklich versteht. Das passiert fast universell bei Erstgründern und überraschend häufig auch bei erfahrenen. Das Muster ist immer dasselbe: Jemand hat eine Idee, findet sie überzeugend und beginnt zu bauen. Der Kunde ist ein Nachgedanke – jemand, der überzeugt werden soll, nicht verstanden.
Das Gegenmittel ist nicht kompliziert, erfordert aber Disziplin: Verbringen Sie mehr Zeit mit dem Problem, als Sie für nötig halten – bevor Sie überhaupt Lösungen in Betracht ziehen. Sprechen Sie mit Menschen, die das Problem haben. Beobachten Sie, wie sie arbeiten. Verstehen Sie die Umgehungslösungen, die sie heute nutzen, und warum diese unvollkommen sind. Erst dann haben Sie genug Kontext, um etwas zu entwickeln, das wirklich passt.
Gute Produktentwicklung ist keine gerade Linie – sie ist eine Schleife. Jede Iteration durch die Schleife ist eine Gelegenheit, Annahmen durch Belege zu ersetzen. Teams, die Produkte bauen, die Menschen wollen, sind diejenigen, die diese Schleife schnell und oft durchlaufen.
Die Schleife ist keine Formalität. Jede Phase hat ein spezifisches Ergebnis, das zum Input für die nächste wird. Phasen zu überspringen – am häufigsten direkt von Problem zu Bauen – ist das, was Produkte entstehen lässt, die das Ziel verfehlen.
Nicht alle Probleme sind es wert, gelöst zu werden. Ein gutes Produktproblem hat drei Eigenschaften: Es ist häufig (betrifft Menschen oft, nicht selten), es ist intensiv (Menschen spüren es genug, um Erleichterung zu wollen), und die bestehenden Lösungen sind wirklich unzureichend (nicht nur etwas anders als das, was man selbst bauen würde).
Der Fehler besteht darin, die erste Eigenschaft zu optimieren und die anderen beiden zu ignorieren. „Menschen verschwenden Zeit in Meetings" ist häufig. Aber wenn der Schmerz gering ist – wenn Menschen gute genug Umgehungslösungen gefunden haben – ist das Problem möglicherweise nicht wert, kommerziell gelöst zu werden. Und wenn es bereits zwölf Tools gibt, die das tun, was man selbst bauen möchte, braucht man einen sehr spezifischen Grund, warum das eigene gewählt werden würde.
Recherche hat einen schlechten Ruf in Produktkreisen – sie wird mit langsamen Beratungsunternehmen, dicken Berichten und Erkenntnissen assoziiert, die niemand liest. Das ist ein Umsetzungsversagen, kein Versagen der Praxis selbst. Gute Produktrecherche ist schnell, spezifisch und verändert das, was man baut.
Das Ziel der Recherche ist nicht, zu bestätigen, dass das Problem real ist. Das sollte man bereits glauben, bevor man stark in Recherche investiert. Das Ziel ist, das Problem tief genug zu verstehen, um zu wissen, wie eine gute Lösung aussieht: wer genau das Problem hat, in welchem Kontext, was er bereits ausprobiert hat, welche Worte er verwendet, um es zu beschreiben, und wie „gelöst" für ihn aussehen würde.
Eine Hypothese ist eine spezifische, falsifizierbare Vorhersage darüber, was man für wahr hält. Sie erzwingt Klarheit. Wenn man keine klare Hypothese formulieren kann, versteht man das Problem noch nicht gut genug, um eine Lösung zu bauen.
Eine nützliche Produkthypothese hat drei Teile:
Das Signal ist der wichtigste Teil – und der am häufigsten weggelassene. Ohne ein vorab festgelegtes Signal hat jedes Experiment „irgendwie funktioniert." Teams finden Wege, mehrdeutige Daten positiv zu interpretieren. Eine Hypothese ohne Falsifizierungsbedingung ist nur ein Wunsch.
Die Bauphase ist, wo die meisten Teams zu viel Zeit verbringen. Das Ziel ist nicht, das Produkt zu bauen – es ist, das Minimum zu bauen, das Ihnen ein Signal zu Ihrer Hypothese gibt. Das sind unterschiedliche Ziele, und sie produzieren sehr unterschiedliche Ergebnisse.
Für die meisten frühen Hypothesen ist das Minimum viel weniger, als Teams denken. Kann man manuell tun, was die Software tun würde, für zehn Menschen, um zu testen, ob sie das Ergebnis schätzen? Kann man bestehende Tools zusammenfügen und den Workflow testen, bevor man neue Infrastruktur baut? Kann man einen Prototyp skizzieren und ihn mit fünf Nutzern durchgehen, bevor man irgendeinen Code schreibt?
Die Disziplin hier besteht darin, vor dem Bauen zu fragen: „Was versuche ich zu lernen?" und „Was ist das Minimum, das mir erlaubt, es zu lernen?" Die Antwort ist fast immer kleiner als das, was das Team bauen möchte.
Nach dem Launch – ob das ein Prototyp, ein manueller Pilotversuch oder eine implementierte Funktion ist – ist die Messphase, wo Teams sich am häufigsten selbst täuschen. Sie fragen Nutzer, ob es ihnen gefallen hat. Nutzer sagen ja. Das Team markiert das Experiment als validiert.
Stimmung ist kein Signal. Das einzige zuverlässige Signal ist Verhalten: Haben Menschen das getan? Sind sie zurückgekommen? Haben sie bezahlt? Haben sie es jemandem empfohlen?
Für quantitative Messungen: Instrumentieren, bevor man startet. Wissen, welche spezifischen Aktionen verfolgt werden. Einen Schwellenwert im Voraus festlegen – „Wir betrachten das als validiert, wenn X% der Nutzer Y innerhalb von Z Tagen abschließen." Für qualitative Messungen: Strukturierte Follow-up-Interviews führen, keine offenen Zufriedenheitsumfragen.
Die Lernphase dreht sich darum, das mentale Modell des Nutzers und des Problems zu aktualisieren, nicht nur zu entscheiden, was als nächstes gebaut werden soll. Teams, die diesen Schritt überspringen, sammeln Daten, häufen aber kein Verständnis an. Sie führen schnell aus, aber verbessern ihr Urteilsvermögen nicht im Laufe der Zeit.
Eine gute Lernsession fragt: Was haben wir vorhergesagt? Was ist tatsächlich passiert? Was sagt uns die Lücke über unsere Annahmen? Was ist jetzt das Wichtigste, das wir nicht wissen?
Das Ergebnis der Lernphase ist eine schärfere Problemdefinition, eine überarbeitete Hypothese oder – wenn das Experiment klar gescheitert ist – eine Entscheidung, eine ganz andere Richtung einzuschlagen. Alle diese Ergebnisse sind wertvoll. Das schlimmste Ergebnis ist Mehrdeutigkeit: „Wir haben etwas gelernt, wissen aber nicht, was wir als nächstes tun sollen." Das ist ein Zeichen dafür, dass das Experiment nicht spezifisch genug war.
Die Produktentwicklung erreicht nie ein Stadium, in dem man aufhört, diese Schleife zu durchlaufen. Die Fragen ändern sich – früh validiert man, ob das Problem real ist; später validiert man, ob ein spezifisches Lösungselement funktioniert – aber die Struktur ist immer dieselbe. Beobachten, Hypothese aufstellen, testen, lernen.
Teams, die Produkte bauen, die Menschen wollen, sind nicht diejenigen mit der klügsten anfänglichen Erkenntnis. Sie sind diejenigen, die die Schleife am schnellsten und ehrlichsten durchlaufen. Lerngeschwindigkeit, nicht Liefergeschwindigkeit, ist der Wettbewerbsvorteil.