Das MVP ist tot. Bau ein Minimum Credible Product.

Ist das MVP tot? Die Lernmethode nicht. Die Ausrede schon. KI-Coding-Tools können den Aufwand für Prototypen senken, doch es gibt keinen universellen Beleg dafür, dass alle Nutzer, Investoren und Käufer dieselbe Qualitätsschwelle angehoben haben. Unsere engere These lautet: sichtbare Rauheit ist ein schwacher Tempobeweis, und vermeidbare Fehler können das geplante Experiment verfälschen.

Das bessere Ziel nennen wir Minimum Credible Product, also ein minimal glaubwürdiges Produkt: die kleinste Version, die die riskanteste Geschäftsannahme testen kann, ohne vermeidbare Fehler auf die Geduld der Nutzer abzuwälzen. Sie enthält weniger Features als viele MVPs. Der eine erhaltene Pfad funktioniert dafür Ende zu Ende und verdient genug Vertrauen für die nächste Entscheidung.

Das bedeutet nicht, jede Ecke zu polieren oder für eine imaginäre Skalierung zu bauen. Es bedeutet nur: Der alte Satz „Es ist ja nur ein MVP“ trägt nicht mehr das Gewicht, das Gründer ihm aufladen.

Was hat sich am Minimum Viable Product verändert?

Das ursprüngliche MVP sollte nie schlechte Software bedeuten. Eric Ries definiert es als die Version, die mit dem geringsten Aufwand möglichst viel validiertes Lernen über Kunden erzeugt, wie die Lean Startup Company dokumentiert. Es ist ein Experiment, um Annahmen vor größeren Investitionen zu testen.

Diese Logik gilt weiterhin. Verändert hat sich die Glaubwürdigkeitsschwelle des Experiments.

Als Software mehr manuelle Umsetzung erforderte, konnte sichtbare Rauheit echte Einschränkungen signalisieren. Aktuelle KI-Tools können Oberflächen, API-Gerüste, Datenbankschemata, Tests und Deployment-Konfiguration schnell erzeugen, doch Prüfung und Integration dauern je nach Kontext sehr unterschiedlich lange. Nicht jeder Prototyp muss poliert aussehen. Rauheit sollte aber bewusst gewählt sein und die getestete Annahme nicht verdecken.

Prüfe beim Scoping vier unterschiedliche Glaubwürdigkeitsrisiken, statt eine universelle Schwelle anzunehmen:

• Nutzerrisiko. Scheitert der Kernpfad, misst du womöglich Onboarding-Reibung statt Nachfrage.
• Investorenrisiko. Ein generiertes Dashboard allein beweist weder technische Machbarkeit noch Differenzierung oder Traktion.
• Enterprise-Risiko. Ein Pilot kann Berechtigungen, Datenverarbeitungsbedingungen, Auditierbarkeit, Integrationen und klare Ownership benötigen, bevor er ein Kaufsignal erzeugt.
• Teamrisiko. Schnellere Generierung kann Scope aufblasen, wenn dem Experiment eine explizite Ausschlussliste fehlt.

Unsere Empfehlung ist daher nicht mehr Politur, sondern weniger Scope und klarere Evidenz.

Prototyp vs. MVP vs. Minimum Credible Product

Das sind nicht drei Polierstufen. Sie beantworten drei verschiedene Fragen.

Der Prototyp beweist Möglichkeit. Das MVP versucht, Nachfrage zu beweisen. Das Minimum Credible Product beweist genug Nutzen und Vertrauen für die nächste Zusage.

Wenn diese nächste Zusage eine Accelerator-Bewerbung ist, hilft dir die technische Checkliste für deine YC-Bewerbung bei Demo, Kennzahlen, Founder-Verantwortung und Fortschrittsbelegen, ohne dass du zu viel baust.

Ist Software Engineering tot, weil KI Code schreibt?

Nein. KI komprimiert Teile der Softwareproduktion. Sie beseitigt nicht die Entscheidung, was existieren sollte, wie es scheitern darf und welche Evidenz einen Launch verantwortbar macht.

Die Produktivitätsdaten sind weniger spektakulär als der Feed. In GitHubs herstellereigenem randomisiertem Experiment implementierten 95 professionelle Entwickler denselben JavaScript-HTTP-Server; die Copilot-Gruppe war im Mittel 55 Prozent schneller. In einem anderen randomisierten Versuch benötigten 16 erfahrene Open-Source-Entwickler für 246 Aufgaben in vertrauten Repositories mit frühen 2025er KI-Tools 19 Prozent länger. METRs Update vom Februar 2026 zeigte rohe Anzeichen für Beschleunigung, bezeichnete die Evidenz wegen Selektionseffekten und paralleler Agentennutzung aber als schwach.

Das widerspricht sich nicht. Es misst unterschiedliche Arbeit. KI ist stark bei klar begrenztem Output, wenn Ziel, Kontext und Verifikation feststehen. Echte Produktarbeit steckt voller fehlendem Kontext, konkurrierender Ziele, unausgesprochener Einschränkungen und Folgen, die in keinen Coding-Benchmark passen.

