Annahmen im Produktbau: Wann man sie fallen lassen muss

Was wir für sicher hielten — und warum das täuschte

Es gibt Annahmen, die sich so robust anfühlen, dass man gar nicht mehr bemerkt, dass es Annahmen sind. Sie stammen aus einem Gespräch, das gut verlief. Aus einem Problem, das mehrere Menschen unabhängig voneinander beschrieben haben. Aus Zahlen, die in eine Richtung zeigten. Das ist genau die Kategorie, die am teuersten werden kann — nicht weil sie zufällig falsch war, sondern weil niemand mehr nachfragte.

Ein konkretes Beispiel: Für ein Buchungssystem, das wir für eine Branche mit sehr vielen Einzelterminen entwickelt haben, gingen wir davon aus, dass die Kernfunktion — das Anlegen und Verwalten von Terminen — so früh wie möglich fertig sein muss. Fünf potenzielle Nutzerinnen hatten das Wort „Terminverwaltung" im Gespräch verwendet. Wir haben dieses Wort notiert und dann gebaut.

Was wir nicht notierten: Keine von ihnen hatte beschrieben, wie viele Termine sie täglich anlegen. Wie sie heute vorgehen. Ob das Anlegen selbst das Problem ist — oder das, was danach kommt: Erinnerungen, Absagen, Nachbearbeitungen. Wir hatten das Symptom gehört und still daraus ein Bild des Problems konstruiert, das unser war, nicht ihres.

Zwei Fehler, die sich ähnlich sehen

Der erste: Man verwechselt Zustimmung mit Bedarf. „Ja, das wäre nützlich" ist keine Aussage über Verhalten. Jemand, der einer Funktion zustimmt, wird sie nicht unbedingt benutzen — und jemand, der sie benutzt, zahlt dafür nicht unbedingt. Wir haben gelernt, diese drei Dinge auseinanderzuhalten: ob jemand etwas gut findet, ob er es benutzen würde, und ob sein Alltag sich dadurch verändert. Nur das letzte zählt.

Der zweite Fehler: Man nimmt an, dass Wiederholung Verlässlichkeit bedeutet. Wenn vier verschiedene Menschen dasselbe Problem nennen, fühlt das wie eine gesicherte Erkenntnis an. Aber vier Menschen, die denselben Satz sagen, können vier verschiedene Probleme meinen. In einem anderen Projekt hatten wir eine Funktion zu Ende gebaut, bevor wir verstanden hatten, was der Begriff, den alle verwendeten, in der Praxis jeweils bedeutete. Das Ergebnis funktionierte — für eine Lesart des Problems. Die anderen blieben außen.

Was diese Erfahrungen gemeinsam haben: Die Annahme fühlte sich nicht wie eine Annahme an. Sie hatte die Textur einer Erkenntnis — aus echten Gesprächen, echten Beobachtungen, echten Wiederholungen. Das macht sie so schwer zu erkennen. Eine Vermutung, die man als Vermutung kennt, prüft man. Eine Erkenntnis, die man für gesichert hält, trägt man einfach weiter — bis sie bricht.

Was sich zu Beginn messen lässt und was nicht

Wer ein Produkt baut, bevor der Markt darüber urteilen kann, arbeitet zwangsläufig mit Annahmen. Das ist kein Mangel und kein Fehler — es ist die Bedingung, unter der jedes Vorhaben beginnt. Der Fehler liegt woanders: wenn Annahmen nicht als solche benannt werden, sondern stillschweigend in den Plan wandern, als wären sie Fakten.

Am Anfang gibt es Dinge, die tatsächlich messbar sind. Und es gibt Dinge, die so aussehen, als wären sie messbar — aber eigentlich nur gezählt werden, ohne dass die Zahl etwas sagt.

Was sich früh tatsächlich messen lässt

In einer frühen Produktphase sind belastbare Zahlen selten, aber sie existieren. Zu den verlässlichen gehören:

