Product Discovery vor der ersten Zeile Code

Die teuersten Zeilen Code, die ich in Projekten gesehen habe, waren technisch tadellos. Sauber getestet, elegant strukturiert, in einer Continuous-Delivery-Pipeline mehrmals am Tag ausgeliefert. Das Problem war nur: Sie lösten ein Problem, das niemand hatte. Ein halbes Jahr Entwicklungskapazität, ein makelloses Feature, und beim ersten echten Nutzerkontakt kippte die Grundannahme. Das ist die unbequeme Wahrheit hinter jeder Effizienzdebatte: Ein Team kann alles richtig bauen und trotzdem das Falsche liefern.

Genau hier setzt Product Discovery an. Und ich meine damit nicht eine vorgeschaltete Analysephase, in der sechs Wochen lang Dokumente entstehen, bevor irgendjemand Code anfassen darf. Ich meine eine parallele, kontinuierliche Spur, die Unsicherheit abbaut, bevor teure Engineering-Kapazität gebunden wird. In diesem Artikel geht es um das Konzept dahinter, um eine Methodik, die im Alltag trägt, und vor allem um das Business-Outcome: kürzere Zyklen, weniger Reibung, höhere Qualität der Entscheidungen. Nicht mehr Prozess, sondern weniger Verschwendung.

Discovery und Delivery sind zwei Spuren, keine Phasen

Der häufigste Denkfehler ist, Discovery als Vorstufe zu begreifen. Erst denken, dann bauen. Das ist Wasserfall im neuen Gewand. Der Ansatz, den Marty Cagan und Jeff Patton unter dem Begriff Dual-Track Agile popularisiert haben, meint etwas anderes: zwei Spuren, die dauerhaft nebeneinanderlaufen. Die Discovery-Spur klärt, was gebaut werden sollte. Die Delivery-Spur baut es solide. Beide laufen in jedem Sprint, nicht nacheinander.

Der Trick liegt in der Übergabe. Nichts wandert in die Delivery-Spur, bevor es in der Discovery-Spur validiert wurde. Ein Backlog-Item ist erst dann "ready", wenn die riskanteste Annahme dahinter geprüft ist. So sieht das im Bild aus:

flowchart LR
  subgraph Discovery
    A[Idea] --> B[Assumption]
    B --> C[Experiment]
    C --> D[Validated item]
  end
  subgraph Delivery
    E[Build] --> F[Test]
    F --> G[Release]
  end
  D -->|only validated work<br/>enters delivery| E

Der Pfeil in der Mitte ist die eigentliche Botschaft. Er ist ein Filter. Alles, was ihn passiert, hat eine Prüfung bestanden. Alles, was in der Discovery-Spur scheitert, hat nie ein Entwicklerteam belastet. Das ist der Hebel: Ein verworfenes Experiment kostet Stunden, ein verworfenes Feature kostet Monate.

Ebenso wichtig ist, wer Discovery betreibt. Es ist keine Aufgabe, die eine vorgelagerte Analyseabteilung erledigt und dann als fertige Spezifikation weiterreicht. In den Teams, die das gut machen, sitzen Produktverantwortung, Design und Engineering gemeinsam an der Discovery-Spur – das Trio, das Marty Cagan beschreibt. Der Entwickler, der die Machbarkeit einschätzt, hört im selben Nutzergespräch, warum ein Feature überhaupt gewünscht ist. Die Designerin, die einen Prototyp baut, versteht die technischen Grenzen aus erster Hand. Diese geteilte Verantwortung ist kein organisatorisches Detail, sondern der Grund, warum Discovery schnell bleibt: Entscheidungen fallen dort, wo das Wissen sitzt, ohne den Umweg über Übergabedokumente. Wer Discovery an eine einzelne Rolle delegiert, holt sich die Wasserfall-Dynamik zurück, die der Dual-Track-Ansatz gerade vermeiden will.

Die vier großen Risiken, die Discovery adressiert

