SchLock Digital
← Journal

Validierung · 12 Min. Lesezeit

Warum die meisten digitalen Produkte schon vor dem Launch scheitern

Und was das über den Aufbau von Unternehmen verrät

Viele digitale Produkte scheitern lange vor ihrer Veröffentlichung: in dem Moment, in dem eine Organisation eine Annahme in Software verwandelt, bevor diese Annahme ausreichend geprüft wurde.

Das Scheitern beginnt nicht beim Launch

Wer ein digitales Produkt scheitern sieht, erlebt das Scheitern häufig bei der Veröffentlichung. Der Launch wird zur Geschichte: ausbleibende Downloads, zu viele Abwanderungen, höfliche, aber gleichgültige Bewertungen. Die Aufarbeitung beginnt, und die Suche nach dem Wendepunkt führt rückwärts: zu wenig Marketing, der falsche Preis, schlechtes Timing, ein Vertriebskanal, der nie funktioniert hat.

Der entscheidende Wendepunkt lag häufig schon vor dem Launch.

Viele digitale Produkte scheitern in dem Moment, in dem eine Organisation beschließt, eine Annahme in Software zu verwandeln, bevor sie dafür genügend Belege gesammelt hat. Beim Launch werden die Folgen sichtbar. Er ist der Nachweis, nicht die Ursache.

Diese Unterscheidung klingt klein. In der Praxis trennt sie eine Organisation, die aus Fehlern lernt, von einer, die mit wachsender Effizienz neue Fehler produziert.

Der Irrtum vom Produkt als Ausgangspunkt

In der Branche hält sich die Überzeugung, dass vor allem das Produkt zählt: Wenn die Technik sauber, das Design durchdacht und die Roadmap überzeugend sind, werde sich der Erfolg einstellen. Diese Vorstellung ist nachvollziehbar. Sie kann aber dazu führen, dass Organisationen sehr viel Produkt und überraschend wenig wirtschaftlichen Erfolg erzeugen.

Gute Produkte entstehen aus Organisationen, die reale Probleme erkennen, Nachfrage prüfen, den Umfang begrenzen und anhand von Belegen weiterarbeiten. Schwache Produkte können dagegen aus Arbeitsweisen entstehen, die Bewegung stärker belohnen als Erkenntnis, zu früh mit dem Bauen beginnen und Überzeugung mit Validierung verwechseln.

Damit rückt das System hinter dem Produkt in den Mittelpunkt. Eine Organisation mit geeigneten Arbeitsweisen kann wiederholt gute Produkte entwickeln und sich korrigieren, wenn sie falschliegt. Ohne solche Arbeitsweisen entstehen technisch eindrucksvolle Angebote, die keine Nachfrage finden. Anschließend wird gefragt, was das Produktteam falsch gemacht hat.

Produktqualität bleibt wichtig. Sie entsteht jedoch aus vorgelagerten Entscheidungen. Wer nur das Ergebnis verbessert, ohne seine Entstehung zu prüfen, wird auf Dauer ähnliche Probleme wiederholen.

Warum Bauen sichtbarer ist als Lernen

Es gibt einen strukturellen Grund dafür, dass Organisationen zu viel bauen und zu wenig lernen: Arbeitsergebnisse sind sichtbar, Erkenntnis ist es häufig nicht.

Ein Team, das drei Wochen einen Markt untersucht hat, besitzt danach möglicherweise keine neuen Bildschirmansichten, keine Demo und keine Funktionsliste. Es versteht aber besser, wer ein Problem hat, wie dringend es ist, welche Alternativen bestehen und weshalb es trotzdem ungelöst bleibt. Dieses Verständnis kann Monate fehlgeleiteter Entwicklung verhindern und die Richtung ändern, bevor Kapital gebunden wird. In einem Statusgespräch lässt es sich dennoch schwerer zeigen. Für Menschen, die an der Untersuchung nicht beteiligt waren, fühlt es sich leicht nach wenig Fortschritt an.

Ein Team, das dieselben drei Wochen mit Entwicklung verbringt, hat einen Prototyp. Es kann etwas vorführen: Ansichten, Interaktionen, eine Roadmap. Führungskräfte möchten Bewegung erkennen, Investoren Verbindlichkeit, Partner Ernsthaftigkeit. Ein neues Produkt, eine Funktion oder eine ausgelieferte Version ist dafür der einfachste sichtbare Beleg.