Google Clouds DORA-Forschung 2025 beschreibt KI als Verstärker bestehender organisatorischer Stärken und Schwächen. Das ist eine beobachtende Organisationsaussage, kein Beweis, dass jedes starke Team besser und jedes schwache Team schlechter wird.

"Ein 100x Engineer, der das falsche Produkt baut, ist nicht 100-mal wertvoller. Er produziert nur 100-mal schneller Schulden."

Engineering war nie bloß Tippen. Knapp wird zunehmend das Urteilsvermögen:

• Welches Feature darf nicht existieren?
• Welcher Edge Case zerstört Vertrauen, statt nur zu nerven?
• Welche Abkürzung ist reversibel und welche erzwingt einen Rewrite?
• Welches Nutzerproblem tut heute genug weh, um dafür zu bezahlen?
• Welche Kennzahl trennt echtes Lernen von Demo-Applaus?
• Wo muss ein Mensch KI-Output prüfen, bevor daraus eine Folge entsteht?

KI kann helfen, diese Fragen zu bearbeiten. Sie trägt nicht die Konsequenzen einer falschen Antwort.

Was ist ein Minimum Credible Product?

Ein Minimum Credible Product ist das kleinste Produkt, das ein schmerzhaftes Problem über einen vollständigen, vertrauenswürdigen Pfad löst und Evidenz für die nächste Geschäftsentscheidung erzeugt. Es ist minimal im Umfang, nicht in der Sorgfalt. Seine Qualitätsschwelle ergibt sich daraus, was das Ergebnis des Experiments glaubwürdig macht.

Wir verwenden Minimum Credible Product als praktischen Arbeitsbegriff, nicht als etablierten Branchenstandard. MCP bedeutet hier Minimum Credible Product, nicht Model Context Protocol. Die Akronym-Kollision ist unglücklich. Die Unterscheidung ist einfach: Das eine ist ein Produktstrategie-Konzept, das andere ein technisches Protokoll, das KI-Systeme mit Tools und Daten verbindet.

Ein Minimum Credible Product besteht aus sieben Teilen:

1. Ein schmerzhaftes Problem. Braucht der Scope dreimal „und“, verkleiden sich vermutlich drei Produkte als ein MVP.
2. Ein konkreter Nutzer. Nicht KMU, Teams oder Wissensarbeiter. Benenne Person, Situation und den Auslöser, der das Problem dringend macht.
3. Ein Grund zurückzukehren oder zu zahlen. Das Produkt muss ein wiederholbares Ergebnis schaffen, nicht nur fünf Minuten Überraschung.
4. Ein vollständiger Produktivpfad. Der Kernablauf deckt Input, Verarbeitung, Output, Fehler und Wiederherstellung ab. Eine schöne Oberfläche über einem unzuverlässigen Pfad bleibt ein Prototyp.
5. Eine zum Risiko passende Vertrauensschwelle. Authentifizierung, Berechtigungen, Datenschutz, QA und menschliche Freigabe gehören überall dorthin, wo ein Fehler den Test wertlos oder unsicher machen würde.
6. Evidenz statt Vanity-Telemetrie. Miss das Verhalten, das die Geschäftsfrage beantwortet: erledigte Aufgaben, Wiederkehr, bezahlte Conversion, gesparte Zeit oder Freigabequote.
7. Eine explizite Ausschlussliste. Glaubwürdig bedeutet nicht breit. Halte fest, was nicht geliefert wird, damit schnellere Codegenerierung den Scope nicht zurückschmuggelt.

Bedeutet ein Minimum Credible Product Overengineering?

Nein. Overengineering fügt Fähigkeiten hinzu, bevor Evidenz sie verlangt. Glaubwürdigkeit entfernt Fähigkeiten, bis der verbleibende Pfad ein belastbares Signal erzeugt. Ein Minimum Credible Product darf manuelle Abläufe, ein gehostetes Modell, eine einfache Architektur und nur eine Integration nutzen. Es versteckt nur keine unsichere oder unfertige Arbeit hinter dem MVP-Label.

Die brauchbare Regel: Bau die Sicherungen, die die Gültigkeit des Experiments schützen. Verschiebe die Maschinerie, die nur eine erfundene Zukunft schützt.

Wie sieht ein Minimum Credible AI Product konkret aus?

Stell dir einen B2B-Assistenten vor, der Fragen aus Unternehmensdokumenten beantwortet.

Der Prototyp lädt ein PDF hoch und liefert in einer sauberen Chat-Oberfläche eine überzeugende Antwort. Er beweist, dass die Interaktion funktionieren kann.

