Den Scope eines KI-MVP schneiden: klein starten, ehrlich lernen
Die meisten KI-MVPs werden zu groß geschnitten, nicht zu klein. Der Reflex ist, alles Denkbare in Version eins zu packen, damit sie sich vollständig anfühlt. Genau das macht sie langsam, teuer und schwer zu beurteilen. Ein tragfähiger Scope nimmt einen einzigen echten Nutzerjob, den häufigsten Normalfall und ein klares Erfolgskriterium mit gemessener Baseline. Der wichtigste Hebel ist die Nein-Liste: Was bewusst draußen bleibt, entscheidet mehr über den Erfolg als das, was drin ist. Ein MVP ist keine abgespeckte Vollversion, sondern die kleinste Version, die schon Wert stiftet und ehrlich zeigt, ob der Fall trägt.
Was ein MVP-Scope wirklich ist
Ein KI-MVP ist die erste echte, nutzbare Version einer KI-Lösung, die schon Wert stiftet. Nicht ein Test im Labor, sondern etwas, das echte Nutzer im Alltag anfassen. Der Scope ist die Linie, die festlegt, was dieser erste Wurf kann und was nicht. Diese Linie zu ziehen ist die eigentliche Arbeit, und sie fällt fast allen schwerer als das Bauen selbst.
Der häufigste Fehler ist nicht der zu kleine, sondern der zu große Scope. Ein MVP wird als abgespeckte Vollversion missverstanden, also als das fertige System minus ein paar Funktionen. So gedacht wächst der Umfang, bis niemand mehr sagen kann, ob Version eins gut ist, weil sie zu viel auf einmal versucht.
Ein MVP ist nicht dasselbe wie ein Prototyp. Ein Prototyp beweist Machbarkeit an echten Daten, oft mit einem Menschen daneben. Ein MVP geht einen Schritt weiter: Es liefert echten Nutzen für echte Nutzer, mit dauerhaftem Datenzugang und einem Fehlerpfad, der nicht davon abhängt, dass jemand zufällig danebensteht.
| Aspekt | KI-Prototyp | KI-MVP |
|---|---|---|
| Zweck | Machbarkeit zeigen | ersten echten Nutzen liefern |
| Nutzer | Testteam | echte Nutzer im Alltag |
| Datenzugang | eng, für den Test freigegeben | dauerhaft, geprüft, rechtlich belastbar |
| Umgang mit Fehlern | Mensch fängt Ausnahmen ab | definierter Fehlerpfad |
| Erfolgsfrage | "geht es grundsätzlich" | "ändert sich die Kennzahl" |
Die In-Draußen-Linie ziehen
Scope schneiden heißt, für jeden Wunsch eine ehrliche Ja-oder-Nein-Entscheidung zu treffen. Die nützliche Frage ist nicht "wäre das gut", denn fast alles wäre gut. Die nützliche Frage ist: Trägt dieses Feature den einen Job, den Version eins beweisen soll, oder ist es Komfort, der auch in Version zwei passt.
Was bewusst draußen bleibt, entscheidet mehr über den Erfolg eines MVP als das, was drin ist.
Ein Beispiel macht es konkret. Soll ein Assistent Rechnungen auslesen, dann ist der eine Job das Auslesen der häufigsten Rechnungsart, sauber und verlässlich. Draußen bleibt für den ersten Scope alles andere: die seltenen Sonderformate, die Anbindung an drei weitere Systeme, das schöne Dashboard. Nicht weil es unwichtig ist, sondern weil es den Beweis nicht trägt und den Schnitt verwässert.
| Frage zum Feature | Spricht für rein | Spricht für raus |
|---|---|---|
| Trifft es den häufigsten Fall? | ja, es ist der Kern | nein, es ist ein Randfall |
| Trägt es das Erfolgskriterium? | ja, direkt | nein, nur indirekt |
| Geht Version eins ohne? | nein, dann fehlt der Nutzen | ja, es ist Komfort |
| Kostet es Wochen extra? | nein | ja, dann später |
Was bewusst draußen bleibt
Die stärkste Disziplin beim Scope ist die Nein-Liste. Sie hält fest, was Version eins nicht kann, und zwar nicht aus Vergesslichkeit, sondern aus Absicht. Eine gute Nein-Liste ist kein Verlust, sie ist der halbe Fahrplan für später. Was draußen bleibt, ist nicht gestrichen, es ist geparkt und wird priorisiert, sobald der Kern trägt.
Typisch draußen bleiben Zweitkanäle, seltene Sonderfälle, die vollständige Abdeckung aller Varianten und jedes Feature, das sich schön anfühlt, aber den einen Job nicht direkt bedient. Wer diese Dinge in Version eins zwingt, kauft sich Umfang, den niemand braucht, um eine Frage zu beantworten, die auch der schmale Kern beantwortet hätte.
So schneidest du den Scope
Bevor gebaut wird, klärst du fünf Punkte. Wer hier sauber schneidet, spart sich die Nacharbeit, die ein aufgeblähter MVP unweigerlich erzeugt.
- Den einen Job benennen, in einem Satz, ohne "und". Sobald ein "und" auftaucht, sind es zwei Jobs, und einer davon gehört raus.
- Das Erfolgskriterium festlegen, samt gemessener Baseline. Ohne Ausgangswert lässt sich am Ende nicht sagen, ob der MVP etwas taugt.
- Den Normalfall zuerst, nicht die Sonderfälle. Der häufigste Fall trägt den Nutzen, die Ausnahmen kommen bewusst später.
- Den Fehlerpfad definieren, also was passiert, wenn das System unsicher ist und wer dann übernimmt. Ein MVP darf nicht schweigend danebenliegen.
- Die Nein-Liste schreiben, sichtbar und geteilt. Was draußen ist, muss benannt sein, sonst schleicht es sich wieder herein.
Kernsatz: Ein MVP-Scope ist zur einen Hälfte die Entscheidung, was drin ist, und zur anderen Hälfte der Mut, das meiste draußen zu lassen. Die zweite Hälfte ist die schwerere.
Häufige Irrtümer
- Ein MVP ist eine abgespeckte Vollversion.
- Nein. Ein MVP ist die kleinste Version, die einen echten Job schon löst, nicht das fertige System mit ein paar fehlenden Knöpfen. Wer es als Vollversion minus X denkt, schneidet zu breit.
- Was draußen bleibt, ist verloren.
- Nein. Die Nein-Liste ist kein Papierkorb, sondern ein geordneter Vorrat. Was der Kern trägt, wird zuerst gebaut, der Rest wird priorisiert, sobald sich der erste Nutzen zeigt.
- Mehr Features senken das Risiko.
- Umgekehrt. Jede zusätzliche Funktion in Version eins vergrößert die Fläche, auf der etwas schieflaufen kann, und verwässert die eine Frage, die der MVP beantworten soll.
Fragen und Antworten
- Wie klein darf ein MVP sein?
- So klein, dass er genau einen echten Job an echten Daten löst und dabei einen messbaren Unterschied macht. Wenn du ihn noch weiter schneidest und der Nutzen verschwindet, warst du zu klein. Solange der Nutzen bleibt, ist kleiner fast immer besser.
- Woran erkenne ich Scope Creep früh?
- An den "und"-Sätzen und an Features, die mit "wenn wir schon dabei sind" beginnen. Sobald der eine Job sich in zwei oder drei aufteilt oder die Nein-Liste stillschweigend schrumpft, wächst der Scope, und mit ihm das Risiko.
- Was ist der Unterschied zwischen MVP und Prototyp?
- Ein Prototyp beweist Machbarkeit, oft mit einem Menschen daneben und nur für ein Testteam. Ein MVP liefert echten Nutzen für echte Nutzer im Alltag, mit dauerhaftem Datenzugang und einem definierten Fehlerpfad. Der Prototyp fragt "geht es", der MVP fragt "hilft es".
Sources and evidence
Es werden keine externen Marktwerte oder ungeprüften Kundenergebnisse behauptet. Datenzugang und Rechtsfragen werden vor dem Bau am realen Stack geprüft.