Wenn ich in Beratungsmandaten frage, warum ein bestimmtes Feature gebaut werden soll, bekomme ich meistens eine Antwort auf genau eine Dimension. Cagan hat in der zweiten Auflage von INSPIRED vier Risikoklassen benannt, die jede ernsthafte Discovery abklopfen muss. Ich halte sie mir bei jeder Idee vor:

Value-Risiko fragt, ob Nutzer das überhaupt wollen und ob sie dafür wechseln oder zahlen. Usability-Risiko fragt, ob sie es bedienen können. Feasibility-Risiko fragt, ob wir es mit unserer Zeit, unseren Daten und unserer Technik bauen können. Und Viability-Risiko fragt, ob es zum Geschäft passt – rechtlich, wirtschaftlich, strategisch.

Die meisten Teams sind unbewusst auf feasibility fixiert, weil das die Frage ist, die Entwickler am liebsten beantworten. "Können wir das bauen?" ist fast immer mit "ja" zu beantworten. Die teuren Fehlschläge sitzen aber im Value- und im Viability-Risiko. Discovery zwingt dazu, alle vier zu betrachten, bevor die erste Story geschnitten wird.

Annahmen sichtbar und priorisierbar machen

Der praktischste Schritt, den ich Teams beibringe, ist banal und wirkungsvoll zugleich: Annahmen aufschreiben. Jede Produktidee ist ein Stapel unausgesprochener Wetten. "Nutzer wollen ihre Reports selbst konfigurieren." "Die Bezahl-API hält unsere Latenz-Anforderung." "Der Vertrieb kann das ohne Schulung verkaufen." Solange diese Sätze im Kopf bleiben, kann man sie nicht testen und nicht priorisieren.

David J. Bland hat mit dem Assumptions Mapping ein einfaches Werkzeug etabliert: eine Matrix aus zwei Achsen. Die eine Achse misst, wie wichtig eine Annahme ist – fällt das ganze Vorhaben, wenn sie falsch ist? Die andere misst, wie viel Evidenz wir schon haben. Der Quadrant oben rechts, wichtig und kaum belegt, wird zuerst getestet. Das ist die riskanteste Annahme, und sie verdient den ersten Test.

quadrantChart
  title Assumptions Map
  x-axis Low evidence --> High evidence
  y-axis Low importance --> High importance
  quadrant-1 Test first
  quadrant-2 Keep as leap of faith
  quadrant-3 Ignore for now
  quadrant-4 Already known
  Users self-configure reports: [0.2, 0.9]
  Payment API meets latency SLA: [0.35, 0.85]
  Sales can sell without training: [0.6, 0.4]
  Login flow is usable: [0.8, 0.3]

Ich mag es, diesen Zustand nicht nur an ein Whiteboard zu heften, sondern versioniert im Repository abzulegen. Ein Assumption-Register neben dem Code macht die Wetten Teil des Projekts, nicht Teil eines vergessenen Workshops:

# assumptions.yaml — reviewed before any story enters delivery
assumptions:
  - id: A-1
    statement: "Users will self-configure their reports instead of asking support"
    type: desirability
    importance: high
    evidence: low
    test: landing-page
    kill_criterion: "signup-to-config rate below 20% after 200 visitors"
  - id: A-2
    statement: "The payment API stays under our latency budget at peak load"
    type: feasibility
    importance: high
    evidence: low
    test: spike
    kill_criterion: "p95 response time above 200ms in a load test"
  - id: A-3
    statement: "Sales can close the feature without extra training"
    type: viability
    importance: medium
    evidence: low
    test: interview
    kill_criterion: "3 of 5 reps ask for a dedicated enablement session"

Das entscheidende Feld ist kill_criterion. Ein Experiment ohne vorher festgelegtes Abbruchkriterium ist kein Experiment, sondern eine Bestätigungssuche. Wer erst nach dem Test entscheidet, was ein gutes Ergebnis gewesen wäre, findet immer eine Erklärung, warum die Lieblingsidee doch gewonnen hat. Das Kriterium vorher festzuschreiben, ist der Unterschied zwischen echtem Lernen und teurer Selbstbestätigung.

