Minimum Viable Product (MVP)

Ziel

Die Technik behält den kleinsten Funktionsumfang, der Early Adopters einen Nutzen liefert, nimmt ihn so rasch wie möglich in Betrieb und liest die Antwort aus deren Verhalten. Ein MVP beantwortet eine Richtungsfrage: Interessiert das angedachte Produkt genug Kunden, um es vollständig zu bauen? Die Agile Extension gibt ihm die Absicht mit, Kosten und Risiko der Entwicklung des falschen Produkts zu vermeiden. Der Leitfaden verortet die Technik am Horizont Strategie, wo sie der Priorisierung der Ressourcenverteilung und der Beschleunigung des organisationalen Lernens dient.

Das behandelte Problem ist die Wette in einem Zug: Eine Organisation wählt ein Produkt, finanziert es vollständig, liefert es nach achtzehn Monaten aus und stellt fest, dass die Nutzung nicht jene ist, die sie angenommen hatte. Eine Marktanalyse verschiebt einen Teil dieses Risikos, ohne ihn aufzuheben, denn sie hält fest, was Personen angeben. Das MVP setzt an die Stelle der Aussage ein beobachtetes Verhalten: Adoption, Bezahlung, wiederholte Nutzung.

Die Technik erzeugt zwei Arbeitsergebnisse. Das erste ist die in Betrieb genommene Version. Das zweite ist das validierte Lernen: der erhaltene Messwert, dem Schwellenwert gegenübergestellt, dann die Entscheidung, die daraus folgt. Eine reduzierte Version, die ohne Messung ausgeliefert wird, hat einen Verzicht auf Umfang bezahlt und nichts dafür erhalten.

Einsatz

Wann einsetzen

• Neues Produkt, dessen Nachfrage angenommen bleibt: den Kern an Early Adopters ausliefern und ihre tatsächliche Nutzung lesen.
• Dienstleistung, deren Preis noch keinem Kunden vorgelegt wurde: die Zahlungsbereitschaft prüfen, bevor das vollständige Angebot gebaut wird.
• Funktion, die das Team und der Auftraggeber unterschiedlich bewerten: über eine Nutzungsmessung entscheiden statt über eine Meinung.
• Eintritt in einen bereits besetzten Markt: die Differenzierung an einem engen Segment prüfen, bevor allgemein geöffnet wird.
• Enges Budget und enger Termin: eine Kundenrückmeldung erhalten, bevor der Rest des Budgets gebunden wird.

Wann nicht einsetzen

• Einfache Lösung, ohne Unsicherheit über die Nutzung: Das vollständige Produkt ist bereits das kleinste tragfähige Produkt, also direkt die User Stories der Lösung schreiben.
• Kein Zugang zu echten Kunden: Ohne beobachtete Nutzung verliert die Technik ihren Gegenstand; die Nachfrage über eine Umfrage oder einen Fragebogen oder über eine Marktanalyse prüfen.
• Teilversion, die aus Sicherheits- oder Compliance-Gründen nicht bei Kunden eingesetzt werden kann: die Absicht über Wegwerf-Prototyping oder eine Simulation prüfen.

Beschreibung

Woher die Technik stammt

Frank Robinson prägte den Begriff 2001 in seiner Methode der synchronen Entwicklung: Zu bauen ist jenes Produkt, dessen Verhältnis von erwartetem Ertrag zu Risiko am höchsten ist, gross genug, um Adoption, Zufriedenheit und Verkauf auszulösen, klein genug, um nicht überladen und riskant zu werden. Eric Ries gab ihm 2011 seine heute gebräuchliche Formulierung und seine Verbreitung: die Version eines Produkts, die es erlaubt, das grösste Mass an validiertem Lernen über die Kunden mit dem geringsten Aufwand zu sammeln. Es ist diese zweite Definition, die die Agile Extension aufnimmt, ohne sie zu benennen.

Der Leitfaden betitelt seinen Eintrag mit "Minimal Viable Product". Die Ursprungsliteratur, das Glossar der Agile Alliance und der Sprachgebrauch der Praktiker sagen "Minimum", die hier verwendete Form; wer auf §7.6 zurückgeht, findet dort die andere Schreibweise für dieselbe Technik.

Die vier Elemente

