MVP richtig abstecken: Was Sie zuerst bauen sollten

Ein MVP abzustecken heisst: eine Nutzergruppe, ein Problem und ein messbares Ergebnis wählen und dann nur das bauen, was nötig ist, um zu lernen, ob dieses Ergebnis eintritt. Alles andere kommt auf eine Liste für später. Gut gemacht, dauert das Tage, nicht Wochen, und es entscheidet darüber, ob Ihre erste Veröffentlichung Ihnen etwas beibringt oder nur Geld verbrennt.

Dieser Leitfaden zeigt das Vorgehen, das wir mit Gründer:innen in Zürich und in der ganzen Schweiz anwenden: von der Annahme, die Sie prüfen müssen, über den Funktionsschnitt und das Budgetgespräch bis zu den Kennzahlen, die Ihnen sagen, was als Nächstes kommt.

Kurz zusammengefasst

• Stecken Sie den Umfang um eine Nutzergruppe, eine zu erledigende Aufgabe und ein messbares Ergebnis ab. Was dem nicht dient, wartet.
• Schreiben Sie die Annahme auf, die das Geschäft kippen würde, wenn sie falsch wäre, und richten Sie das MVP darauf aus, zuerst genau diese Annahme zu prüfen.
• Ein Prototyp prüft, ob die Leute das Produkt verstehen. Ein MVP prüft, ob sie genug Nutzen daraus ziehen, um wiederzukommen oder zu bezahlen.
• Schätzen Sie Zeit und Budget anhand der Funktionsliste, der Schnittstellen und der offenen Fragen, nicht anhand einer Pauschalzahl. Halten Sie den Umfang fest und lassen Sie das Gelernte über die nächste Phase entscheiden.
• Legen Sie die Erfolgsschwellen vor dem Start fest, damit sich das Ergebnis nachher nicht wegdiskutieren lässt.

Was ein MVP ist und wozu die Abgrenzung dient

Ein MVP ist die einfachste Version eines Produkts, die Ihre Idee echten Nutzer:innen vorlegt und Ihre zentralen Annahmen prüft. Es geht darum, Risiko zu senken: Sie wollen früh merken, wenn Sie etwas bauen, das niemand will. Der guide to business model testing von Innosuisse und Founders Hive beschreibt das als wissenschaftliches Prüfen: Ersetzen Sie Annahmen so günstig und so schnell wie möglich durch Fakten. Ziel ist nicht, den Gründer:innen recht zu geben.

Diese Sichtweise verändert die Abgrenzung. Wenn das MVP ein Experiment ist, umfasst es genau das, was das Experiment braucht. Wenn es eine „Version eins“ der ganzen Vision ist, wächst der Umfang mit jeder Sitzung. Die meisten Überschreitungen, die wir sehen, stammen aus der zweiten Haltung.

Der Wagniskapitalgeber CRV formuliert denselben Gedanken anders: Die unit of progress in an MVP ist bestätigtes Lernen, nicht die Zahl der Funktionen oder Codezeilen. Hängen Sie diesen Satz an die Wand, solange Sie den Umfang festlegen.

MVP oder Prototyp: Was brauchen Sie?

Gründer:innen fragen oft, ob sie einen Prototyp oder ein MVP brauchen. Die beiden beantworten unterschiedliche Fragen.

	Prototyp	MVP
Frage, die er beantwortet	Verstehen die Leute, wie man das benutzt?	Ziehen echte Nutzer:innen genug Nutzen, um dranzubleiben oder zu bezahlen?
Typische Form	Skizzen auf Papier, klickbare Figma-Bildschirme, manchmal eine programmierte Demo	Ein funktionierendes Produkt mit wenigen Funktionen
Was Sie messen	Aufgabenerfüllung, Verwirrung, Verständnis	Aktivierung, Verbleib, Zahlungsbereitschaft
Backend	Meist keines oder simuliert	Echt, auch wenn klein
Kosten und Tempo	Tage bis wenige Wochen	Wochen bis wenige Monate

Die Faustregel: Passen Sie den Reifegrad der Frage an. Wenn Sie wissen müssen, ob Nutzer:innen den Buchungsknopf finden, reicht ein klickbares Modell. Wenn Sie wissen müssen, ob Praxen ihre Papieragenda wirklich aufgeben, brauchen Sie etwas, das echte Termine bucht.

