Minimum Viable Product (MVP)

Der häufigste MVP-Fehler besteht darin, es als Qualitätsdefinition statt als Umfangsentscheidung zu behandeln – eine fehlerhafte, kaum funktionierende Version auszuliefern und sie als MVP zu bezeichnen. Das „Minimum Viable“ in MVP bezieht sich auf den minimalen Funktionsumfang, nicht auf die minimale Qualität. Ein MVP sollte Produktionsqualität haben und sein enges Versprechen vollständig erfüllen – es macht lediglich ein kleineres Versprechen, als es die vollständige Vision tun würde. Ein besseres mentales Modell ist Steve Blanks Definition: Ein MVP ist der minimale Funktionsumfang, für den ein bestimmtes Kundensegment zahlen würde, um ein spezifisches Problem zu lösen. Eric Ries fügt das entscheidende Wort hinzu: „viable“ (lebensfähig) – das Produkt muss ausreichend lebensfähig sein, damit echte Kunden es zum Lernen nutzen, und nicht Code auf Prototypen-Niveau, den nur interne Teams akzeptieren würden.

Das Lernziel muss vor dem Bau des MVP definiert werden – andernfalls gibt es keine Möglichkeit festzustellen, ob das Experiment erfolgreich war. Das Lernziel beantwortet eine Kernfrage: „Werden die Kunden, von denen wir glauben, dass sie dieses Problem haben, diese Lösung tatsächlich nutzen, und wird sie gut genug funktionieren, um sie zu binden?“ Spezifische Hypothesen zum Testen: „Kunden im Segment X werden Funktion Y innerhalb der ersten Sitzung aktivieren“, „Benutzer, die Funktion Y aktivieren, werden mindestens wöchentlich zurückkehren“ und „Wir können den Kern-Workflow ohne den vollständigen Funktionsumfang, den wir uns vorgestellt haben, aufbauen.“ Product Ops dokumentiert die MVP-Hypothese, legt die quantitativen Erfolgskriterien fest (z.B. 40% Aktivierung innerhalb von Woche 1, 60% Rückkehr in Woche 2) und führt die Post-MVP-Analyse durch, um jede Hypothese zu bestätigen oder zu widerlegen.

Es gibt mehrere MVP-Archetypen entlang eines Spektrums von Entwicklungsaufwand. Concierge MVP – der Service wird manuell für eine kleine Gruppe von Kunden erbracht, um zu verstehen, ob sie ihn schätzen (kein Code erforderlich). Wizard of Oz MVP – der Kunde interagiert mit einem scheinbar automatisierten Produkt, aber Menschen erledigen die Arbeit hinter den Kulissen. Prototype MVP – ein klickbarer Prototyp mittlerer Wiedergabetreue, der auf Verständnis und Aufgabenabschlussraten getestet wird. Single-Feature Build MVP – es wird nur die Kerninteraktionsschleife ohne Randfälle, Fehlerbehandlung oder Integrationen erstellt. Tech-Spike MVP – es wird nur die technisch riskante Komponente erstellt (der Rest wird simuliert), um die technische Machbarkeit zu validieren. Der geeignete MVP-Typ hängt vom primären zu validierenden Risiko ab – wenn das Risiko darin besteht, ob Kunden die Funktion wünschen, ist ein Concierge MVP am schnellsten; wenn das Risiko technischer Natur ist, ist ein Tech Spike notwendig.