Daten schlagen Meinungen – meistens

Nahezu jede Interaktion in einer Software kann erfasst werden. Klicks, Events, Funnels, Conversion Rates oder die Frage, an welcher Stelle Nutzer eine Aufgabe abbrechen. Ebenso lässt sich erkennen, welche Features regelmäßig genutzt werden und welche kaum Beachtung finden.

Dafür braucht es keine hochkomplexen Systeme. Bereits mit sauberem Event-Tracking und Tools wie Firebase, Google Analytics oder Mixpanel lassen sich Erkenntnisse gewinnen, die viele Teams bis heute nicht konsequent nutzen.

Und wenn eine Frage wirklich offen ist, muss man darüber oft gar nicht lange diskutieren. Ein A/B-Test macht aus einer Meinung ein Experiment. Zwei Varianten werden ausgespielt, der Traffic wird aufgeteilt und anschließend entscheidet nicht das Bauchgefühl, sondern das Nutzerverhalten.

Unternehmen wie Booking.com haben diesen Ansatz perfektioniert. Dort laufen permanent Hunderte oder sogar Tausende Experimente parallel – immer mit der Grundannahme, dass auch die eigene Idee zunächst nur eine Hypothese ist. Genau diese Haltung finde ich spannend: Nicht Recht haben wollen, sondern herausfinden, was tatsächlich funktioniert.

Der Grund dafür ist eigentlich simpel: Nur weil ein Stakeholder etwas möchte, heißt das noch lange nicht, dass Nutzer es auch brauchen.

Trotzdem passiert genau das erstaunlich häufig. Eine Vermutung wird zur Anforderung. Die Anforderung landet auf der Roadmap. Irgendwann wird sie entwickelt, ohne dass jemals überprüft wurde, ob das zugrunde liegende Problem überhaupt existiert.

Je höher eine Idee in der Organisation entsteht, desto seltener wird sie hinterfragt. Eigentlich müsste es genau umgekehrt sein.

Deshalb versuche ich, möglichst viele Produktentscheidungen auf echte Nutzung statt auf die lauteste Meinung im Raum zu stützen. Feature Flags und gestaffelte Rollouts machen das heute vergleichsweise einfach. Man zeigt eine Funktion zunächst nur einem kleinen Teil der Nutzer, beobachtet die Nutzung und entscheidet anschließend, ob ein vollständiger Rollout sinnvoll ist.

Ein bisschen bauen, ehrlich messen, daraus lernen und anschließend verbessern. Dieser Prozess fühlt sich manchmal langsamer an als eine starke Meinung – führt langfristig aber meist zu besseren Produkten.

Daten helfen nicht nur dabei zu entscheiden, was gebaut werden sollte. Sie helfen auch dabei zu erkennen, was wieder verschwinden kann.

Genau das fällt vielen Teams schwer. Ein Feature zu entfernen fühlt sich schnell wie das Eingeständnis eines Fehlers an. Tatsächlich ist das Gegenteil der Fall.

Ein Feature, das niemand nutzt, verursacht dauerhaft Kosten. Es muss gewartet, getestet, dokumentiert und bei jeder zukünftigen Änderung berücksichtigt werden. Mit jeder zusätzlichen Funktion steigt die Komplexität eines Produkts.

Nutzungsdaten schaffen hier eine objektive Grundlage. Wenn ein Feature über längere Zeit keinen messbaren Mehrwert liefert und keine wichtige Kennzahl beeinflusst, sollte zumindest die Frage erlaubt sein, ob es überhaupt noch einen Platz im Produkt verdient.

Nicht jedes Feature muss bleiben, nur weil es einmal entwickelt wurde.

Trotzdem wäre es ein Fehler, Produktentwicklung ausschließlich datengetrieben zu betrachten.

Daten zeigen sehr zuverlässig, was passiert. Wesentlich schwieriger beantworten sie die Frage, warum etwas passiert. Außerdem können sie nur das messen, was bereits existiert. Große Produktideen, völlig neue Konzepte oder mutige strategische Entscheidungen besitzen zunächst gar keine Datenbasis.

Wer ausschließlich bestehende Kennzahlen optimiert, verbessert oft nur das Vorhandene. Das führt zu besseren Formularen, schnelleren Prozessen oder höheren Conversion Rates – aber nicht zwangsläufig zu besseren Produkten.

Viele erfolgreiche Produkte hätten in ihrer ersten Woche vermutlich keinen überzeugenden A/B-Test bestanden.

Deshalb bleiben Erfahrung, Intuition und Produktverständnis unverzichtbar. Sie helfen dabei zu entscheiden, welche Hypothesen überhaupt getestet werden sollten, welche Kennzahlen wirklich relevant sind und wann eine Auffälligkeit lediglich ein Messfehler ist.

Ich plädiere deshalb nicht für datengetriebene Entscheidungen um jeden Preis. Ich plädiere dafür, Daten dort entscheiden zu lassen, wo sie objektiv entscheiden können. Meinungen sind wichtig, weil sie neue Ideen hervorbringen. Ob diese Ideen funktionieren, sollten am Ende aber möglichst echte Nutzer beantworten.

Für mich gilt deshalb eine einfache Regel: Meinungen starten Diskussionen, Daten beenden sie meistens.

Ganz ohne Grenzen funktioniert dieser Ansatz allerdings nicht. Selbst die besten Kennzahlen helfen nur bedingt weiter, wenn man nicht versteht, wie die Software darunter funktioniert. Wie entsteht eine Kennzahl überhaupt? Welche technische Änderung steckt dahinter? Was ist tatsächlich einfach umzusetzen und was wirkt nur von außen unkompliziert?

Wer das System hinter den Daten nicht versteht, stellt oft auch die falschen Fragen.

Und genau deshalb gehört für mich zu guter Produktarbeit noch eine weitere Fähigkeit: ein solides technisches Verständnis.