waiting..
MVP richtig definieren

Blog

Agile Themen

MVP? Wir bauen lieber erst mal viele MCPs!

Das sogenannte MVP, also das Minimum Viable Product, wird oft fehlinterpretiert als erste Version des finalen Produkts, mit der man bereits Geld verdient. Fehlinterpretiert ist in diesem Zusammenhang jedoch nur teilweise richtig. Denn im Grunde gibt es nicht DIE EINE Definition des Begriffs MVP. Jedes Unternehmen muss für sich selbst definieren, wie es diesen Begriff versteht und wie er in der Organisation gelebt wird. Theoretisch ist als Definition alles denkbar vom ersten Blatt Papier, auf dem Prozesse zur Lösung des gegebenen Problems aufgezeichnet werden bis hin zur ersten Produktversion, die auf den Markt gebracht wird.

Definition MVP

Es gibt zwei gängige Definitionen, auf die oft verwiesen wird. Die eine stammt vom Begründer des MVP Begriffs, dem Unternehmer Frank Robinson. Er beschreibt das Minimum Viable Product 2001 als “smallest product or release of a product that can succeed in the market”. Aber was bedeutet in diesem Zusammenhang “succeed”? Die Rede ist hier vom Return on Investment (ROI). Es geht also darum, eine möglichst hohe Kapitalrendite zu erwirtschaften.

Ganz anders lautet die Definition der Unternehmer Steve Blank und Eric Ries, die den Begriff MVP im Rahmen der Lean-Startup-Methode popularisiert haben. Nach ihnen ist ein MVP “The smallest thing we can use or make to test a product hypothesis”. Die Hypothesen sind dabei Annahmen oder Vermutungen, die aus den Ideen zur Lösung des gegebenen Problems getroffen werden. Sie gelten erst als sicher, wenn sie empirisch validiert wurden. Man entwickelt also eine erste Testversion, total rudimentär. Anschließend geht es ins Testing, Userdaten werden erhoben und ausgewertet. Aus den Ergebnissen lernt man. Das ganze wird als Build-Measure-Learn Zyklus bezeichnet.

Nach der Definition von Robinson handelt es sich beim “product” also tatsächlich um ein Produkt oder Release. “Viable” bedeutet in diesem Zusammenhang erfolgreich, also einen hohen ROI generierend. Nach Blank und Ries ist das “product” ein Test und “viable” bedeutet, dass man etwas davon lernt. In der Praxis vertreten wir auch eher die Meinung von Blank und Ries … aber Fakt ist: Der Begriff MVP kann je nach Definition alles sein vom ersten schnellen und kostengünstigen Entwurf bis hin zur teuren und zeitaufwändigen finalen Produktversion.

Und was ist ein MCP?

Wir bei der prosma haben uns deshalb auf folgenden Standard committet: Wir nennen unsere allererste Version, mit der wir unsere Annahmen be- oder widerlegen, ein MCP. MCP steht für Minimum Crappy Product.

Damit vermeiden wir es, dass bei den Nutzern falsche Erwartungen hervorgerufen werden. Vom MVP wird aufgrund des Namens in der Regel erwartet, dass es schon “viable” ist, also lebens- bzw. funktionsfähig. Die Enttäuschung ist groß, wenn es das eben noch nicht ist. Das MCP dagegen muss im Grunde gar nichts sein. Es ist die allererste Version von etwas, das schrittweise zum MVP verbessert werden kann. Die Tests können also völlig unvoreingenommen und ohne Erwartungen seitens der Nutzer durchgeführt werden. Wenn wir bei einem Kunden als Product Owner eingesetzt werden, starten wir typischerweise mit den kritischsten und unsichersten Elementen der Lösung, da wir genau dort möglichst früh ein Feedback benötigen. Sobald die kritschen Punkte validiert sind, entwickeln wir unser MCP iterativ weiter, bis es den gewünschten Mehrwert für unsere Zielgruppe generiert. Auch hier sind wir sehr fokussiert. Wir nutzen Prozessdiagramme (EPK-Modelle, Swimlandes, BPMN-Modelle) um dann den Prozess möglichst schnell End-to-End abdecken zu können, wobei wir alles Unnötige rigoros rausstreichen – Hauptsache, das Produkt ist möglichst schnell nutzbar und stabil. Dabei ist es uns vor allem wichtig, bei dem Prozess möglichst viel zu lernen. Die erste Produktversion, die live geht, nennen wir in unseren Projekten dann MVP.

