Was ein MVP ist und wie man den Umfang festlegt

Ein MVP, also ein Minimum Viable Product, ist die kleinste funktionierende Version, die ausreicht, um die riskanteste Annahme einer Produktidee mit echten Nutzern zu prüfen. Das wichtige Wort in dieser Definition ist nicht „klein“, sondern „prüfen“. Deshalb wachsen die meisten MVPs: Das Team listet auf, was gebaut wird, bevor es aufgeschrieben hat, was geprüft wird.

Was ein MVP nicht ist

Ein MVP ist kein Prototyp. Ein Prototyp wird gebaut, um eine Idee zu zeigen, und danach weggeworfen. Ein MVP erledigt die echte Arbeit eines echten Nutzers.

Ein MVP ist auch nicht die erste Version des Produkts. Die erste Version erscheint, um verkauft zu werden; das MVP, um zu lernen. Beides kann derselbe Code sein, aber über den Umfang entscheiden andere Fragen.

Und ein MVP ist nicht „die Hälfte von jeder Funktion“. Zehn Funktionen halb zu bauen heißt, keine davon zu prüfen. Einen einzigen Ablauf von Anfang bis Ende vollständig zum Laufen zu bringen ist kleiner und lehrreicher.

Zuerst die Annahme aufschreiben

Beginnt das Gespräch über den Umfang mit einer Funktionsliste, wird die Liste nur länger. Denn jede Funktion ist für sich genommen vernünftig.

Ein besserer Anfang ist ein einziger Satz: „Diese Leute nutzen das für dieses Problem und tun dafür Folgendes.“ Auf den letzten Teil kommt es an. „Nutzen“ ist eine Annahme; „bezahlen“, „ihr Team einladen“, „in der Woche darauf wiederkommen“ sind jeweils andere Annahmen, und jede verlangt ein anderes Produkt.

Steht die Annahme, bleibt für jede Funktion eine einzige Frage: Lässt sich die Annahme auch ohne sie prüfen? Wenn ja, gehört die Funktion in die zweite Version.

Einen Ablauf von Anfang bis Ende bauen

In einem SaaS-Produkt trägt meist ein einziger Ablauf den Wert: Der Nutzer kommt, gibt etwas ein und erhält ein Ergebnis. Das MVP ist dieser Ablauf als Ganzes.

Als Ganzes heißt: die Registrierung, die eigentliche Arbeit und der Weg des Ergebnisses zum Nutzer. Fehlt einer der Schritte dazwischen, kommt der Nutzer nicht zum Ergebnis, und geprüft wird dann nicht das Produkt, sondern der fehlende Schritt.

Was außerhalb des Ablaufs liegt, lässt sich dagegen erstaunlich gut aufschieben: fein abgestufte Berechtigungsrollen, die Einstellungsseite, Benachrichtigungsoptionen, der Export, eine zweite Sprache. Das sind alles echte Bedürfnisse, und keines davon prüft die erste Annahme.

Nicht automatisieren, was von Hand geht

Für die ersten zehn Nutzer lassen sich viele Schritte von Hand erledigen. Sie legen das Konto an, Sie stellen die Rechnung aus, Sie erstellen den Bericht und schicken ihn los.

Das ändert nichts an dem Produkt, das der Nutzer sieht, schiebt aber Wochen an Entwicklung auf. Wichtiger noch: Es zeigt, welcher Schritt die Automatisierung wirklich wert ist. Die Automatisierung eines Schritts zu bauen, den niemand nutzt, ist die häufigste Verschwendung bei MVPs.

Eine Grenze gibt es: Der von Hand erledigte Schritt darf das Versprechen an den Nutzer nicht verzögern. Steht dort „sofort“, darf im Hintergrund kein Mensch warten lassen.

Was sich nicht aufschieben lässt

Nicht alles lässt sich aufschieben. Drei Dinge kosten in der späteren Korrektur mehr als das Produkt selbst, wenn sie nicht von Anfang an richtig angelegt sind.

Das erste ist das Datenmodell. In einem Produkt, das mehrere Kunden bedienen soll, muss die Trennung der Daten nach Kunde vom ersten Tag an entworfen sein.

Das zweite sind Identität und Berechtigungen. Wer was sehen darf, ist keine Funktion, die später dazukommt, sondern Teil jeder Abfrage.

Das dritte ist die Messung. Ein Produkt, das gebaut wird, um eine Annahme zu prüfen, verfehlt seinen Zweck, wenn es die Ereignisse nicht aufzeichnet, die zeigen, ob die Annahme bestätigt ist.

Die fünf Zeilen eines MVP-Umfangs

1. Die geprüfte Annahme, in einem Satz.
2. Der eine Ablauf, der diese Annahme prüft, Schritt für Schritt.
3. Die Schritte, die von Hand erledigt werden.
4. Was bewusst aufgeschoben wird, als Liste.
5. Die Messgröße, die zeigt, dass die Annahme bestätigt ist.

Die vierte Zeile wird am häufigsten übersprungen. Steht das Aufgeschobene nirgends, kommt jedes Stück während der Entwicklung als „kleine Ergänzung“ zurück, und das MVP wird zu einer ersten Version, über die niemand entschieden hat.