Menschen von oben fotografiert, die an einem Tisch sitzen.

adesso Blog

Ihr kennt solche Situationen sicherlich: Eine scheinbar einfache Anforderung löst unerwartete Schwierigkeiten aus. Mit Build-Measure-Learn möchte ich euch daher eine geeignete Methode vorstellen, mit der ihr euch schrittweise einer optimalen Lösung annähern und die Risiken von Fehlentwicklungen minimieren könnt.

Eine „einfache“ Erweiterung

Gehen wir von folgendem Beispiel aus: Ein Kunde nutzt den Online-Service eines Versicherers. Dabei müssen natürlich auch persönliche Daten - insbesondere die E-Mail-Adresse - in ein Online-Formular eingegeben werden. Da der Kunde jedoch online-affin ist, hat er vielleicht auch Interesse an speziellen Online-Versicherungsprodukten. Es liegt also nahe, diesem Kunden per E-Mail über solche Produkte und deren attraktive Preise informieren zu wollen.

Nichts leichter als das: Der Kunde wird einfach um Erlaubnis gefragt.

Das Entwickler-Team sieht darin auch kein Problem. Es wird einfach eine Checkbox vor dem Absendeknopf eingebaut und das Ergebnis in der Datenbank gespeichert. Der Requirements Engineer fragt aber nicht ganz zu Unrecht, wie denn das Kennzeichen für diesen Kunden, das in Datenbank A gespeichert ist, von der Marketingabteilung oder einer Versicherungsagentur ausgewertet werden soll, wenn diese für ihre Arbeit Datenbank B und C verwenden.

Außerdem stellt die Datenschutzabteilung nüchtern fest, dass solche persönlichen Daten selbstverständlich schützenswert sind und nicht in einem beliebigen Kontext gespeichert werden dürfen. Und schließlich meldet sich auch die Rechtsabteilung mit dem Hinweis zu Wort, dass es wesentlich vom Inhalt des Einwilligungstextes abhängt, ob solche Werbe-E-Mails überhaupt rechtmäßig versendet werden dürfen.

Die Konzeption und Umsetzung des Vorhabens wird damit schnell zu einem kleinen Projekt, das je nach Größe des Unternehmens erhebliche Aufwände nach sich ziehen kann. Folglich muss auch noch ein kleiner Business Case konstruiert werden, um die Wirtschaftlichkeit des Projektes nachzuweisen.

Annahmen hinterfragen, in Hypothesen denken

Doch wie lässt sich dieser abteilungsübergreifende Aufwand vermeiden? Schließlich ist die Systemlandschaft des Unternehmens über viele Jahre gewachsen und ihr könnt nicht einfach auf der „grünen Wiese“ anfangen.

Zunächst einmal ist es wichtig, dass feststeht, von welchen Annahmen ihr eigentlich ausgeht. So steckt in unserem Beispiel die Annahme, dass Kunden generell bereit sind, eine Einwilligung für Werbezwecke zu erteilen, um besser über attraktive Produkte informiert zu werden. Doch trifft das tatsächlich auf alle online-affinen Kunden zu? Welchen Nutzen haben Kunden von diesen Werbe-E-Mails? Und schließlich: Sind die jeweiligen Produkte wirklich so attraktiv?

Hier wird schnell klar, dass man nur allzu schnell bereit ist, vom eigenen Wunschdenken auf die Bedürfnisse der Kundinnen und Kunden zu schließen. Nun ist es nicht per se verboten, von Annahmen auszugehen. Ihr solltet euch aber immer im Klaren darüber sein, dass es sich dabei häufig nur um Hypothesen handelt, die sich auch mal als unzutreffend erweisen können.

Um euch bestmöglich in die Lage eurer Kundinnen und Kunden hineinversetzen zu können, solltet ihr daher zunächst überlegen, was eure Zielegruppe, die ihr erreichen möchtet, genau ausmacht. Hierzu könnt ihr beispielsweise Personas nutzen. Ich persönlich bevorzuge jedoch weniger detaillierte Analysen, da sie in der Regel eine schnellere Überprüfung einzelner Hypothesen ermöglichen. Mit steigendem Arbeitsaufwand erhöht sich aus psychologischen Gründen nämlich häufig auch der Grad der Überzeugung, dass die getroffenen Annahmen korrekt sind. Bekommen die jeweiligen Personas noch Namen und Gesichter zugeordnet, werden die Annahmen häufig nicht mehr hinterfragt und empirisch überprüft. Womit wir dann leider wieder am Anfang des Problems sind.

Für welches Vorgehen ihr euch entscheidet, ist allerdings auch immer von der jeweiligen Situation und Aufgabenstellung abhängig.