So kann eine Organisation schneller Software als Wissen ansammeln. Produkte, die ohne ausreichende Belege entstehen, bleiben wirtschaftliche Wetten mit attraktiver Oberfläche. Ein belastbares Produktkonzept wurde bereits gegen die Realität geprüft, bevor es um größere Investitionen bittet. Eine Wette verlangt zunächst Geld für genau diese Prüfung.

Eine Idee ist noch keine Marktchance

Bei vielen gescheiterten Vorhaben beginnt das Problem mit der Sprache. Eine Organisation verfolgt eine Idee und beschreibt sie bereits als Chance. Damit wird es schwerer, die richtigen Fragen zu stellen.

Eine Idee ist zunächst intern. Ein Mensch oder ein Team glaubt, dass ein Problem besteht, dass bestimmte Menschen es haben, es gelöst sehen wollen und dass der vorgeschlagene Ansatz dabei hilft. Solche Ideen entstehen durch Nachdenken. Sie lassen sich innerhalb einer Organisation beliebig verfeinern, ausbauen und optimieren, ohne je mit der Außenwelt in Kontakt zu kommen.

Eine Marktchance liegt außerhalb dieser Überzeugung. Sie verbindet ein reales Problem, eine benennbare Kundengruppe, eine Lücke zwischen bestehenden Angeboten und tatsächlicher Zahlungsbereitschaft sowie einen passenden Zeitpunkt. Überzeugung allein kann diese Bedingungen nicht herstellen. Belege müssen zeigen, ob sie vorliegen.

Trotzdem kann sich die vermeintliche Suche nach Marktchancen auf interne Arbeit beschränken: Brainstormings, Roadmaps, Wettbewerbspräsentationen. Dabei wird die eigene Sicht auf die Welt immer genauer ausgearbeitet, ohne die Welt selbst zu befragen.

Der Übergang von der Idee zur Chance ist die Aufgabe der frühen Venture-Phasen. Durch Kontakt mit tatsächlichen Kunden, ihren Alternativen und ihrer Zahlungsbereitschaft wird geprüft, ob die eigene Annahme trägt. Diese Arbeit gehört vor die größere Ressourcenbindung. Wer sie auslässt oder nur zur Bestätigung der eigenen Sicht betreibt, verfolgt eine Idee mit teuren Folgen.

Fünf typische Fehler vor der Veröffentlichung

Viele Produktprobleme lassen sich auf fünf Bedingungen vor dem Launch zurückführen. Sie sind nicht immer sauber voneinander zu trennen und können sich gegenseitig verstärken. Einzeln erkennbar sind sie trotzdem. Sie früh zu erkennen ist eine zentrale Aufgabe disziplinierter Produktentwicklung.

Erstens: ein zu schwaches Problem. Nicht jedes reale Problem trägt ein Geschäft. Manche Probleme sind zu klein, zu selten oder zu leicht zu ertragen. Andere sind bereits hinreichend gelöst; niemand wechselt, weil die bestehende Lösung ausreicht. Wieder andere sind weit verbreitet, werden aber so diffus erlebt, dass niemand allein für eine Lösung bezahlen würde. Hervorragendes Design und saubere Technik ersetzen kein Problem, das den Preis der Lösung rechtfertigt.

Zweitens: ein unklarer Kunde. „Kleine Unternehmen“ oder „Menschen, die gesünder leben wollen“ sind Bevölkerungsgruppen, keine präzise Kundendefinition. Für die Entwicklung zählt ein Mensch in einer konkreten Situation, mit einem konkreten Problem und tatsächlichen Abwägungen. Wer diese Situation genau beschreibt, kann dafür bauen. Eine unscharfe Beschreibung führt leicht zu einem statistischen Durchschnitt, der in der Wirklichkeit niemandem entspricht.

Drittens: angenommene Nachfrage. Interne Überzeugung, freundliche Gespräche und ausbleibender Widerspruch können das Gefühl erzeugen, dass Kunde, Problem und Zahlungsbereitschaft bereits feststehen. Tatsächlich hat sich die Organisation nur selbst überzeugt. Das fühlt sich bis zur Veröffentlichung angenehm an. Mit dem Marktauftritt kann sich diese Sicherheit abrupt auflösen. Nachfrage anzunehmen ist schneller und bequemer, als sie zu prüfen — bis die Folgen sichtbar werden.

