Wenn man sich heutzutage mit Produktenwicklung und Startups beschäftigt, dann kommt man um das Minimum Viable Product (MVP) kaum herum. Aus Zeit- und Kostengründen ist es üblich geworden, nicht auf das fertige Produkt zu warten, sondern bereits frühzeitig Versionen zu veröffentlichen. Ganz früher hat man das mal abschätzig Bananensoftware genannt, die beim Kunden reift, dann kam die Open Source Bewegung mit dem “Release early, release often!”-Mantra und die Beta-Version gehört seitdem zum guten Ton. Mittlerweile ist quasi alles Beta und der Nutzer wird Teil der Produktentwicklung:
A Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.
Eric Ries hat dies mal netterweise in einer kurzen Präsentation aufgemalt und erläutert:
In der Theorie klingt dies alles sehr nachvollziehbar, aber in der Praxis ist das Minimum Viable Product ganz schön anstrengend. Es beginnt mit der Festlegung auf ein bestimmtes Featureset, das minimal genug ist, aber eben auch die Nutzer bereits anspricht. Und es geht munter weiter mit der Festlegung der nächsten Entwicklungsschritte anhand des Nutzerfeedbacks. Richtig anstrengend wird es allerdings, wenn der gemeine Nutzer an sich nicht versteht, dass er gerade ein MVP benutzt, sondern völlig zu recht erwartet, dass er bereits ein fertiges Produkt nutzt.
Ich möchte mal eben anhand unseres aktuellen Projektes Stuffle erläutern, wieso das Minimum Viable Product in der Praxis so anstrengend ist.
1. Es gibt ein Budget, das eingehalten werden soll. Das Budget sorgt für die ersten Rahmenbedingungen und vor allem für Beschränkungen.
2. Time to market: Wir wollen schnell an den Start gehen, auch weil wir glauben, daß wir nicht die einzigen sind, die das Thema lokaler Flohmarkt neu interpretieren wollen.
3. Entwickler-Ressourcen sind grundsätzlich limitiert, daher müssen wir mit einer gewissen Grundknappheit auskommen.
Bei Stuffle haben die drei Punkte dazu geführt, daß wir uns für den Start auf eine App für iPhone mit iOS 5 gepaart mit einer Anmeldung über Facebook entschieden haben. Und wir wissen durchaus, dass nicht jeder ein iPhone hat und auch nicht alle Facebook toll finden. Aber die Kombination iPhone + Facebook hat bei uns den Entwicklungsaufwand dramatisch reduziert. Wir lassen also eine ganze Reihe interessierter Menschen außen vor und handeln uns noch dazu jede Menge schlechter Bewertungen im iTunes Store ein, weil Nutzer enttäuscht sind. Daraus lernen wir natürlich und sehen, dass es durchaus Nachfrage nach unserem Produkt gibt. Aber der Tradeoff “schneller am Markt vs. volle Zufriedenheit der Nutzer” ist schon hart, denn natürlich wollen wir keine unzufriedenen Nutzer haben und verstehen auch, dass Nutzer für sie als unnötig empfundene Limitierungen nicht tolerieren möchten. Toll ist wiederum, das viele Feedback von Leuten, die sagen, was sie alles noch gerne hätten, was verbessert werden könnte und was sie wirklich erfreut an dem Produkt. Abgesehen davon lernen wir durch die tagtägliche Nutzung eben auch sehr viel darüber, ob und wie unser Produkt genutzt wird und wo wir optimieren müssen. Wir vermeiden eben auch, dass wir lange irgendetwas entwickeln, das dann nicht genutzt wird, sondern holen uns frühzeitig Feedback von den Nutzern.
Hätten wir auch gleich in der ersten Version mit iPhone, Android, Windows7, Facebook, Twitter, Google+, Githb, Deutsch, Englisch, Mandarin, perfekter UX/UI und super Nutzerführung starten können? Sicherlich, aber nicht in diesem Mai, sondern erst viel, viel später und zu ganz anderen Kosten und mit viel größerem Aufwand. Wahrscheinlich hätten wir auch unzählige Features für die Tonne entwickelt, die kein Mensch braucht, wir uns aber dennoch ausgedacht hatten. Natürlich ist das perfekte Produkt das Ziel, aber das schaffen wir nur mit viel Nutzerfeedback und vielen Iterationen bei der Entwicklung.
Wir leiden also derzeit sehr über jede einzelne Bewertung mit einem Stern, nehmen dies aber in Kauf, um in den nächsten Releases des Produkts besser zu sein als wir es ohne Nutzer je hinbekommen hätten. Wir haben es ja nicht anders gewollt. Wir freuen uns allerdings auch immer über jede einzelne positive Bewertung für Stuffle im iTunes Store und über jede Empfehlung:
Würden wir es wieder so machen? Ja, auch wenn das Minimum Viable Product anstrengend ist, so sind die Ergebnisse für den Nutzer einfach besser. Die frühe Verifizierung der eigenen Annahmen ist ein riesiger Pluspunkt, dafür nehmen wir die anstrengenden Faktoren des MVP als Ansporn, das Produkt noch besser machen zu können, durchaus in Kauf.
Google+