Habt ihr nun eine Vorstellung vom Kundenprofil, mit dem ihr starten möchtet, gilt es, Hypothesen über dessen Probleme abzuleiten. Solche Hypothesen könnten beispielsweise folgendermaßen formuliert werden:

  • Ich glaube, online-affine Kunden benötigen eine finanzielle Absicherung gegen Hacker-Angriffe.
  • Ich glaube, „John Online“ hat Probleme, sich über unsere Produkte zu informieren.
  • Ich glaube, „Rebecca Fuchs“ sucht gezielt nach dem bestmöglichen Preis-/Leistungsverhältnis für ein Versicherungsprodukt.

Erst wenn ihr Kunden- und Problemhypothesen formuliert und priorisiert habt, könnt ihr nach möglichen Lösungen für die wichtigsten Probleme suchen.

Mit Build-Measure-Learn Hypothesen und grundlegende Annahmen überprüfen

Es dürfte klar sein, dass die Vielzahl der Kunden-, Problem- und Lösungshypothesen vorab schwerlich in Gänze analysiert werden können. Annahmen müssen also frühzeitig hinterfragt und überprüft werden.

Die Erfahrung zeigt jedoch, dass es leider nicht ausreicht, potenzielle Kundinnen und Kunden oder User nach ihrer Meinung zu fragen. Was sie sagen und wie sie handeln, sind nämlich häufig zwei unterschiedliche Paar Schuhe.

Wie könnt ihr also vorgehen? Die sicherste Methode besteht darin, das Kundenverhalten im echten Leben zu beobachten. Dazu bietet sich die aus dem „Lean Startup“-Umfeld bekannte Methode Build-Measure-Learn an.

Hinter dieser Methode verbirgt sich folgendes: Mit geringstmöglichem Aufwand wird versucht, die „einfachste mögliche“ Lösung umzusetzen, die eine Überprüfung einer Hypothese ermöglicht. Wichtig ist dabei, das Verhalten des Kunden bei der Nutzung der Lösung zu messen. Nur so lassen sich die Eingangshypothesen praktisch überprüfen.

Da ihr aber nicht jede Hypothese überprüfen könnt und auch nicht sollt, müsst ihr vorab natürlich priorisieren. Das funktioniert natürlich am besten im Team. Mit der Zeit wird euch dieses Verfahren immer einfacher von der Hand gehen. Wenn ihr die grundlegenden Kunden-, Problem- und Lösungshypothesen validiert habt, geht es dann eher um die Überprüfung kleinerer und ergänzender Fragestellungen, etwa wie im oben genannten Beispiel.

Wie solltet ihr mit dem genannten Beispiel nun umgehen?

Vertretet ihr beispielsweise die Annahme, das Kundinnen und Kunden bereit sind, ihr E-Mail-Adresse für Newsletter oder ähnliches zur Verfügung zu stellen, solltet ihr in einem ersten Schritt zunächst überprüfen, ob und in welchem Kontext diese überhaupt bereit sind, Werbe-E-Mails zu akzeptieren. Dazu genügt es tatsächlich, eine einfache Checkbox mit einem einfachen Bestätigungstext in den Online-Service einzubauen. Das Kundenverhalten liefert ein klares Ergebnis, denn die Checkbox wird angeklickt oder nicht.

Und was ist mit den Themen Recht, Datenschutz, Marketing und den Versicherungsagenturen? Wenn ihr das Ergebnis einfach nur anonym speichert, bedarf es weder einer breiten Abstimmung noch einer Weiterverarbeitung der Daten. Auf diese Weise könnt ihr sehr schnell und mit wenig Aufwand anfangen zu messen und auch daraus lernen.

Steht am Ende dieses ersten Lernzyklus die Erkenntnis, dass nur wenige Kundinnen und Kunden bereit sind, Werbe-E-Mails zu akzeptieren, habt ihr eure grundlegende Annahme widerlegt und ihr könnt euch sämtliche, darauf basierende Folgearbeiten sparen. Stattdessen könnt ihr andere Lösungswege ausprobieren. In jedem Fall habt ihr aber nach einem solchen Experiment eine weitaus bessere Entscheidungsgrundlage für das weitere Vorgehen.

Ideen an der Realität messen

Auch wenn es im täglichen Geschäft längst nicht immer so einfach ist, wie in unserem Beispiel, lohnt sich der Einsatz. Wenn ihr nämlich den Mut habt, kleinere Schritte zu wagen, bleiben euch größere Umwege erspart. Die Build-Measure-Learn-Methode unterstützt euch effektiv dabei, eure Ideen schnellstmöglich an der Realität zu messen.

Wenn ihr mehr über interessante Themen aus der adesso-Welt erfahren möchtet, werft auch einen Blick in unsere bisher erschienen Beiträge.

Bild Joachim  Flierdl

Autor Joachim Flierdl

Joachim Flierdl ist seit vielen Jahren als Consultant und Agilist bei adesso tätig. Sein Arbeitsschwerpunkt liegt in der Beratung von Product Ownern und Business Analysten. Darüber hinaus beschäftigt er sich intensiv mit digitalen Kundenservices.

Diese Seite speichern. Diese Seite entfernen.