MVP

Was ist ein MVP?

MVP (Minimum Viable Product, kleinstes funktionsfähiges Produkt) bezeichnet die einfachste Fassung eines Produkts, die Kunden tatsächlich nutzen können. Mit ihr lässt sich eine bestimmte Annahme über Kundenbedarf, Nutzungsverhalten oder Zahlungsbereitschaft unter realen Bedingungen prüfen. Sein Zweck ist Erkenntnis: Es soll mit möglichst geringem Aufwand eine Frage beantworten, die sich sonst nur schätzen ließe. Vergleichbar ist ein Probestand auf dem Wochenmarkt, der zeigt, ob jemand ein Gericht kauft, bevor ein Restaurant eröffnet wird.

Das Konzept stammt aus der Methodik der schrittweisen, datengestützten Produktentwicklung junger Unternehmen (Lean Startup) und gehört zur frühen Unternehmensphase. Es begegnet im Businessplan, in Förderanträgen und in den Unterlagen früher Finanzierungsrunden. Später taucht es in der technischen Prüfung wieder auf, wenn Investoren oder Käufer wissen wollen, wie viel des ursprünglichen Codes noch im Produkt steckt. Beteiligt sind vor allem Gründer, Produktverantwortliche, erste Kunden und Frühphaseninvestoren.

Zweck und Grenzen eines MVP

Ein MVP löst ein eng umrissenes Problem vollständig, nicht ein großes Problem unvollständig. „Viable“ bedeutet, dass das Produkt für den Kunden einen echten Nutzen stiftet und deshalb echtes Verhalten auslöst. Ein Produkt, das niemand ernsthaft verwenden kann, liefert keine verwertbaren Daten. Der geringe Umfang ist deshalb keine Rechtfertigung für mangelhafte Ausführung bei der eigentlichen Leistung.

Abzugrenzen ist auch, was ein MVP nicht leisten soll. Es ist kein erster Teil des Endprodukts, der später nur erweitert wird, und kein Mittel, um möglichst früh Umsatz zu erzielen. Zahlungen von Testkunden sind ein Beleg für Zahlungsbereitschaft, nicht das Ziel. Oft wird das MVP nach der Prüfung weitgehend ersetzt. Wer es als Fundament des späteren Produkts plant, neigt dazu, zu viel zu bauen und die eigentliche Frage aus dem Blick zu verlieren.

Formen des MVP

Je nach Annahme eignen sich unterschiedliche Formen, die sich in Aufwand und Aussagekraft unterscheiden:

• Angebotsseite mit Vorbestellung: Eine Beschreibung des Produkts mit Preis und der Möglichkeit, verbindlich zu bestellen oder eine Anzahlung zu leisten. Sie prüft Nachfrage und Zahlungsbereitschaft, bevor entwickelt wird.
• Manuell erbrachte Leistung (Concierge-MVP): Das Team erbringt die versprochene Leistung zunächst von Hand. Der Kunde erlebt den Nutzen, das Unternehmen lernt die Abläufe genau kennen.
• Automatisierte Oberfläche mit manuellem Hintergrund: Der Kunde bedient eine Software, die Verarbeitung erfolgt aber noch durch Mitarbeitende. So lässt sich prüfen, ob sich eine Automatisierung lohnt.
• Einzelfunktion: Eine einzige Kernfunktion wird als Software umgesetzt, alles Weitere entfällt.

Auch in der Testphase gelten die rechtlichen Pflichten eines regulären Angebots. Verarbeitet das Unternehmen personenbezogene Daten im Auftrag seiner Geschäftskunden, ist nach Art. 28 der Datenschutz-Grundverordnung (DSGVO) ein Auftragsverarbeitungsvertrag nötig. Arbeiten hinter einer automatisierten Oberfläche noch Menschen, sollten Kunden wissen, dass Mitarbeitende ihre Daten bearbeiten.

Annahme, Erfolgskriterium und Entscheidung

