Wenn Bauchgefühl und Daten nicht übereinstimmen

Die Situation, in der das Team nicht länger warten kann

Ein Projekt läuft seit mehreren Monaten. Erste Rückmeldungen liegen vor. Einige sprechen dafür, weiterzumachen. Einige dagegen. Die Datenlage ist dünn, aber die Frage steht: Weiterentwickeln oder einfrieren?

Das ist kein Ausnahmefall. Das ist der Normalzustand produktiver Arbeit.

Die Mehrzahl der Entscheidungen, die ein Entwicklungsteam trifft, wird nicht getroffen, weil die Lage klar ist — sondern weil sie nicht länger aufgeschoben werden kann. Eine Datenlage, die gut genug für eine belastbare Entscheidung wäre, entsteht meistens erst dann, wenn die Entscheidung längst gefallen und teuer geworden ist.

Was gemessen wird – und warum das manchmal nicht reicht

Zahlen sind selten das Problem. Die meisten Projekte haben Zahlen: wie oft etwas genutzt wird, wo Abbrüche entstehen, wie lange Bearbeitungen dauern. Was fehlt, ist die Verbindung zwischen diesen Zahlen und der Frage, die gerade auf dem Tisch liegt.

Ein Beispiel aus unserer Arbeit: Wir haben ein Kontaktformular überarbeitet, weil die Abbruchrate hoch war. Nach der Überarbeitung sank sie. Das klang nach einem Erfolg. Drei Monate später zeigte sich, dass die Anfragen, die jetzt ankamen, deutlich weniger qualifiziert waren als zuvor. Wir hatten eine Zahl verbessert — und gleichzeitig eine andere verschlechtert, die wir nicht gemessen hatten.

Was eine Zahl allein nicht sagt

Eine Messung beschreibt immer nur das, was gemessen wurde. Was nicht gemessen wurde, bleibt unsichtbar — auch wenn es wichtiger wäre als das Sichtbare.

In diesem Fall: Wir wussten, wie viele Menschen das Formular abschickten. Wir wussten nicht, was mit diesen Menschen danach passierte. Die Verbindung zwischen dem Absenden und der Qualität der Anfrage hatte niemand gezogen. Das ist kein technisches Versäumnis. Es ist ein Frage-Problem: Was ist die eigentliche Frage? Die Abbruchrate war nicht die eigentliche Frage — sie war die leicht messbare Stellvertreterin für etwas Schwerer-Messbares.

Annahmen, die nie ausgesprochen wurden

Hinter jeder Entscheidung stecken Annahmen, die das Team nicht explizit gemacht hat. In dem Beispiel lautete die stille Annahme: Eine geringere Abbruchrate bedeutet bessere Anfragen. Diese Annahme war nie ausgesprochen worden. Nie überprüft. Einfach als selbstverständlich geltend — bis sie sich als falsch herausstellte.

Stille Annahmen sind teurer als ausgesprochene, weil niemand sie anfechten kann, wenn sie nicht auf dem Tisch liegen.

Wie lange man an einer Annahme festhält

Der Moment, in dem eine Annahme aufzugeben ist, kommt selten klar. Meistens gibt es ein Signal, das das Team wahrnimmt — aber zunächst als Ausnahme behandelt. Dann ein zweites Signal, das wieder als Ausnahme gilt. Irgendwann ist erkennbar, dass die Ausnahmen die Regel sind. Aber dieser Punkt liegt meistens zwei bis drei Monate hinter dem ersten Signal.

Wir haben einmal eine Funktion entwickelt, weil wir annahmen, dass ein bestimmter Nutzertyp sie regelmäßig einsetzen würde. Die ersten zwei Monate nach dem Start: geringe Nutzung. Das Team erklärte es mit der Eingewöhnungszeit. Dritter Monat: geringe Nutzung. Das Team erklärte es mit mangelnder Sichtbarkeit. Vierter Monat: geringe Nutzung. Erst hier begann das Team, die Annahme selbst zu hinterfragen.

Was das Festhalten kostet

In diesem Fall: vier Monate Entwicklungszeit für eine Funktion, die bis heute kaum genutzt wird. Das ist die direkte Zahl. Die indirekte: vier Monate, in denen eine andere Frage nicht gestellt wurde, weil diese Frage bereits als entschieden galt.

Das ist der weniger sichtbare Teil der Kosten einer falschen Annahme. Nicht nur das, was gebaut wurde. Auch das, was nicht gebaut wurde, weil Aufmerksamkeit und Kapazität woanders lagen.

Ab wann ein Signal zählt

Wie früh eine Annahme aufzugeben ist, hängt von der Form des Signals ab. Ein Wert, der konstant in dieselbe Richtung zeigt — geringe Nutzung, Monat für Monat, ohne Aufwärtstrend — ist etwas anderes als ein Wert, der schwankt.

