Wer sind die besseren Produkt-Manager: Fliegen oder Bienen?

Die meisten von uns sind der Meinung, viel zu wissen. Einige wenige sind sogar der Meinung, ALLES zu wissen. Darüber könnte man trefflich philosophieren und lästern. In diesem Blog möchte mich jedoch ganz allgemein damit beschäftigen, was es bedeutet, etwas zu “wissen”. Und noch spannender ist die Frage: “Wie bauen wir als Individuen bzw. als gesamte Menschheit Wissen auf?”

Bei dem Begriff “Wissen” denken wir natürlich zunächst mal an Bücher, an Lehrer, an unsere Schul- und Studienzeit. Doch viel “Wissen” erfährt man eben nicht so einfach aus Büchern und in Bildungseinrichtungen. Es ist sehr spezifisches Wissen, das man selber als Invidiuum oder als Organisation erwerben muss. Z.b. “Wie erreiche ich meine Ziele?” oder “Wie begeistere ich meine Kunden?” 

Die Wissenschaft kennt für den Wissenserwerb eine eigene Disziplin. Diese nennt sich Wissenschaftstheorie und es geht dabei ganz abstrakt um die effizienteste und nachvollziehbarste Art Wissen zu erlangen. Egal ob in der Informatik, in der Betriebswirtschaftslehre, in der Psychologie – das Ziel ist strukturierte und belastbare Methoden zu finden und zu beschreiben, um neues Wissen zu generieren. 

Viele Studenten werden sich möglicherweise noch an viele fast unlesbare Schmöker erinnern, die Methoden wie “Literatur-Analyse”, “Experten-Interview”, “Experiment” im Detail beschreiben. Den erhellensten Ansatz fand ich aber bei Henry Mintzberg in seinem Buch “Strategy Safari”, der Wissens-Erwerb mit folgendem fiktiven Experiment beschrieben hat:

Man nimmt eine leere Flasche, entfernt den Schraubverschluss und hält sie so, dass der Kopf der Flasche in Richtung einer Lichtquelle (z.B. der Sonne) zeigt. Der Boden der Flasche zeigt in die andere Richtung.

Zunächst füllt man diese Flasche mit Bienen. Was passiert? Die Bienen versuchen immer und immer wieder in Richtung der Lichtquelle zu fliegen. Sie (glauben zu) wissen, dass der direkteste Weg zur Lichtquelle auch der richtige ist. An diesem Ende ist die Flasche aber geschlossen, die Bienen schaffen es also nicht aus der Flasche zu entkommen und sterben an Erschöpfung.

Jetzt versucht man dasselbe mit Fliegen. Die Fliegen verfolgen einen anderen Ansatz und liegen chaotisch in der Flasche herum – ohne erkennbare Struktur und Logik. Tatsächlich fliegen aber manche Fliegen in Richtung des Flaschenhals und entkommen daher der Flasche.

Intelligentere Lebewesen (“Bienen”) scheitern mit ihrem ziel-orientierten, logischen Ansatz gegenüber dummen Fliegen. Chaos triumphiert über Wissen und Strategie? Ist dies als Plädoyer für chaotisches, unwissenschaftliches Vorgehen zu sehen?

Nein! 

Oder genauer gesagt: Es kommt auf die Problemstellung an…

Bei einfachen, klar definierten Problemstellungen wird das logisch-analytische Vorgehen schneller zum Ziel führen. Ein Kreuzworträtsel mit Zufallsgenerator zu lösen, wird lange benötigen. Da hilft Wissen und ein klares Verständnis der Problem-Domäne.

Viele der heutigen Problemstellungen beziehen sich aber auf komplexe Umgebungen, d.h. wir verstehen weder (in ihrer Gesamtheit) die Problem-Domäne, noch gibt es klare, wiederholbare Lösungs-Strategien. Und zu allem Überdruss ändert sich das Gesamtsystem permanent.

Aus diesem Grund bringt es nichts, Wochen, Monate, Jahre alles bis ins letzte Detail zu analysieren, um dann einen Lösungsansatz zu erarbeiten. Ein besserer Ansatz ist in diesem Fall Dinge einfach auszuprobieren!

Agieren wir dann wie die dummen, chaotischen Fliegen in der Flasche?

Wenn wir die Experimente rein zufällig auswählen und nichts aus den Ergebnissen lernen, dann ja. Der goldene Mittelweg – und in dieser Form durchaus wissenschaftlich fundiert – ist jedoch:

