MVP entwickeln: Umfang, Tools und Kennzahlen

Um ein MVP zu entwickeln, bestimmst du die eine Annahme, die stimmen muss, damit dein Startup funktioniert, wählst das günstigste Produktformat, mit dem du sie mit echten Nutzern testen kannst, streichst jede Funktion, die diesem Test nicht dient, lieferst innerhalb von Wochen aus und bewertest das Ergebnis anhand einer vorher festgelegten Erfolgskennzahl. Ein MVP ist fertig, wenn es eine klare Antwort liefern kann, nicht wenn es vollständig aussieht. Die Schritte unten zeigen, wie du den Umfang festlegst, welchen Typ du wählst und was du misst.

Was ein Produkt „minimal“ und „tragfähig“ macht

Beide Wörter zählen. Minimal heißt, du lässt alles weg, was zum Test deiner Kernannahme nicht nötig ist: Einstellungsseiten, Integrationen, Admin-Dashboards, Sonderfälle. Tragfähig (viable) heißt, das Produkt bringt einem echten Nutzer trotzdem echten Nutzen, sodass sein Verhalten aussagekräftig ist. Ein kaputtes oder verwirrendes Produkt lehrt dich nichts, weil Nutzer aus den falschen Gründen abspringen.

Eine hilfreiche Denkweise: Das MVP sollte eine Aufgabe für einen Nutzertyp von Anfang bis Ende erledigen. Ein schmales Produkt, das funktioniert, schlägt ein breites, das halb funktioniert.

Schritt 1: Die Annahme aufschreiben, die du testest

Bevor du irgendetwas planst, vervollständige diesen Satz: „Wir glauben, dass [Zielnutzer] [Verhalten] wird, weil [Grund]. Wir wissen, dass es stimmt, wenn [messbares Signal].“

Beispiel (fiktiv): „Wir glauben, dass freiberufliche Designerinnen und Designer jeden Monat Rechnungen über unser Tool verschicken, weil es ihnen Zeit beim Hinterherlaufen hinter Zahlungen spart. Wir wissen, dass es stimmt, wenn mindestens 10 unserer ersten 30 Nutzer in ihren ersten sechs Wochen zwei oder mehr Rechnungen verschicken.“

Hast du noch nicht bestätigt, dass das Problem echt ist, mach das zuerst. Unser Ratgeber Startup-Idee validieren behandelt Interviews und Tests mit Verbindlichkeit, die vor dem Bauen kommen sollten.

Schritt 2: Den richtigen MVP-Typ wählen

Verschiedene Annahmen verlangen verschiedene MVP-Formate. Die günstigste Option, die eine verlässliche Antwort liefern kann, ist meist die richtige.

MVP-Typ	So funktioniert er	Kosten und Tempo	Am besten, um zu testen
Concierge	Du lieferst das Ergebnis persönlich, ganz ohne Produkt	Sehr günstig, sehr schnell	Ob das Ergebnis überhaupt wertvoll ist
Wizard of Oz	Nutzer sehen eine Produktoberfläche, du erledigst die Arbeit dahinter manuell	Günstig, schnell	Nutzererfahrung und Nachfrage vor der Automatisierung
Landingpage / Vorverkauf	Du beschreibst das Produkt und nimmst Bestellungen oder Anzahlungen an	Sehr günstig, sehr schnell	Zahlungsbereitschaft und Botschaft
No-Code-Produkt	Mit vorhandenen No-Code- oder Low-Code-Tools gebaut	Gering bis mittel, schnell	Abläufe, Retention, frühe Nutzung
Software mit einer Funktion	Eigener Code, nur eine Kernfunktion	Mittel bis hoch, langsamer	Technische Machbarkeit plus Nutzung
Stückwerk (Piecemeal)	Vorhandene Tools zusammengesteckt (Formulare, Tabellen, E-Mail)	Sehr günstig, schnell	Den Prozess, bevor du in Software investierst

Eine praktische Regel: Lautet dein Risiko „Wollen Menschen dieses Ergebnis?“, beginne mit Concierge oder Wizard of Oz. Lautet es „Können Menschen diesen Ablauf allein nutzen?“, brauchst du irgendeine Art Produkt, oft zuerst No-Code.