Verhalten, nicht Meinung. Wer auf einen Link klickt, wer abbricht, wer zurückkommt — das lässt sich ablesen. Was jemand über sein zukünftiges Verhalten sagt, ist dagegen eine Absichtserklärung, keine Messung.
Abbruchpunkte in bestehenden Abläufen. Wenn ein Prozess heute manuell läuft und an einer bestimmten Stelle regelmäßig stockt, ist das beobachtbar — unabhängig davon, ob die Ursache schon verstanden wird.
Wiederholungsrate. Kommt jemand ein zweites Mal? Ein drittes? Das ist ein frühes Signal dafür, ob etwas einen echten Platz im Arbeitsalltag findet oder nur ausprobiert wurde.

Was sich nicht messen lässt — und trotzdem oft so behandelt wird

Schwieriger ist die zweite Gruppe. Dazu gehört die Frage, ob eine Zielgruppe ein Angebot kaufen würde, wenn es fertig wäre. Oder ob ein bestimmtes Feature den Unterschied macht zwischen Abschluss und Ablehnung. Oder ob die Menschen, die sich jetzt für eine Warteliste eintragen, auch dann noch zahlen, wenn der Preis feststeht.

Das alles lässt sich nicht messen, weil die Situation, in der die Entscheidung getroffen wird, noch nicht existiert. Man kann Näherungswerte sammeln — Gespräche, Prototyp-Reaktionen, frühe Vorbestellungen — aber diese Werte sind Indizien, keine Beweise. Sie können in die richtige Richtung deuten, und sie können täuschen.

Ein konkretes Beispiel aus der eigenen Arbeit: Für ein Buchungssystem für kleine Dienstleister war die Resonanz in frühen Gesprächen eindeutig. Alle sagten, der manuelle Aufwand sei zu hoch, eine eigene Lösung wäre willkommen. Das war eine messbare Aussage — aber sie maß die Frustration mit dem Status quo, nicht die Bereitschaft, etwas Neues einzuführen. Beides fühlt sich ähnlich an. Beides ist es nicht.

Der Unterschied zwischen diesen zwei Gruppen — was messbar ist und was Annahme bleibt — muss zu Beginn explizit gemacht werden. Nicht für externe Berichte, sondern für das Team selbst. Wer weiß, welche seiner Überzeugungen auf Daten beruhen und welche auf Plausibilität, kann beim ersten widersprüchlichen Signal unterscheiden, ob er nachschärfen oder abschreiben muss.

Das Signal, das zum Abschreiben zwingt

Es gibt Daten, die einen unruhig machen. Und es gibt Daten, die eine Entscheidung erzwingen. Der Unterschied ist selten so klar, wie man sich das wünscht.

Eine Annahme ist nicht schon widerlegt, weil etwas einmal nicht funktioniert. Systeme haben schlechte Tage. Menschen haben schlechte Wochen. Wer bei jedem Ausreißer die Richtung ändert, kommt nirgends an. Die eigentliche Frage lautet: Wann ist ein Muster kein Rauschen mehr?

Drei Situationen, in denen wir aufgehört haben zu warten

Erstens: Wenn dasselbe Problem unabhängig voneinander auftaucht. Nicht der zweite Anruf zum selben Thema — sondern zwei Personen, die sich nicht kennen, die dasselbe sagen, ohne gefragt worden zu sein. Der erste Hinweis ist ein Datenpunkt. Der zweite unabhängige Hinweis ist ein Muster.

Zweitens: Wenn der Umweg zur eigentlichen Lösung wird. Ein Bereich, der so gebaut wurde, dass Menschen ihn auf eine bestimmte Art nutzen, wird stattdessen konsequent umgangen — mit einem eigenen Weg, den sich alle still und leise beigebracht haben. An dem Punkt ist die Annahme nicht nur falsch. Sie steht dem Weg im Weg, den die Menschen tatsächlich gehen.

Drittens: Wenn niemand fehlt, was fehlt. Das ist das härteste Signal. Ein Bereich, den wir für notwendig hielten, wird nicht genutzt — und niemand fragt danach. Keine Rückmeldung, keine Beschwerde, keine Nachfrage. Stille ist kein Zeichen von Zufriedenheit. Sie ist oft das Zeichen, dass die Erwartung von Anfang an falsch war.

