Wie Sie ein MVP richtig zuschneiden: Reduzieren Sie Ihre erste Version auf das, was wirklich zählt

Fast jeder, der mit einer App-Idee zu uns kommt, hat die vollständige Version davon bereits im Kopf gebaut. Man kann das Dashboard beschreiben, die Einstellungsseite, das Empfehlungsprogramm, den Dark Mode. Was man meist nicht sagen kann, ist, welcher einzelne Teil dieses Bildes, wenn er funktionierte, das Ganze überhaupt erst lohnenswert machen würde. Ein MVP zuzuschneiden ist die wenig glamouröse, etwas schmerzhafte Arbeit, genau diesen einen Teil zu finden — und mutig genug zu sein, den Rest auf später zu verschieben.

Ich habe viele erste Produkte entstehen sehen, und die, die straucheln, scheitern fast nie an Faulheit des Teams. Sie scheitern, weil der Zuschnitt schon in der ersten Woche falsch war. In Version eins wurde zu viel hineingepackt, das Budget war erschöpft, bevor irgendjemand etwas gelernt hatte, und bis zum Start hatte das Team alles ausgegeben, nur um an die Startlinie zu kommen — ohne Geld, um auf das zu reagieren, was echte Nutzer tatsächlich taten.

Das ist also der Leitfaden, den ich Menschen gebe, bevor eine einzige Zeile Code geschrieben wird. Es geht nicht um agile Rituale oder ausgefeilte Frameworks. Es geht um eine ehrliche Frage — was ist das Kleinste, das wir bauen können, das uns zeigt, ob diese Idee tragfähig ist? — und um die Disziplin, sie immer wieder zu beantworten, während die Versuchung, ‚nur eine Funktion mehr‘ hinzuzufügen, zurückkehrt. Denn sie kehrt immer zurück.

Was ein MVP wirklich ist (und was nicht)

Der Begriff ist durch Überbeanspruchung abgenutzt, also seien wir präzise. Ein Minimum Viable Product ist die kleinste Version Ihrer Idee, die einem echten Nutzer echten Wert liefert und Ihnen etwas beibringt, das Sie aus einer Folienpräsentation nie hätten lernen können. Das Schlüsselwort, das man vergisst, ist viable, also tragfähig. Es muss für jemanden tatsächlich funktionieren, von Anfang bis Ende, selbst wenn es nur eine einzige Sache tut.

Hier ist, was ein MVP nicht ist. Es ist keine halbfertige Version des vollständigen Produkts mit kaputten Ecken überall. Es ist kein Prototyp, den Sie wegwerfen. Und es ist definitiv nicht ‚die billige Version‘ — billig ist eine Nebenwirkung guten Zuschnitts, nicht das Ziel. Das Ziel ist Lernen. Sie geben so wenig Geld wie möglich aus, um die teuerste Frage zu beantworten, die Sie haben: Wird das überhaupt jemand nutzen, und wird er es so nutzen, wie ich denke?

Dieser Unterschied wiegt schwerer, als er klingt. Die Denkweise ‚die ersten 20 %‘ führt zu etwas, das in jede Richtung kaputt und in keiner brauchbar ist. ‚Eine Sache, richtig gemacht‘ führt zu etwas, das ein Mensch in die Hand nehmen, wirklich nutzen und sich eine Meinung dazu bilden kann. Meinungen sind der ganze Sinn. Auf Schweigen lässt sich nicht iterieren.

Die Zu-viel-bauen-Falle und warum man so leicht hineintappt

Niemand setzt sich vor, zu viel zu bauen. Es passiert, eine vernünftige Entscheidung nach der anderen. Sie fügen einen Login hinzu, weil Sie natürlich Konten brauchen. Konten bedeuten einen Ablauf zum Zurücksetzen des Passworts, eine E-Mail-Verifizierung und eine Einstellungsseite. Einstellungen bedeuten ein Profil, was Bild-Uploads bedeutet, was wiederum einen Ort zum Speichern bedeutet. Jeder Schritt ist für sich genommen sinnvoll. Zusammengestapelt haben Sie zwei Monate und einen Teil des Budgets ausgegeben, bevor der Teil, der Ihre Idee besonders macht, überhaupt begonnen wurde.