Der Leitfaden hält fest, dass die Menge der Anforderungen subjektiv und kontextabhängig ist, mit zwei Grenzen: Es muss genug entstehen, um die Hypothese zu validieren, und es muss die kleinste Menge sein, die die Lösung rasch in Betrieb bringt. Ein Team, das damit beginnt, in sein Backlog zu schneiden, gelangt deshalb nie zu einem MVP. Wo die Erfassung fehlt, stehen die Metriken und KPI vor dem Messmechanismus.

Die drei Schritte

1. Das zu lösende Problem bestimmen und die Hypothese aufstellen
   Das Problem ergibt sich aus dem, was die Early Adopters erleben. Die Hypothese sagt, was man über ihr Verhalten für wahr hält, wenn die Lösung bestünde.
2. Den kleinsten Funktionsumfang bestimmen, der diese Hypothese prüft
   Der Leitfaden verlangt kreative, kostengünstige Testoptionen am Zielmarkt. Eine Seite, die das Angebot mit seinem Preis beschreibt, und ein Anmeldeformular messen eine Zahlungsbereitschaft, ohne dass eine Zeile Produktcode geschrieben wird.
3. Das validierte Lernen auswerten und über den weiteren Weg entscheiden
   Der Messwert wird dem Schwellenwert gegenübergestellt. Die Rückmeldung betrifft auch die Machbarkeit der Lösung und die zusätzlichen Funktionen, die eine breitere Adoption braucht.

Die Nummerierung liest sich wie eine gerade Linie; der Leitfaden beschreibt jedoch aufeinanderfolgende Zyklen, wobei die Rückmeldung gesammelt und ausgewertet wird, bevor weitere Funktionen ausgeliefert werden. Schritt 3 führt deshalb zu Schritt 1 zurück, wenn die Messung die Hypothese widerlegt, zu Schritt 2, wenn sie sie bestätigt und ein breiterer Umfang gerechtfertigt ist.

Eine Hypothese schreiben, die scheitern kann

Eine brauchbare Hypothese hält vier Dinge fest: das betroffene Publikum, ein beobachtbares Verhalten, einen bezifferten Schwellenwert und einen Zeithorizont. "Treuhandbüros werden die automatische Vorbereitung der Abrechnung schätzen" hält keines davon fest. "Mindestens 30% der Pilot-Treuhandbüros schliessen nach den sechs Monaten Testbetrieb die kostenpflichtige Option ab" hält alle vier fest und lässt sich durch eine Zahl widerlegen.

Der Schwellenwert wird vor der Inbetriebnahme mit dem Auftraggeber festgelegt, denn er beantwortet eine Finanzierungsfrage: Ab welcher Quote wird der weitere Weg finanziert? An derselben Zahl hängen drei Entscheidungen: Weiterführen, Überarbeiten der Hypothese und Abbrechen, jede mit ihrem eigenen Wertebereich. Eine Adoptionsrate von 12% lässt sich vor einem Lenkungsausschuss ebenso als Ermutigung wie als Misserfolg vertreten.

Wie den kleinsten Funktionsumfang wählen?

Der Leitfaden ist deutlich: Es gibt keine Formel, und die gewünschten Funktionen beruhen auf einer Schätzung nach bestem Wissen. Zwei Fragen genügen, um die in Betracht kommenden Funktionen zu sortieren. Lässt sich die Hypothese ohne diese Funktion noch prüfen? Wäre die Messung ohne sie verfälscht? Eine Sicherheitsanforderung, eine gesetzliche Pflicht, die Richtigkeit einer Berechnung oder eine vertretbare Antwortzeit gelangen über diese zweite Frage in den Umfang. Die Kano-Analyse ordnet dieselben Funktionen nach der Zufriedenheit, die sie erzeugen, und trennt jene, die die zwei Fragen gleichauf lassen.

Das Qualitätsniveau bestimmt sich also nach dem, was ein ehrlicher Test verlangt. Eine hingepfuschte Version vermengt zwei Abbruchgründe, den Defekt und das fehlende Interesse, und macht die Messung unbrauchbar, um einige Tage einzusparen. Was ausserhalb des Umfangs bleibt, wird aufgeschrieben, mit den Funktionen einzeln benannt: Ohne diese Liste beginnt die Diskussion über den Umfang bei jedem Refinement des Backlogs von neuem.

Der Leitfaden nennt als Grenze, dass die Technik eine weitgehende Marktanalyse verlangt, um den Funktionsumfang zu bestimmen, den die Early Adopters brauchen. Das ist der verdeckte Preis eines MVP: Die Segmentierungsarbeit, oft gestützt auf Personas und Interviews, findet vor der ersten Codezeile statt.