Das Signal von der Reaktion trennen

Was ein Signal nicht ist: eine Meinung nach einer Demonstration. Menschen, denen man etwas zeigt, sagen selten „das brauche ich nicht". Sie sagen „interessant" oder „könnte nützlich sein". Das ist keine Bestätigung — es ist Höflichkeit. Erst das tatsächliche Verhalten unter echten Bedingungen, ohne dass jemand zuschaut, zeigt, ob eine Annahme trägt.

Ein Beispiel aus unserem Alltag: Wir bauten eine Übersichtsansicht für ein Buchungssystem, weil wir davon ausgingen, dass der erste Blick in den Tag der wichtigste Moment sei. Gemessen haben wir, wie oft diese Ansicht geöffnet wurde. Sie wurde geöffnet — aber nie länger als drei Sekunden. Die Menschen navigierten sofort weiter. Die Annahme, dass sie dort verweilen würden, war falsch. Das Signal war eindeutig: nicht die Öffnungsrate, sondern die Zeit, die jemand tatsächlich damit verbrachte — reproduziert über drei Wochen, unabhängig von Tageszeit und Gerät.

An diesem Punkt ist die Frage nicht mehr, ob man die Annahme fallen lässt. Die Frage ist nur noch, wie schnell — und was man stattdessen gebaut hätte, wenn man früher hingeschaut hätte.

Was das Festhalten konkret gekostet hat

Das Offensichtlichste ist Entwicklungszeit. Wenn ein Team sechs Wochen an einem Bereich arbeitet, der auf einer Annahme basiert, die sich drei Wochen früher hätte überprüfen lassen, sind drei Wochen weg. Nicht verschwendet im Sinne schlechter Arbeit — die war gut. Aber in die falsche Richtung gewendet.

Das weniger Offensichtliche ist, was in diesen Wochen nicht passiert ist. Die Frage, die nicht gestellt wurde, weil die Antwort ja schon klar war. Das Gespräch, das nicht stattfand, weil man sich sicher war. Ein Produkt, das drei Monate zu spät an den Punkt kommt, an dem man echte Nutzung sieht, verliert diese drei Monate nicht als Kalenderzeit, sondern als Information.

In einem unserer Projekte hatten wir uns früh entschieden, wie Nutzer einen bestimmten Arbeitsschritt erledigen würden. Die Entscheidung war nicht unüberlegt — sie basierte auf Gesprächen, auf dem, was wir aus ähnlichen Projekten kannten, auf dem, was sinnvoll klang. Was sie nicht basierte auf: wie die Nutzer diesen Schritt tatsächlich in ihrem Alltag angingen.

Als wir das vier Monate später verstanden, hatten wir:

eine fertig gebaute Funktion, die kaum jemand nutzte
eine Datenstruktur, die auf die falsche Nutzung ausgelegt war und sich nicht ohne Weiteres umstellen ließ
ein Team, das das ungute Gefühl schon früher hatte, es aber nicht laut sagte — weil die Annahme nie als Annahme markiert worden war

Der dritte Punkt ist der teuerste. Wer nicht weiß, dass etwas eine Annahme ist, behandelt es wie eine Tatsache. Er baut darauf. Er zweifelt nicht daran. Er erwähnt nicht, wenn er etwas sieht, das dagegen spricht — denn es gibt ja nichts, wogegen etwas sprechen könnte.

Festhalten kostet auch dann, wenn die Annahme zufällig stimmt. Der Moment, in dem man aufhört zu prüfen, ist der Moment, in dem man aufhört zu sehen. Eine Annahme, die nie zur Frage wird, wächst mit der Zeit fester — und wird dadurch teurer zu revidieren, wenn sich doch noch herausstellt, dass sie falsch war.

Die versteckte Rechnung

