Das MVP ist tot. Bau ein Minimum Credible Product.

Ist das MVP tot? Die Lernmethode nicht. Die Ausrede schon. KI macht Prototypen drastisch einfacher. Deshalb lesen Nutzer, Investoren und Käufer ein grobes Produkt nicht mehr automatisch als Beweis für Tempo. Immer häufiger lesen sie darin: Dieses Team hat den einen wichtigen Pfad weder getestet noch priorisiert oder fertiggebaut.

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 beschreibt es als die einfachste Version, mit der der Lernprozess schnell beginnt: zentrale Geschäftsannahmen mit echten Nutzern testen, bevor große Ressourcen gebunden werden.

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

Als Software teuer war, signalisierte sichtbare Rauheit eine echte Einschränkung. Eine einfache Oberfläche und ein manueller Ablauf konnten sagen: Das Team investiert seine knappe Engineering-Zeit in die wichtigste Annahme. Heute entstehen eine polierte Oberfläche, eine API, ein Datenbankschema, Tests und ein Deployment in Tagen. Dieselbe Rauheit sendet deshalb ein anderes Signal: Wenn schon die billige, sichtbare Schicht unfertig ist, wie sieht dann der unsichtbare Rest aus?

KI hat den sozialen Vertrag rund um frühe Software verändert:

• Nutzer erwarten einen vollständigen Kernpfad. Sie haben zu viele Alternativen, um aus Sympathie dein Onboarding zu debuggen.
• Investoren erwarten, dass ein Demo einfache Rückfragen überlebt. Ein generiertes Dashboard ist allein kein technischer Fortschrittsbeweis mehr.
• Enterprise-Käufer setzen die Schwelle höher. Berechtigungen, Datenverarbeitung, Auditierbarkeit, Integrationen und Ownership kommen im Pilotgespräch, nicht danach.
• Gründer erwarten mehr Output von kleineren Teams. Ob fair oder nicht: Diese Erwartung verändert, was ein frühes Produkt vermitteln muss.

Die Kosten für Code sind gefallen. Die Kosten, ernst genommen zu werden, sind gestiegen.

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.

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.

Auch die Produktivitätsdaten sind weniger spektakulär als der Feed. GitHub berichtete, dass Copilot-Nutzer eine kontrollierte Coding-Aufgabe bis zu 55 Prozent schneller abschlossen. In einem völlig anderen Setting stellte METR 2025 fest, dass erfahrene Open-Source-Entwickler in vertrauten, reifen Repositories mit den damaligen Tools länger brauchten. Das METR-Update von 2026 sah Anzeichen für Verbesserungen durch neuere Agenten, erklärte aber auch, warum eine saubere Messung schwieriger geworden ist.

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.

Die DORA-Forschung von Google Cloud zieht die nützlichere organisatorische Schlussfolgerung: KI verstärkt das System um sie herum. Starke Teams verwandeln schnelleren Output in bessere Lieferung. Schwache Produktdisziplin verwandelt denselben Output in mehr Instabilität und mehr Software, die niemand brauchte.

"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, 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.