Meine Arbeitsdefinition für ein MVP: lernen statt halb fertig liefern

Wer die Hälfte weglässt und das Ergebnis MVP nennt, hat kein Risiko gesenkt, sondern nur den Tag verschoben, an dem der Irrtum auffällt. Bauzeit ist verbraucht, ausgeliefert wurde etwas Halbes, und die teuerste Frage steht unverändert im Raum: Woher wissen wir, dass wir überhaupt das Richtige bauen?

Trotzdem hängt das Wort genau in dieser Bedeutung an Roadmaps, Ticket-Titeln und Budgetzeilen. Weniger Buttons, weniger Screens, weniger Backend – MVP ist zum höflichen Ausdruck für „das Produkt, aber schlechter“ geworden. Das reduzierte Feature-Set beantwortet keine einzige offene Frage. Es verwechselt Geschwindigkeit beim Bauen mit Geschwindigkeit beim Lernen.

Für meine Arbeit halte ich mich an die Lesart aus Lean Startup: Ein MVP ist ein Experiment, die kleinste Version eines Produkts, mit der sich eine konkrete, riskante Annahme ehrlich testen lässt. Der Begriff wird in der Praxis auch anders verwendet; diese Arbeitsdefinition ist meine bewusste Entscheidung. Aus ihr folgt, was hineingehört, was nicht, und warum der scheinbare Umweg über das Lernen der schnellste Weg zum tragfähigen Produkt sein kann.

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 für diese Arbeitsdefinition ein hartes Kriterium, das im Alltag fehlt: Ein MVP ohne definierte Lernfrage und ohne Metrik ist dann kein Experiment, sondern 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

Der Unterschied lässt sich an zwei Schnitten durch denselben geplanten Funktionsumfang zeigen.

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 MVP ist häufig ein vertikaler Schnitt: ein dünner, aber durchgehender Pfad vom Nutzer bis zum Wert, an dessen Ende eine Messung hängt. Bei Concierge-, Wizard-of-Oz- oder Landingpage-Experimenten kann die kleinste belastbare Prüfung jedoch anders aussehen. Entscheidend ist nicht die Form des Schnitts, sondern ob sie die riskante Annahme ehrlich prüft.

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 Trennung zum Prototyp, ohne daraus eine künstliche Mauer zu bauen. Ein Prototyp untersucht meist Machbarkeit oder Bedienbarkeit und kann dafür selbstverständlich mit echten Nutzern getestet werden. Ein MVP in meiner Arbeitsdefinition prüft dagegen eine Markt- oder Wert-Hypothese. Entscheidend sind Frage und Evidenz, nicht ob das Artefakt intern oder extern gezeigt wird.

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 den Projekten, in denen das getragen hat, stand die Hypothese vor der ersten Zeile Code – strukturiert, versioniert, neben dem Code im Repository statt 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. Am kill_criteria scheitert die Einigung am häufigsten, und genau darin liegt sein Wert: 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 wächst wochenlang in einem langen Feature-Branch neben dem Hauptstrang und landet irgendwann in einem großen, riskanten Merge. 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: Experimente, Metriken, Flags und Contracts aufzusetzen klingt nach mehr Arbeit, nicht nach weniger. Der Einwand verwechselt zwei Größen – Aufwand pro Auslieferung und Aufwand pro gelernter Erkenntnis.

„Accelerate“ von Forsgren, Humble und Kim liefert dafür einen Teil des technischen Fundaments. Die vier damaligen DORA-Metriken – Deployment Frequency, Lead Time for Changes, Change Fail Rate und Time to Restore – stehen für Lieferfähigkeit, nicht für den Marktwert eines Experiments. Ein Team, das kleine Änderungen häufig und stabil ausliefern kann, senkt jedoch die technische Hürde für kurze Versuche und schnelle Rücknahmen.

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 früher sichtbar. Das ist keine Garantie für weniger Reibung oder höhere Qualität. Es trennt aber die Frage „Können wir es liefern?“ von der wichtigeren Frage „Welche Annahme prüfen wir damit?“.

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. In meiner Arbeitsdefinition ist es ein Experiment, das eine riskante Annahme ehrlich testet – die kleinste Version, mit der man eine Hypothese wirklich prüfen kann. Ein bestätigender Test braucht eine Lernfrage und ein vorab festgelegtes Entscheidungskriterium; explorative Discovery darf offener beginnen. Häufig ist das ein vertikaler Schnitt bis zum Wert, manchmal ein Concierge-Test oder eine Landingpage. „Minimal“ meint den nötigen Umfang, nicht Nachlässigkeit. Und es muss nicht einmal Code sein.

Wenn ein Team von „das Produkt, aber weniger“ auf „die kleinste Version, die eine Annahme ehrlich testet“ umschwenkt, ändert sich nicht der Werkzeugkasten, sondern die Leitfrage. 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 verhindert keine Fehlentscheidung, macht aber sichtbar, welches Lernen die nächste Investition rechtfertigen soll.

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

Wie fandest du diesen Beitrag?

Kommentare