Wann wir eine Produktannahme abschreiben

Womit ein Team beginnt, wenn die Zahlen noch nicht da sind

Vor dem ersten Nutzungsdatum, vor dem ersten Klickpfad, vor dem ersten Supportticket steht eine Entscheidung: Womit rechtfertigt das Team, dass es das Richtige baut? Die ehrliche Antwort lautet fast immer: mit Gesprächen, mit Beobachtungen aus früheren Projekten und mit dem kollektiven Bauchgefühl derer, die im Raum sitzen.

Das ist kein Fehler. Es ist der Ausgangszustand. Der Fehler passiert einen Schritt später — wenn das Team so tut, als wären diese Annahmen bereits Erkenntnisse.

Annahmen aufschreiben, bevor die erste Zeile gebaut wird

Was wir gelernt haben, nie zu überspringen: die tragende Annahme eines Vorhabens in einem Satz aufzuschreiben, bevor etwas gebaut wird. Nicht die Anforderung, nicht die technische Beschreibung — sondern die Wette darunter. „Wir glauben, dass Verwalter diesen Schritt mindestens dreimal pro Woche machen." Oder: „Wir nehmen an, dass das Problem nicht die Erfassung ist, sondern das Wiederfinden."

Diese Sätze sehen unspektakulär aus. Sie zu schreiben dauert zehn Minuten. Aber sie erzwingen etwas, das unangenehm ist: Das Team muss sich einigen, worauf es sich genau einlässt. Nicht auf eine Produktvision — auf eine prüfbare Behauptung über das Verhalten echter Menschen.

Oft zeigt sich in diesem Gespräch, dass zwei Personen im gleichen Raum unterschiedliche Annahmen hatten — und beide davon ausgingen, die andere denke genauso. Das ist der produktivste Moment des frühen Stadiums, weil er der billigste ist.

Was aus eigenen Projekten zurückbleibt

In einem unserer Projekte für einen Dienstleister mit wiederkehrendem Kundenkontakt lautete die Ausgangsannahme: Der Engpass liegt bei der Dateneingabe. Die Nutzer verbringen zu viel Zeit damit, Informationen einzutragen. Gebaut wurde entsprechend — schnelle Eingabemasken, Vorausfüllungen, kurze Wege.

Was sich drei Monate später zeigte: Der Engpass lag beim Wiederfinden. Nicht beim Eintragen. Die Eingabe war nie das Problem gewesen — aber weil niemand diese Annahme aufgeschrieben hatte, war auch niemand in der Position gewesen, sie zu hinterfragen. Sie hatte einfach als Tatsache im Raum gestanden.

Der Unterschied zwischen einer aufgeschriebenen Annahme und einer unausgesprochenen ist nicht akademisch. Eine aufgeschriebene Annahme hat ein Verfallsdatum. Man kann zurückgehen und fragen: Gilt das noch? Eine unausgesprochene verändert sich still mit jeder Entscheidung, die auf ihr aufbaut — bis das Team sechs Monate später auf einem Fundament steht, das niemand so gebaut hätte, wenn er es von Anfang an gesehen hätte.

Annahme benennen: Was genau glauben wir über das Verhalten der Nutzer?
Priorität festlegen: Welche dieser Annahmen trägt das Vorhaben — und welche ist nur bequem?
Signal definieren: Woran würden wir merken, dass die Annahme nicht stimmt?

Das letzte dieser drei Punkte ist das schwierigste. Es verlangt, sich schon am Anfang vorzustellen, wie die Widerlegung aussähe — bevor man in das Vorhaben investiert hat und ein Interesse daran entwickelt, sie nicht zu sehen.

Was sich wirklich messen lässt — und was Annahme bleibt

Wer Software baut, hat früh das Gefühl, alles sei messbar. Klicks, Aufrufe, wie lange jemand auf einer Seite bleibt, wo er abbricht — das lässt sich zählen. Und weil es sich zählen lässt, wirkt es wie Wissen. Das ist der erste Irrtum.

Was Zahlen zeigen, ist Verhalten. Was sie nicht zeigen, ist Bedeutung. Jemand öffnet eine Funktion dreimal und nutzt sie nie. Bedeutet das, die Funktion ist falsch? Oder dass sie falsch beschriftet ist? Oder dass die Person jedes Mal durch etwas unterbrochen wurde? Die Zahl ist identisch, die Ursache vollkommen verschieden.

Was tatsächlich messbar ist

Messbar sind Ereignisse: Ein Formular wird abgeschickt oder nicht. Eine Ansicht wird aufgerufen. Ein Vorgang wird bis zum Ende geführt oder mittendrin verlassen. Diese Ereignisse sind zuverlässig, weil sie keine Interpretation brauchen. Sie sind entweder eingetreten oder nicht.