Die andere Hälfte der Falle ist emotional. Funktionen zu streichen fühlt sich an, als gestünde man, die Idee sei klein. Das ist sie nicht — man gesteht ein, dass man noch nicht weiß, welche Funktionen zählen, was schlicht die Wahrheit ist. Jede Funktion, die Sie bauen, bevor Sie Nutzer haben, ist eine Wette ins Blaue. Einige dieser Wetten werden falsch sein, und die, die Sie aus dem MVP streichen, sind die billigsten Wetten, bei denen man sich irren kann, denn Sie haben sie nie platziert.

Finden Sie die eine Aufgabe, die Ihr MVP erfüllen muss

Jedes Produkt, so groß es am Ende auch wird, hat eine Kernschleife — die eine Abfolge, die ein Nutzer wiederholt und die den Wert erzeugt. Bei einer Buchungs-App ist es einen Termin finden, ihn buchen, erinnert werden. Bei einem Marktplatz ist es etwas einstellen, jemand findet es, Geld wechselt den Besitzer. Bei einem internen Werkzeug ist es die Daten einmal erfassen, sie überall nutzen. Alles andere im Produkt existiert, um diese Schleife zu unterstützen, zu verzieren oder zu erweitern. Ihr MVP ist die Schleife. Nur die Schleife.

Um Ihre zu finden, vollenden Sie diesen Satz laut: „Ein Nutzer kommt zu meinem Produkt, um ______, und er ist zufrieden, wenn ______.“ Die erste Lücke ist die Aufgabe. Die zweite ist, woran Sie erkennen, dass es funktioniert hat. Wenn Sie beide Lücken nicht in einem Atemzug füllen können, haben Sie den Kern noch nicht gefunden — und Sie sind nicht bereit zuzuschneiden, geschweige denn zu bauen.

Seien Sie unerbittlich beim Unterschied zwischen der Kernschleife und den Dingen, die sich wesentlich anfühlen, es aber nicht sind. Ein Login fühlt sich wesentlich an. In Version eins ist er es meist nicht — viele MVPs starten mit einem einzigen geteilten Link, einer manuellen Einladung oder ganz ohne Konten und lernen alles Nötige, bevor sie die Authentifizierungs-Mechanik bauen. Analyse-Dashboards fühlen sich wesentlich an. Sind sie nicht; Sie können die Datenbank von Hand lesen, wenn Sie elf Nutzer haben. Reduzieren Sie auf die Schleife, und Sie werden staunen, wie viel wegfällt.

Sortieren Sie jede Funktion in Muss, Sollte und Wird-nicht

Sobald Sie die Kernschleife benannt haben, nehmen Sie Ihre große Funktionsliste und sortieren Sie jeden Punkt in drei Körbe. Die Körbe sind bewusst grob, denn grob ist das, was die endlosen ‚aber vielleicht‘-Gespräche beendet.

• Muss: Die Kernschleife funktioniert ohne diese Funktion buchstäblich nicht. Entfernt man sie, gibt es kein Produkt. Halten Sie diese Liste erschreckend kurz — meist drei bis sechs Punkte.
• Sollte: Es macht das Produkt besser, aber die Schleife funktioniert auch ohne. Alles hier wartet auf Version zwei. Keine Ausnahmen im ersten Build.
• Wird (noch) nicht: die Funktionen, die Sie bewusst jetzt nicht bauen. Sie aufzuschreiben ist wichtig — so versichern Sie sich und Ihrem Team, dass die Idee nicht aufgegeben, sondern nur in eine Reihenfolge gebracht wird.

Der Kniff, der das funktionieren lässt, ist der dritte Korb. Die meisten streiten nur über Muss gegen Sollte, was zermürbend ist und nie endet. Die ‚Wird noch nicht‘-Liste ist der Ort, an dem die Erleichterung wohnt — sie ist ein Versprechen an Ihr künftiges Ich, dass die coole Idee sicher und eingeplant ist, nur eben nicht jetzt. Sobald die Leute darauf vertrauen, dass nichts weggeworfen wird, hören sie auf, darum zu kämpfen, alles in Version eins zu behalten.

Schneiden Sie nach Zeit und Geld zu, nicht nach Funktionsliste

