Wie Finanzdienstleister in drei Monaten MVPs auf die Straße bringen können

Die Entwicklung von MVPs (Minimum Viable Products = minimal funktionsfähige Produkte) dauert gerade in regulierten Branchen mit viel IT-Altlasten wie in der Finanzindustrie häufig deutlich länger als geplant und übersteigt hierfür veranschlagte Budgets. Oft liegt das jedoch nicht an der Natur des MVPs, sondern ließe sich vermeiden.

von Dr. Johannes Huebner, CTO Stryber

Ein MVP ist die erste minimal funktionsfähige Iteration eines Produkts, die dazu dient, möglichst schnell aus Nutzerfeedback zu lernen und so Fehlentwicklungen an den Anforderungen der Nutzer vorbei zu verhindern. Um hochqualitative, individualisierte MVPs zügig an den Markt zu bringen, sind organisatorische, prozessuale und technologische Aspekte zu beachten. Darüber hinaus gilt es natürlich, diverse inhaltliche Punkte wie Wertversprechen, Zielgruppe, Monetarisierung etc. zu klären, welche aber nicht der Fokus dieses Beitrags sind.

1. Organisatorische Aspekte

Zunächst muss die Zielstellung des MVPs klar definiert werden, welche maßgeblich die Ausgestaltung des MVPs beeinflusst. Soll etwa allgemeines Kundeninteresse und -verhalten besser verstanden, die Details des Wertversprechens ausgearbeitet, oder technische Machbarkeit geprüft werden?

Manche dieser Fragen lassen sich etwa auch mit ganz einfachen Smoke-Tests oder Klick-Prototypen beantworten, ohne überhaupt mit IT-Entwicklung zu beginnen. Auch in allen anderen Fällen gibt die Zielstellung wichtige Leitplanken vor, etwa bzgl. der Priorisierung der Features.”

Des Weiteren sollte ein dediziertes, funktionsübergreifendes Team mit der Entwicklung und dem Betrieb des MVP beauftragt werden, das sich voll auf diese Aufgabe fokussieren kann. Während es auf den ersten Blick verlockend erscheinen mag, MVPs als Nebenprojekt zu betrachten, so resultiert der mangelnde Fokus häufig in nicht erreichten Deadlines und weniger erkenntnisreichen Ergebnissen. Genau wie sich auch Startups nur schwer ohne vollen Fokus zum Erfolg führen lassen, ist auch die sinnvolle Entwicklung von MVPs anspruchsvoll und erfordert entsprechende Ressourcen, um möglichst viele Schlüsse ziehen zu können. Die Analogie zu Startups verdeutlicht auch die erforderlichen Rollen:

Neben Software-Entwicklern werden in der Regel auch UX/UI Designer, Product Owner, Marketing-Experten und Businessseitige Owner und Sponsoren gebraucht.”

All das ist nötig, um neben der Entwicklung des technischen Produkts auch die Erforschung des Geschäftsmodells, Gewinnung und Kommunikation mit Pilotkunden usw. abzudecken.

Außerdem gilt es, das regulatorische Setup abzustecken. Sofern möglich, liegt es auf der Hand, den Umfang des MVPs so zu definieren, dass dieser regulierte Bereiche komplett vermeidet, etwa indem man für den MVP lediglich ein schlankes Frontend um ein bereits vorhandenes, internes Backend herum (oder das eines regulierten Drittanbieters) entwickelt. Für den Fall, dass man sich in regulierten Gewässern begibt, muss eruiert werden, ob dies mit dem internen Setup in angemessenem Zeitrahmen möglich ist. Andernfalls bieten diverse Banking-as-a-Service-Anbieter in Deutschland und der EU häufig einen schnelleren Zugang zum Markt.

2. Prozessuale Aspekte

Wegen der bei MVPs inhärenten großen Unsicherheiten empfiehlt sich der Einsatz agiler Methoden und der Lean-Startup-Methode – und zwar nicht nur bei der Software-Entwicklung selbst, sondern auch bei diversen Aspekten des Geschäftsmodells wie Wertversprechen, Vermarktung usw. Jeder Aspekt muss iterativ entwickelt werden. Im Anfangsstadium sollten alle offenen Fragen mittels qualitativer und quantitativer Methoden so früh und datengetrieben wie möglich beantwortet werden. Bereits vor Beginn der IT-Entwicklung sollten leichtgewichtige Benutzertests durchgeführt werden, z.B. mit Hilfe von Benutzerumfragen, Mockups, Landing Pages oder anderen Artefakten, die sich mittels No-Code-Tools wie Unbounce oder Webflow innerhalb von wenigen Stunden erstellen lassen.

Ebenfalls wichtig ist eine effiziente Kommunikation. Das Team kann sich nicht erlauben, immer wieder Tage auf Antworten auf wichtige Fragen warten zu müssen – sei es teamintern oder mit Stakeholdern außerhalb des Projektteams. Tools wie Microsoft Teams oder Slack helfen hier immens. Auch sollte zu Beginn geklärt werden, wo Artefakte wie Umfrageergebnisse, Designs oder Code abgelegt werden und wie der MVP möglichst effizient und häufig bereitgestellt werden kann.

Essentiell ist auch ein klares Management der Erwartungen hinsichtlich des ersten MVP-Releases. Schon der LinkedIn-Gründer Reid Hoffman sagte:

Wenn einem die erste Version seines Produkts nicht peinlich ist, hat man dieses zu spät veröffentlicht.”

Hilfreich kann dabei sein, die kontinuierliche Weiterentwicklung des Produkts hervorzuheben, d.h. im Umkehrschluss, dass das Produkt nie komplett fertiggestellt sein wird, geschweige denn mit dem ersten Release endet. Wichtig ist jedoch eine Priorisierung aller Features z.B. nach der MoSCoW-Methode, die die Umsetzungsreihenfolge vorgibt und damit den Umfang des ersten Releases maßgeblich bestimmt.

Ebenso sollte das Team Klarheit über den Zielkonflikt zwischen Zeit, Kosten, Umfang und Qualität schaffen. Um MVPs schnell an den Markt zu bringen, dürfen nicht alle Zieldimensionen gleichzeitig fixiert werden. Häufig sind Zeit- und Budgetrahmen eher inflexibel und auch hinsichtlich der Qualität herrscht wenig Kompromissbereitschaft. Ergo liegen im Umfang oft die größten Stellschrauben. Es ist hilfreich, alle Features als priorisierte Liste anzusehen, die soweit wie möglich bis zum Release abgearbeitet wird – mit dem klaren Anspruch, weitere Features nach dem ersten Release nachzuliefern. Auch werden Beta-Nutzer höchstwahrscheinlich neue Features fordern, die möglichst zeitnah umgesetzt werden wollen. Bei der Priorisierung sollte man sich fragen, welche Features oder Prozesse sich anfangs manuell abbilden lassen – und das evtl. ohne das sich diese merklich auf die User Experience auswirken würde, wie etwa im ursprünglichen Mechanical Turk vorgesehen (https://en.wikipedia.org/wiki/Mechanical_Turk). Müssen außerdem wirklich alle Features von Anfang an umgesetzt werden oder können die Kernfragen des MVPs auch mit einem abgespeckter Funktionsumfang beantwortet werden? Muss der MVP bereits Grenzfälle abdecken oder lassen sich diese im kleinen MVP-Benutzerkreis entsprechend des Pareto-Prinzips auch anders abhandeln?

Weiterhin muss geplant werden, was mit dem Projekt im Erfolgsfall geschieht.

Wird der MVP als Start-Up ausgegründet, lebt dieser als eigenständige Marke weiter, oder werden die Funktionalitäten in bestehende Produkte integriert (und ggf. neu entwickelt)?”

In jeder Variante sollte auch absehbar sein, welche Budgets hierfür jeweils herangezogen werden können. Interne Sponsoren für das Projekt auch nach der MVP-Phase können spielentscheidend sein, wenn es darum geht sicherzustellen, dass aus dem MVP letztendlich ein für den breiteren Markt skaliertes Produkt entsteht. Genauso wichtig ist es, mit dem MVP ehrlich ins Gericht gehen und diesen wieder einzustellen, falls dieser seine Zielsetzung nicht erreicht. Dies ist nicht als Scheitern anzusehen, sondern gehört zum Lernprozess.

3. Technische Aspekte

Neben organisatorischen und prozessualen Aspekten, tragen auch technische Aspekte zum Erfolg eines MVPs bei. Es empfiehlt sich zum einen, die technische Architektur so einfach wie möglich zu halten. Wenn es für die eingangs definierten Ziele des MVPs ausreicht, eine einfach Website mit einem No-Code-Tool zu bauen, ist dies in aller Regel gegenüber einer aufwändigen Eigenentwicklung zu bevorzugen. Auch bei einer Eigenentwicklung sollte zunächst auf soviel Overhead wie möglich verzichtet und etwa mit einem monolithischen Backend anstatt Microservices begonnen werden. In diesem Stadium ist es vollkommen in Ordnung, ein System zu entwickeln, das nicht skaliert – es sei denn, die Zielstellung des MVP beinhaltet bspw. explizit die technische Machbarkeitsprüfung, ob ein System eine gewisse Anzahl an Transaktionen pro Sekunde abwickeln kann.

Zum anderen sollte der Tech-Stack entsprechend der Rahmenbedingungen pragmatisch gewählt werden.

Bei der Entwicklung eines einzelnen MVPs sollte das verwenden werden, was das Team am besten beherrscht. Sollen mehrere MVPs gebaut werden, könnte es durchaus eine Überlegung wert sein, auf Stacks zu wechseln, die Rapid Prototyping begünstigen, z.B. Ruby on Rails.”

Zuletzt sollten auch Make-or-Buy-Entscheidungen tendenziell zugunsten des Einkaufs getroffen und so viele Komponenten wie möglich eingekauft statt selbst entwickelt werden. Im kurzfristigen MVP-Zeithorizont schlagen Entwicklungszeit und -kosten i.d.R. deutlich stärker zu Buche als etwaige Kosten für SaaS-Anbieter. Bei erfolgreichem MVP-Abschluss können solche Entscheidungen nochmals überdacht werden.

Fazit:

Wenn Unternehmen die obenstehenden Punkte berücksichtigen, steht der erfolgreichen Lancierung eines MVPs in wenigen Monaten nichts im Wege.”

Dr. Johannes Huebner, Stryber