Fortschritt heißt validiertes Lernen, nicht ausgelieferte Features

Eric Ries hat in The Lean Startup den Begriff geprägt, der mir bis heute als Kompass dient: validated learning. Fortschritt misst sich nicht an Features im Release, sondern an Annahmen, die wir belastbar geklärt haben. Der Build-Measure-Learn-Kreis dreht sich um genau diese Frage: Was ist der schnellste Weg, um eine Wette zu prüfen?

Hier lauert das größte Missverständnis rund um das MVP. Ein Minimum Viable Product ist kein billiges, halbfertiges Produkt. Es ist das Experiment mit dem größten Lernertrag pro Aufwand. Sehr oft enthält es gar keinen Code. Eine Landingpage, die ein noch nicht existierendes Feature bewirbt und Anmeldungen zählt. Ein Concierge-Ansatz, bei dem ein Mensch manuell tut, was später Software tun soll. Ein Demo-Video, das die Reaktion misst. Für die Annahme A-1 oben ist die Landingpage schneller und ehrlicher als jede Implementierung. Sie beantwortet die Value-Frage in Tagen statt in Monaten.

Wenn das Ergebnis eindeutig gegen die Annahme spricht, ist die richtige Reaktion nicht, trotzdem zu bauen. Es ist der Pivot – die Richtung ändern und eine andere Wette angehen. Das fällt Teams schwer, weil verworfene Ideen sich wie Scheitern anfühlen. Sie sind das Gegenteil. Jede früh gekippte Annahme ist eingespartes Kapital.

Auch technische Annahmen gehören getestet

Discovery ist kein reines Produkt- oder UX-Thema. Das Feasibility-Risiko ist oft die stillste und teuerste Wette. "Die Bezahl-API hält unsere Latenz" ist eine technische Annahme, die man greifbar machen kann, bevor ein Feature darauf aufbaut. Ich formuliere solche Annahmen als ausführbaren Test – eine Fitness Function im Sinne von Building Evolutionary Architectures. Sie macht ein Qualitätsziel messbar und wiederholbar:

// fitness function — runs the riskiest technical assumption as a test
import { measureP95 } from "./load-harness";

const SLA_MS = 200;

test("checkout endpoint stays under the latency budget at peak load", async () => {
  const p95 = await measureP95({
    endpoint: "/api/checkout",
    concurrentUsers: 500,
    durationSeconds: 60,
  });

  expect(p95).toBeLessThan(SLA_MS);
});

Der Wert liegt nicht im grünen Häkchen, sondern in dem Moment, in dem der Test rot wird, bevor ein Feature live geht. Dann wissen wir: Die technische Annahme trägt nicht. Besser jetzt als in der Produktion. Dieselbe Denkweise gilt für Ausfallverhalten. Wenn ein Feature von einem externen Dienst abhängt, ist die Annahme "der Dienst ist verfügbar" eine Wette, die man mit Stabilitätsmustern wie einem Circuit Breaker aus Michael Nygards Release It! entschärft – und mit Consumer-Driven Contract Tests, die prüfen, ob zwei Dienste sich noch verstehen, bevor der Bruch in Produktion auffällt.

Warum Effizienz allein nicht schützt

An dieser Stelle kommt fast immer der Einwand: "Wir liefern doch schon schnell und stabil aus." Und ja, das ist wertvoll. Das Buch Accelerate von Nicole Forsgren, Jez Humble und Gene Kim hat mit vier Kennzahlen gezeigt, wie sich Auslieferungsqualität messen lässt: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Restore. Teams, die hier stark sind, liefern häufig, schnell und mit wenig Fehlern.

