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 jede Definition denkbar. Das MVP kann das  erste Blatt Papier sein, auf dem Prozesse zur Lösung des gegebenen Problems aufgezeichnet werden. Definieren wir das MVP als erste Produktversion, die auf den Markt gebracht wird, eröffnen sich damit viele Möglichkeiten.

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  rudimentäre Testversion. 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 einen hohen ROI generierend, also „erfolgreich.“ Nach Blank und Ries ist das „product“ ein Test und „viable“ bedeutet, dass man etwas davon lernt. In der Praxis vertreten wir die Meinung von Blank und Ries. 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. Genau hier ist es wichtig möglichst früh ein Feedback zu bekommen.

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. Dabei streichen wir alles Unnötige rigoros. Wir fokussieren uns darauf das Produkt möglichst schnell nutzbar und stabil zu machen. 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:

  • Verstehen wir wirklich die Probleme, die wir lösen wollen / sollen?
  • Wollen / brauchen die Menschen unser Produkt wirklich?
  • Können die Menschen es benutzen?
  • Ist eine Entwicklung tatsächlich realistisch?
  • 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 „Don’t build it, just offer it“ von Jeff Patton. Patton ist ein 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. Viel wichtiger ist es zunächst zu wissen, 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 zunächst heraus, wie viele User Interesse an einer neuen Funktion haben. Zum Beispiel das Interesse an einem Newsletter.

Dafür bauen sie einen Link auf ihrer Homepage ein, auf den die User klicken können, um sich für den Newsletter anzumelden. Der Link bleibt dann für einen beliebigen – meist relativ kurzen – Zeitraum auf der Seite. Das kann zum Beispiel nur für eine Stunde oder einen Tag lang der Fall sein. Die Newsletter-Funktion ist noch nicht entwickelt, der Link führt also ins Nichts. Der User erhält eine Fehlermeldung. Daher nennt Kaufer dieses Vorgehen auch 404-tests.

Kaufer sagt, dass viele Unternehmen Angst davor hätten, Links oder Buttons ohne Funktionen einzubinden. Sie seien von der Sorge getrieben, 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. Es ist unwahrscheinlich, dass sich die Nutzer der Website die 404-Meldung als negatives Empfinden gegenüber dem Produkt merken.

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. Wir können ableiten, ob ein Interesse der User an der Funktion 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. Verbessern wir  unser Produkt iterativ, kann der Zustand „viable“ womöglich anders und damit schon viel früher erreicht werden. Wir können so die anfänglichen Prognosen kontinuierlich testen.

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. Wir hätten festgestellt, dass die ursprüngliche Idee für den User keinen größeren Mehrwert generieren würde.

Es ergibt keinen Sinn, jede Idee zu skalieren. Viele Ideen bedeuten einfach keinen oder zu wenig Wert für eine Zielgruppe. Denn das ist es letztlich, was zählt: bietet den Usern den richtigen Mehrwert an. Ein eindeutiger Mehrwert wirkt sich am positivsten auf euren ROI aus.

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. Messt und verbessert das Produkt immer weiter. 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 heraus.

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.

3 Comments

Comments are closed.

  1. […] Product Owner sollten in jedem Sprint überlegen, wie die Metriken verändert werden sollten und diese danach gewissenhaft prüfen. An die Steakholder sollte viel mehr über Mehrwert-Kennzahlen berichtet werden, um die „Featuritis“ zu heilen und datengesteuertes Geschäftsdenken zu fördern. Aus diesem Grund sind übrigens Unternehmen wie Amazon, Netflix, Google, AirBnb, usw. so erfolgreich – sie entwickeln etwas um dann schnellstmöglich die Veränderung zu messen und zu bewerten. […]

  2. […] Feedback – und das idealerweise in Echtzeit oder Zeitfenstern von Stunden oder Minuten (404 Tests). Das MVP wird schnell und einfach erstellt und verfügt nur über die nötigsten Kernfunktionen, […]

  3. […] bedeutet, Kennzahlen sind temporär. Während unserer Entwicklungszeit definierte KPIs, können später im Entwicklungsprozess für nicht so wichtig erachtet werden. Andere Kennzahlen werden uns hingegen während des gesamten Produktlebens […]

Log in with your credentials

Forgot your details?