Aus unserer Sicht sollten sich POs immer folgende Fragen stellen:

  1. Verstehen wir wirklich die Probleme, die wir lösen wollen / sollen?
  2. Wollen / brauchen die Menschen unser Produkt wirklich?
  3. Können die Menschen es benutzen?
  4. Können wir es tatsächlich entwickeln?
  5. Werden die Menschen es auch in Zukunft benutzen?

Wichtig ist vor allem, die Kunden und ihre Bedürfnisse genau zu kennen. Dafür ist es wichtig, Zeit mit ihnen zu verbringen, sie zu beobachten, sich mit ihnen auszutauschen. Lasst eure Kunden bereits euer MCP testen, seht ihnen dabei zu, wie sie es benutzen und lernt von ihnen. Versucht, ihr Problem bis ins kleinste Detail zu verstehen.

Ständige Validierung der Lösungsansätze

Ein wichtiger Aspekt dabei ist die Devise “Not built it, just offer it” von Jeff Patton, ehemaliger Softwareentwickler und heute erfolgreicher Berater und Autor im Bereich der agilen Methoden. In der Branche wird er häufig als Godfather of User Stories bezeichnet. Ihm zufolge soll man keinerlei Ressourcen auf die Entwicklung von fertigen Features verschwenden, bevor man nicht weiß, ob die Nutzer sie wollen bzw. brauchen. Aber was genau meint er damit, die Funktionen einfach anzubieten, bevor man sie entwickelt?

Lasst uns dazu das Beispiel TripAdvisor betrachten. Der Gründer der Plattform, Stephen Kaufer, sagte in einem Interview, dass sie neue Funktionen stets testen, bevor sie sie entwickeln. Ihr fragt euch, wie das funktionieren soll? Ganz einfach – sie finden heraus, wie viele User Interesse an einer neuen Funktion haben, zum Beispiel an einem Newsletter. Dafür bauen sie einen Link auf ihrer Homepage ein, auf den die User klicken sollen, um sich für den Newsletter anzumelden. Der Link bleibt dann für einen beliebigen – meist relativ kurzen – Zeitraum auf der Seite, also zum Beispiel nur für eine Stunde oder einen Tag lang. Die Newsletter-Funktion ist noch nicht entwickelt, der Link führt also ins Nichts. Der User erhält eine Fehlermeldung.

Kaufer sagt, dass viele Unternehmen Angst davor hätten, Links oder Buttons ohne Funktionen einzubinden, aus Sorge, das könne beim Nutzer zu negativen Erfahrungen und damit zu einer negativen Wahrnehmung des Produkts führen. “Kommen Sie schon – was passiert, wenn ein User auf einen Dead Link klickt? Er wird seine Internetverbindung dafür verantwortlich machen, aber nicht mich”, so Kaufer in dem Interview.

Anforderungsvalidierung durch Dummy-Lösung

Für den User ist es also nur eine kleine Fehlermeldung, nichts, an das er sich nachhaltig erinnern wird oder was bei ihm ein negatives Empfinden gegenüber dem Produkt hervorruft. Für das Unternehmen ist es aber weit mehr als eine Fehlermeldung. Denn mit jedem Klick auf die neu angebotene – noch nicht entwickelte – Funktion kann es Nutzerdaten sammeln. Anhand der Klickzahlen kann man ableiten, ob die neue Funktion gewollt bzw. gebraucht wird, also ob ein Interesse der User an ihr besteht. Und erst dann sollte man Energie, Zeit und Geld darauf verwenden, die Funktion auch wirklich zu entwickeln.