Hier ist eine stille Verschiebung, die alles ändert: Hören Sie auf, nach ‚was wollen wir‘ zuzuschneiden, und beginnen Sie, nach ‚was passt ins Budget und in den Termin‘ zuzuschneiden. Entscheiden Sie zuerst, wie viel Geld und wie viele Wochen Sie auszugeben bereit sind, um Ihre Kernfrage zu beantworten. Dann passen Sie die Funktionsliste in diesen Kasten ein. Das klingt verkehrt herum, aber es ist die nützlichste Einschränkung, die Sie sich selbst geben können, denn sie erzwingt die Priorisierung, die Sie sonst vermeiden würden.

Ein fester Kasten bewirkt auch etwas Psychologisches. Wenn das Budget offen ist, ist jede Funktion verhandelbar und die Liste wächst nur. Wenn der Kasten fest ist — sagen wir, acht Wochen und ein bestimmter Betrag — kippt das Gespräch. Es geht nicht mehr um ‚sollten wir das hinzufügen?‘, sondern um ‚was fällt raus, wenn das hineinkommt?‘ Diese zweite Frage baut gute MVPs. Kompromisse werden sichtbar statt verborgen, und das Team trifft sie mit Absicht.

Ein echtes Beispiel: eine Idee zur Auftragsverwaltung zuschneiden

Lassen Sie mich das mit einem Fall konkret machen, an dem wir gearbeitet haben — anonymisiert, aber wahrheitsgetreu. Ein kleiner Heizungs- und Sanitärbetrieb kam zu uns und wollte eine App für sein Außendienstteam. Das Briefing war auf dem Papier riesig: Live-Auftragsplanung, GPS-Ortung der Fahrzeuge, ein Kundenportal, automatisierte Rechnungsstellung, eine Bestandsführung der Teile in jedem Fahrzeug, ein Angebotsersteller, Fotodokumentation und ein Berichtswesen für den Inhaber. Ein wirklich nützliches Produkt, irgendwann. Als erster Build ein garantierter Weg, ein Jahresbudget auszugeben, bevor man etwas lernt.

Also machten wir die Übung. Wir stellten dem Inhaber den Satz: ‚Ein Nutzer kommt hierher, um ______, und er ist zufrieden, wenn ______.‘ Nach einigem Hin und Her tauchte die wahre Antwort auf. Der größte tägliche Schmerz der Techniker war weder die Planung noch die Rechnungsstellung — es war der Papierkram-Rücklauf. Sie beendeten einen Auftrag, kritzelten Stunden und Teile auf einen Zettel, fuhren zurück, und jemand im Büro tippte alles ins Buchhaltungssystem — oft Tage später, oft mit Fehlern. Die Kernschleife war schlicht: einmal vor Ort erfassen, was passiert ist, damit niemand etwas abtippt.

Was es schaffte — und was nicht

Alles wurde sortiert. Der Muss-Korb kam auf vier Dinge herunter: eine Liste der heutigen Aufträge für jeden Techniker, ein einfaches Formular zur Erfassung von Stunden und verwendeten Teilen pro Auftrag, ein Foto-Anhang und eine Möglichkeit für das Büro, diese Daten in dem Moment zu sehen, in dem sie übermittelt wurden. Das war das ganze MVP. Kein GPS, kein Kundenportal, kein Angebotsersteller, kein ausgefeiltes Berichtswesen — all das ausdrücklich auf der ‚Wird noch nicht‘-Liste geparkt, mit einer Notiz, dass es kommen würde.

Wir bauten diesen Kern in wenigen Wochen statt im Großteil eines Jahres. Und hier ist der Teil, der den ganzen Ansatz rechtfertigt: Als er live war, unterschieden sich die echten Prioritäten des Teams vom Briefing. Der Inhaber hatte angenommen, GPS-Ortung käme als Nächstes; die Techniker erwähnten sie kaum. Was sie laut wollten, war, dem Kunden aus der App heraus ein Ankunftsfenster zu schreiben — eine Funktion, die nicht einmal auf der ursprünglichen Liste stand. Weil das MVP klein und günstig war, blieb Budget, um das zu bauen, was sie tatsächlich wollten, statt das, was sie Monate zuvor erraten hatten.

Die Fehler, die einen MVP-Zuschnitt leise ruinieren

Selbst Teams, die ‚halt es klein‘ verinnerlicht haben, stolpern über dieselben paar Dinge. Keines davon ist dramatisch. Es sind langsame Lecks, die den Zuschnitt wieder aufblähen, während Sie nicht hinsehen, bis das ‚minimale‘ Produkt eines Tages wieder dreißig Bildschirme und einen Sechs-Monats-Plan hat.