Nur misst keine dieser Kennzahlen, ob das Richtige gebaut wird. Sie messen, wie gut die Delivery-Spur läuft. Ein Team mit Bestwerten kann mit hoher Frequenz Features ausliefern, die niemand braucht. Tempo beim Bauen des Falschen ist immer noch Verschwendung – nur schnellere. Deshalb gehören beide Spuren zusammen: Discovery sorgt dafür, dass wir am Richtigen arbeiten, Delivery-Exzellenz sorgt dafür, dass wir es gut bauen. Wer nur die zweite Hälfte optimiert, wird zum effizientesten Weg, Geld zu verbrennen.

Genau das ist der ökonomische Kern. Discovery ist keine zusätzliche Prozessschicht, die Zyklen verlangsamt. Sie verkürzt den Zyklus, der wirklich zählt: von der Idee bis zur validierten Erkenntnis. Ein Landingpage-Test dauert Tage. Ein fehlgeleitetes Feature dauert Monate und fällt trotzdem. Discovery tauscht die teure, späte Rückmeldung des Marktes gegen eine billige, frühe Rückmeldung im Experiment.

Wie das im Alltag konkret aussieht

Ich fasse die Methodik in wenige Gewohnheiten, die ohne schweres Framework auskommen. Vor jedem größeren Vorhaben werden die Annahmen aufgeschrieben und auf der Zwei-Achsen-Matrix eingeordnet. Die riskanteste Annahme bekommt ein Experiment mit vorab definiertem Abbruchkriterium. Technische Wetten werden als Fitness Function oder Spike geprüft, nicht als Bauchgefühl abgenickt. Und nichts wandert in die Delivery-Spur, solange die größte Unsicherheit nicht geklärt ist.

Das klingt nach mehr Arbeit vorne. In der Praxis ist es weniger Arbeit insgesamt, weil die großen Umwege ausbleiben. Die Teams, mit denen ich so arbeite, streiten weniger über Meinungen und mehr über Evidenz. Diskussionen, die früher endlose Meetings füllten, entscheidet ein Test mit zweihundert Besuchern in einer Woche. Das ist die Reibung, die verschwindet: nicht die produktive Reibung am Problem, sondern die unproduktive Reibung zwischen Meinungen ohne Daten.

Fazit

Die erste Zeile Code ist eine Verpflichtung. Ab ihr kostet jede Änderung Zeit, jede Annahme wird zu Ballast, jeder Irrtum wird teuer. Product Discovery verschiebt die riskantesten Entscheidungen vor diesen Punkt, an dem sie noch billig sind. Discovery und Delivery laufen dabei parallel, nicht nacheinander – die eine Spur klärt, was zu bauen ist, die andere baut es solide, und nur validierte Arbeit passiert den Filter dazwischen.

Der rote Faden ist einfach: Man kann alles technisch richtig machen und trotzdem das Falsche liefern. Effizienz in der Auslieferung ist notwendig, aber sie ist kein Ersatz für die Frage, ob wir am Richtigen arbeiten. Wer Annahmen sichtbar macht, die riskanteste zuerst testet und ein Abbruchkriterium vorher festlegt, kauft sich kürzere Lernzyklen, weniger Verschwendung und Entscheidungen, die auf Evidenz statt auf Meinung ruhen. Das ist kein Prozess-Overhead. Das ist die eleganteste Art, teure Fehler zu vermeiden, bevor sie entstehen.

Weiterführende Quellen

• Marty Cagan: INSPIRED (2. Auflage, 2017) und die "four big risks" auf svpg.com/four-big-risks
• Jeff Patton und Marty Cagan zu Dual-Track Agile, jpattonassociates.com und svpg.com
• Eric Ries: The Lean Startup (2011), Build-Measure-Learn und MVP, theleanstartup.com
• David J. Bland: Assumptions Mapping, precoil.com und strategyzer.com
• Nicole Forsgren, Jez Humble, Gene Kim: Accelerate (2018)
• Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures (2017)
• Michael Nygard: Release It! zu Circuit Breaker und Stability Patterns

Kommentare