Was ist ein MVP – ein Minimum Viable Product?

Heute folgt mal wieder ein vorsichtiger Blick in unsere Zauberküche. Ich möchte aufzeigen, wie wir neue Entwicklungsprojekte angehen. Dabei gibt es für uns zwei unterschiedliche Ansätze.

Wir bauen die App einfach

Wenn der Umfang einer neuen App sehr überschaubar ist, kann man das Risiko der Entwicklung gut einschätzen. Die Kosten sind gering, weil zum Beispiel nur ein Entwickler für eine kurze Zeit (weniger als einen Monat) daran arbeitet. In diesem Fall definieren wir einen Funktionsumfang, die App wird gebaut und raus an die Öffentlichkeit damit. So war das der Fall bei den Telefonnotizen, den Meetingkarten und auch bei Herein.

Der Funktionsumfang ist für „mal eben bauen“ zu groß

Manchmal kann man bei ersten Diskussionen zu einer neuen App sofort erkennen, dass dieser Umfang die Grenze des Personen-Monats überschreiten wird. Oder – wie bei Merlin Project – das Produkt ist von strategischer Bedeutung. In diesem Fall reden wir von einem Risiko-Investment und hier gehen wir natürlich entsprechend vorsichtiger vor.

In der ersten Phase bauen wir Mockups (Bilder in Apple Keynote, wie wir uns die App vorstellen) anhand derer wir die Bedienung und die Abläufe in der künftigen App gedanklich simulieren. Hin und wieder kommen wir aber an unsere Grenzen der Vorstellungskraft und brauchen eine weitere Technik: einen Prototypen.

Ein Prototyp ist für uns ein kleines Programm, was eine bestimmte Technik, einen Arbeitsablauf oder nur ein Konzept verdeutlicht. Es werden also viele kleine Apps gebaut. Da diese Test-Apps nur sehr kurz leben, versuchen wir schnell zum Ziel zu kommen. Es geht uns dabei also nicht um Schönheit oder saubere Programmierung.

Während dieser Phase ist es meistens noch meine Aufgabe, das Finanzielle der künftigen App zu prüfen: Was wird uns die Entwicklung der App kosten und was könnten wir damit verdienen. Denn wie pflege ich immer zu sagen: „Die Siebziger sind vorbei. Von reiner Liebe können wir leider nicht leben.“

Irgendwann haben wir dann (hoffentlich) alle Aspekte der neuen App erforscht. Es gibt dann ein Set von Slides, die das Aussehen zeigen. Und wann immer es notwendig war, wurden neue oder kritische Techniken in einem Prototyp getestet bis wir mit dem Ergebnis zufrieden waren. Zusätzlich gibt es eine große Aufstellung der zu erwartenden Kosten und erhofften Einnahmen. Dann setzen wir uns (natürlich Remote via Zoom) zusammen und diskutieren unsere Erkenntnisse.

An dieser Stelle sind bei uns schon sehr viele neue App-Ideen gescheitert. Sei es durch eine schlechte Basisidee, eine zu niedrige technische Hürde oder auch eine zu hohe. Und auch, wenn die geglaubten Nutzerzahlen zu gering sind, wird eine App nicht entwickelt. Natürlich ist mir klar, dass diese Einschätzungen – selbst wenn sie im Team getroffen werden – sehr subjektiv sind und in keiner Weise mit einer zukünftigen Realität übereinstimmen müssen. Aber irgendwann muss einfach eine Entscheidung getroffen werden.

Startschuss für den MVP

Wenn unsere Zuversicht in die neue App – und die Motivation diese zu bauen – auf einem ausreichend hohen Niveau sind, starten wir mit der Entwicklung.

Aber auch hier gilt es vorsichtig zu sein. Ich will ja nicht mit einem Fehlschuss die Zukunft des Teams aufs Spiel setzen. Und genau hier setzt ein weiterer Mechanismus des Risikomanagements ein: Ein minimal lebensfähiges Produkt herstellen.

Laut Wikipedia wurde der Begriff MVP, das erste Mal von einem Frank Robinson geprägt und von Steve Blank und Eric Ries popularisiert. Die Idee dahinter ist so intuitiv klar sinnvoll: Man baut ein neues Produkt, was nur mit den wichtigsten Kernfunktionen ausgestattet ist. Anhand diesen Produkts kann man dann innerhalb des Teams, strategischen Partnern und gerne auch Vertretern möglicher Kundengruppen testen, ob Interesse an diesem Produkt besteht und der eingeschätzte Markt dafür ausreichend groß ist. Natürlich testet man dabei auch, ob die Bedienung der App mit den getroffenen Annahmen gut ist.

In der Entwicklung hat sich bei ProjectWizards schon seit vielen Jahren ein iterativer Ansatz etabliert:

1. Man entwickelt nach dem erstellten Mockups
2. Wir schauen uns das Ergebnis in kleiner Runde an und entscheiden, ob es gut funktioniert.
3. Sind wir nicht zufrieden, iterieren wir bei kleineren Problemen in der Software, bei grundsätzlichen Problemen wird am Mockup gezeichnet.

Immer nach dem Motto: Der schnellste und einfachste Weg diktiert das Vorgehen.

So werden peu à peu alle Bausteine für den MVP zusammengebaut. Ab einem bestimmten Zeitpunkt beginnt jemand (also meistens ich) mit der neuen Software zu spielen.

Erste Tests während der MVP-Entwicklungsphase

Auch wenn es sehr zeitaufwendig und machmal sogar sehr frustrierend ist, müssen die Konzepte und Annahmen immer wieder überprüft werden. Da heißt, es muss mit Beispieldaten in der neuen App gearbeitet werden. Natürlich crasht es zunächst an allen Ecken und Enden. Aber im Laufe der Zeit bessert sich die Situation.

Irgendwann kommt die Frage auf, wie viel Zeit man in einen MVP investieren soll oder muss. Dafür gibt ess keine Regel und keine Vorschrift. Es dauert so lange, bis man für sich selbst die Frage beantworten kann, ob das neue Programm in der freien Wildbahn überlebensfähig ist.

Abgrenzung zum Minimum Marketable Product (MMP)

Das minimal marktfähige (oder verkaufsfähige) Produkt geht einen deutlichen Schritt weiter – zumindest in meiner Definition.

Während das MVP nur für den internen Gebrauch (inkl. einiger Schlüsselpersonen) gebaut ist und ich damit noch gar kein Geld verdienen kann, geht das MMP einen wesentlichen Schritt weiter: Diese Version kann verkauft werden.

Im Gegensatz zu den Gepflogenheiten der Open Source-Szene, braucht eine MMP für mich mindestens:

• eine Versionsnummer 1.0
• eine Dokumentation
• eine Webseite
• einen Verkaufspartner (App Store, Paddle etc.)
• und mehr

Aus diesem Grund verwenden wir auch nicht die Bezeichnung MMP, sondern Version 1 oder 1.0.

Wann ist der Übergang von MVP zu Version 1

Das ist bei uns ein fließender Übergang. Wir setzen uns zwar einen Termin für die Finalisierung des MVP, was dann wiederum gleich der Start-Termin für die Entwicklung der verbleibenden Funktionen der Version 1.0 ist.

Wie man an der Grafik erkennen kann, ist es als sequentieller Prozess geplant. In der Realität verwischen die Grenzen aber teilweise sehr.

Wann ist ein MVP fertig?

Hierfür gibt es kein wirklich festgelegtes Datum. Wenn wir entscheiden, dass wir mit der Qualität oder dem Funktionsumfang nicht glücklich sind, dann arbeiten wir weiter an der App. Auch, wenn es nur eine interne Version ist.