Eine Warnung aus dem Produktmanagement-Kurs der BYU: Ein MVP muss das Erlebnis gut genug liefern, damit die Rückmeldungen ein ehrliches Signal sind. Broken prototypes draw polite responses, aus denen Sie nichts lernen. Klein heisst nicht schlampig. Ein schmales Produkt, das funktioniert, schlägt ein breites, das halb funktioniert.

Der günstigste Weg ist oft eine Abfolge: Prototyp zum Prüfen des Verständnisses, ein manueller Test zum Prüfen der Nachfrage, dann ein programmiertes MVP, sobald Sie wissen, was den Code verdient.

Schritt 1: Nutzergruppe, Problem und Annahme benennen

Bevor Sie eine einzige Funktion auflisten, beantworten Sie drei Fragen schriftlich.

1. Wer ist die Nutzerin oder der Nutzer? Nicht „kleine Unternehmen“. Ein bestimmtes Segment: zum Beispiel unabhängige Physiotherapiepraxen in der Deutschschweiz mit ein bis drei Therapeut:innen.
2. Welche Aufgabe müssen sie erledigen? Beschreiben Sie etwas, das tatsächlich passiert, nicht etwas, das sie sich vielleicht wünschen: was sie letztes Mal getan haben, wie oft, welchen Behelf sie nutzen und was sie das an Zeit, Geld oder Nerven kostet.
3. Was ist die riskanteste Annahme? Jene, deren Scheitern das Geschäft hinfällig macht. Oft ist sie nicht technisch. Sie lautet „die Leute zahlen dafür“ oder „sie ändern ihren heutigen Ablauf“.

Der Leitfaden von Innosuisse empfiehlt, jedes Element Ihres Geschäftsmodells als Hypothese zu behandeln und die Annahmen danach zu ordnen, wie kritisch sie sind und wie unsicher Sie dabei sind. Er verlangt zudem widerlegbare Erfolgskennzahlen, die vor den Experimenten festgelegt werden. Vorgeschlagen werden 10 bis 20 strukturierte Problemgespräche, um Kundensegment und Problem zu bestätigen.

Fragen Sie in diesen Gesprächen nach vergangenem Verhalten, nicht nach künftigen Absichten. „Würden Sie eine App nutzen, die X macht?“ bringt Ihnen ein höfliches Ja. „Erzählen Sie mir vom letzten Mal, als das schiefging“ bringt Ihnen Fakten. Das Team von Lean Startup hat beschrieben, wie ein Gründungsteam erst nach talking to users merkte, dass seine ursprüngliche Problemhypothese falsch war. Das bewahrte es davor, das Falsche zu bauen.

First Round Review geht einen Schritt weiter und empfiehlt minimum viable tests für einzelne riskante Annahmen, bevor Sie überhaupt ein MVP bauen. Eine Landingpage kann das Nutzenversprechen prüfen. Wenn Ihre Annahme die Zahlungsbereitschaft betrifft, prüft eine manuelle Version der Dienstleistung das zu einem Bruchteil der Kosten.

Concierge und Wizard of Oz: MVPs fast ohne Code

Zwei Muster lohnen sich zu kennen. Bei einem Wizard-of-Oz-Test sehen die Nutzer:innen eine echte Oberfläche, während Menschen die Arbeit dahinter von Hand erledigen. Bei einem Concierge-Test erbringt ein Mensch die Leistung direkt für die Nutzer:innen. Mind the Product erklärt the difference between the two gut. Beide lassen Sie etwas über die Nachfrage lernen, bevor Sie in Automatisierung investieren, und beide sind legitime MVPs.

Wer zum Beispiel ein KI-gestütztes Vermittlungswerkzeug will, kann die Vermittlung für die ersten 20 Kundinnen und Kunden oft von Hand erledigen. Zahlt niemand, haben Sie sich die Entwicklung gespart. Zahlen sie, wissen Sie jetzt genau, welche Teile Sie zuerst automatisieren.

Schritt 2: Das Ergebnis in eine Funktionsliste übersetzen

