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. 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. Sauberes Handwerk sagt eben nichts darüber aus, ob am Ende jemand etwas davon hat. Diese Frage stellt keine Pipeline.

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. Eine Annahme wird mit dem billigsten sinnvollen Versuch konfrontiert, bevor das Team sie als Feature ausbaut. Darum geht es in diesem Artikel.

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 Größe der Übergabe. Bevor ein Team ein großes oder schwer umkehrbares Vorhaben in Delivery bindet, sollte die riskanteste Annahme dahinter geprüft sein. Kleine technische Spikes und dünne, reversible Schnitte dürfen früher in Delivery laufen und selbst Evidenz erzeugen. Dual Track ist keine harte Schleuse zwischen Denken und Bauen.

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. Teams, die das gut machen, setzen Produktverantwortung, Design und Engineering gemeinsam an die 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 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

Auf die Frage, warum ein bestimmtes Feature gebaut werden soll, kommt in Diskussionen meist eine Antwort, die nur eine einzige Dimension abdeckt. Cagan hat in der zweiten Auflage von INSPIRED vier Risikoklassen benannt, die jede ernsthafte Discovery abklopfen muss:

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.

Feasibility zieht die Aufmerksamkeit an, weil es 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 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]

Diesen Zustand lege ich versioniert im Repository ab, statt ihn an ein Whiteboard zu heften. Ein Assumption-Register neben dem Code macht die Wetten Teil des Projekts und 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"

Für einen bestätigenden Test ist kill_criterion das entscheidende Feld. Wer erst nach dem Test entscheidet, was ein gutes Ergebnis gewesen wäre, findet leicht eine Erklärung, warum die Lieblingsidee doch gewonnen hat. Explorative Discovery darf offener beginnen; sobald eine konkrete Hypothese entschieden werden soll, gehört das Kriterium vorher festgeschrieben.

Fortschritt heißt validiertes Lernen, nicht ausgelieferte Features

Eric Ries hat in The Lean Startup den Begriff geprägt, an dem ich mich bis heute ausrichte: validated learning. Fortschritt misst sich an Annahmen, die wir belastbar geklärt haben, und nicht an Features im Release. 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 dieses Tests zeigt sich in dem Moment, in dem er 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

Der naheliegende Einwand lautet: "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, baut sich am Ende die effizienteste Art, 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 einen passenden Versuch; ein bestätigender Test erhält ein vorab definiertes Entscheidungskriterium. Technische Wetten werden als Fitness Function oder Spike geprüft, nicht als Bauchgefühl abgenickt. Solange die größte Unsicherheit offen ist, bleibt die Delivery-Investition klein und umkehrbar.

Das klingt nach mehr Arbeit vorne. In der Praxis kann es große Umwege verkürzen, garantiert sie aber nicht. Die Teams, mit denen ich so arbeite, streiten weniger über Meinungen und mehr über Evidenz. Eine Landingpage mit zweihundert Besuchern kann ein Signal liefern, wenn Zielgruppe, Traffic-Quelle und erwarteter Effekt dazu passen; sie ersetzt weder sauberes Stichprobendesign noch qualitative Rückfragen. Was dabei verschwindet, ist ein Teil der unproduktiven Reibung zwischen Meinungen ohne Daten. Die produktive Reibung am Problem bleibt.

Fazit

Die erste Zeile Produktionscode erhöht die Investition, ist aber kein unumkehrbarer Grenzübertritt. Product Discovery hält die riskantesten Entscheidungen so lange klein, bis es genug Evidenz für den nächsten Einsatz gibt. Discovery und Delivery laufen dabei parallel: Die eine Spur klärt, was zu bauen ist, die andere liefert kleine, belastbare Schritte und kann selbst Teil des Experiments sein.

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 prüft und für bestätigende Tests ein Entscheidungskriterium festlegt, verbessert die Chance auf kürzere Lernzyklen und begründete Entscheidungen. Discovery bleibt Arbeit; ihr Wert liegt darin, teure Gewissheit nicht mit unbelegter Zuversicht zu verwechseln.

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

Wie fandest du diesen Beitrag?

Kommentare