Vor der Umsetzung steht die Annahme, die geprüft werden soll, zusammen mit einem messbaren Erfolgskriterium und einer Frist. Eine brauchbare Annahme nennt Zielgruppe, Nutzen und Preis, etwa: Eine bestimmte Gruppe von Geschäftskunden zahlt einen bestimmten Monatsbetrag für eine bestimmte Zeitersparnis. Das Kriterium legt fest, welches Ergebnis die Annahme bestätigt, beispielsweise eine Mindestzahl zahlender Kunden innerhalb von acht Wochen. Ohne ein vorab festgelegtes Kriterium wird fast jedes Ergebnis im Nachhinein als Erfolg gedeutet.

Nach Ablauf der Frist folgt eine von drei Entscheidungen: ausbauen, ändern oder verwerfen. Führt das Ergebnis zu einer grundlegenden Änderung von Zielgruppe oder Erlösmodell, spricht man von einem Pivot. Ein häufiges Problem ist nicht ein misslungenes MVP, sondern ein MVP, das über Jahre fortbetrieben wird, weil keine Entscheidung getroffen wurde.

Das MVP in Finanzierungsrunde und technischer Due Diligence

In frühen Finanzierungsrunden überzeugen weniger das MVP selbst als die Ergebnisse, die es geliefert hat: zahlende Kunden, Nutzungsdaten, Wiederkaufquoten und die daraus abgeleiteten Entscheidungen. Investoren achten dabei auch auf die Lerngeschwindigkeit, also darauf, wie viele Annahmen das Team mit welchem Mitteleinsatz in welcher Zeit geprüft hat. In einer Series A, der ersten größeren Finanzierungsrunde mit professionellen Investoren, liegt die MVP-Phase meist weit zurück. Erwartet werden dann Belege für einen Product-Market Fit, also für dauerhafte, zahlende Nachfrage in einem Kundensegment, und belastbare Kennzahlen.

Später wirkt das MVP in der technischen Due Diligence nach. Schnell entwickelter Code, der ohne Überarbeitung in das Produkt übernommen wurde, erhöht die Technical Debt, also technische Altlasten in Code und Architektur, die später Nacharbeit erfordern. Die Prüfer fragen auch, ob die Rechte am Code bei der Gesellschaft liegen. Bei angestellten Entwicklern stehen die vermögensrechtlichen Befugnisse an Computerprogrammen nach § 69b UrhG grundsätzlich dem Arbeitgeber zu. Für Code, den Gründer vor der Gründung oder freie Entwickler geschrieben haben, braucht es eine ausdrückliche vertragliche Rechteeinräumung (IP Assignment).

Praxisbeispiel: Concierge-MVP für ambulante Pflegedienste

Ein Gründerteam nimmt an, dass ambulante Pflegedienste 300 Euro im Monat für eine Software zahlen, die die tägliche Tourenplanung übernimmt und die Planungszeit der Pflegedienstleitung halbiert. Statt die Software sofort zu entwickeln, wählt das Team eine manuell erbrachte Leistung.

• Zehn Pflegedienste übermitteln ihre Einsatzdaten täglich über ein Formular. Das Team erstellt die Tourenpläne mit Standardwerkzeugen und schickt sie bis zum Vorabend zurück. Weil dabei Daten von Pflegebedürftigen verarbeitet werden, schließt das Team mit jedem Pflegedienst einen Auftragsverarbeitungsvertrag.
• Erfolgskriterium: Mindestens sechs Pflegedienste zahlen nach vier kostenlosen Wochen drei Monate lang den vollen Preis.
• Aufwand: zwei Personen über rund vier Monate (vier Wochen Testphase und drei Monate zahlender Betrieb), statt einer mehrmonatigen Entwicklung der vollständigen Software.
• Ergebnis: Sieben von zehn Pflegediensten zahlen, also 70 % bei einer Schwelle von 60 %. Das ergibt 7 × 300 = 2.100 Euro monatlichen Umsatz. Die Auswertung zeigt, dass vor allem die kurzfristige Umplanung bei Personalausfällen genutzt wird.

Die Annahme gilt damit als bestätigt, allerdings mit einer Verschiebung des Schwerpunkts. Der Umsatz von 2.100 Euro ist dabei nicht der Maßstab. Aussagekräftig ist, dass zahlende Kunden die Annahme bestätigt haben, bevor Geld in die Entwicklung geflossen ist. Das Team entwickelt als Erstes die Umplanungsfunktion und legt für die nächste Stufe ein neues Kriterium fest.

