Entscheiden mit dünner Datenlage: Annahmen sichtbar machen

Das Problem: Wenn Daten fehlen, glaubt man trotzdem zu wissen

Jedes Produktteam kennt die Situation. Nutzer melden sich über Feature A. Das Team diskutiert, ob Feature B oder C als nächstes gebaut werden soll. Jemand sagt: „Unsere Kunden wollen das bestimmt." Ein anderer nickt. Ein dritter hat eine andere Meinung, aber keine Zahlen. Am Ende entscheidet, wer am lautesten spricht oder am längsten dabei ist.

Das ist keine Ausnahme. Das ist der Normalzustand — in frühen Produktphasen und auch in etablierten Teams, wenn eine neue Domäne betreten wird. Die Frage ist nicht, ob man mit dünner Datenlage entscheidet. Die Frage ist, ob man es weiß. Und ob man vorab definiert hat, ab wann man eine Entscheidung revidiert.

Was sich wirklich messen lässt — und was nicht

Bevor man über Entscheidungsqualität reden kann, muss man sauber trennen: Was ist ein messbares Signal, was ist eine Annahme? Diese Unterscheidung klingt trivial. Sie ist es nicht.

Messbare Signale

Messbare Signale haben eine Quelle, ein Datum und einen Wert. Beispiele:

• „Feature X wurde in drei Kundengesprächen der letzten zwei Wochen als Blocker genannt."
• „Der Absprung auf Schritt 3 des Onboarding-Flows liegt bei 68 Prozent."
• „Seit dem letzten Release haben Support-Tickets zu Thema Y um 40 Prozent zugenommen."

Diese Signale sind nicht perfekt. Drei Kundengespräche sind kein statistisch valides Sample. Aber sie haben eine klare Herkunft, lassen sich auf eine konkrete Beobachtung zurückführen — und vor allem: Sie können im Verlauf überprüft werden.

Annahmen

Annahmen klingen oft wie Fakten, haben aber keine Quelle. Erkennbar an Formulierungen wie:

• „Unsere Kunden brauchen das."
• „Das ist branchenüblich."
• „Das machen alle so."
• „Ohne das werden wir nicht wachsen."

Das Gefährliche: Annahmen, die lange im Team kursieren, werden irgendwann als Fakten behandelt. Niemand fragt mehr nach der Quelle, weil die Behauptung schon so oft wiederholt wurde. Das ist kein Versagen von Einzelpersonen — es ist ein strukturelles Problem, das jedes Team trifft, das nicht explizit dagegen vorgeht.

Wie wir Annahmen in eigenen Projekten sichtbar gemacht haben

Bei einem Projekt für die Verwaltung von Immobiliendaten haben wir mehrere Monate an einem Import-Feature gearbeitet, weil „die Kunden das definitiv brauchen". Die Überzeugung kam aus einem frühen Gespräch mit einem einzigen Interessenten. Sie wurde nie wieder hinterfragt, weil das Thema komplex war und das Team aufgehört hatte, die Ursprungsfrage zu stellen.

Das Feature wurde geliefert. Im ersten Jahr wurde es von keinem Kunden aktiv eingesetzt. Die Entwicklungskosten lagen bei etwa drei Wochen Entwicklerzeit. Das war keine Katastrophe — aber ein teurer Irrweg, der vermeidbar gewesen wäre.

Was wir mitgenommen haben: Eine Annahme bleibt eine Annahme, egal wie oft sie wiederholt wird. Die entscheidende Frage hätte von Anfang an lauten müssen: „Was müsste passieren, damit wir diese Annahme aufgeben?"

Annahmen explizit machen: die konkrete Methode

Seitdem dokumentieren wir produktrelevante Annahmen explizit, bevor Entwicklung beginnt. Kein aufwändiger Prozess — eine kurze Liste zu jeder größeren Entscheidung:

• Was glauben wir, warum dieses Feature gebraucht wird?
• Woher stammt diese Überzeugung — Gespräch, Beobachtung oder Bauchgefühl?
• Welches Signal würde die Annahme bestätigen?
• Welches Signal würde sie widerlegen?

Das dauert 20 Minuten. Der Effekt ist erheblich — nicht weil die Liste magisch wäre, sondern weil das Aufschreiben zwingt, die Annahme überhaupt zu benennen. Viele Annahmen halten diesem Test nicht stand.

Ab wann schreibt man eine Annahme ab?

Das ist die eigentlich schwierige Frage. Und sie wird in den meisten Teams nicht gestellt, weil die Antwort unbequem ist: Sie bedeutet, dass man eine Entscheidung revidiert, die man öffentlich vertreten hat.

Das Killkriterium vorab definieren

Wenn man eine Annahme explizit macht, muss man gleichzeitig definieren, was sie falsifiziert — nicht im Nachhinein, wenn das Feature halb fertig ist, sondern vorab.

Beispiel: „Wir glauben, dass Nutzer das Dashboard täglich aufrufen werden." Das Killkriterium könnte lauten: „Wenn nach acht Wochen weniger als 20 Prozent der aktiven Nutzer das Dashboard mindestens zweimal pro Woche geöffnet haben, dann war die Annahme falsch."

Die Zahl ist willkürlich — das ist der Punkt. Sie zwingt das Team, vorab zu definieren, ab wann man korrigiert. Bevor der Sunk-Cost-Effekt einsetzt. Bevor das Feature zur unantastbaren Investition wird, die niemand mehr in Frage stellt.

Woran wir das gelernt haben