Jetzt dürfen Sie Funktionen aufschreiben, und der Test für jede einzelne ist einfach: Braucht die Kernnutzerin das in der ersten Veröffentlichung, um das Kernergebnis zu erreichen?

Nehmen Sie ein Buchungswerkzeug für Praxen als Beispiel. Wenn das Ergebnis weniger verpasste Termine sind, dann sind eine Buchungsseite, Verfügbarkeiten, ein Kalender, die Bestätigung, Erinnerungen und die Stornierung unverzichtbar. Online-Zahlungen, Patientendossier, Auswertungen und eine native Mobile-App sind ergänzende Funktionen. Sie sind nützlich und können warten, bis sich der Kernablauf bewährt hat.

Ein einfacher Schnitt: Muss, Sollte, Später

Listen Sie jede Funktion auf, die im Team genannt wurde, und sortieren Sie sie.

• Muss: Ohne sie erreichen die Nutzer:innen das Ergebnis nicht. Nehmen Sie sie weg, scheitert das Experiment.
• Sollte: Sie verbessert das Erlebnis, aber das Ergebnis ist auch ohne sie erreichbar. Meist gibt es einen Behelf von Hand.
• Später: Eine gute Idee, die aber die Hauptannahme nicht prüft.

Seien Sie streng bei der Spalte „Muss“. Ein gutes Zeichen ist, wenn sie auf einen Bildschirm passt und Sie das ganze Produkt in zwei Sätzen beschreiben können. Gelingt das nicht, stecken Sie ein Produkt ab, kein MVP.

Fragen Sie bei jedem „Sollte“, wie der Behelf von Hand aussieht. Für die ersten 30 Nutzer:innen Erinnerungen per E-Mail aus einer Tabelle zu verschicken, kostet nichts. Eine Benachrichtigungsmaschine zu bauen, kostet Wochen.

Die Messlatte an Ihren Markt anpassen

Wie viel Feinschliff nötig ist, hängt vom Wettbewerb ab. In einem besetzten Markt vergleichen Nutzer:innen Sie mit etablierten Angeboten, entsprechend höher liegt das Minimum. In einem neuen Markt besteht die erste Aufgabe darin zu zeigen, dass das Problem existiert, und das schafft auch ein roheres Produkt. Seien Sie ehrlich, in welcher Lage Sie sind. Das verändert die Spalte „Muss“ stärker als jedes Modell.

Die Plattform zuletzt wählen

Gründer:innen beginnen oft mit „wir brauchen eine App für iOS und Android“. Fragen Sie, ob eine responsive Web-App dieselbe Erkenntnis liefert. Meist tut sie das, zu tieferen Kosten und ohne Prüfung im App Store. Ist eine native App wirklich nötig, planen Sie den Store-Eintrag früh. Am Starttag indexed correctly on launch day zu sein, zählt, denn eine neue App mit schwachen Metadaten ist für genau die Leute unsichtbar, mit denen Sie testen wollen.

Schritt 3: Zeit und Budget in der Schweiz schätzen

Wir nennen Ihnen keine einzelne Pauschalzahl, denn sie würde in die Irre führen. Die Preise in der Schweiz unterscheiden sich stark danach, wer baut, was gebaut wird und wie viel unbekannt ist. Was wir tun können: Ihnen zeigen, was die Schätzung treibt, damit Sie jede Offerte einordnen können.

Die vier Treiber einer MVP-Schätzung

1. Anzahl und Komplexität der Kernabläufe. Jeder Nutzungspfad (registrieren, buchen, bezahlen, verwalten) hat Bildschirme, Logik, Sonderfälle und Tests. Drei klar beschriebene Abläufe sind ein ganz anderes Projekt als zehn.
2. Schnittstellen. Zahlungsanbieter, CRM, ERP, Shopsysteme, Identität und E-Mail bringen je zusätzliche Arbeit und oft Unbekanntes mit. Die Anbindung an ein Altsystem ist die klassische Überraschungsquelle.
3. Regulierung und Daten. Personendaten nach dem Schweizer Datenschutzgesetz oder Branchenregeln im Gesundheits- und Finanzwesen bringen Entscheide zu Aufbau und Hosting mit sich. Sprechen Sie das im ersten Gespräch an, nicht im fünften.
4. Offene Fragen. Ist das Problem noch nicht bestätigt oder der Entwurf noch nicht fix, muss das Budget Änderungen auffangen. Fester Umfang zum Festpreis funktioniert nur, wenn der Umfang wirklich fest ist.

