Stell dir einen Jenga-Turm vor. Jeder Baustein steht für eine Annahme. Nutzer haben dieses Problem. Unsere Lösung löst es. Sie werden ihr Verhalten ändern. Das Geschäftsmodell trägt. Die Technik funktioniert.
Solange niemand zieht, sieht alles stabil aus. Doch irgendwann zieht jemand. Und dann fällt der ganze Turm.
Genau so entstehen viele digitale Produkte.
Jedes Produkt beginnt mit Hypothesen. Das ist normal. Das ist unvermeidlich. Wer am Anfang eines Projekts behauptet, er wisse genau was Nutzer brauchen, lügt – oder täuscht sich selbst.
Das Problem ist nicht, dass Annahmen existieren.
Das Problem ist, dass sie unsichtbar bleiben.
In den meisten Projekten gibt es keinen Moment wo ein Team gemeinsam fragt: Was glauben wir eigentlich? Was davon haben wir überprüft? Was davon ist Wunschdenken?
Stattdessen werden Annahmen still zu Fakten erklärt. Sie wandern von der Idee in die Roadmap, von der Roadmap ins Backlog, vom Backlog in den Sprint. Und irgendwann baut ein ganzes Team auf einem Fundament, das niemand je wirklich geprüft hat.
Nicht aus Nachlässigkeit. Selten aus Unwissen. Meistens aus Druck.
Projekte starten mit Lösungen, nicht mit Fragen. Die Idee ist bereits gesetzt bevor das Problem wirklich verstanden wurde. Geschwindigkeit wird mit Fortschritt verwechselt – früh starten, viel bauen, sichtbare Resultate zeigen. Das beruhigt Stakeholder. Es reduziert aber keine Risiken.
Und dann gibt es noch das subtilste Muster: Annahmen die so selbstverständlich klingen, dass niemand sie ausspricht. Natürlich hat der Nutzer dieses Problem. Natürlich wird er die App nutzen. Natürlich passt das ins Geschäftsmodell.
Natürlich.
Wenn eine zentrale Hypothese falsch ist und niemand hat sie überprüft, merkt man das spät. Sehr spät. Dann sind Monate Arbeit, grosse Budgets und organisatorische Entscheidungen bereits in eine Richtung geflossen.
Der Schaden ist nicht nur finanziell. Teams die in Hypothesen-Jenga geraten verlieren Vertrauen – in die Methode, in die Führung, in das Produkt. Und das ist schwerer zu reparieren als ein Budget.
Hypothesen sichtbar machen.
Nicht in einem langen Workshop. Nicht mit einem komplizierten Framework. Sondern mit einer einfachen Frage zu Beginn eines Projekts: Was glauben wir – und was wissen wir wirklich?
Dann priorisieren. Nicht alle Annahmen sind gleich riskant. Einige sind existenziell: Existiert das Problem wirklich? Würden Nutzer ihr Verhalten ändern? Lässt sich damit ein tragfähiges Geschäftsmodell bauen? Diese Hypothesen müssen zuerst auf den Tisch – und zuerst überprüft werden.
Jede validierte Hypothese stabilisiert den Turm. Jede widerlegte verhindert, dass man weiter in die falsche Richtung baut.
Das ist kein Bremsen. Das ist Geschwindigkeit – die richtige Art davon.
Viele Teams messen Fortschritt in Features. In Velocity. In Releases.
In der frühen Phase eines Produkts bedeutet Fortschritt etwas anderes: Unsicherheit reduzieren. Risiko abbauen. Lernen bevor man baut.
Ein gutes Produkt entsteht nicht aus einem Turm von Annahmen. Es entsteht aus einem Prozess der Annahmen früh sichtbar macht, priorisiert und überprüft – bevor sie teuer werden.
Alles andere ist Hypothesen-Jenga.
Und irgendwann zieht jemand den falschen Baustein.
