Was ist ein MVP wirklich? Lerne 5 entscheidende Unterschiede zwischen MVP und Release kennen!

Ganz häufig erlebe ich angehende Product Owner in meinen Kursen, die den Begriff des MVP völlig missverstehen. Er wird mit einem Initial Release gleichgesetzt, dem später weitere Releases mit mehr Features folgen sollen. All diese Releases werden dann von ihnen als MVP bezeichnet, gerne auch mit folgenden Zahlen, etwa MVP 1, MVP 2, usw.

Dem liegt ein grundliegendes Missverständnis zugrunde, das leider in vielen Firmen weit verbreitet ist und immer wieder hohe unnötige Kosten verursacht.

Was ist mit MVP gemeint?

Was also ist ein MVP? MVP steht für Minimum Viable Product. Der Begriff wurde ganz wesentlich von Eric Ries in seinem Buch „Lean Startup“ verwendet und dadurch auch einer breiteren Masse bekannt gemacht. Wenn ich also von MVP rede, meine ich ein MVP im Sinne von Eric Ries.

Der wesentliche gedankliche Impuls seines Buches ist folgender: Zu Beginn einer Produktentwicklung ist fast alles unbekannt. Das größte Risiko ist nicht, das Produkt nicht bauen zu können, sondern das falsche Produkt zu bauen. Es geht darum, so schnell wie möglich zu lernen, was genau ein erfolgreiches Produkt ausmacht. Und dazu muss man 1. etwas bauen, 2. messen, wie Kunden damit interagieren und 3. daraus lernen.

Diese Feedback-Schleife, „Build – Measure – Learn“ Schleife genannt, durchlaufen wir so schnell es irgend geht und experimentieren dabei, d.h. wir führen Experimente durch, die Hypothesen bestätigen oder widerlegen.

Die drei Kernideen des MVP 

Darin stecken bereits die drei wichtigsten Ideen, die ein MVP ausmachen.

1. In diesen Experimenten wird jeweils etwas überprüft, mit dem Kunden in irgendeiner Weise interagieren können, etwas das sie wertschätzen können (oder auch nicht) – ein „Product“.  
2. Um möglichst schnell durch diese Feedback-Schleife zu gehen, bauen wir so wenig wie irgend möglich. Das ist mit „Minimum“ gemeint. 
3. Wir müssen so viel bauen, dass wir unsere Hypothese verproben und dadurch lernen können. Genau das ist mit „Viable“ gemeint. „Viable“ bedeutet so viel wie „lebensfähig“, auch „tragfähig“. Unser „Minimum Product“ muss also eine geeignete Interaktion mit Kunden ermöglichen, das Produkt muss uns also durch das Experiment tragen.

Beim Schaffen eines MVP stellt man sich also die Frage: Wie kann ich dieses Experiment mit minimalem Aufwand durchführen, OHNE bereits die komplette Lösung bauen zu müssen.

Im Laufe der Zeit verändert sich die Art der Hypothesen, die wir so überprüfen. Während zu Beginn geschäftskritische Annahmen auf dem Prüfstand stehen, die das Geschäftsmodell hinter dem Produkt untermauern, drehen sich Hypothesen später z.B. um die Art von Features oder Produkteigenschaften, die Kunden besonders schätzen und als wertvoll erachten.

Was ist ein Initial Release?

Unter Initial Release versteht man gemeinhin die allgemeine Verfügbarmachung eines neuen Produkts. Dies geschieht oft im Rahmen eines Product Launch, mit begleitenden Marketing-Maßnahmen. Ein Initial Release hat ein Feature-Set, von dem man davon ausgeht, dass einerseits „fit-for-use“, also tatsächlich nützlich ist, und das es für Kunden so attraktiv ist, dass sie bereit sind, den geforderten Preis zu bezahlen bzw. es zu benützen.

Hier geht es nicht um primär um Feedback-Schleifen oder Lernen, sondern rein um die erstmalige Delivery, um die Bereitstellung eines neuen Produkts.

Ein Initial Release enthält oft längst nicht alle Features, die sich ein Product Owner mittelfristig vorstellt, sondern idealerweise ein „minimum marketable feature set“. In Folge-Releases wird dieses Feature-Set dann erweitert, z.B. um das Produkt für bestehende Nutzer oder neue Kundengruppen attraktiver zu machen. 

Die 5 wichtigsten Unterschiede zwischen Initial Release und MVP