In einem SaaS-Projekt haben wir eine Exportfunktion priorisiert, weil wir glaubten, sie sei ein entscheidendes Kriterium für Enterprise-Abschlüsse. Das Signal dafür: ein einzelner Interessent hatte das Thema in einem Demo-Gespräch erwähnt. Wir haben drei Wochen entwickelt.

Kein einziger Abschluss ließ sich auf diese Funktion zurückführen. Was die Enterprise-Kunden tatsächlich aufgehalten hatte, war ein zu komplizierter Onboarding-Prozess — ein Problem, das wir nicht einmal auf dem Radar hatten. Wir hätten das früher erkennen können, wenn wir vorab definiert hätten: „Wenn wir drei Enterprise-Deals abschließen, ohne dass der Export erwähnt wird, ist die Annahme falsch."

Was messbar ist, wenn Nutzerzahlen noch fehlen

In frühen Phasen gibt es oft keine belastbaren Nutzungsdaten. Kein Traffic, keine Klickraten, keine Kohorten. Trotzdem muss entschieden werden. Was dann?

Qualitative Signale strukturieren

Kundengespräche, Support-Anfragen und Demo-Feedback sind keine schlechten Quellen — sie sind nur unstrukturiert. Wenn man sie systematisch dokumentiert, werden auch kleine Stichproben aussagekräftiger. Relevante Fragen dabei:

• Wer hat das Problem genannt? Welche Rolle, welche Unternehmensgröße, welcher Kontext?
• Wie dringend war es? Hat es das Gespräch dominiert oder wurde es am Rande erwähnt?
• Kam das Thema ungefragt oder als Reaktion auf eine direkte Frage?

Ein Problem, das in drei unabhängigen Gesprächen ungefragt als Hauptthema auftaucht, trägt mehr Gewicht als elf Nennungen auf eine gezielte Leitfrage hin. Der Unterschied liegt nicht in der Anzahl, sondern in der Spontaneität des Signals.

Proxy-Metriken früh aufbauen

Wenn direkte Metriken fehlen, helfen Näherungswerte: Wie oft werden bestimmte Themen in Support-Tickets erwähnt? Welche Hilfeseiten werden am häufigsten aufgerufen? Welche Workarounds bauen sich Nutzer selbst, weil eine Funktion fehlt?

Diese Signale ersetzen keine echten Nutzungsdaten. Aber sie sind ehrlicher als Vermutungen — und sie lassen sich dokumentieren, vergleichen und im Zeitverlauf verfolgen. Wer früh anfängt, diese Signale zu erfassen, hat später eine Vergleichsbasis, auf der Entscheidungen stehen können.

Drei Irrwege und was sie uns gekostet haben

Drei konkrete Fehler aus eigenen Projekten — ohne Beschönigung:

Irrweg 1: Das lauteste Feedback gewinnt

Ein Nutzer mit direktem Draht zur Geschäftsführung hat ein Feature angefragt. Wir haben es priorisiert und gebaut. Zwei Wochen später stellte sich heraus, dass genau dieser Nutzer das Feature schon nach drei Tagen nicht mehr brauchte — sein interner Prozess hatte sich geändert. Kosten: zwei Wochen Entwicklerzeit und eine verschobene Roadmap für alle anderen. Die Lektion: Lautstärke ist kein Signal für Relevanz.

Irrweg 2: Kein Killkriterium, kein Ausstiegspunkt

Wir haben ein Analyse-Dashboard gebaut, weil wir glaubten, es sei der Schlüssel für die nächste Wachstumsstufe. Kein Killkriterium definiert. Sechs Monate nach dem Release: Das Dashboard wurde von weniger als 10 Prozent der Nutzer geöffnet, davon mehr als die Hälfte genau einmal. Ohne ein vorab definiertes Abbruchkriterium gab es keinen Moment, an dem das Team klar hätte sagen können: Das funktioniert nicht. Wir haben zu lange weiterentwickelt, weil der Exit nicht vorbereitet war.

Irrweg 3: Das falsche Problem lösen

Wir haben Monate an einer Verbesserung für ein bekanntes Problem gearbeitet — und dabei nicht hinterfragt, ob das Problem wirklich das war, was Nutzer beschäftigte. Es war eine bessere Lösung für ein Symptom, nicht für die Ursache. Die Ursache lag in einem anderen Prozessschritt, den wir nicht im Scope hatten. Das hätten wir früher erkennen können, wenn wir die Annahme „das ist das richtige Problem" genauso explizit gemacht hätten wie alle anderen Annahmen.

Was bleibt: Entscheidungen trotzdem treffen

Das Ziel dieser Überlegungen ist nicht, weniger zu entscheiden. Lähmung durch Überanalyse ist genauso teuer wie blinde Annahmen — nur stiller. Das Ziel ist, den Unterschied zu kennen: Wann entscheide ich auf Basis eines echten Signals? Wann entscheide ich auf Basis einer Annahme? Und was wäre das Signal, das mich umstimmt?

Wer das sauber trennen kann, entscheidet nicht weniger — aber bewusster. Und vor allem: schneller. Weil man weiß, worauf man wartet. Und wann man nicht mehr wartet, sondern korrigiert.

Es gibt kein Tool, das diese Arbeit abnimmt. Was hilft, ist Explizitmachen: Annahmen benennen, bevor man baut. Killkriterien definieren, bevor man liefert. Und die Bereitschaft aufzubauen, früh zu sagen: Das war falsch — bevor der Preis zu hoch ist.

Weitere Einblicke aus der Werkstatt — zu Architekturentscheidungen, Produktfragen und dem Alltag in laufenden Projekten — gibt es auf innosirius.de.