Wie viele Personen eine bestimmte Funktion mindestens einmal aufgerufen haben
An welcher Stelle ein Prozess regelmäßig endet, bevor er abgeschlossen ist
Ob eine Änderung an der Oberfläche dazu führt, dass mehr oder weniger Menschen den nächsten Schritt gehen
Wie oft Rückfragen zu einem bestimmten Bereich eingehen — und ob das nach einer Änderung weniger werden

Das sind Fakten. Kein Team muss darüber diskutieren, ob sie zutreffen. Sie sind eingetreten oder nicht.

Was Annahme bleibt — auch wenn man sehr sicher ist

Annahme ist alles, was Absicht erklärt. Warum jemand einen Vorgang abbricht. Ob sie zufrieden war oder nur fertig. Ob er wiederkommen wird. Ob eine Funktion anders genutzt würde, wenn sie anders hieße oder an anderer Stelle stünde.

Die häufigste Verwechslung in der eigenen Arbeit: Eine Funktion wird selten aufgerufen, und das Team schließt daraus, sie werde nicht gebraucht. Das kann stimmen. Es kann aber auch bedeuten, dass sie nicht gefunden wird, dass sie zu früh im Ablauf steht, oder dass die Menschen, für die sie gebaut wurde, noch gar nicht im System sind. Alle drei Erklärungen sehen im Datensatz gleich aus.

Eine andere Verwechslung, die teurer war: Jemand nutzt eine Funktion täglich. Das Team wertet das als Bestätigung. Dabei kann tägliche Nutzung auch bedeuten, dass die Funktion einen Aufwand nicht abnimmt, sondern ihn erst erzeugt — und die Nutzerin sie täglich braucht, weil etwas anderes nicht funktioniert. Häufige Nutzung und nützliche Nutzung sind zwei verschiedene Dinge.

Die Frage, die den Unterschied macht

Wer Fakten und Annahmen nicht trennt, diskutiert dieselbe Frage zweimal: einmal als Datenfrage, einmal als Meinungsfrage. Das kostet Zeit, und am Ende entscheidet meistens die Meinung — weil die Daten nicht das beantworten, was man eigentlich wissen wollte.

Was hilft, ist nicht kompliziert: Vor jeder Entscheidung benennen, was davon beobachtet wurde und was nicht. Nicht als Ritual, sondern weil es die Frage verändert. Aus „Diese Funktion wird kaum genutzt, sollen wir sie entfernen?" wird dann: „Wir wissen, dass sie selten aufgerufen wird. Wir wissen nicht, ob das an ihr liegt oder an ihrer Stelle im Ablauf. Was müssten wir beobachten, um das zu unterscheiden?"

Das ist keine Garantie für die richtige Entscheidung. Aber es ist der Unterschied zwischen einer Annahme, die man kennt, und einer, die man für einen Fakt hält. Letztere ist die, die einen Irrweg auslöst — nicht weil sie falsch war, sondern weil niemand sie als Annahme behandelt hat.

Die Signale, die eine Annahme kippen

Ein Signal kippt eine Annahme nicht durch seinen bloßen Widerspruch. Es kippt sie durch Wiederholung — durch das dritte oder vierte Mal, dass dieselbe Beobachtung aus einer anderen Quelle kommt.

Das erste Mal lässt sich erklären. Ein Nutzer hat etwas falsch verstanden. Das Gespräch verlief unter ungünstigen Bedingungen. Die Stichprobe war zu klein. Wer Annahmen beim ersten Gegenbeispiel verwirft, verwirft zu viel zu früh. Wer wartet, bis kein Zweifel mehr möglich ist, wartet zu lange. Dazwischen liegt das, worüber es sich zu sprechen lohnt.

Wenn das Verhalten von der Absicht abweicht

Jemand sagt, er wolle eine Funktion nutzen. Er nutzt sie nicht. Das ist kein Missverständnis — das ist eine Annahme, die eine Nutzung prognostiziert hat und sich jetzt gegen eine messbare Realität stellt. Die Lücke zwischen Absicht und Verhalten ist in fast jedem Projekt das erste Signal, das Bedeutung trägt.

Eine Verwalterin bat uns, eine bestimmte Übersicht prominenter zu platzieren, weil sie diese täglich brauche. Vier Wochen nach der Änderung öffnete sie diese Übersicht durchschnittlich einmal pro Woche. Das Gegenteil war nicht eingetreten — aber unsere Annahme über den Stellenwert dieser Funktion in ihrer täglichen Arbeit war falsch gewesen.

Wenn Umgehungswege zur Gewohnheit werden

Wer einen Umweg geht, hat eine Entscheidung getroffen. Vielleicht unbewusst, vielleicht aus Gewohnheit — aber getroffen. Wenn drei unabhängige Nutzerinnen und Nutzer denselben Umweg beschreiten, ist das ein Signal über den Weg, den wir gebaut haben.

