Was gehört in ein MVP? So legen Sie den Umfang der ersten Version fest

Ein MVP, ein Minimum Viable Product, ist die erste funktionierende Version eines neuen Produkts. Es wird gebaut, um herauszufinden, ob eine Idee trägt, bevor alles gebaut ist. Was hineinkommt, entscheidet, was Sie daraus lernen und was es kostet.

Was ist ein MVP, und was ist es nicht?

Ein MVP ist funktionierende Software, die eine Idee mit echten Nutzern prüft. Eric Ries definierte es 2009 als die Version eines neuen Produkts, mit der ein Team mit dem geringsten Aufwand am meisten gesichertes Wissen über seine Kunden sammeln kann. Das Ziel ist Erkenntnis, nicht ein kleines Produkt. Ries selbst betont, dass es beim MVP trotz des Namens nicht darum geht, minimale Produkte zu bauen.

Es ist auch kein Prototyp. Ein Prototyp ist klickbar und hat keine Datenbank dahinter: Er zeigt, wie Ihre Software aussehen wird und wie man sie bedient. Ein MVP ist funktionierende Software mit Datenbank, die die Personen, die Sie einladen, hinter einem Login nutzen und die an einer einzigen Zahl gemessen wird. Prototyp, Proof of Concept oder MVP? stellt die drei einander gegenüber.

Was muss die erste Version enthalten?

Genug, um Ihre riskanteste Annahme mit echten Nutzern zu prüfen, und nichts, was der Test nicht braucht. In der Praxis ist das die eine Aufgabe, von der Ihre Idee abhängt, durchgängig von Anfang bis Ende, und das Wenige, das ein echter Test rundherum braucht: eine Datenbank, ein Login und eine Möglichkeit zu messen.

• Die Kernaufgabe, von Anfang bis Ende. Wenn Ihre Idee ist, dass Leute ihre Woche in Ihrem Tool planen, müssen sie darin eine ganze Woche planen können.
• Eine Datenbank. Echte Daten, sicher gespeichert, damit die Leute am nächsten Tag weiterarbeiten können.
• Ein Login. Die Personen, die Sie einladen, melden sich an. Die erste Version ist nicht öffentlich.
• Eine Möglichkeit zu messen. Die eine Zahl, auf die es bei Ihrem Test ankommt, erfasst, während die Leute die Software nutzen.
• Gründliche Tests. Von Anfang bis Ende getestet, bevor Ihre Nutzer Zugang erhalten.

Minimaler Umfang, nie minimale Qualität: An der Datenbank und an gründlichen Tests wird nie gespart. Eine erste Version, die abstürzt, verrät Ihnen etwas über ihre Fehler, nicht über Ihre Idee.

Was kann warten?

Alles, was Ihr Test nicht braucht. Funktionen, die ein Produkt bequem oder vollständig machen, können folgen, sobald Sie wissen, dass die Idee trägt. Manches lässt sich anfangs sogar von Hand erledigen, hinter den Kulissen.

• Öffentliche Seiten und Suchmaschinen. Die erste Version nutzen die Personen, die Sie einladen, hinter einem Login.
• Zahlungen, ausser Ihre Annahme dreht sich genau darum, ob die Leute zahlen.
• Anbindungen an andere Software, ausser der Test hängt davon ab.
• Weitere Sprachen, Rollen und Einstellungen. Beginnen Sie mit den Nutzern, auf die es beim Test ankommt.
• Auswertungen und Exporte über die eine Zahl hinaus, die Sie messen.
• Seltene Fälle. Erledigen Sie sie von Hand, bis Sie wissen, dass sie wichtig sind.

Wie entscheiden Sie, was hineinkommt?

Gehen Sie von der Annahme aus, nicht von einer Liste an Funktionen. Halten Sie die riskanteste Annahme schriftlich fest, die eine Messgrösse, die sie prüft, und den Schwellenwert, den sie erreichen muss. Dann stellen Sie bei jeder Funktion eine einzige Frage: Braucht der Test sie? Wenn nicht, wartet sie.

1. Benennen Sie die riskanteste Annahme. Die Überzeugung, die alles andere sinnlos macht, wenn sie falsch ist.
2. Legen Sie eine Messgrösse und ihren Schwellenwert fest, vor jedem Design und jeder Zeile Code.
3. Behalten Sie die Funktionen, die der Test braucht, und setzen Sie den Rest auf eine Liste für später.
4. Sehen Sie zuerst das Design. Mit einem Prototyp probieren Sie aus, wie die Software aussehen und sich anfühlen wird, bevor sie gebaut ist, und können sie noch ändern.

The Lean Startup beschreibt den Kreislauf dahinter: Ideen in Produkte umsetzen, messen, wie die Kunden reagieren, und daraus lernen, ob man umsteuert oder weitermacht. Bei uns wählen wir nach dem Design die Funktionen aus, die die erste Version braucht, und der Rest kann warten.

Ein Beispiel: eine erste Version mit drei Funktionen

Nehmen wir ein erfundenes Beispiel. Ein Gründer möchte kleinen Reinigungsfirmen ein Planungstool verkaufen. Die riskanteste Annahme: Die Inhaber planen ihre Woche im Tool statt auf Papier. Die Messgrösse: wie viele der eingeladenen Firmen ihre Woche darin planen, Woche für Woche, gemessen an einem Schwellenwert, der vor der Umsetzung festgelegt wird.

Die erste Version erhält drei Funktionen:

1. Der Inhaber plant die Woche: Wer reinigt wann an welcher Adresse.
2. Jede Reinigungskraft sieht ihren Tag auf dem Handy und hakt jeden Einsatz ab.
3. Der Inhaber sieht, was erledigt wurde und was nicht.

Rechnungsstellung, Lohnabrechnung, eine Seite für die Endkunden und weitere Sprachen warten alle. Jedes davon kann später wichtig werden. Keines davon zeigt, ob die Inhaber ihre Woche im Tool planen.

ScoutCopilot, eines der vielen Produkte, die wir gebaut haben, begann als erste Version mit genau drei Funktionen.

Was passiert nach dem Livegang?

Es geht für die Personen live, die Sie einladen. Sie melden sich an und nutzen es, und wie sie es nutzen, zeigt, ob der Schwellenwert erreicht wird. Das Ergebnis ist eindeutig: umsteuern, weitermachen oder aufhören.

• Umsteuern: die Richtung ändern und die nächste Annahme prüfen.
• Weitermachen: Die Idee trägt, darum bauen Sie darauf auf.
• Aufhören: Die Idee trägt nicht, und Sie wissen es, bevor alles gebaut ist.

Lautet die Antwort Ja, wird das komplette Produkt als Web-Software nach Mass gebaut, bereit für den Alltag. Zuerst ein MVP oder gleich das komplette Produkt? hilft Ihnen bei der Wahl, wo Sie beginnen. Unser Beitrag darüber, was die Kosten eines SaaS-MVP bestimmt, erklärt, wovon der Preis abhängt, und MVP-Entwicklung zeigt, wie wir eine erste Version bauen.