Der KI-MVP ist gerade das am stärksten überdimensionierte Artefakt in der Softwareindustrie. Gründer fragen nach einem Copilot. Drei Wochen später ist der Scope auf eine Roadmap, ein Abrechnungssystem, ein Admin-Panel und eine Slack-Integration angewachsen. Das, was eine Annahme prüfen sollte, prüft jetzt dreissig, und zwar schlecht. Zwei-Wochen-MVPs, die shippen und lehren, schlagen zehnwöchige, die feststecken, jedes Mal.

Das MVP-Paradox.

Der Minimum Viable Product soll das kleinste Artefakt sein, das eine einzelne Geschäftshypothese beweist. In der Praxis bauen die meisten Teams die kleinste Version eines ganzen Produkts, was eine ganz andere und viel grössere Sache ist. Das erste ist eine Sonde. Das zweite ist ein Prototyp, der so viel kostet wie v1. Diese beiden zu verwechseln ist der teuerste Fehler in frühen KI-Engagements.

«Ein MVP ist eine Annahme, fürs Testen gekleidet. Nicht ein Produkt, für den Investor gekleidet.»

Regel 1, einen einzigen Entscheidungspunkt skopen.

Jeder KI-MVP sollte eine Entscheidung beantworten, die der Operator heute manuell trifft. Nicht drei. Nicht den gesamten Workflow. Eine. «Kann das die erste Version einer Outbound-E-Mail besser als eine leere Seite entwerfen?» «Kann das Support-Tickets in drei Kategorien gut genug sortieren?» «Kann das eingehende Leads gegen eine geschriebene Rubrik bewerten?» Wenn die Antwort Nein ist, haben Sie etwas Günstiges gelernt. Wenn Ja, ist die zweite Entscheidung ein separater MVP, später durchgeführt.

Regel 2, eine einzige Oberfläche shippen.

Der schnellste MVP, den wir shippen, ist eine einzige Seite mit einem Eingabefeld und einem Ausgabepanel. Kein Login, keine Einstellungen, keine Historie, kein Admin. Der Operator fügt ein Beispiel ein, das System gibt eine Antwort zurück, der Operator bewertet sie. Vierzig Mal wiederholen. Das ist das ganze Produkt für die Dauer des MVP. Jede zweite Oberfläche, ein Admin-Panel, ein Einstellungsbildschirm, ein Konto, verdoppelt den Zeitplan und halbiert das Lernen.

Regel 3, einen akzeptierten Faktor vereinbaren.

Bevor der MVP startet, einigen sich der Operator und das Studio auf die einzige Zahl, die als Pass gilt. «Wenn das System auf 70% der Beispiele eine akzeptable erste Version produziert, bauen wir es zu einem Produkt aus.» Schriftlich. Wer sich ohne diese Zahl in den Sprint begibt, kommt mit einem beweglichen Ziel zurück, was dasselbe ist wie ohne Ziel.

Anatomie eines echten Zwei-Wochen-Sprints.

Tag 1-2: die Entscheidungs- und Faktorvereinbarung, die Eingabesammlung. Tag 3-5: die einfachste Pipeline, die plausibel die Antwort produziert, ausgeliefert hinter dem Eingabe-/ Ausgabepanel. Tag 6-9: vierzig Beispiele durchgereicht, jedes handgescort. Tag 10: gemeinsames Review, der Faktor wird überschritten oder nicht. Beides ist ein gutes Ergebnis. Beides spart Wochen v1-Bau.

Wann man keinen MVP baut.

Wenn die Entscheidung, die Sie testen wollen, von einer Datenintegration abhängt, die zwei Wochen dauert, ist der MVP falsch skopiert. Reduzieren Sie zuerst die Integration auf einen Stub oder verschieben Sie die Hypothese. Ein MVP, der mit einer unfertigen Datenpipeline startet, testet die Pipeline, nicht die KI-Annahme.

Vollständige englische Fassung: The two-week AI MVP, and the ten-week one that never ships.

Diese deutschsprachige Fassung ist eine eigenständige Übersetzung der englischen Ausgabe. Read the English original ›