• Hypothesen aufzustellen
• Experimente auszuführen, um diese Hypothesen zu bestätigen oder zu widerlegen
• Die Ergebnisse zu analysieren („lernen“) und wieder neue, überarbeitete Hypothesen aufzustellen
• und das ständig wiederholend (iterativ)

Im Marketing ist dieser Ansatz weit verbreitet. Eine gängige Methode sind A/B-Tests, wo Kunden mit einem leicht modifizierten Produkt (=Hypothese) konfrontiert werden und die Reaktionen dieser Gruppe mit dem Durchschnitt der Gesamtheit verglichen wird. Das können sehr banale Modifikationen sein: 

• Hypothese: Wenn wir Kunden in dem neuen Prospekt statt “Sie” mit “Du” anreden, dann bekommen wir 5% mehr Bestellungen
• Experiment: Wir schicken an 50% den alten und 50% den neuen Prospekt
• Wenn tatsächlich von den Kunden, die den neuen Prospekt bekommen haben, 5% mehr Bestellungen kommen, dann ist die Hypothese bestätigt.
• Wir ziehen aus dieser Erkenntnis unsere Schlüsse und führen weitere Hypothesen-getriebene Experimente durch.

Wichtig für diese Vorgehensweise ist:

• die Hypothesen sollten nicht wahllos getroffen werden, sondern auf Basis von Experten-Wissen ausgewählt werden. Es ist grundsätzlich ok, mit einer Hypothese falsch zu liegen, aber Organisationen haben nicht unbeschränkte Mittel zur Verfügung, um alles auszutesten.
• Die Modifikation sollte im kleinen Rahmen sein. Größere Änderungen können auf mehrere Iterationen aufgeteilt werden, wodurch man frühzeitiger Feedback bekommt und den Kurs gegebenenfalls korrigieren kann.
• Es ist besser, immer nur eine Modifikation auszutesten, um eine klare Zuordnung von der Modifikation und den Ergebnissen zu haben. 
• Die Messungen müssen repräsentativ sein.

Was für Marketing bereits gängige Praxis ist, ist in der IT noch nicht wirklich angekommen. Wenn wir IT-Systeme konzipieren, dann passiert das oftmals immer noch mit großen Schritten (Big bang!). Wir glauben, dass wir die Bedürfnisse des End-Anwender auf Basis von Logik und detaillierter Analytik adressieren können. Also schreiben wir ein Pflichtenheft, spezifizieren die Anforderungen und die IT setzt dies ohne Rücksicht auf Verluste um. Sollten die End-Anwender mit dem Resultat nicht zufrieden sein, dann haben sie Pech gehabt. Beziehungsweise bekommen von uns gesagt, dass “sie einfach nicht wissen, was sie wollen!” 

Doch diese Sichtweise beginnt zu bröckeln. A/B Testing ist in der IT noch nicht allzu weit verbreitet, es gibt aber mehr und mehr technologische Konzepte, die eine hypothesengetriebene Software-Entwicklung ermöglichen:

• Continuous Deployment propagiert häufige und vom Umfang her kleine Deployments
• Flexible Deployment-Strategien ermöglichen eine bewusste Entscheidung, WELCHER Anwender WELCHES Feature zu sehen bekommt. Beispiele dafür sind:
  • Canary Deployment: Nur eine kleine Menge von Anwendern werden auf die neue Version geroutet.
  • Feature-Flags: Bestimmte Funktionalitäten befinden sich bereits physisch in der produktiven Live-Umgebung, können aber per Schalter (Flag) ein und ausgeschaltet werden
• Umfangreiche Telemetrie-Daten: Diese wurden ursprünglich primär zur Messung von IT-bezogenen Problemstellungen verwendet, können aber in diesem Kontext auch für geschäfts-spezifische Fragestellungen verwendet werden.

Mit diesen Ansätzen verbinden wir die intelligente, logik-basierende Vorgehensweise einer Biene mit der ergebnisorientierten Agilität einer Fliege. Wir lernen kontinuierlich, hinterfragen bestehendes Wissen und haben keine Angst vor Scheitern („Fail early“). Das ist intelligent und effektiv. Und es scheint sich auszuzahlen: Am Ende des Tages geht es darum, Kunden bzw. Anwender zufrieden zu stellen – denn diese zahlen unser Gehalt!