Was das Team in dem beschriebenen Fall hätte früher erkennen können: Die Nutzung stieg nicht. Kein Trend — nur ein konstanter Wert. Das hätte nach dem zweiten Monat als ausreichendes Signal gelten können, nicht erst nach dem vierten. Eine Frage, die das Team seitdem öfter stellt: Was müsste sich verändern, damit diese Annahme richtig wird? Wenn die Antwort lautet: nichts, was wir beeinflussen können — war die Annahme vermutlich von Anfang an falsch.

Was ein Frühsignal leistet – und was nicht

Frühsignale sind trügerisch. Die ersten Menschen, die eine neue Funktion nutzen, sind selten repräsentativ. Sie sind entweder besonders engagiert oder besonders kritisch. Beides verzerrt das Bild.

Was ein Frühsignal trotzdem leisten kann: zeigen, ob eine Annahme grundsätzlich haltbar ist. Nicht ob sie sich bewährt hat — sondern ob etwas Grundsätzliches dagegen spricht.

Ein eindeutiges Frühsignal gegen eine Annahme ist wertvoller als ein unklares Signal dafür. Wenn die ersten Nutzerinnen eine Funktion nicht verwenden, obwohl sie genau der Typ sind, für den sie gebaut wurde — dann ist das ein Hinweis, den man ernst nehmen sollte. Auch ohne statistisch belastbare Basis dahinter.

Vier Wochen statt sechs Monate

Was wir in der Rückschau öfter beobachten: Es gab einen früheren Zeitpunkt, an dem eine kleinere Prüfung möglich gewesen wäre. Nicht ein vollständiger Aufbau — aber ein erster Schnitt, der früh genug gezeigt hätte, ob die Richtung trägt.

Der Unterschied liegt weniger in der Methode als in der Frage, die man sich stellt: nicht „Wie bauen wir das am vollständigsten?" — sondern „Wann würde sich zeigen, ob wir falsch liegen?" Diese zweite Frage führt manchmal in vier Wochen zu einer Antwort, für die das Team sonst sechs Monate eingeplant hatte.

Die Projekte, die wir bei Innosirius betreuen, sind unterschiedlich. Aber diese Frage taucht in allen auf — und ihre Antwort kostet fast nie so viel, wie das Ausweichen vor ihr.

Entscheidungsqualität und Ergebnis sind nicht dasselbe

Die Entscheidungen, die sich im Rückblick als richtig erwiesen haben, sehen im Moment des Treffens genauso aus wie die falschen. Das ist das Unbehagliche an Entscheidungen unter Unsicherheit: Die Qualität einer Entscheidung und ihr Ergebnis sind zwei verschiedene Dinge.

Eine gute Entscheidung kann zu einem schlechten Ergebnis führen. Eine schlechte zu einem guten. Was ein Team aus einer falschen Entscheidung lernen kann, hängt davon ab, ob es auseinanderhalten kann, was an der Entscheidung selbst falsch war — und was an den Umständen, die sich geändert haben.

Wenn jede falsche Entscheidung als Versagen behandelt wird, lernt das Team das Falsche: nämlich, Entscheidungen zu vermeiden. Was stattdessen zu lernen wäre: welche Annahmen still geblieben sind, obwohl sie hätten ausgesprochen werden sollen. Welche Signale früher da waren, als das Team bereit war, sie wahrzunehmen.

Was sich nicht messen lässt – und trotzdem zählt

Es gibt eine Klasse von Entscheidungen, bei der die Frage nach dem Messbaren falsch gestellt ist. Nicht weil keine Messung möglich wäre — sondern weil das Messbare nicht das ist, was eigentlich auf dem Spiel steht.

Ob eine Funktion genutzt wird, lässt sich messen. Ob sie das Richtige verspricht — ob das Produkt damit langfristig das einlöst, wofür es gebaut wurde — lässt sich nicht messen. Beides ist real. Beides beeinflusst die Entscheidung. Wer nur misst, was messbar ist, hat die zweite Frage nicht gestellt.

Das ist kein Argument gegen Messen. Es ist ein Argument dafür, den Bereich, in dem keine Messung hilft, als eigenen Bereich zu benennen — und dort nicht so zu tun, als wären das Entscheidungen wie alle anderen.

Was im Team bleibt

Die Irrwege, die ein Entwicklungsteam gegangen ist, hinterlassen mehr als Zeitverlust. Sie hinterlassen eine Haltung: das nächste Mal schneller hinschauen, wenn ein Signal kommt. Das nächste Mal die stille Annahme laut machen, bevor vier Monate vergangen sind.

Ob das gelingt, zeigt sich nicht im Rückblick auf die Entscheidung, die falsch war. Es zeigt sich in der nächsten Situation, in der die Datenlage dünn ist und die Frage trotzdem nicht wartet.