Was ist ein MVP? Der ehrliche Leitfaden für Gründer

«MVP» ist zum Sammelbegriff geworden: von der Landing Page bis zum halbfertigen SaaS. Gemeint ist fast immer: das kleinste Mittel, um eine konkrete Annahme zu prüfen – und nicht «möglichst wenig liefern, um Geld zu sparen». Die meisten Teams verwechseln genau das mit «schnell und billig bauen» und verlieren Monate. Weiterführend: Startup-Idee validieren und MVP-Kosten in der Schweiz.

Was Eric Ries eigentlich gemeint hat

Als Ries den MVP-Begriff in The Lean Startup geprägt hat, war seine Definition sehr präzise: Ein MVP ist «die Version eines neuen Produkts, mit der ein Team bei minimalem Aufwand das Maximum an validierten Erkenntnissen über Kunden gewinnt.»

Ziel ist Lernen, nicht Sparen. Das «Minimum» bezieht sich auf den Aufwand, nicht auf die Anzahl der Features. «Viable» heisst: das Ergebnis muss echt genug sein, um belastbare Erkenntnisse zu liefern. Es geht um Wissen, nicht um ein fertiges Produkt.

Im Laufe der Zeit ist dieser Kern verloren gegangen. «MVP» wurde zur Chiffre für «halbfertiges Produkt, zu dem wir selbst keine Lust haben». Gründer haben unter dem Label «lean» holprige Beta-Versionen verkauft. Investoren haben plötzlich polierte Demos erwartet, bevor sie irgendetwas als viable gelten lassen. Der Begriff hat seine Schärfe verloren.

Drei Fehler, die fast jeder Erstgründer macht

Fehler 1: Zu viel bauen

Das ist die häufigste Falle – gerade im DACH-Raum, wo «ordentlich machen» tief in der Kultur verankert ist. Ein Team baut sechs Monate lang ein vollständiges Produkt: Authentifizierung, Admin-Dashboard, Abrechnungslogik, Onboarding-Strecken. Dann kommt der Launch – und die zentrale, nie geprüfte Annahme («will das überhaupt jemand?») stellt sich als falsch heraus.

Das war kein MVP, das war ein Produkt. Der Unterschied ist zentral: Ein Produkt kostet Monate und viel Kapital. Ein MVP sollte Wochen dauern und eine konkrete Frage beantworten. Wer das verwechselt, verbrennt echte Ressourcen, um etwas herauszufinden, das sich in wenigen Tagen hätte testen lassen.

Fehler 2: Zu wenig bauen

Das andere Extrem: So stark reduzieren, dass sich daraus nichts mehr lernen lässt. Ein fünfseitiges Deck ist kein MVP. Ein Klick-Prototyp ist kein MVP. Eine Landing Page mit Warteliste ist kein MVP – ausser die zu prüfende Hypothese lautet tatsächlich «Tragen sich Leute für Updates ein?».

Wenn ein Produkt KMU bei der Automatisierung ihrer Lieferantenprozesse helfen soll und man dafür manuell Excel-Tabellen pflegt, die als «Concierge-MVP» deklariert werden, zeigt das vielleicht, dass Menschen mit Excel-Tabellen leben können. Es zeigt nicht, ob sie für das echte Produkt zahlen würden.

Der Test muss zur Hypothese passen. Sonst erzeugt er nur Rauschen statt verwertbarer Information.

Fehler 3: Die falschen Dinge messen

Der dritte Fehler ist feiner. Ein Team baut etwas Sinnvolles, launcht es – und misst dann an der falschen Stelle. Es zählt Anmeldungen statt Aktivierungen, verfolgt Seitenaufrufe statt Wiederkehrraten und feiert Demo-Anfragen, anstatt zu prüfen, ob Nutzer den eigentlichen Workflow am Ende auch abschliessen.

Aktivität ist keine Validierung. Tausend Signups zeigen, dass die Landing-Page-Copy zieht. Über die Frage, ob das Produkt ein echtes Problem löst, sagen sie kaum etwas. Validieren heisst, genau das Verhalten zu messen, das die Hypothese bestätigen würde – und dieses Verhalten zu erzeugen ist meist deutlich anspruchsvoller, als eine E-Mail-Adresse einzusammeln.

Wie ein echter MVP aussieht

Ein echter MVP beginnt nicht mit einer Feature-Liste, sondern mit einer Frage. Welche Annahme würde, wenn sie nicht stimmt, das Geschäftsmodell sofort kippen? Das ist die Hypothese. Der MVP ist der schnellste, günstigste Test genau dieser Hypothese – mit echten Nutzern unter echten Bedingungen.

Mal ist das ein funktionierendes Stück Software. Mal ist es ein manueller Prozess, bei dem ein Mensch die Arbeit erledigt, die später Software übernehmen soll. Die Form richtet sich ausschliesslich danach, was gelernt werden soll.

Allen echten MVPs gemeinsam ist: Sie werden vom Lernziel her rückwärts gedacht. Erst die Frage, dann die minimale Umsetzung, die diese Frage ehrlich beantworten kann.

Warum «Minimum» nichts mit «billig» zu tun hat

Hartnäckig hält sich die Vorstellung, ein MVP müsse günstig sein. Manchmal ist er das – ein Concierge-MVP kann fast nichts kosten. Aber günstig ist ein Nebeneffekt von Fokus, kein Selbstzweck.

Wenn die Hypothese ein funktionierendes Produkt braucht, weil alles darunter nur höfliche Antworten statt echtem Verhalten liefert, ist der MVP eben nicht billig. Das ist in Ordnung. Was er nie sein darf: verschwenderisch. Jedes Feature, das nicht aufs Lernziel einzahlt, ist Verschwendung – egal zu welchem Preis.

Das «Minimum» im MVP heisst: das Minimum, das nötig ist, um eine belastbare Antwort zu bekommen. Wer darunter bleibt, macht die Daten wertlos. Wer darüber hinaus baut, verbrennt Runway – in der Schweiz bekanntlich ein besonders teures Vergnügen.

Zuerst die Hypothese, dann der MVP

Vor dem ersten Design-Tool, vor der ersten Zeile Code, vor dem ersten Team-Workshop: die wichtigste Annahme aufschreiben, von der das Unternehmen abhängt.

Nicht «Selbstständige brauchen bessere Tools» – das bleibt zu vage. Sondern etwas Konkretes wie: «Freiberufliche Übersetzerinnen in der Schweiz verbringen mehr als drei Stunden pro Woche mit Angebotserstellung und wären bereit, dafür CHF 30 pro Monat zu zahlen, um das zu automatisieren.» Das ist eine Hypothese. Sie trifft eine konkrete Aussage über ein konkretes Verhalten in einem konkreten Markt – und lässt sich testen.

Sobald diese Hypothese steht, wird die MVP-Frage deutlich einfacher: Was ist der schnellste, ehrlichste Weg, um herauszufinden, ob das stimmt?

Genau dafür war das MVP-Konzept ursprünglich gedacht. Wer dort ansetzt, macht sich alles Weitere leichter.

Hypothese klar, MVP danach

Du hast eine Hypothese und willst sie mit einem MVP in Produktionsqualität testen, nicht mit einem Deck? Discovery Call buchen: Testdesign, Scope, optional 12-Wochen-Validierung mit echten Nutzern.