Wir hatten einmal eine Filterlogik so gestaltet, dass ein bestimmtes Ergebnis erreichbar war, aber nur über mehrere Schritte. Nutzer begannen, eine andere Seite als Ausgangspunkt zu wählen, von der aus der Weg kürzer war. Keiner meldete sich dazu. Keiner beschwerte sich. Der Umweg wurde zur Gewohnheit. Erst als wir die Navigationspfade auswerteten, erkannten wir, dass unsere Annahme über den natürlichen Einstiegspunkt falsch gewesen war. Bis dahin hatten wir drei Monate eine Logik gepflegt, die niemand so benutzte wie gedacht.

Wenn derselbe Einwand in unterschiedlicher Form wiederkehrt

Manchmal ist das Signal nicht ein einzelner Widerspruch, sondern ein Muster aus vielen kleinen. Jemand fragt nach einem Exportweg. Jemand anderes möchte eine Benachrichtigung. Ein dritter würde eine Seite gerne in einem anderen Fenster öffnen. Das sind nicht drei verschiedene Wünsche — das ist ein Hinweis, dass etwas in der Grundlogik nicht passt. Die Formulierungen sind verschieden; die Ursache nicht.

Solche Muster erkennt man nur, wenn man sie nebeneinanderlegt. Im Einzelgespräch klingt jeder Wunsch nach einer Kleinigkeit. Erst zusammen zeigen sie, wo eine Annahme gehalten hat, die nicht halten sollte.

Wenn Stille kein Einverständnis ist

Kein Feedback bedeutet nicht, dass alles stimmt. Es bedeutet, dass niemand den Aufwand für eine Rückmeldung als lohnend betrachtete — oder dass die Nutzung so selten geworden ist, dass es niemanden mehr betrifft.

Ein Bereich, den wir für ein kleineres Projekt entwickelt hatten, erzeugte nach dem Launch keine einzige Rückmeldung. Wir interpretierten das zunächst als Erfolg. Erst die Auswertung zeigte, dass diesen Bereich von Anfang an fast niemand geöffnet hatte. Die Annahme, er werde genutzt, war falsch. Die Stille hatte sie nicht bestätigt — sie hatte sie verdeckt.

Verhalten weicht von der geäußerten Absicht ab — wiederholt, nicht einmalig.
Umgehungswege werden still zur Standardpraxis.
Ähnliche Bitten häufen sich, ohne dass jemand die Gemeinsamkeit benennt.
Eine Funktion erzeugt keine Rückmeldung und wird auch nicht genutzt.

Keines dieser Signale ist für sich genommen eindeutig. Zusammen zeichnen sie ein Bild, das klarer ist als jede Vorabumfrage es hätte sein können.

Was das Festhalten kostet: zwei Irrwege aus der eigenen Arbeit

Es gibt einen bestimmten Moment, den die meisten Entwicklungsteams kennen: Man hat eine Annahme formuliert, erste Signale sprechen dagegen — aber man zieht weiter. Nicht aus Überzeugung, sondern weil das Umkehren sich anfühlt wie Aufgeben. Was dabei entsteht, ist selten ein offenes Scheitern. Es ist ein langsam wachsender Schuldenposten, den man erst am Ende der Abrechnung sieht.

Irrweg 1: Das Nutzungsversprechen, das niemand einlöste

Für ein Buchungssystem hatten wir früh die Annahme, dass Kundschaft eine Funktion zur Auslastungsplanung aktiv nutzen würde — wir sahen sie als Kernelement, das den Unterschied ausmachen sollte. Nach dem Launch zeigten drei Wochen Nutzungsdaten: Die Funktion wurde geöffnet, kurz angesehen, und dann nicht mehr berührt. Wir hatten das als Eingewöhnungsphase interpretiert. Nach sechs Wochen hatten wir die Interpretation nicht geändert.

Wir haben damals nicht gefragt, warum. Wir haben gewartet. Und in der Zwischenzeit neue Abhängigkeiten gebaut, die genau diese Funktion voraussetzten. Als wir schließlich mit den Nutzenden sprachen, war die Antwort nüchtern: Die Planung fand woanders statt — in einem Kalender, den sie nicht wechseln wollten und auch nicht mussten. Unsere Annahme, dass das Buchungssystem der zentrale Planungsort werden würde, war falsch. Drei Monate lang hatten wir darauf gebaut.

Der Preis war nicht das, was wir gebaut hatten. Es war, was wir in dieser Zeit nicht gebaut hatten — Funktionen, die tatsächlich genutzt wurden, und Erkenntnisse, die wir schon früher hätten haben können, wenn wir früher gefragt hätten.