Abgrenzung: MVP, Prototyp, Proof of Concept und Pilotprojekt

• Prototyp: zeigt, wie ein Produkt aussehen oder funktionieren könnte, und wird meist intern oder in Gesprächen vorgeführt. Ein MVP wird dagegen von Kunden tatsächlich genutzt.
• Machbarkeitsnachweis (Proof of Concept): belegt, dass eine technische Lösung grundsätzlich funktioniert. Das MVP prüft, ob Kunden sie brauchen und bezahlen.
• Pilotprojekt: erprobt ein weitgehend fertiges Produkt beim Kunden unter Realbedingungen, oft mit einem größeren Geschäftskunden. Das MVP steht davor.
• Product-Market Fit: der Zustand, in dem ein Markt ein Produkt nachhaltig nachfragt. MVPs sind ein Werkzeug auf dem Weg dorthin.

Typische Fehler

• Zu viel bauen. Jede Funktion, die zur Prüfung der Annahme nichts beiträgt, verlängert die Entwicklung und erschwert die Auswertung.
• Kein Erfolgskriterium. Ohne vorab festgelegte Schwelle lässt sich das Ergebnis nicht objektiv beurteilen.
• Die falschen Testkunden. Rückmeldungen aus dem persönlichen Umfeld sind höflich, aber wenig aussagekräftig. Belastbar ist das Verhalten von Kunden, die zahlen.
• Nutzung mit Zahlungsbereitschaft verwechseln. Ein kostenlos genutztes Angebot belegt nicht, dass Kunden dafür bezahlen würden.
• Code ungeprüft übernehmen. Wird der MVP-Code ohne Überarbeitung zum Produktkern, entstehen technische Altlasten, die in späteren Prüfungen auffallen.
• Rechte am Code ungeklärt. Fehlt eine Rechteeinräumung durch freie Entwickler, liegen wesentliche Rechte am Produkt womöglich nicht bei der Gesellschaft.

Häufige Fragen

Wofür steht die Abkürzung MVP?

Für Minimum Viable Product, auf Deutsch etwa kleinstes funktionsfähiges oder minimal marktfähiges Produkt. Im Sport steht dieselbe Abkürzung für den wertvollsten Spieler (Most Valuable Player); im Startup- und Softwarekontext ist immer das Produkt gemeint.

Wie lange sollte die Entwicklung eines MVP dauern?

In der Regel wenige Wochen bis wenige Monate. Dauert sie länger, ist der Umfang meist zu groß oder die Annahme zu unscharf formuliert.

Reicht ein MVP für eine Finanzierungsrunde?

Allein selten. Investoren bewerten die Ergebnisse, die das MVP geliefert hat, also zahlende Kunden, Nutzungsdaten und die daraus folgenden Entscheidungen. Für eine Series A werden zusätzlich belastbare Wachstums- und Bindungskennzahlen erwartet.

Was ist der Unterschied zwischen MVP und Prototyp?

Ein Prototyp veranschaulicht eine Idee, ein MVP wird von Kunden unter realen Bedingungen genutzt. Nur das MVP liefert deshalb Daten über tatsächliches Verhalten und Zahlungsbereitschaft.

Muss ein MVP eine Software sein?

Nein. Eine manuell erbrachte Leistung oder eine Angebotsseite mit Vorbestellung kann eine Annahme schneller und günstiger prüfen als eine programmierte Lösung.

Roemer Capital Perspektive

Die Unternehmen, die wir begleiten, haben die MVP-Phase in der Regel hinter sich. Sie wirkt aber in zwei Punkten nach, die wir vor einer Finanzierungsrunde oder einem Verkauf prüfen lassen. Der erste ist, ob die Rechte am frühen Code vollständig bei der Gesellschaft liegen, der zweite, wie viel ungeprüfter Code aus dieser Phase noch im Produkt steckt. Beides wird in der technischen Due Diligence gefragt, und Lücken lassen sich vor dem Prozess meist leichter schließen als unter dem Zeitdruck einer laufenden Prüfung.

In der Equity Story, der Wachstumserzählung für Investoren, nutzen wir die frühen Tests als Beleg dafür, dass das Team seine Entscheidungen auf Daten stützt, nicht auf Annahmen.