Aus den bisherigen Überlegungen ergibt sich: Während ein Initial Release die Bereitstellung von Features zum Ziel hat, ist ein MVP ein Enabler für ein Experiment.

Ein MVP ist einerseits viel weniger als ein Initial Release

• Ein MVP muss längst nicht alle Features enthalten, die erforderlich sind, um das Produkt tatsächlich erfolgreich zu verkaufen. Es muss nur genug Features enthalten, dass der Kunde mit der Produktidee so interagieren kann, dass Messen und daraus Lernen möglich ist.
• Ein MVP kann, muss aber keineswegs ein Inkrement sein, das bisherige MVPs enthält. Anders geartete Experimente können ganz unterschiedliche MVPs erforderlich machen, beispielsweise Pappmodelle, Produktsimulationen, Videos über das Produkt o.ä.

Ein MVP ist andererseits viel mehr als ein Initial Release

• Ein MVP steht nie allein, sondern ist immer ein Mittel zur Klärung einer produktbezogenen Frage. Ohne Hypothese macht ein MVP keinen Sinn. Ein MVP dient zur Überprüfung einer Hypothese.
• Es reicht nicht ein MVP zu erstellen, sondern man muss auch Sorge dafür tragen, dass tatsächlich Kunden damit interagieren. Zu einem MVP gehört also auch eine Idee, wie es in Kontakt mit Kunden kommt. 
• Nach dem durchgeführten Experiment hat man entsprechende Daten und daraus entstandene Erkenntnisse. Ein zum Kunden gebrachtes MVP ohne Daten und Erkenntnisse ist kein MVP.

Was passiert, wenn man MVP und Initial Release in einen Topf wirft?

Das zeigt sich am einfachsten an einem Beispiel: Vor einigen Jahren war ich an der Entwicklung eines Kundenportals für einen großen Energiekonzern beteiligt. Über viele Monate hinweg wurde mit großem Einsatz von vier Teams auf ein „MVP“ zugesteuert, das zum Ende des Jahres 2014 Live gehen sollte. Selbstverständlich sollte das Portal nicht nur über Desktops nutzbar sein, sondern auch von Mobilgeräten, darunter auch über das Windows Phone, von dem man annahm, das es einen schnell wachsenden Marktanteil haben würde. Leider stellte sich der Aufwand, der in die Windows Phone Unterstützung gesteckt wurde, im Laufe der Zeit als völlig vergebens heraus. Der Marktanteil des Windows Phone sank bis von 2,8% in Q4 2014 auf 0,4% in Q2 2016.

Was war passiert? Der ganze Fokus des Projekts lag auf Delivery. Es galt, zum Jahreswechsel ein Initial Release zu liefern. Dabei geriet über all der vielen Arbeit völlig aus dem Blickfeld, kritisch zu hinterfragen, welche Features tatsächlich zu einem minimum marketable feature set gehören sollten. Eine Überprüfung der vielen impliziten Hypothesen fand nicht statt. 

So wurde viel Zeit in Realisierung und Testing von Features mit einem zweifelhaften Kundennutzen gesteckt. Durch den hohen Zeitdruck sank gleichzeitig die innere Qualität der Software, was bereits zum Initial Release zu erheblichen zusätzlichen Kosten für Wartung und Weiterentwicklung führte.

Fazit

In einer Welt, in der wesentliche Aspekte in Bezug auf ein Produkt und das damit verbundene Business-Modell unbekannt sind, ist die Lerngeschwindigkeit der entscheidende Vorteil bei der Produktentwicklung. Erfolgreiche Product Owner schaffen es, den Return-on-Invest ihres Produkts zu maximieren. Sie investieren die Arbeitszeit ihres Teams ganz bewusst so, dass ein möglichst wertvolles Produkt entsteht. 

Bei der Gestaltung des Initial Release vermeiden sie es systematisch, in Produkteigenschaften und Features zu investieren, die von Kunden nicht als wertvoll erachtet werden. Dabei lassen sie sich nicht von Vermutungen leiten, sondern überprüfen diese systematisch möglichst frühzeitig mit Experimenten, für die sie passend gestaltete MVPs nutzen. 

Also haben beide, Initial Release und MVP ihre Berechtigung. Erfahrene Product Owner nutzen beide Konzepte gezielt zur Wertmaximierung ihrer Produkte.

Wie wird der Begriff MVP bei Dir verwendet? Welche Rolle spielt systematisches Lernen dabei? Bitte hinterlasse einen Kommentar mit deiner Perspektive. Es würde mich sehr interessieren, sie kennenzulernen.