Irrweg 2: Die Annahme, die erst beim Rollout einen Namen bekam

Bei einem anderen Projekt hatten wir stillschweigend angenommen, dass die vorhandene Datenbasis unserer Kundschaft regelmäßig und konsistent gepflegt war. Die gesamte Importlogik baute darauf auf. In der Testphase funktionierte alles — weil wir mit Testdaten gearbeitet hatten, die wir selbst erzeugt hatten. Beim ersten echten Import mit einer realen Datei aus dem laufenden Betrieb war ein Drittel der Einträge in einem Format, das wir nicht vorgesehen hatten.

Das eigentliche Problem war nicht das Format. Es war, dass wir die Annahme nie explizit gemacht hatten. Sie hatte keinen Namen, stand in keinem Dokument, und deshalb hatte sie auch niemand hinterfragt. Sie war einfach dagewesen — als selbstverständliche Bedingung, bis sie es nicht mehr war.

Was das kostete: zwei Wochen Nacharbeit, einen verschobenen Rollout und das Vertrauen, das in den ersten Wochen nach einer Einführung entweder gewonnen oder verspielt wird. Ein frühes Gespräch über echte Produktionsdaten hätte die Annahme in einer Stunde sichtbar gemacht.

Beide Fälle haben dasselbe Muster: Die Annahme war nie explizit formuliert worden. Sie konnte deshalb auch nicht gezielt geprüft werden. Und als die Signale kamen, fehlte das Kriterium, anhand dessen man hätte entscheiden können, ob sie bereits reichten — oder ob man noch warten sollte.

Ab wann ein Signal reicht, um umzukehren

Die Frage stellt sich selten so eindeutig, wie man es sich wünscht. Ein einzelnes negatives Signal rechtfertigt keine Kehrtwende — das stimmt. Aber wer auf Eindeutigkeit wartet, hat die Kosten des Festhaltens meist schon bezahlt, bevor die Eindeutigkeit eintrifft.

Was in der Praxis hilft, ist keine Schwellenwert-Formel, sondern eine andere Frage: Erklärt das Team das Signal weg, oder nimmt es es ernst? Wenn die erste Reaktion auf eine enttäuschende Zahl, auf ein ausbleibendes Verhalten oder auf ein Gespräch mit einem Nutzer darin besteht, Gründe zu finden, warum dieses Signal nicht zählt — zu klein, zu früh, falsche Gruppe — dann ist das oft der Moment, in dem man innehalten sollte. Nicht weil die Erklärung falsch ist. Sondern weil sie gesucht wurde.

Was ein Signal schwer macht

Ein Signal wird erst dann zum Entscheidungsanlass, wenn es wiederholbar ist und wenn es nicht von einer gleichzeitigen Veränderung überlagert wird. Ein Feature, das niemand nutzt, ist ein anderes Signal als ein Feature, das in der Woche nach einer schlechten Einführung niemand nutzt. Der Unterschied liegt nicht in der Zahl, sondern im Kontext.

Trotzdem gibt es Situationen, in denen ein einzelnes Signal ausreicht. Wenn ein Nutzer beschreibt, wie er das Feature umgeht — nicht weil es nicht funktioniert, sondern weil es ihm nicht hilft —, ist das aussagekräftiger als hundert Sitzungsprotokolle ohne Klick. Verhalten ist schwerer zu erklären weg als eine Zahl.

Drei Konstellationen, bei denen wir früher umgekehrt wären

Das Signal ist schwach, aber es wiederholt sich. Drei Nutzer, die denselben Umweg nehmen, ohne sich abgesprochen zu haben, sind kein Zufall. Wir haben das einmal als Stichprobe abgetan — zu wenige, zu ähnlich. Vier Wochen später hatten wir mehr davon, aber keinen einzigen Nutzer, der den direkten Weg genommen hatte.
Das Team redet über das Feature, aber die Nutzer reden nicht darüber. Wenn etwas gebaut wurde und in keinem Gespräch mit Nutzern auftaucht — nicht als Lob, nicht als Problem —, ist das Schweigen ein Befund. Nicht jedes Feature muss laut sein, aber manche Stille bedeutet, dass es schlicht nicht vorkommt.
Die Annahme hat sich verschoben, ohne dass jemand es ausgesprochen hat. Manchmal passt das Team die Beschreibung des Problems an, ohne die Lösung zu ändern. Das ist der Moment, in dem die ursprüngliche Annahme längst abgeschrieben ist — nur eben intern, stillschweigend. Wer das ausspricht, spart sich meistens mehrere Wochen.

Es gibt keine Zahl von Signalen, nach der eine Entscheidung sicher ist. Was es gibt, ist ein Punkt, an dem das Festhalten teurer ist als das Umkehren — und dieser Punkt liegt fast immer früher, als er sich anfühlt.