Viertens: eine überladene erste Lösung. Selbst wenn Problem, Kunde und Nachfrage ausreichend geprüft wurden, wird häufig mehr gebaut, als der Markt braucht. Beim Entwickeln ist gut erkennbar, was ein Produkt einmal werden könnte. Begrenzungen erscheinen dann als Kompromiss statt als Disziplin. Eine zu große erste Version kostet mehr, erscheint später und verlangt von den ersten Nutzern den Umgang mit Komplexität, die sie weder angefragt haben noch benötigen. Ein vorgestellter künftiger Kunde verdrängt den tatsächlichen heutigen.

Fünftens: aufgeschobene wirtschaftliche Realität. Manche Teams nähern sich dem Launch, ohne ernsthaft geklärt zu haben, wie Kunden gewonnen werden, wie sich Akquisitionskosten entwickeln, wie Erlöse entstehen und was nach Betriebskosten übrig bleibt. Diese Fragen beeinflussen Preisgestaltung, Funktionsumfang und die Wahl des ersten Kundensegments von Beginn an. Wer sie verschiebt, vermeidet sie nicht. Er begegnet ihnen später, wenn Änderungen teurer und die Spielräume kleiner sind.

Der Preis der Selbstbestätigung

Eine Organisation entwickelt ihre Produkthypothese selbst. Häufig ist sie zugleich die wichtigste Interpretin der Belege, die diese Hypothese prüfen sollen. Daraus entsteht ein strukturelles Problem: Gute Absichten allein reichen nicht, um eigene Annahmen unabhängig zu bewerten.

Sobald eine These diskutiert, verfeinert, in Roadmaps übersetzt, präsentiert und genehmigt wurde, haben viele Beteiligte ein Interesse an ihrem Fortbestand. Das Team hat Zeit investiert, die Führung Kapital oder Glaubwürdigkeit. Die Alternative — das Vorhaben vor größeren Ausgaben zu beenden — wird psychologisch immer teurer. Weiterzumachen erscheint leichter.

Das Ergebnis kann ein Prozess sein, der wie Validierung aussieht, aber Selbstbestätigung erzeugt. Befragt werden wohlwollende Menschen. Positive Antworten zählen stärker als negative. Widersprüche gelten als Ausnahmen oder Stichprobenfehler. Die These übersteht eine Prüfung, die auf ihr Überleben angelegt war, und gilt anschließend als unabhängig bestätigt. Der Schaden betrifft auch die nächste Entscheidung: Die Organisation glaubt, ihre Validierungsmethode habe funktioniert.

Was Validierung tatsächlich zeigen muss

Validierung ist ein so geläufiger Begriff geworden, dass seine Bedeutung leicht unscharf wird. Fragt man Teams, ob sie ihre Idee validiert haben, lautet die Antwort häufig ja.

Auf die Frage nach dem Vorgehen folgen Umfragen, Interviews, Wartelisten oder positives Feedback aus ersten Gesprächen. Solche Methoden können nützlich sein. Allein beweisen sie jedoch noch keine tragfähige Nachfrage.

Eine Umfrage zeigt, was Menschen nach eigener Aussage glauben. Sie zeigt nicht, was sie tun, wenn sie Geld ausgeben, Gewohnheiten ändern oder eine funktionierende Alternative aufgeben sollen. Ein Interview beschreibt ein Problem in einer vergleichsweise unverbindlichen Situation. Freundliches Feedback zeigt zunächst Wohlwollen. Eine Warteliste belegt, dass etwas interessant genug für die Eingabe einer E-Mail-Adresse war. Ob es auch interessant genug für Bezahlung, Einführung und wiederholte Nutzung ist, bleibt offen.

Belastbare Validierung braucht Signale, die sich nicht allein durch die richtige Frage in freundlichem Ton erzeugen lassen. Jemand trifft eine Entscheidung: bezahlt, wechselt von einem bestehenden Angebot oder investiert Zeit in die Einführung. Die Bedingungen sollten sich der tatsächlichen Nutzung annähern. Solche Signale sind schwerer zu erzeugen als eine Umfrage. Sie entstehen langsamer, kosten mehr und können deutlicher gegen die eigene These sprechen. Genau diese Eigenschaften machen sie wertvoll.

Belege kosten mehr als Meinungen