MVP, Prototyp und Minimum Marketable Product

Drei benachbarte Gegenstände unterscheiden sich nach ihrem Publikum und nach dem Kriterium, das sie beurteilt. Ein Prototyp zeigt eine Machbarkeit oder eine Absicht; er zirkuliert innerhalb der Organisation oder vor einem eigens versammelten Panel, und er wird nach Meinungen beurteilt. Ein MVP ist eine in Betrieb genommene Version, echten Kunden unter ihren gewohnten Bedingungen angeboten, und es wird nach gemessenem Verhalten beurteilt. Das Minimum Marketable Product ist der kleinste Umfang, der sich verkauft; das Glossar der Agile Alliance setzt den Unterschied über den Zweck, Lernen für das eine und Ertrag für das andere.

Ein MVP, dessen Hypothese widerlegt wird, hat seinen Zweck erfüllt, denn es hat einen vollständigen Bau erspart; ein Minimum Marketable Product, das sich nicht verkauft, ist gescheitert.

Was die Technik scheitern lässt

Die reduzierte Version ohne Hypothese

Der Leitfaden sagt es unter seinen Grenzen: Die Technik betrifft die Prüfung einer anfänglichen Hypothese. Ein Team unter Termindruck streicht Funktionen, liefert den Rest aus und nennt ihn ein MVP. Kein Schwellenwert wurde geschrieben und keine Messung wurde eingerichtet.

Der übersprungene Schritt 3

Die Version geht in Produktion, das Team beginnt die nächste Iteration und niemand wertet die Messung aus. Der Preis eines MVP wird im Voraus bezahlt, in aufgegebenem Umfang und in der Einrichtung der Messung; er zahlt sich in Schritt 3 aus. Das Gegenmittel ist ein Termin, der im Moment der Inbetriebnahme festgelegt wird, auf das Ende des Beobachtungszeitraums, mit dem Auftraggeber.

Das zu breite Publikum

Die Version allen Nutzern zu öffnen, übertönt das Signal der Early Adopters und setzt eine absichtlich reduzierte Version Kunden aus, die etwas anderes erwartet haben. Eine benannte Kohorte, ein Feature Flag und eine Kommunikation, die die Version als das benennt, was sie ist: Diese drei Elemente halten die Exposition unter Kontrolle.

Das MVP zum endgültigen Produkt befördert

Die Messung ist gut, die Version bleibt unverändert und die Abkürzungen werden zum Fundament des Produkts. Die Auswertung in Schritt 3 entscheidet zweierlei: was als Nächstes gebaut wird und was neu gebaut wird, weil es nur für acht Wochen gebaut war.

KI-Überlegungen

Ein Sprachmodell nützt an beiden Enden der Technik. Beim Aufsetzen erzeugt es Hypothesen aus einer Problemstellung und einer Beschreibung des Zielpublikums; für die Analyse zählen jene, die der Raum nicht formuliert hatte. Es schlägt kostengünstige Testoptionen vor, was der Leitfaden in Schritt 2 verlangt, und es listet die Ereignisse auf, die zu erfassen sind, damit die Messung am Tag der Inbetriebnahme besteht. Funktion für Funktion befragt, "welche Hypothese prüft diese Funktion?", bringt es jene zum Vorschein, die keine prüfen. Bei der Auswertung gruppiert es die freien Kommentare der Early Adopters nach Muster und weist auf jene hin, die der quantitativen Messung widersprechen.

Der Schwellenwert wird nicht von einem Modell erfragt. Zur Ausgabe gedrängt, liefert es einen plausiblen Prozentsatz, der aus keiner Entscheidung des Unternehmens stammt, obwohl diese Zahl ein Budget bindet. Dieselbe Klippe gilt für das Urteil: Ein Modell, das gefragt wird, ob das MVP gelungen sei, baut aus denselben Daten eine günstige Erzählung, was der im Voraus geschriebene Schwellenwert wirkungslos macht. Die während der Beobachtung erhobenen Nutzungsdaten weisen Kunden und mitunter Beträge aus, also Personendaten im Sinne des Bundesgesetzes über den Datenschutz (DSG); sie werden anonymisiert, bevor sie an einen bei einem Dritten gehosteten KI-Dienst gehen, und der Hosting-Standort wird geprüft, wenn die Bearbeitung die Schweiz verlässt.

Die Codegenerierung verändert die Ökonomie der Technik. Eine reduzierte Version zu bauen kostet weniger als früher, was das Kostenargument des Leitfadens schwächt und den Wert auf die Seite der Messung verlegt: Hypothese, Schwellenwert und Auswertung bleiben Aufgabe der Business-Analyse.

