Raus zum Kunden. Schnell.

Time to market – kennt jeder, doch nicht immer wird in Projekten strikt danach gehandelt . Durch das Schleifen auf 100% vor Markteintritt werden Chancen vertan und das Risiko erhöht, am Markt vorbei etwas entwickelt zu haben. Rucksack packen. Raus. Zum. Kunden.

Der klassische Ansatz

Projekte zum Aufbau neuer Produkte oder Dienstleistungen laufen in der Finanzbranche nach ähnlichem Muster ab: Nachdem in mehrmonatigen Vorstudienphasen grobe Anforderungen an ein Zielbild formuliert und das Budget für das Umsetzungsprojekt gesichert sind, geht das Projekt in eine ein- bis zweijährige Umsetzungsphase.

Innerhalb dieser Phase werden mittlerweile agile Softwareentwicklungsmethoden (Scrum, Kanban, etc.) verwendet, um das Produkt iterativ und in enger Abstimmung zwischen Fachbereichen und IT weiterzuentwickeln.

Nach zwei Jahren und verbrauchtem Projektbudget dann der Go-Live mit dem vor anderthalb Jahren spezifizierten Funktionsumfang. Hier auf einmal das große Erstaunen: Andere Anbieter haben mittlerweile dieselbe Dienstleistung an den Markt gebracht oder das Produkt ist am Kunden und Markt vorbei entwickelt.

Kennt man.

Sicherlich etwas überspitzt dargestellt, aber das Problem verpasster Chancen durch einen verpassten First Mover Advantage oder das Risiko, ein Produkt an den Kundenbedürfnissen vorbei entwickelt zu haben, ist durchaus existent. Dabei wäre es gerade bei einer Branche mit “virtuellen” Produkten wie im Banking ein leichtes, Produkte frühzeitig zu launchen und diese dann iterativ zu erweitern und anzupassen.

Der Lean Startup Ansatz

In diesem Kontext können sich Banken von FinTechs und Startups doch noch ein Scheibchen abschneiden. In diesem Branchensegment haben sich aus Eigeninteresse mittlerweile Methoden aus der Lean Startup Bewegung etabliert. Im Mittelpunkt dieser Methoden tauchen immer wieder die Schlagworte Build-Measure-Learn (BML) und das Minimal Viable Product (MVP) auf.

BML beschreibt dabei ein Vorgehen, indem auf Basis einer (Produkt-)Idee kritische Hypothesen abgeleitet werden, für die ein MVP entwickelt wird (Build). Das MVP beschreibt wiederum den Umfang eines Produkts oder einer Dienstleistung, der es ermöglicht, schnellstmöglich und unter minimalem Ressourcenaufwand eine Produktidee und die zugrundeliegende Annahmen zu validieren (Measure) und daraus Erkenntnisse für den nächsten Lauf zu erhalten (Learn). In den Instituten wird allerdings das MVP dazu genutzt, die minimalste Version eines Produktumfangs zu definieren, mit dem man an den Markt gehen kann — genau da kann es zu Friktionen kommen.

Denn das MVP ist ein Hilfsmittel eines Produktanbieters, um getroffene Annahmen frühzeitig zu validieren.

Jetzt kommt der mutige Teil an der Geschichte:

Man muss. das Ruder rumreißen, wenn sich eine wichtige Annahme nicht als richtig erweist.

Daher kann ein MVP das fertige Produkt sein – muss es aber nicht. Es ist durchaus möglich und sinnvoll, verschiedene Experimente am Produkt auszuführen ohne viele Projektmonate zu investieren: Es können Papierprototypen präsentiert, Produktvideos lanciert, Features simuliert oder Umfragen durchgeführt werden. Im Vordergrund steht hierbei, dass aus den obengenannten MVP-Arten dann auch echte Erkenntnisse gewonnen werden. Daher sollte man sich zu jeder Annahme schon Gedanken gemacht haben, wie diese getestet werden sollen und welche Art des MVPs dafür geeignet sind.

Bei Produktvideos oder der Vorstellung von Papierprototypen kann beispielsweise ausgewertet werden, wer bereit wäre, ein solches Produkt zu nutzen und dafür auch zu bezahlen. Bei Feature-Simulationen können bspw. die Anzahl der Klicks auf einen “Jetzt Investieren” Button gezählt werden. Das zu testende Feature muss noch nicht mal da sein. Als Besucher einer Webseite hat es jeder bestimmt auch schon selbst erlebt, man klickt auf den “Kaufen” Button und anstatt der Aktion taucht Folgendes auf:

“Sorry – Du kannst es noch nicht kaufen, wir brauchen noch ein bisschen . Wenn Du magst, hinterlasse Deine Email hier und wir informieren Dich, sobald du kaufen kannst”.

Aha: An dieser Stelle validiert der Anbieter seine Annahme direkt mit zwei Kennzahlen: Wieviele Besucher haben auf den Button geklickt und wieviele sind tatsächlich so sehr daran interessiert, dass sie ihre Email-Adresse hinterlassen.

Was man an diesem Beispiel merkt: Das MVP ist nicht in erster Linie für den Kunden gebaut, sondern als Hilfsmittel zur Validierung von Annahmen. Und hier wird es tatsächlich genutzt. Bei echten Kunden. Und wenn das gut gemacht ist und richtig kommuniziert wird, gibt’s auch kein Fiasko.

MVP ist nicht alles und sofort

Wenn man sich als Projekt- und Product Owner auf den MVP Ansatz geeinigt hat und plant, wie das erste MVP geschnitten und wann der erste Go-Live geplant ist, kommt oftmals die Ernüchterung:

“Ohne bereitgestellte Stornierungsfunktionalität brauchen wir das erste MVP nicht online nehmen” – Product Owner.

Da sind wir auch schon wieder am Anfang angelangt . MVP ist nicht alles und sofort, im Gegenteil: es geht darum, das MVP auf die Features zu beschränken, die die entscheidenden Hypothesen überprüfen. Es ist nicht vom ersten Tag an wichtig, jede Randfunktionalität implementiert zu haben . Im Zweifel kann bei einer Anfrage durch den Kunden dieser gegebenenfalls manuell durchgeführt werden.

“Time is money” kennt jeder – gerade in der Startup Branche ein wichtiges Credo : Die Finanzierung reicht nur für eine bestimmte Zeit , da macht man sich schon Gedanken darüber, was wirklich wichtig ist . Daher ist eine (richtige) Priorisierung auch das A und O. Vor allem. die Fokussierung auf die wichtigsten Punkte schafft Geschwindigkeit und Vorteile. So kommt man schnell an den Markt, bekommt schnell Feedback, kann – sofern sich Annahmen als falsch erweisen – reagieren und trotzdem immer noch “Erster” sein.

Und da Geschwindigkeit eben alles ist, sollte man sich immer wieder hinterfragen: Ist das wirklich so wichtig oder kann das auch später erledigt werden?

Raus aus dem Haus

Und da sind wir wieder beim eigentlichen Thema: raus aus dem Haus. Geschwindigkeit bringt nur dann was, wenn dadurch echte Erkenntnisse gewonnen werden. Schnelle Entwicklung und dann doch erst in zwei Jahren Live-Gehen ist gemessen am Umfang vielleicht schnell, aber es kann schneller gehen.

Steve Blank, ein bekannter Autor aus der Startup-Szene (“The four steps to Epiphany”) schrieb in seinem Buch:

“Rule 1: There Are No Facts Inside Your Building, So Get Outside.”

Auch wenn Vertriebsmitarbeiter oder Product Owner “wissen”, was die Kunden wollen: Sie wissen es nicht, sie glauben es jedoch zu wissen. Daher ist doch nichts besser als ein direkter Einsatz unter Einbezug echter Kunden. Natürlich kann man hier noch Abstufungen machen: Interviews, UX-Labore oder nur Kunden mit expliziter Einladung (Friends/Family Test) sind oftmals die richtigen Hilfsmittel. Na dann: MVP einpacken und raus vor die Tür.

Abfall reduzieren

Oftmals wird man im Projekt mit Mitarbeitern und Entscheidern konfrontiert, die die fehlende Effizienz des Vorgehens bemängeln und ja , sie haben recht. BML ist nicht effizient im Sinne des Projektfortschritts , allerdings unterstützt die Methode die Effektivität . Und vor allem dann, wenn es heißt: es besteht kein Kundeninteresse, das Projekt wird abgesetzt.

Der Kern der Methode ist es, Abfall zu reduzieren und dadurch effektiv und effizient zu sein. Es gibt nichts ineffektiveres und ineffizienteres als ein Konzept, das keiner liest oder ein Produkt, das keiner nutzt.

Große Frage: Warum machen wir das nicht (öfters) bei Finanzdienstleistungen?

Gerade bei bestehenden Online-Vertriebskanälen sind solche Methoden einfach umzusetzen und geben schnell Einblick in vorhandenes Kundeninteresse und deren Bedürfnisse, bevor Omnibusse an Mitarbeitern dann die Umsetzung durchführen. Anregung zum Nachdenken.