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. Irgendwann zieht jemand. Und dann fällt der ganze Turm.
Ich habe das mehrfach erlebt. Und ich habe gelernt, wann es passiert.
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 fast jedem Projekt, in dem ich gearbeitet habe, gab es keinen Moment, in dem das Team gemeinsam gefragt hat: 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. Irgendwann baut ein ganzes Team auf einem Fundament, das niemand je wirklich geprüft hat.
Meistens aus Druck. Projekte starten mit Lösungen, nicht mit Fragen – die Idee ist gesetzt, bevor das Problem wirklich verstanden wurde. Geschwindigkeit wird mit Fortschritt verwechselt. 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 Annahme 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. Ich kenne Projekte, die technisch sauber durchgeführt wurden – Zeitplan eingehalten, Budget getroffen, Scope geliefert – und trotzdem scheiterten. Nicht weil schlecht gearbeitet wurde, sondern weil niemand die Fundament-Frage gestellt hatte.
Teams, die in Hypothesen-Jenga geraten, verlieren Vertrauen – in die Methode, in die Führung, in das Produkt. Das ist schwerer zu reparieren als ein Budget.
Ich fange mit einer Frage an, die selten gestellt wird: Was glauben wir – und was wissen wir wirklich?
Nicht in einem langen Workshop. Nicht mit einem komplizierten Framework. Sondern bevor das Backlog steht, bevor die Roadmap gezeichnet wird – zu dem Zeitpunkt, wo es noch etwas kostet, die Antwort zu kennen, aber wenig kostet, sie herauszufinden.
Nicht alle Annahmen sind gleich riskant. Die existenziellen Fragen – Existiert das Problem wirklich? Würden Menschen ihr Verhalten ändern? Lässt sich damit etwas Tragfähiges bauen? – diese müssen zuerst auf den Tisch.
Jede überprüfte Annahme 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.
Ich habe gelernt, Fortschritt anders zu messen als in Features, Velocity oder 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 – sondern aus einem Prozess, der Annahmen früh sichtbar macht und überprüft, bevor sie teuer werden.
Alles andere ist Hypothesen-Jenga.
Und irgendwann zieht jemand den falschen Baustein.