Schritt 3: Den Umfang radikal begrenzen

Liste jede Funktion auf, die das Produkt deiner Meinung nach braucht. Sortiere dann jede in einen von drei Töpfen.

Topf	Frage	Beispiel (Rechnungstool)
Muss rein	Ist der Kerntest ohne sie unmöglich?	Rechnung erstellen, per E-Mail senden, als bezahlt markieren
Faken	Können wir es manuell oder mit einem vorhandenen Tool erledigen?	Zahlungserinnerungen, vom Gründer per Hand verschickt
Später	Zählt es erst, wenn Leute das Produkt schon nutzen?	Mehrere Währungen, Team-Accounts, Export in die Buchhaltung

Gebaut wird nur der erste Topf. Der zweite wird im Hintergrund manuell erledigt. Der dritte kommt auf eine Liste, die du wieder aufgreifst, wenn Nutzer wiederholt danach fragen.

Checkliste für den Umfang

• Ein Zielnutzertyp, nicht mehrere
• Eine Kernaufgabe, die das Produkt von Anfang bis Ende erledigt
• Anmeldung so einfach wie möglich (oder nur auf Einladung)
• Keine Einstellungen oder Anpassungen über das hinaus, was die Kernaufgabe braucht
• Manuelle Prozesse überall akzeptiert, wo Nutzer sie nicht sehen
• Einfache Analytics, um die Erfolgskennzahl zu messen
• Ein einfacher Weg für Feedback (E-Mail, Chat, Anruf)

Schritt 4: Zeit- und Geldbudget festlegen

Grenzen schützen dich davor, zu viel zu bauen. Leg vorab fest, wie viele Wochen und wie viel Geld das MVP verbrauchen darf, und wähl dann Umfang und Typ, die in diese Grenzen passen.

Beispiel (fiktiv): Zwei Gründer haben 30.000 € zur Verfügung und monatliche Lebens- und Toolkosten von 4.000 €. Nach dem MVP wollen sie mindestens sechs Monate Runway behalten, um zu iterieren und zu verkaufen. Das lässt 30.000 € − (6 × 4.000 €) = 6.000 € frei verfügbares Budget und ungefähr einen Monat Zeit, bevor es eng wird. Ein individuell programmiertes Produkt von einer Agentur passt nicht hinein, ein No-Code-Aufbau plus manuelle Abläufe schon.

Diese Rechnung ausdrücklich zu machen, lohnt sich. Mit dem Runway-Rechner kannst du deinen eigenen Kontostand, deine Kosten und deinen Zeitplan eingeben und sehen, wie lange du dir Bauen und Iterieren leisten kannst.

Schritt 5: Tools wählen und bauen

Wähl den Stack, der dich am schnellsten zum Test bringt, nicht den, der auf Millionen Nutzer skalieren würde. Funktioniert das MVP, kannst du es später mit dem Gelernten neu bauen.

Typische Optionen:

• No-Code-App-Builder und Datenbanken für interne Tools, Marktplätze und einfache SaaS-Abläufe.
• Formular-Builder, Tabellen und Automatisierungstools für Stückwerk-MVPs.
• Website-Baukästen mit Checkout für Landingpages und Vorverkauf.
• Eigener Code, wenn der Kernnutzen von Technologie abhängt, die kein Tool bietet – halte dann aber alles drumherum einfach.

Beauftragst du externe Entwickler, schreib die Annahme, die Muss-Liste und die Erfolgskennzahl ins Briefing. Vereinbart einen festen Umfang und eine Frist, und stell sicher, dass Code, Accounts und geistiges Eigentum deinem Unternehmen gehören.

Schritt 6: Für eine kleine, konkrete Gruppe launchen

Launch nicht für alle. Launch für 10 bis 50 Nutzer aus deinem Zielsegment, idealerweise Leute, die du bei der Validierung interviewt hast. Sie verstehen das Problem, verzeihen Ecken und Kanten, und du kannst direkt mit ihnen sprechen.