Was in keiner Nachbetrachtung auftaucht: die Entscheidungen, die unter dem Einfluss der falschen Annahme getroffen wurden, bevor der Fehler überhaupt sichtbar war. Wer plant, solange der Irrtum noch nicht aufgedeckt ist, vergrößert ihn stillschweigend. Eine falsche Annahme über das Nutzungsverhalten verändert, welche Funktionen priorisiert werden, wie ein Ablauf strukturiert wird, welche Rückfragen man sich spart. Der eigentliche Schaden ist nicht die falsche Funktion — es ist die Form, die das Produkt deswegen angenommen hat. Die lässt sich nicht einfach herausoperieren; sie steckt in allem, was danach gebaut wurde.

Wie das Team heute mit offenen Fragen umgeht

Die wichtigste Veränderung war keine neue Methode. Es war eine Unterscheidung, die heute am Anfang jedes Projekts steht: Was wissen wir — und was nehmen wir an?

Klingt selbstverständlich. Ist es nicht. In der Praxis vermischen sich beide Kategorien fast automatisch, weil eine Annahme, die niemand widerspricht, sich mit der Zeit anfühlt wie ein Fakt. Das Team schreibt sie heute explizit auf — in zwei Spalten, nicht einer.

Jede Annahme bekommt ein Verfallskriterium

Nicht im Sinne eines Deadlines. Sondern als Antwort auf die Frage: Wann würden wir merken, dass diese Annahme nicht trägt? Bei einem Buchungssystem für Friseure hatten wir anfangs angenommen, dass Stammkunden regelmäßig zurückbuchen. Die Gegenannahme wurde sofort mitformuliert: Wenn nach acht Wochen weniger als ein Drittel einen zweiten Termin gebucht hat, stimmt das Bild nicht. Dieses Kriterium stand von Anfang an fest — nicht rückwirkend, wenn die Zahlen unbequem wurden.

Das klingt streng, ist aber das Gegenteil von Misstrauen. Wer das Kriterium erst formuliert, wenn die Ergebnisse schon vorliegen, wird fast immer einen Grund finden, warum es diesmal anders ist.

Eine Person trägt die Annahme

Für jede offene Annahme gibt es heute eine Person im Team, die sie beobachtet. Nicht um sie zu verteidigen — um das Signal zu erkennen, wenn es kommt. Diese Verantwortung klingt klein. Tatsächlich ist es der einzige Schutzmechanismus dagegen, dass ein schwaches Signal in einer vollen Woche untergeht.

In einem früheren Projekt war niemand zuständig dafür, dass eine Annahme über die Nutzungsfrequenz überprüft wurde. Das Signal kam — in Form von Abbruchquoten, die niemand erwartet hatte. Es blieb drei Monate unbemerkt, weil die Zahl zwar sichtbar war, aber niemand sie mit der Annahme in Verbindung gebracht hatte, die sie widerlegte.

Offene Fragen bleiben offen — bis sie es nicht mehr sind

Es gibt Dinge, die sich zu Beginn eines Projekts schlicht nicht messen lassen. Wie oft jemand wirklich in ein System schaut. Ob eine Funktion, die theoretisch Zeit spart, auch tatsächlich genutzt wird. Das Team dokumentiert diese Fragen heute als offene Fragen — nicht als Annahmen mit positivem Vorzeichen, sondern als bewusste Leerstellen.

Der Unterschied ist nicht semantisch. Eine als offen markierte Frage erinnert daran, dass hier noch kein Urteil gefällt wurde. Eine als Annahme formulierte Version derselben Frage suggeriert, dass jemand bereits entschieden hat — und das Gehirn hört auf, aktiv nach dem Gegenteil zu suchen.

Was das Team nicht getan hat: ein System eingeführt, das diesen Prozess automatisch absichert. Das wäre die falsche Hoffnung. Annahmen sichtbar zu halten ist eine Gewohnheit, keine Einstellung in einem Werkzeug. Und Gewohnheiten entstehen durch Wiederholung — durch das wiederholte Unbehagen, eine Annahme aufzuschreiben, die man eigentlich lieber still gelassen hätte.