MVP heißt kleinstes lernendes Produkt, nicht halbfertig

In fast jedem Projekt, in das ich als Berater komme, ist das Wort MVP schon da. Es hängt an Roadmaps, an Ticket-Titeln, an Budgetzeilen. Und fast immer meint es dasselbe: die Version, in der wir die Hälfte weglassen. Weniger Buttons, weniger Screens, weniger Backend. Das MVP ist zum höflichen Wort für „das Produkt, aber schlechter" geworden.

Das ist ein teures Missverständnis. Nicht weil es unschön ist, sondern weil es die eigentliche Frage überspringt: Woher wissen wir, dass wir überhaupt das Richtige bauen? Ein MVP, das nur ein reduziertes Feature-Set liefert, beantwortet diese Frage nicht. Es liefert einfach früher etwas Halbfertiges aus – und verwechselt Geschwindigkeit beim Bauen mit Geschwindigkeit beim Lernen.

Ich möchte in diesem Artikel den Begriff zurückholen auf seine ursprüngliche Bedeutung. Ein MVP ist ein Experiment. Es ist die kleinste Version eines Produkts, mit der wir eine konkrete, riskante Annahme ehrlich testen können. Nicht mehr, nicht weniger. Und aus dieser einen Definition folgt fast alles Praktische: was hineingehört, was nicht, und warum der scheinbare Umweg über das Lernen der schnellste Weg zum tragfähigen Produkt ist.

Die Definition, die alles trägt

Eric Ries hat den Begriff 2011 in „The Lean Startup" so gefasst: ein MVP ist „that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." Der Kern steckt in zwei Wörtern: validated learning. Der Zweck ist Lernen, das durch echte Daten bestätigt wird, und zwar über die leap-of-faith assumptions – jene Annahmen, auf denen die ganze Idee ruht und die bisher niemand belegt hat.

Damit ist das MVP kein Auslieferungsschritt, sondern der Bau-Teil eines Experiments. Ries stellt es in den Build-Measure-Learn-Loop: Wir bauen etwas, messen die Reaktion, lernen daraus und entscheiden. Der Ausgang eines MVP ist immer eine Entscheidung, die Ries pivot or persevere nennt – Kurs halten oder Annahme verwerfen und drehen.

flowchart LR
  A[Riskante Annahme] --> B[Build:<br/>MVP als Experiment]
  B --> C[Measure:<br/>echte Nutzer, echte Metrik]
  C --> D[Learn:<br/>validated learning]
  D --> E{pivot or<br/>persevere?}
  E -->|persevere| A
  E -->|pivot| A

Daraus ergibt sich ein hartes Kriterium, das im Alltag fehlt: Ein MVP ohne definierte Lernfrage und ohne Metrik ist per Definition kein MVP. Es ist dann nur ein kleines Produkt. Der Unterschied ist nicht akademisch. Wenn niemand vorher aufgeschrieben hat, welche Annahme geprüft wird und woran man den Ausgang erkennt, kann das Ergebnis auch nichts widerlegen. Man baut, launcht, findet es „ganz okay" und macht weiter – gelernt hat man nichts.

Steve Blank formuliert die Gegenseite des Missverständnisses direkt. „A minimum viable product is not always a smaller/cheaper version of your final product." Sein Customer-Development-Ansatz kreist um einen einzigen Imperativ: get out of the building. Die Wahrheit über das Produkt steht nicht im Meetingraum, sie steht bei den Nutzern. Das MVP ist das Werkzeug, mit dem man rausgeht.

Vertikaler Schnitt statt horizontaler Amputation

Das Bild, das mir in Beratungen am meisten hilft, ist der Unterschied zwischen zwei Schnitten durch dieselbe Feature-Landschaft.

Der falsche MVP ist ein horizontaler Schnitt. Man nimmt alle geplanten Features und baut jedes zu vierzig Prozent. Das Registrierungsformular steht halb, die Suche liefert Ergebnisse ohne Filter, der Checkout endet in einer Sackgasse. Nichts funktioniert end-to-end. Der Nutzer kommt an keiner Stelle vom Anfang bis zum Wert. Es gibt nichts zu messen, weil es keinen vollständigen Pfad gibt, den jemand durchlaufen könnte.

Der echte MVP ist ein vertikaler Schnitt. Ein einziger, dünner, aber vollständig durchgehender Pfad vom Nutzer bis zum Wert – und an dessen Ende hängt eine Messsonde. Ein Feature, eine Nutzergruppe, ein klar definierter Erfolg, aber dieses eine Segment funktioniert wirklich.

flowchart TB
  subgraph L[Horizontal: halbfertig]
    L1[Feature A – 40%]
    L2[Feature B – 40%]
    L3[Feature C – 40%]
  end
  subgraph R[Vertikal: kleinstes lernendes Produkt]
    R1[Einstieg] --> R2[ein durchgehender Pfad] --> R3[Wert] --> R4[Metrik]
  end