• Die Ränder vergolden: Tage damit verbringen, ein Admin-Panel zu perfektionieren, das nur Sie je sehen werden, während die Kernschleife noch rau ist. Polieren Sie, was Nutzer berühren; lassen Sie das Backoffice hässlich und funktional.
• Für eine Skalierung bauen, die Sie nicht haben: für eine Million Nutzer architekturieren, wenn Sie beweisen müssen, dass die ersten zehn zurückkehren. Lösen Sie das Skalierungsproblem, wenn Sie das schöne Problem der Skalierung haben.
• ‚Muss-Funktion‘ mit ‚Branchenstandard‘ verwechseln: Nur weil jeder Wettbewerber Funktion X hat, braucht Ihr MVP sie nicht, um Ihre Kernidee zu testen. Sie starten kein fertiges Produkt, Sie führen ein Experiment durch.
• Jeden Sonderfall im Voraus entwerfen: die seltenen, schrägen Eingaben behandeln, bevor Sie wissen, ob überhaupt jemand den üblichen, normalen Pfad nutzt. Lassen Sie die echte Nutzung Ihnen sagen, welche Sonderfälle überhaupt real sind.
• Keine Definition von Fertig: Ohne eine geschriebene Zeile, die beschreibt, wie ‚fertig‘ aussieht, endet der Build nie. Scope Creep liebt ein Projekt ohne Ziellinie.

Wenn Sie sich nur gegen einen davon wappnen, dann gegen den letzten. Eine klare, geschriebene Definition von Fertig — ‚ein Techniker kann Stunden und Teile eines Auftrags auf seinem Handy erfassen, und das Büro sieht es sofort‘ — ist das mächtigste Werkzeug, um den Zuschnitt ehrlich zu halten. Jede vorgeschlagene Ergänzung wird gegen diesen Satz gehalten. Dient sie dem Satz nicht, ist es eine Version-zwei-Idee, so gut sie auch sein mag.

Ein einfacher Prozess, um Ihr MVP zuzuschneiden

Fassen wir zusammen: Hier ist die Abfolge, die ich mit jedem durchgehen würde, bevor ein erster Build beginnt. Sie ist bewusst Low-Tech — das meiste davon können Sie mit einem Dokument und einem ehrlichen Gespräch erledigen, lange bevor Sie einen Entwickler im Raum brauchen.

1. 1
   Benennen Sie die Kernschleife

   Vollenden Sie den Satz: ‚Ein Nutzer kommt, um ___, und ist zufrieden, wenn ___.‘ Wenn Sie es nicht können, sind Sie nicht bereit zuzuschneiden — reden Sie weiter, bis die echte Aufgabe auftaucht.
2. 2
   Jede Funktion auflisten, dann sortieren

   Holen Sie die ganze Wunschliste aus dem Kopf aufs Papier. Sortieren Sie jeden Punkt in Muss, Sollte oder Wird-noch-nicht. Halten Sie die ‚Muss‘-Liste brutal kurz.
3. 3
   Den Kasten festlegen

   Entscheiden Sie das Budget und den Termin, bevor Sie die Funktionsliste finalisieren. Machen Sie die Liste passend zum Kasten, nicht umgekehrt.
4. 4
   Die Definition von Fertig schreiben

   Ein konkreter Satz, der die funktionierende Kernschleife beschreibt. Das ist Ihr Schutzschild gegen Scope Creep für den Rest des Projekts.
5. 5
   Bauen, starten, beobachten, dann entscheiden

   Bringen Sie den Kern zu echten Nutzern. Beobachten Sie, was sie tatsächlich tun. Lassen Sie ihr Verhalten — nicht Ihre früheren Vermutungen — wählen, was als Nächstes von der ‚Sollte‘-Liste kommt.

Beachten Sie, dass der letzte Schritt Sie zum Anfang zurückführt. Ein gutes MVP ist kein einmaliges Ereignis, es ist die erste Umdrehung eines Rades. Sie schneiden klein zu, Sie liefern, Sie lernen, und was Sie lernen, schneidet den nächsten Build neu zu. Die Teams, die gewinnen, sind nicht die, die das perfekte Produkt im Voraus planten — das tut niemand. Es sind die, die schnell genug etwas Echtes vor Nutzer brachten, dass die Realität sie noch lenken konnte.

Häufige Fragen