MVP entwickeln lassen: In 8 bis 12 Wochen von der Idee zum ersten Produkt

Die meisten gescheiterten Produkte sind nicht an schlechter Technik gescheitert. Sie sind daran gescheitert, dass zu viel gebaut wurde, bevor jemand wusste, ob es überhaupt jemand will.

Ein MVP — Minimum Viable Product — ist die Antwort darauf. Aber es ist nicht „eine abgespeckte Version". Es ist das kleinste Ding, das eine konkrete, riskante Annahme in eine echte Antwort verwandelt.

Was ein MVP ist — und was nicht

Ein MVP ist kein halbfertiges Produkt mit fehlenden Knöpfen. Es ist ein vollständiges, benutzbares Stück Wert für einen Anwendungsfall, gebaut, um eine Frage zu beantworten: Nutzen echte Nutzer das, lösen wir ein echtes Problem, zahlt jemand dafür?

Das Missverständnis „MVP = billig und schlecht" führt zu einem Produkt, das niemand ernst nimmt. Das richtige Bild: ein scharf geschnittener, funktionierender Kern, an dem man Realität misst — nicht ein Prototyp im Schaufenster.

Warum 8 bis 12 Wochen

Kürzer als 8 Wochen ist meist eine Demo, kein benutzbares Produkt. Länger als 12 Wochen verliert man den eigentlichen Vorteil: früh und mit echtem Nutzerfeedback zu lernen, bevor ein großes Budget gebunden ist.

Der Accelerate State of DevOps Report 2024 von DORA zeigt den Mechanismus dahinter: kleine, häufige, getestete Auslieferungen sind stabiler und schneller als große, seltene. Ein MVP ist die erste Anwendung genau dieses Prinzips auf Produktebene.

Die fünf Schnitte eines guten MVP

1. Eine Zielgruppe, nicht „alle"

Ein MVP für „kleine und mittlere Unternehmen in Europa" ist kein Schnitt. Ein MVP für „Disponenten in Lebensmittelgroßhandel mit unter 50 Mitarbeitenden" ist einer. Je enger die Zielgruppe, desto schärfer das Feedback.

2. Eine Kernfunktion

Nicht das Funktionsmenü, das man sich wünscht — die eine Sache, ohne die das Produkt sinnlos ist. Alles andere ist Version 2.

3. Ein Erfolgskriterium, vorab definiert

„Sieht gut aus" ist kein Kriterium. „30 % der Pilotnutzer nutzen die Kernfunktion in Woche 2 erneut" ist eins. Ohne vorab definierte Messgröße ist ein MVP ein teures Bauchgefühl.

4. Ein Abbruch- und ein Skalierkriterium

Was muss eintreten, damit wir nicht weiterbauen? Diese Frage trennt ein Experiment von einem unkündbaren Projekt.

5. Ein Weg vom MVP zur produktiven Version

Ein MVP, dessen Code man wegwerfen muss, war ein teurer Prototyp. Gut geschnitten ist der MVP-Kern die Basis, auf der Version 1 wächst.

Ein realistischer 8–12-Wochen-Ablauf

• Woche 1–2: Zielgruppe, Kernfunktion, Erfolgskriterium und Abbruchkriterium festnageln. Ein einseitiges Produkt-Charter, keine 60-Seiten-Spezifikation.
• Woche 3–8: Den Kern bauen — benutzbar, nicht „demoreif". Echte Daten, echte Anmeldung, echter Workflow für den einen Anwendungsfall.
• Woche 9–10: Mit echten Pilotnutzern testen, nicht mit dem eigenen Team. Beobachten, nicht erklären.
• Woche 11–12: Erfolgskriterium gegen die Realität messen. Genau eine Entscheidung: skalieren, iterieren oder sauber stoppen.

Build or Buy gilt auch im Kleinen

Bevor man einen MVP baut, lohnt die Frage, ob die Idee überhaupt Eigenentwicklung braucht — siehe Custom oder Standard?. Und ein MVP ist die günstigste Methode, eine belastbare Kostenschätzung zu bekommen, statt sie zu raten — siehe Was kostet individuelle Softwareentwicklung?.

Checkliste vor dem MVP

• Ist die Zielgruppe eng genug für scharfes Feedback?
• Gibt es eine Kernfunktion — oder eine Wunschliste?
• Ist das Erfolgskriterium vorab und messbar definiert?
• Gibt es ein Abbruchkriterium?
• Ist der Kern benutzbar, nicht nur vorzeigbar?
• Wächst Version 1 auf dem MVP-Code — oder muss er weg?
• Testen wir mit echten Nutzern, nicht intern?

Häufige Fragen

Ist ein MVP billiger als das „richtige" Produkt? Am Anfang ja. Vor allem aber ist es risikoärmer: Es verhindert, ein großes Budget in etwas zu stecken, das niemand will.

Reicht ein Klick-Prototyp? Für UI-Feedback ja. Für die Frage „nutzen Menschen das im Alltag und zahlen dafür" nein — dafür braucht es einen benutzbaren Kern mit echten Daten.

Was, wenn das Erfolgskriterium verfehlt wird? Dann hat der MVP seine Aufgabe erfüllt: Er hat eine teure Fehlinvestition verhindert. Ein sauber gestoppter MVP ist ein Erfolg, kein Scheitern.

Wie geht es nach einem erfolgreichen MVP weiter? Aus dem Experiment wird ein Produkt: gleicher Kern, breiterer Funktionsumfang, härtere Anforderungen an Betrieb, Sicherheit und Skalierung.

Fazit

Ein MVP ist kein billiges Produkt, sondern das schnellste Experiment, das eine echte Frage beantwortet. 8 bis 12 Wochen, eine Zielgruppe, eine Kernfunktion, ein Erfolgskriterium, ein Abbruchkriterium — das ersetzt eine teure Wette durch eine messbare Erkenntnis.

Weiterlesen

• Individuelle Softwareentwicklung: Custom oder Standard? — braucht die Idee überhaupt Eigenentwicklung?
• Was kostet individuelle Softwareentwicklung? — der MVP als günstigste Methode zur belastbaren Kostenschätzung.

Nächster Schritt

Sie haben eine Produktidee, aber keine teure Wette eingehen wollen? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir schneiden gemeinsam einen MVP mit messbarem Erfolgskriterium — in Wochen, nicht Quartalen.

Quellen

• DORA, Accelerate State of DevOps Report 2024 — dora.dev
• Atlassian, Agiles Projektmanagement — atlassian.com
• Thoughtworks, Technology Radar — thoughtworks.com