Discovery: Das Problem verstehen, bevor man löst
Der häufigste Fehler in der Produktentwicklung ist nicht schlechte Ausführung — es ist das Lösen des falschen Problems. CB Insights hat in einer vielzitierten Analyse der Gründe für das Scheitern von Startups festgestellt, dass 35 Prozent aller gescheiterten Unternehmen angaben, kein Marktbedürfnis adressiert zu haben. Das ist keine Aussage über schlechte Teams oder mangelndes Kapital. Es ist eine Aussage über eine übersprungene Discovery-Phase.
Discovery bedeutet: das Problem validieren, bevor man mit der Lösung beginnt. Das umfasst Nutzerinterviews mit potenziellen Kunden, Wettbewerbsanalysen, Marktforschung und eine ehrliche Auseinandersetzung mit der Frage, ob das identifizierte Problem tatsächlich groß genug ist, um ein Produkt zu rechtfertigen. Die Methoden dafür — Jobs-to-be-Done-Interviews, Problem-Hypothesen, qualitative Feldforschung — sind bekannt, werden aber in der Praxis regelmäßig zugunsten schnellerer Ergebnisse übersprungen. Der Preis dafür zahlt sich meist erst nach Monaten der Entwicklungsarbeit.
Definition: Scope setzen, bevor Anforderungen wachsen
Sobald das Problem ausreichend verstanden ist, beginnt die Definitionsphase. Hier werden aus Erkenntnissen Entscheidungen: Was wird das Produkt konkret tun? Für wen genau? In welchem Rahmen? Diese Phase produziert keinen Code und kein Design — sie produziert Klarheit. Und Klarheit ist das, was die meisten Projekte am wenigsten haben, wenn die eigentliche Arbeit beginnt.
Scope-Creep — das schleichende Wachsen des Projektumfangs ohne entsprechende Anpassung von Budget oder Zeitplan — ist die häufigste Ursache für überschrittene Budgets und verfehlte Deadlines. Er entsteht fast immer aus einer unvollständigen Definitionsphase. Was nicht explizit ausgeschlossen wurde, wird irgendwann als selbstverständlich vorausgesetzt. Ein gutes Produkt-Briefing definiert deshalb nicht nur, was gebaut wird — es definiert auch, was bewusst nicht gebaut wird. Das klingt trivial. In der Praxis ist es eine der schwierigsten Entscheidungen im gesamten Prozess.
Design-Iteration: Zwischen Konzept und Realität
Die Design-Phase ist nicht der Schritt, in dem Entscheidungen visualisiert werden — sie ist der Schritt, in dem sie getroffen werden. Wireframes, Prototypen und Nutzertests sind keine Dokumentation eines bereits gefundenen Weges; sie sind das Werkzeug, mit dem der Weg gefunden wird. Das bedeutet, dass diese Phase grundsätzlich iterativ ist und Ergebnisse produziert, die man verwerfen und überarbeiten kann — was kein Zeichen von Schwäche ist, sondern das Ziel.
Jake Knapp, der bei Google Ventures das Design-Sprint-Format entwickelt hat, bringt das auf eine griffige Formel: Ein fünftägiger Design-Sprint kann Monate an Entwicklungsarbeit ersparen, weil er zwingt, Annahmen zu testen, bevor sie in Code gegossen werden. Das Grundprinzip dahinter gilt universell — je früher im Prozess Fehlentscheidungen sichtbar werden, desto günstiger ist ihre Korrektur. Eine geänderte Wireframe-Ansicht kostet nichts. Eine geänderte Datenbankarchitektur nach drei Monaten Entwicklung kostet erheblich.
Entwicklung und Testing: Qualität ist kein Schlussspurt
In der Entwicklungsphase besteht die größte Gefahr darin, Qualitätssicherung als nachgelagerten Prozess zu behandeln. Testing — sowohl technisches als auch nutzerseitiges — gehört von Beginn an in den Entwicklungszyklus. Continuous Integration, automatisierte Regressionstests und regelmäßige Usability-Reviews sind keine optionalen Add-ons für große Projekte. Sie sind das, was sicherstellt, dass ein wachsendes Codebase nicht zunehmend fragil wird.
Das gilt besonders für den Aspekt der Nutzerqualität. Ein Produkt, das technisch fehlerfrei läuft, aber in zentralen User Flows Reibung erzeugt, ist kein fertiges Produkt — es ist ein technischer Prototyp mit einer Oberfläche. IDEOs Design-Thinking-Methodik betont deshalb, dass Empathie mit dem Nutzer kein einmaliger Schritt in der Discovery-Phase ist, sondern eine durchgehende Haltung, die jede Phase des Entwicklungsprozesses durchzieht. Entwickler, die Nutzer-Feedback in ihre Arbeit integrieren, bauen robustere Produkte als solche, die es nicht tun.
Launch und danach: Warum der Launch nicht das Ziel ist
Der Launch eines digitalen Produkts ist kein Abschluss — er ist der Beginn des eigentlichen Lernzyklus. Die ersten echten Nutzer im echten Kontext verhalten sich in der Regel anders als Teilnehmer in kontrollierten Tests. Seiten, die im Prototyp-Test perfekt funktionierten, können in der Live-Umgebung überraschende Abbruchpunkte entwickeln. Features, die das Team für zentral hielt, werden kaum genutzt; Nebenfunktionen, die als optional galten, erweisen sich als Kernbedürfnis.
Ein guter Produktprozess endet deshalb nicht mit dem Launch, sondern definiert schon in der Discovery-Phase, wie nach dem Launch gemessen, gelernt und iteriert wird. Welche Metriken zeigen echten Produkterfolg — nicht nur Traffic, sondern Nutzungstiefe, Wiederkehrquoten, Aufgabenerfüllungsraten? Wer diese Fragen nach dem Launch stellt, verliert wertvolle Zeit. Wer sie davor beantwortet, hat ein Produkt, das tatsächlich lernt.