Wie aufwendig eine Information zu gewinnen ist, kann ein Hinweis auf ihren Aussagewert sein. Ein belastbares Verhaltenssignal verlangt in der Regel mehr Arbeit als eine unverbindliche Einschätzung.

Eine Meinung zu einem Produktkonzept kann jeder äußern. Sie kommt schnell, fällt oft positiv aus und kostet die befragte Person nichts. Wer beim Kaffee sagt, eine Idee klinge interessant, hat damit noch wenig darüber verraten, ob er das Produkt bezahlen, regelmäßig nutzen oder weiterempfehlen würde. Vielleicht war er einfach höflich.

Ein Kunde, der sich vor Fertigstellung zu einer Zahlung verpflichtet, liefert ein aufwendigeres Signal. Zuvor musste das Team diesen Kunden identifizieren, erreichen und seine Aufmerksamkeit gewinnen. Es musste ein glaubwürdiges Angebot machen, das sich an bestehenden Alternativen messen lässt. Jeder Schritt verlangt Arbeit. Entsprechend ernst lässt sich die anschließende Entscheidung nehmen.

Es geht deshalb nicht darum, möglichst viele Meinungen zu sammeln. Gesucht ist ein effizienter Weg zu aussagekräftigen Belegen: der kleinste ehrliche Test, der tatsächliches Verhalten sichtbar macht. Was er zeigt, begrenzt den nächsten Entwicklungsschritt. Der Aufwand für diese Prüfung ist der Preis dafür, sich auf das Gelernte verlassen zu können.

Ein Produkt und ein Venture sind verschiedene Aufgaben

Viele Menschen entwickeln ein digitales Produkt. Ein kleinerer Teil baut zugleich ein Venture auf. Die Unterscheidung verändert Fragen, Erfolgskriterien und Entscheidungen in fast jeder Phase.

Ein Produkt ist eine Lösung für ein definiertes Problem eines definierten Nutzers. Es kann gut gestaltet, technisch belastbar und tatsächlich hilfreich sein, ohne ein tragfähiges Geschäft zu ergeben. Die Produktprüfung fragt: Funktioniert es? Lässt es sich gut bedienen? Löst es das beschriebene Problem? Diese Fragen sind wichtig, aber nicht ausreichend.

Ein Venture ist eine wirtschaftliche Hypothese. Es setzt voraus, dass ein Markt besteht, ein Kunde ein relevantes Problem hat, die Lösung zu vertretbaren Kosten angeboten werden kann und das Geschäft die nötigen Investitionen rechtfertigt. Selbst ein gutes Produkt reicht nicht, wenn der Markt zu klein ist, der Vertrieb zu teuer wird oder sich wiederkehrende Nutzung nicht in tragfähige Erlöse übersetzt.

Beide Aufgaben brauchen von Anfang an passende Prüfungen. Produktentscheidungen betrachten den Nutzen einer Funktion. Venture-Entscheidungen berücksichtigen zusätzlich die Wirtschaftlichkeit. Zur Nutzungserfahrung kommen etwa Kundenbindung, Akquisitionskosten und das Verhältnis zwischen Kundenerlösen und den Kosten seiner Gewinnung hinzu.

Wer beides vermischt, kann ein hochwertiges Produkt für ein nicht tragfähiges Geschäft entwickeln. Das Angebot ist gut, die Nutzer sind zufrieden, die Bindung erscheint vielversprechend — doch die wirtschaftliche Hypothese wurde nie eigenständig geprüft. Zu wissen, welche Aufgabe gerade gelöst wird, bestimmt die Arbeit vor dem nächsten Entwicklungsschritt.

Die unsichtbaren Kosten eines gescheiterten Vorhabens

Ein gescheitertes Produkt hat sichtbare und unsichtbare Kosten. Sichtbar sind ausgegebenes Kapital, Gehälter, vergangene Monate und verpasste Alternativen. Diese Kosten sind real. Häufig endet dort die Betrachtung.

Unsichtbar bleibt das Wissen, das nicht erhalten wurde.

Auch ein gescheitertes Vorhaben erzeugt Informationen: Wofür zahlen Kunden? Wie verhalten sich Vertriebskanäle? Welche Kosten entstehen im tatsächlichen Betrieb? Was hätte das Produkt gebraucht, um wiederholt genutzt zu werden? Diese Erkenntnisse können zu den wertvollsten Ergebnissen gehören. Trotzdem werden sie häufig nicht so festgehalten, dass sie das beteiligte Team überdauern.