Das schwache KI-MVP verbindet einen gemeinsamen Dokumentenordner, ergänzt Login und geht live. Es sieht fertig aus. Trotzdem kann jeder Nutzer jedes Dokument abrufen, Antworten haben keine Quellen, Fehler bleiben still und niemand misst die Antwortqualität. Die Nutzungsdaten dieses Produkts sind kontaminiert: Wenn Menschen abspringen, weißt du nicht, ob sie die Idee ablehnen oder nur der Umsetzung misstrauen.

Das Minimum Credible Product bedient eine Abteilung und eine Dokumentenquelle. Es respektiert die Berechtigungen des Quellsystems, zitiert die Textstellen hinter jeder Antwort, verweigert oder eskaliert bei fehlender Evidenz, protokolliert Qualität und Kosten und bietet einen klaren Korrekturpfad. Es kann weniger. Das Lernen ist mehr wert.

Die Glaubwürdigkeitsschwelle hängt vom Risiko ab. Ein internes Tool für Social-Post-Entwürfe braucht einen anderen Standard als Software, die medizinische Maßnahmen empfiehlt, Geld bewegt oder Kundendaten offenlegt. Glaubwürdigkeit ist kontextabhängig, keine starre Checkliste.

Für die technischen Prüfungen vor echten Nutzern und Daten hilft die Vibe-Code-Production-Readiness-Checkliste. Für KI-spezifische Abnahmekriterien, Eval-Sets und Launch-Gates nutze unsere Scope-Vorlage für ein KI-MVP.

Wie grenzt man ein Minimum Credible Product ab?

Beginne mit der Entscheidung, nicht mit der Featureliste. Ein brauchbarer Scope beantwortet sechs Fragen in normaler Sprache:

1. Was ist die riskanteste Annahme? Nachfrage, Zahlungsbereitschaft, Wiederkehr, technische Machbarkeit, Vertrauen oder Beschaffung? Wähle ein Primärrisiko.
2. Wessen Verhalten kann sie klären? Benenne das kleinste erreichbare Segment mit Problem und Handlungsmacht.
3. Was ist die kleinste vollständige Schleife? Definiere Einstieg, Ergebnis und den für den Nutzer klaren nächsten Schritt.
4. Welcher Fehler würde den Test entwerten? Macht ein Berechtigungsfehler, eine falsche Antwort, eine langsame Reaktion oder ein kaputter Handoff die Ablehnung mehrdeutig, gehört er in die Glaubwürdigkeitsschwelle.
5. Welches sichtbare Ereignis ändert die nächste Entscheidung? Zehn bezahlte Piloten, 40 Prozent wöchentliche Wiederkehr, ein unterschriebener Beschaffungsschritt oder ein anderer vor dem Launch vereinbarter Schwellenwert.
6. Was bauen wir bewusst nicht? Leg den Feature-Friedhof neben den Scope. KI macht Wiederauferstehung gefährlich billig.

Die Reihenfolge zählt. Fragt ein Team zuerst, was es diese Woche generieren kann, entsteht eine Output-Liste. Beginnt es mit dem Geschäftsrisiko, kann es entscheiden, welcher Output überhaupt existieren darf.

Wann reicht weiterhin ein Prototyp?

Nutze einen Prototyp, wenn das Publikum den Experimentcharakter versteht und die Frage kein echtes Vertrauen verlangt. Ein klickbarer Flow für fünf Kundeninterviews, ein technischer Spike, ein Fake-Door-Test oder eine interne Demo dürfen rau sein, weil niemand davon abhängen soll.

Mach daraus nicht stillschweigend Produktion, nur weil das Demo gut lief. Sobald echtes Geld, Kundendaten, operative Abhängigkeit oder Markenvertrauen in die Schleife kommen, hat das Artefakt einen anderen Job. Unser Leitfaden vom Lovable- oder Cursor-Prototyp zur Produktion zeigt die Engineering-Arbeit in diesem Wechsel.

Was sollten Gründer von einem Entwicklungspartner verlangen?

„Wir können das bauen“ ist Grundvoraussetzung. Wertvoller sind die schwierigeren Fragen:

• Sollte das überhaupt gebaut werden?
• Welches Geschäftsrisiko soll diese Version klären?
• Was ist der billigste ehrliche Test vor Individualsoftware?
• Welcher Teil braucht am ersten Tag produktionsreifes Engineering?
• Was darf manuell bleiben, bis Nutzer seine Bedeutung beweisen?
• Welche Evidenz lässt uns stoppen, weitermachen oder mehr investieren?

Discovery, Product Leadership, individuelle Softwareentwicklung, KI-Integration und QA hängen zusammen. Sie sind nicht derselbe Job. Wer daraus einen generischen „Baut mir ein MVP“-Auftrag macht, bekommt einen schnellen Prototyp und ein langsames Geschäft.

Ein ernsthafter Partner sollte den Scope verkleinern, bevor er das Angebot vergrößert. Er muss erklären können, welche Abkürzungen bewusst sind, welche Risiken blockiert werden und was Release eins beweisen soll. Das ist der Standard hinter unserer MVP-Entwicklung: Software, die live geht und verkauft, nicht bloß demonstriert.