So kommen Sie zu einer verlässlichen Offerte

• Bringen Sie die einseitige Abgrenzung mit: Nutzergruppe, Ergebnis, Annahme, Liste der Muss-Funktionen und was ausdrücklich nicht dazugehört.
• Fragen Sie, wer die Arbeit tatsächlich macht und ob dieselben Personen vom Start bis zur Übergabe dabei sind. Personalwechsel mitten im Projekt gehören zu den häufigsten Gründen für neu geschriebene Anforderungen.
• Fragen Sie, was Ihnen am Ende gehört: Code, Repository, Hosting-Konten, Dokumentation. Sie wollen weitermachen können, auch ohne das Studio.
• Verlangen Sie einen Plan in Phasen: eine erste Veröffentlichung, zugeschnitten auf das Experiment, danach ein Entscheidungspunkt, statt einer grossen Schätzung für die ganze Vision.

Als grobe Planungsregel gilt: Ein sauber abgestecktes MVP bemisst sich in Wochen bis wenigen Monaten, nicht in einem Jahr. Liegt eine Offerte deutlich darüber, ist der Umfang vermutlich über ein MVP hinausgewachsen.

Schritt 4: Erfolgskriterien vor dem Bauen festlegen

Das nützlichste Ergebnis der Abgrenzung ist nicht die Funktionsliste. Es ist der Satz, der festhält, welches Resultat Sie zum Weitermachen bewegt und welches zum Aufhören.

Ihre Schwellen sollten konkret sein. Ein Beispiel von Unlock Labs ist eine target conversion rate von 25 % für Anmeldungen auf der Warteliste. Ihre Zahl hängt von Kanal und Preis ab. Gleichen Sie sie deshalb mit realistischen conversion rate benchmarks für ähnliche Angebote ab, statt eine zu wählen, die sich gut anfühlt.

Ein brauchbares Set an Signalen umfasst laut Microsoft for Startups drei Dinge, die zusammen gelesen werden: activation, retention and conversion. Ihr Prüfrahmen testet zudem Machbarkeit des Produkts, technische Skalierbarkeit und Marktnachfrage parallel statt nacheinander.

Eine Vorlage, die Sie übernehmen können:

Feld	Beispiel
Nutzergruppe	Einzelpraxen, 1 bis 3 Mitarbeitende
Ergebnis	Weniger verpasste Termine
Riskanteste Annahme	Praxen verschicken Erinnerungen über ein neues Werkzeug
Kernfunktionen	Buchungsseite, Verfügbarkeiten, Kalender, Bestätigung, Erinnerungen, Stornierung
Zurückgestellt	Zahlungen, Patientendossier, Auswertungen, native App
Erfolgsschwelle	Vor dem Start festgelegt: aktivierte Praxen, Verbleib nach 4 Wochen, zahlende Abschlüsse
Überprüfungstermin	Beim Projektstart gesetzt

Schritt 5: Klein starten, dann über das Nächste entscheiden

Legen Sie das MVP echten Nutzer:innen in strukturierten Sitzungen vor und verfolgen Sie gleichzeitig die Zahlen. Jemandem beim Versuch zuzusehen, den Kernablauf abzuschliessen, erklärt Ihnen, warum die Kennzahlen so aussehen. Die Kennzahlen zeigen Ihnen, ob das Gesehene typisch ist.

Vergleichen Sie die Ergebnisse dann mit den Schwellen, die Sie gesetzt haben. Drei Ausgänge sind möglich:

• Schwelle erreicht: Bauen Sie den nächstwertvollsten Punkt aus der Liste, nicht den lautesten Wunsch.
• Teilweise erreicht: Finden Sie heraus, wo Nutzer:innen abspringen, und ändern Sie eine Sache nach der anderen.
• Nicht erreicht: Gehen Sie zur Annahme zurück. Vielleicht stimmten Segment, Problem oder Preis nicht. Jetzt die Richtung zu wechseln, heisst, dass das MVP funktioniert, nicht dass es gescheitert ist.