Löst sich das Team auf, geht die Erfahrung mit den Menschen. Das nächste Vorhaben beginnt wieder mit ähnlichen Ausgangsannahmen, weil das Wissen in Einzelnen statt in der Organisation lag. Bereits Bekanntes muss zu vollen Kosten neu entdeckt werden.

Der Kapitalverlust steht in der Buchhaltung. Der Wissensverlust erscheint dort nicht. Über mehrere Anläufe verringert er jedoch erheblich, was sich mit derselben Investition hätte erreichen lassen. Die nächste Fehlentscheidung muss dann nicht günstiger werden als die vorige.

Wissen braucht eine Erinnerung an seine Herkunft

Es macht einen Unterschied, ob eine Organisation etwas weiß oder auch erinnert, weshalb sie es weiß.

Eine Organisation sammelt Praktiken: wie entschieden wird, was zu vermeiden ist und wo Risiken liegen. Dahinter stehen oft konkrete Erfahrungen bestimmter Menschen. Das Wissen ist real. Geht aber der Zusammenhang verloren, bleibt eine Regel ohne Begründung. Andere können nicht mehr prüfen, ob sie für ihre Situation noch passt oder längst zur Gewohnheit geworden ist.

Wer die Herkunft seines Wissens bewahrt, kann eine Praxis bis zu den zugrunde liegenden Belegen zurückverfolgen. Er kann prüfen, ob diese unter veränderten Bedingungen noch tragen. Frühere Entscheidungen helfen dann bei der Einordnung: Was wurde entschieden? Welche Arbeit führte dorthin? Was wurde erst anschließend bekannt?

Dafür muss der Zusammenhang gemeinsam mit dem Ergebnis erhalten bleiben. Zu einer Entscheidung gehören die erwogenen Alternativen, die gewichteten Belege und die verbleibende Unsicherheit. So sammelt eine Organisation neben Wissen auch Verständnis, das über Personen, Teams und Zeit hinweg nutzbar bleibt.

Gute Produkte erarbeiten sich ihre Grundlage vor dem Bauen

Die bekannte Erfolgsgeschichte stellt den Menschen in den Mittelpunkt, der etwas früher als andere erkannt, gegen Widerstände gebaut und den Markt überzeugt hat. Solche Geschichten können stimmen. Sie stammen jedoch aus einer kleinen Auswahl erfolgreicher Ergebnisse. Die viel größere Zahl erfolgloser Vorhaben wird seltener erzählt und weniger sorgfältig untersucht.

Entscheidend ist häufig die Disziplin vor der Entwicklung: länger bei offenen Fragen zu bleiben, zu prüfen statt anzunehmen und ein schnelles, gut begründetes Nein als wertvolles Ergebnis zu behandeln. Überzeugung darf vorhanden sein. Sie muss sich aber ehrlicher Kritik stellen, bevor größere Mittel eingesetzt werden.

Bevor ein Produkt veröffentlicht wird, braucht die zugrunde liegende Chance eine belastbare Grundlage. Der Markt muss verstanden, der Kunde konkret beschrieben und die Nachfrage durch mehr als interne Begeisterung gestützt sein. Die Wirtschaftlichkeit muss plausibel werden. Der Umfang orientiert sich daran, was der Markt nachweisbar benötigt, nicht allein daran, was das Team entwickeln könnte.

Das dauert länger, als sofort loszubauen. Es verlangt, Unsicherheit auszuhalten, statt sie durch Aktivität zu überdecken. Ein gut begründeter Verzicht muss als Erfolg gelten können. Und Erkenntnis muss einen eigenen Wert bekommen, auch wenn sie kein neues Produkt hervorbringt.

Dauerhafte Produkte entstehen auf einer erarbeiteten Grundlage: einem verstandenen Markt, überprüfter Nachfrage und einem Umfang, den die Belege tragen. Aus der ursprünglichen Idee wird eine Antwort auf Fragen, die jemand sorgfältig gestellt und geduldig beantwortet hat.

Diese Disziplin begrenzt nicht die Fähigkeit zu bauen. Sie schafft die Voraussetzung, um gut zu bauen.


← Zurück zum JournalEnglish version →