Aber selbst dann ist es nicht unbedingt ratsam, sofort ein fertiges MVP zu entwickeln. Auch hier beginnt wieder alles mit einem ersten MCP, das dann iterativ weiterentwickelt wird. Wenn man iterativ sein Produkt verbessert, kann es sogar passieren, dass das MVP, also das, was per definitionem “viable” ist, schon viel früher oder anders erreicht wird, als man es sich am Anfang vorgestellt hat.

Ein (altes) MVP Beispiel

Lasst uns das an einem einfachen Beispiel verdeutlichen. Unsere Zielgruppe hat folgendes Problem: Sie wollen ein Produkt, das sie von A nach B befördert. Wir entwickeln also die Idee von einem Produkt, das unsere Zielgruppe lieben wird – ein Auto. Da wir dabei iterativ und agil vorgehen, entwickeln wir zunächst ein Skateboard. Ein einfaches Brett mit kleinen Rädern. Kostengünstig und wenig zeitaufwändig in Entwicklung und Produktion. Das ist unser MCP. Es löst das Grundproblem, da es Fortbewegung ermöglicht. Es wird den Nutzer aber nicht glücklich machen. Also entwickeln wir es weiter. Zum Roller, zum Fahrrad, zum Motorrad. Und dann kann es passieren, dass unsere Zielgruppe merkt, dass ein Fahrrad oder ein Motorrad total praktisch ist, weil sie damit an Staus vorbeifahren kann, schnell Parkplätze findet und wenig bis gar kein Benzin benötigt. In diesem Fall würde die bisherige Weiterentwicklung unseres MCPs die Nutzer bereits vollends zufriedenstellen und unser MVP läge folglich irgendwo zwischen Fahrrad und Motorrad. Wir bräuchten also keinerlei Zeit, Geld oder Energie darauf verschwenden, unsere ursprüngliche MVP-Idee – also das Auto – zu entwickeln, weil es für den User keinen größeren Mehrwert generieren würde.

Es macht keinen Sinn, jede Idee zu skalieren, weil viele Ideen keinen oder zu wenig Wert für die Zielgruppe generieren. Denn das ist es letztlich, was zählt: Generiert den richtigen Mehrwert für die User, dann wird es sich auf euren ROI auswirken.

Einfache Lösungen helfen früher

Unser Appell an euch lautet daher: Entwickelt eine Idee, die ein bestimmtes Problem lösen kann, betreibt genaue Recherche, analysiert eure Zielgruppe und ihre Probleme, Wünsche und Bedürfnisse. Entwickelt ein erstes MCP, gebt es an einen kleinen Teil der Menschen heraus und sammelt Userdaten. Wenn ihr euch gemeinsam darauf geeinigt habt, dass das Produkt die beabsichtigten Auswirkungen auf die kleine Benutzergruppe hat, liefert es schrittweise an mehr Benutzer aus, während ihr es immer weiter messt und verbessert. Das gibt euch Zeit, euch mit operativen Aspekten wie Hardwarekapazität, Monitoring, kontinuierlicher Bereitstellung, Skalierbarkeit usw. zu befassen.

Entwickelt eure MCPs iterativ immer weiter zum MVP, veröffentlicht es und führt Tests durch. Bringt dann weitere Features raus. Und lernt von jeder einzelnen Iteration, von jeder Annahme, die ihr falsch getroffen habt und von jeder Annahme, die ihr richtig getroffen habt. Von jeder Änderung, die ihr nicht geplant hattet und von jeder Funktion, die bei den Usern gut ankam. Lernt während des gesamten Entwicklungszyklus. Denn das ist der Mehrwert, der euch besser macht und sich letztendlich natürlich auch auf den Gewinn auswirkt. Macht Fehler, lernt aus ihnen und werdet besser – nur so könnt ihr erfolgreich sein.

Über den Autor

Michael Schneppensiefer
Michael Schneppensiefer
Geschäftsführer