Genau hier liegt die Bedeutung von „viable". Das Wort meint nicht die Qualität, es meint den Scope. Minimal ist der Umfang, nicht die Sorgfalt. Ein buggy zusammengeschusterter MVP verfälscht das Lernsignal, denn dann weiß man am Ende nicht, ob die Nutzer die Idee ablehnen oder nur die kaputte Umsetzung. „Viable" heißt: gut genug, um ein ehrliches Signal zu erzeugen. Der schmale Pfad muss sauber sein, sonst misst man Rauschen.

Das MVP muss kein Code sein

Der stärkste Beleg dafür, dass „viable" nicht „fertig gebaut" bedeutet, sind zwei MVP-Typen, die es lange vor 2018 gibt und die ganz ohne fertiges Produkt auskommen.

Beim Concierge-MVP erbringt zunächst ein Mensch die Leistung von Hand, die später Software erbringen soll. Man tut nicht so, als gäbe es ein Produkt – man liefert den Wert direkt und persönlich an eine Handvoll echter Nutzer und beobachtet, ob sie ihn überhaupt wollen. Beim Wizard-of-Oz-MVP sieht der Nutzer eine echte Oberfläche, aber dahinter arbeitet kein System, sondern ein Mensch, der die Antworten von Hand einträgt. Der Nutzer glaubt an Software, gelernt wird über echtes Verhalten, gebaut wurde fast nichts.

Beide testen eine Hypothese, bevor eine Zeile Produktionscode existiert. Sie beweisen die These auf die klarste Art: „viable" heißt genug, um ehrlich zu lernen, nicht genug, um zu verkaufen.

Wichtig ist dabei die saubere Trennung zum Prototyp. Ein Prototyp klärt intern eine Machbarkeits- oder Bedienbarkeitsfrage – funktioniert die Technik, versteht jemand die Navigation. Ein MVP testet eine Markt- oder Wert-Hypothese mit echten Nutzern draußen. Beide sind nützlich, aber sie beantworten verschiedene Fragen, und sie zu verwechseln kostet Wochen.

Die Hypothese als Code

Wenn ein MVP ein Experiment ist, dann sollte das Experiment so präzise deklariert sein, dass man es widerlegen kann. In der Praxis lasse ich Teams die Hypothese vor dem Bauen aufschreiben – idealerweise so strukturiert, dass sie neben dem Code lebt und nicht in einem vergessenen Slide.

# experiment.yaml – declares the MVP before any code is written
experiment:
  name: "concierge-checkout"
  riskiest_assumption: "users will connect a payment method to finish an order"
  hypothesis: "at least 30% of activated users will add a payment method"
  target_metric: activation_rate      # added payment / reached checkout
  success_threshold: 0.30
  kill_criteria: "activation_rate < 0.10 after 200 sessions"
  sample_size: 200
  cohort: "new signups, region DE"

Der entscheidende Punkt sind die letzten Felder. Ohne success_threshold und kill_criteria ist es kein Experiment. Ein Experiment, das man nicht scheitern lassen kann, misst nichts. Das kill_criteria ist unbequem, gerade deshalb ist es wichtig: es zwingt das Team, vorher zu vereinbaren, wann die Idee widerlegt ist – bevor die emotionale Bindung an die eigene Lösung das Urteil trübt. Ries nennt die Gegenspieler dieser ehrlichen Zahlen vanity metrics: Kennzahlen wie Gesamtregistrierungen, die immer nach oben zeigen und nie eine Entscheidung erzwingen. Der target_metric muss eine actionable metric sein, an der man eine Annahme kippen kann.

Den schmalen Pfad technisch sauber schneiden

Der vertikale Schnitt hat auch eine technische Seite, und hier verbinden sich zwei Welten, die oft getrennt diskutiert werden: Produktdenken und Delivery.

Der falsche MVP lebt gern in einem langen Feature-Branch, der wochenlang neben dem Hauptstrang wächst und irgendwann in einem großen, riskanten Merge landet. Der bessere Weg ist, das Experiment auf dem Trunk zu bauen und über ein Feature-Flag nur für die Experiment-Kohorte einzuschalten. Alle anderen sehen den Status quo, der schmale neue Pfad ist für eine kleine Gruppe vollständig live.

// the MVP path ships on trunk, gated by a flag – not hidden in a long branch
function renderCheckout(user, cart) {
  if (featureFlags.isEnabled("concierge_checkout", user)) {
    trackExperiment("concierge-checkout", user);
    return conciergeCheckout(cart); // narrow but complete path to value
  }
  return standardCheckout(cart);     // everyone else: unchanged status quo
}

Das ist mehr als ein technischer Trick. Es macht sichtbar, was ein MVP ist: ein schmales, aber vollständig funktionierendes Segment – nicht ein überall halb sichtbares, nirgends fertiges Feature. Trunk-Based Development und kurzlebige Branches sorgen dafür, dass das Experiment jederzeit ausgeliefert und ebenso schnell wieder abgeschaltet werden kann. Techniken wie Canary Release und Blue-Green Deployment geben demselben Prinzip die Betriebsseite: eine kleine Kohorte bekommt das Neue, der Rest bleibt sicher.