Beispiele

Ein Westschweizer Anbieter von Buchhaltungssoftware will wissen, ob Treuhandbüros für die automatische Vorbereitung der MWST-Abrechnung ihrer Mandate bezahlen. Der Steckbrief unten ist das Arbeitsergebnis, mit dem die Technik beginnt.

Visualisierungen

Die erste Zeichnung ist die Schleife: Problem und Hypothese, kleinster Funktionsumfang, Inbetriebnahme bei Early Adopters, Messung des Lernens, dann Entscheidung. Sichtbar werden muss die Linie, die von der Entscheidung zur Hypothese zurückführt statt zur Funktionsliste.

Eine zweite Zeichnung dient der Sortierung des Umfangs. Die in Betracht kommenden Funktionen verteilen sich dort auf drei Zonen: jene, die die Hypothese prüfen, jene, die die Messung ehrlich halten (Sicherheit, Compliance, Richtigkeit einer Berechnung), und jene, die ausserhalb des Umfangs warten. Sichtbar werden muss das zweite Zulassungskriterium, über das eine Anforderung ohne Bezug zur Hypothese dennoch in die ausgelieferte Version gelangt.

Aufwand

Werkzeuge

Das Feature Flag (LaunchDarkly, Unleash oder der in der Entwicklungsplattform eingebaute Mechanismus) ist das der Technik eigene Werkzeug: Es öffnet die Version einer benannten Kohorte, schliesst sie in einem Zug wieder, wenn ein Defekt auftritt, und trennt die Produktivsetzung von der Exposition. Ohne es wird die Exposition über aufeinanderfolgende Auslieferungen geregelt, was teuer ist und die Kontrolle über das beobachtete Publikum nimmt.

Die Werkzeuge zur Nutzungsmessung (Matomo, Piwik PRO, Amplitude und ihre Entsprechungen) erzeugen die Quote, die dem Schwellenwert gegenübergestellt wird, sofern die Ereignisse vor der Inbetriebnahme erfasst werden.

Die Werkzeuge für A/B-Tests (Optimizely, VWO, GrowthBook) bedienen die Variante, in der zwei Angebote parallel ausgespielt werden, behandelt unter A/B-Testing. Sie bringen die zufällige Aufteilung der Population und die Verfolgung der Signifikanz mit, die Werkzeuge zur Nutzungsmessung allein nicht bieten.

Die Werkzeuge zur Erstellung von Seiten und Formularen (Webflow, Typeform, Jotform) tragen die kostengünstigen Testoptionen aus Schritt 2: eine Angebotsseite, einen ausgewiesenen Preis und ein Formular.

Die Werkzeuge zum Backlog-Management (Jira, Azure DevOps, GitLab und ihre Entsprechungen) nehmen den Steckbrief und den Ausschluss aus dem Umfang auf, sofern ein Feld die Hypothese trägt, auf die jedes ausgewählte Element zielt. Diese Zuordnung erlaubt es in Schritt 3 zu sagen, über welche Funktionen die Messung entschieden hat. Für den Steckbrief selbst genügt eine Tabellenkalkulation, die in der Entscheidungssitzung durchgegangen wird.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.6 Minimal Viable Product: der Zweck der Technik, die Definition des kleinsten Funktionsumfangs, die vier Anwendungsfelder, die drei Schritte, die vier Elemente, die genannten Stärken und die Grenzen, darunter das Fehlen einer Formel, die vorgängige Marktanalyse und der Fall der einfachen Lösung.
• Eric Ries, The Lean Startup, Crown Business, 2011, Kapitel 6: die gebräuchliche Definition, die Version eines Produkts, die es erlaubt, das grösste Mass an validiertem Lernen mit dem geringsten Aufwand zu sammeln, und die Schleife bauen, messen, lernen.
• SKMurphy, Frank Robinson's Minimum Viable Product Definition: dokumentierte Wiedergabe der Definition von Frank Robinson, dem der Begriff seit 2001 zugeschrieben wird, und ihrer Dimensionierung über das Verhältnis von erwartetem Ertrag zu Risiko.
• Agile Alliance, Glossar, Minimum Viable Product (MVP): die von der Profession verwendete Form des Begriffs und die Unterscheidung zwischen dem MVP, das auf Lernen zielt, und dem Minimum Marketable Product, das auf Ertrag zielt.