Das MVP ist der Beginn einer Lernschlaufe aus Veröffentlichen, Messen, Lernen und Verbessern. Echtes Verhalten soll die nächsten Produktentscheide leiten, stärker als Meinungen im Sitzungszimmer.

Häufige Fehler beim Abstecken

• Von der Lösung her denken. „Wir brauchen ein Dashboard“ ist kein Nutzerbedürfnis. Beginnen Sie bei der Aufgabe.
• Für drei Nutzertypen gleichzeitig bauen. Wählen Sie einen. Die anderen kommen später.
• Jeden Wunsch aus dem Umfeld als Muss behandeln. Nutzen Sie die Sortierung oben und machen Sie den Abtausch sichtbar.
• Den manuellen Test überspringen. Wenn Sie es von Hand nachstellen können, tun Sie das zuerst.
• Keine Abbruchkriterien. Ohne Schwelle lässt sich jedes Resultat als ermutigend lesen.
• Schnittstellen unterschätzen. Alles, was einen bestehenden Shop, ein CRM oder ein ERP berührt, braucht eine eigene Vorabklärung.
• Einen Anbieter wählen, der mitten im Projekt das Team wechselt. Beständigkeit zählt mehr als eine geschliffene Präsentation.

Wie Ampersand Sie unterstützt

Wir sind ein kleines Zürcher Studio, und erfahrene Entwickler:innen bleiben von der ersten Beratung bis zur Übergabe auf Ihrem Projekt. Das zählt am meisten beim Abstecken, wo ein falscher Entscheid still und leise drei Monate später zur Neuentwicklung wird. Wir bauen Websites, Web- und Mobile-Apps, MVPs und Plattformen, und wir helfen Ihnen, den Umfang zu schärfen, bevor gebaut wird, über unsere Beratungspläne: Guidance kostet 799 CHF pro Monat. Sobald Ihr Produkt live ist, kostet die Unterstützung mit Run & monitor 750 CHF pro Monat. Weitere Angebote richten sich nach Ihrem Projekt; siehe die Leistungen und Pläne oder unsere aktuellen Arbeiten.

Häufige Fragen

Was ist der Unterschied zwischen einem MVP und einem Prototyp?

Ein Prototyp prüft, ob die Leute verstehen, wie man das Produkt benutzt, oft anhand eines klickbaren Entwurfs. Ein MVP ist ein funktionierendes Produkt, das prüft, ob echte Nutzer:innen genug Nutzen ziehen, um dranzubleiben oder zu bezahlen. Viele Teams machen beides und beginnen mit dem Prototyp.

Wie viele Funktionen soll ein MVP haben?

So wenige wie nötig, um das Kernergebnis für eine Nutzergruppe zu liefern. Wenn Sie das Produkt nicht in zwei Sätzen beschreiben können, ist die Liste wahrscheinlich zu lang. Verschieben Sie alles andere auf eine Liste für später und schauen Sie es erneut an, sobald Sie echtes Verhalten sehen.

Wie lange dauert es, ein MVP zu bauen?

Ein eng abgestecktes MVP dauert in der Regel Wochen bis wenige Monate, je nach Anzahl der Kernabläufe, Schnittstellen und regulatorischen Anforderungen. Die Dauer steigt schnell, wenn der Umfang unklar ist oder der Entwurf laufend ändert. Ein Plan in Phasen mit einem Entscheidungspunkt nach der ersten Veröffentlichung hält die Verpflichtung überschaubar.

Muss ich vor dem Abstecken mit Nutzer:innen sprechen?

Ja. Problemgespräche über kürzlich tatsächlich Erlebtes sind der günstigste Weg zu prüfen, ob Sie etwas lösen, das den Leuten wichtig ist. Der Leitfaden von Innosuisse schlägt 10 bis 20 strukturierte Gespräche vor, um Kundensegment und Problem zu bestätigen.

Quellen

• guide to business model testing
• unit of progress in an MVP
• Broken prototypes draw polite responses
• talking to users
• minimum viable tests
• the difference between the two
• activation, retention and conversion
• target conversion rate
• conversion rate benchmarks
• indexed correctly on launch day