Wenn das Experiment über einen Service hinausgeht, hilft ein weiterer Winkel beim ehrlichen Testen. Statt eine Vollintegration vorzutäuschen, erfüllt der MVP-Service einen minimalen, aber echten Consumer-Driven Contract. Der Konsument schreibt auf, was er wirklich braucht, und der MVP erfüllt genau das – nicht mehr.

// consumer-driven contract: the MVP fulfils a real, minimal contract
// instead of faking a full integration
Pact.provider("payment-service").upon("checkout")
  .given("an activated user")
  .uponReceiving("a request to attach a payment method")
    .withRequest(method: "POST", path: "/methods")
  .willRespondWith(status: 201, body: [status: "attached"])

Der Sinn dahinter: Der schmale Pfad ist echt, nicht Fassade. Er integriert wirklich gegen das, was er braucht, aber eben nur gegen das. So bleibt das Lernsignal sauber, ohne dass man das ganze System fertig bauen muss.

Warum das schneller ist, obwohl es aufwendiger klingt

Der häufigste Einwand in Beratungen lautet: Das Aufsetzen von Experimenten, Metriken, Flags und Contracts klingt nach mehr Arbeit, nicht nach weniger. Der Einwand verwechselt zwei Dinge – Aufwand pro Auslieferung und Aufwand pro gelernter Erkenntnis.

Genau hier liefert „Accelerate" von Forsgren, Humble und Kim aus 2018 das technische Fundament. Die vier DORA-Metriken – Deployment Frequency, Lead Time for Changes, Change Fail Rate und Time to Restore – zeigen messbar, dass kleine Batches und schnelle Feedback-Schleifen mit hoher Leistung korrelieren. Das ist der ökonomische Kern: Wenn ein Team häufig, schnell und mit niedriger Fehlerrate ausliefert, wird jedes einzelne Experiment billig. Und wenn Experimente billig sind, kann man sie sich leisten, statt monatelang auf eine unbelegte Annahme zu wetten.

Ein MVP, das nur ein reduziertes Feature-Set ist, spart einmalig Bauzeit und verschiebt das Risiko nach hinten. Ein MVP als Experiment kostet vorne etwas Disziplin und macht das Risiko sofort sichtbar. Der Unterschied summiert sich brutal: Man baut nicht mehr das Falsche halbfertig, sondern das Nächste als kleinstes lernendes Segment. Verkürzte Zyklen, weniger Reibung, höhere Qualität – weil man die Sorgfalt in den einen schmalen Pfad steckt statt sie über zehn halbe Features zu verteilen.

Wer das MVP als Experiment ernst nimmt, denkt übrigens von Anfang an in Richtung tragfähiger Architektur. Ein Ansatz wie die evolutionary architecture mit fitness functions passt genau, weil er akzeptiert, dass sich das Produkt entlang dessen entwickelt, was man lernt – nicht entlang eines Plans, den niemand geprüft hat.

Fazit

Ein MVP ist kein amputiertes Produkt. Es ist ein Experiment, das eine riskante Annahme ehrlich testet – die kleinste Version, mit der man eine Hypothese wirklich prüfen kann. Aus dieser einen Definition folgt der Rest: Es braucht eine Lernfrage und eine actionable Metrik mit Schwelle und Abbruchkriterium, sonst ist es kein MVP. Es ist ein vertikaler Schnitt bis zum Wert, kein horizontaler über halbfertige Features. „Minimal" meint den Scope, nicht die Qualität. Und es muss nicht einmal Code sein.

Wenn ich Teams von „das Produkt, aber weniger" auf „die kleinste Version, die eine Annahme ehrlich testet" umstelle, ändert sich nicht der Werkzeugkasten, sondern die Frage. Nicht mehr „Was können wir noch weglassen?", sondern „Was müssen wir als Nächstes lernen, und wie sieht der kleinste ehrliche Test dafür aus?". Diese Frage ist einfach, fast unbequem einfach – und genau deshalb spart sie am Ende die meisten Monate.

Weiterführende Quellen

• Eric Ries, The Lean Startup (2011) – Definition des MVP, Build-Measure-Learn, validated learning, vanity vs. actionable metrics
• Steve Blank, „A minimum viable product is not always…" (Blog, 2013) und The Four Steps to the Epiphany (2005) – Customer Development
• Melissa Perri, „Finding the Truth Behind MVPs" (2016) – Concierge- und Wizard-of-Oz-MVP
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (2018) – die vier DORA-Metriken
• Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) – fitness functions
• Martin Fowler, „FeatureToggle" (2017) und trunkbaseddevelopment.com – Feature-Flags und Trunk-Based Development
• Consumer-Driven Contracts (Fowler/Robinson, 2006) sowie das Contract-Testing-Werkzeug Pact

Kommentare