In den ersten Wochen:

1. Bring frühe Nutzer persönlich an Bord, wenn möglich per Anruf oder Bildschirmfreigabe.
2. Beobachte, wo sie hängen bleiben.
3. Frag, was sie bei jedem Schritt erwartet hatten.
4. Behebe Blockaden sofort; füge Funktionen nur hinzu, wenn mehrere Nutzer nach derselben Sache fragen.

Schritt 7: Das Richtige messen

Eitelkeitskennzahlen wie Gesamtanmeldungen oder Seitenaufrufe sagen wenig. Konzentrier dich auf Verhalten, das echten Nutzen zeigt.

Kennzahl	Was sie zeigt	Beispielfrage
Aktivierung	Haben Nutzer den Kernnutzen erreicht?	Welcher Anteil der Anmeldungen hat eine erste Rechnung erstellt und verschickt?
Retention	Kommen sie wieder?	Wie viele Nutzer waren nach vier Wochen noch aktiv?
Häufigkeit	Wie oft nutzen sie es?	Verschickte Rechnungen pro Nutzer und Monat
Zahlungsbereitschaft	Zahlen sie oder steigen sie auf?	Wie viele haben nach dem Test einen bezahlten Plan angenommen?
Qualitativer Sog	Wäre es ihnen wichtig, wenn es verschwindet?	Wären sie ohne das Produkt sehr enttäuscht?

Vergleiche die Ergebnisse mit dem Erfolgssignal, das du in Schritt 1 aufgeschrieben hast. Verkaufst du ein Abo-Produkt, schau dir auch den frühen Umsatz pro Nutzer an und wie er sich zu den Akquisekosten verhält; der Artikel zum LTV-CAC-Verhältnis erklärt, wie. Unser Überblick über die Startup-Kennzahlen zeigt, welche Zahlen du verfolgen solltest, sobald die Nutzung wächst.

Schritt 8: Entscheiden, wie es weitergeht

Prüf nach einem festgelegten Zeitraum, oft vier bis acht Wochen Nutzung, die Belege:

• Signal erreicht: Weite auf mehr Nutzer im selben Segment aus und automatisiere dann, was du bisher manuell erledigt hast.
• Teilweise erreicht: Finde heraus, warum. Interviewe Nutzer, die gegangen sind, und Nutzer, die geblieben sind. Ändere eine Variable (Segment, Onboarding, Kernfunktion, Preis) und teste erneut.
• Nicht erreicht: Geh zurück zum Problem. War das Problem echt, aber die Lösung falsch – oder war das Problem kleiner, als es schien?

Typische MVP-Fehler

• Die ganze Vision bauen. Hat dein MVP eine Roadmap mit zwanzig Funktionen, ist es kein MVP.
• Mehrere Annahmen gleichzeitig testen. Scheitert es, weißt du nicht, welche Annahme falsch war.
• Polieren vor dem Testen. Design ist wichtig, aber perfekte Optik rettet kein Produkt, das niemand braucht.
• Nur für Fremde launchen. Ohne direkten Kontakt zu frühen Nutzern sammelst du Daten, aber kein Verständnis.
• Keine Erfolgskennzahl. Ohne vorher festgelegte Schwelle wirkt jedes Ergebnis ermutigend.
• Zu früh eine Agentur beauftragen. Wer vor der Validierung der Nachfrage für einen großen individuellen Bau bezahlt, verbraucht Runway, die er später braucht.
• Ignorieren, was Nutzer tun. Was Menschen im Produkt tun, zählt mehr als das, was sie in Feedbackformulare schreiben.

Wo das MVP hingehört

Das MVP liegt zwischen Validierung und Wachstum in der Abfolge, die unser Ratgeber zur Startup-Gründung beschreibt. Es macht aus Erkenntnissen aus Interviews beobachtetes Verhalten. Funktioniert es, hast du das Material für eine glaubwürdige Preisstrategie (siehe SaaS-Preisgestaltung) und – falls du Kapital aufnehmen willst – die Traktion, die Investorengespräche deutlich produktiver macht.