Der Prozess, durch den Produktteams herausfinden, was gebaut werden soll — bevor sie es bauen. Unterschied zu klassischem “Requirements Engineering”: Discovery ist iterativ, kundengetrieben und endet nie. Sie ist kein Projektabschnitt, sondern eine dauerhafte Gewohnheit.

Das Problem mit einmaligem Research

Typisches Muster: Vor einem Launch gibt es einen “Discovery Sprint” — Interviews, Personas, Workshops. Dann wird gebaut. Dann ist das Discovery-Budget verbraucht. Das Ergebnis: Teams optimieren Produkte auf das Nutzerbild von vor sechs Monaten. Teresa Torres nennt das “batch discovery” — und es ist der Hauptgrund, warum Produktteams an Lösungen vorbeientwickeln.

Continuous Discovery (Torres-Methode)

Minimum: ein Kundeninterview pro Woche, pro Team. Nicht als Forschungsprojekt, sondern als Routine. Das erzwingt:

  1. Ein aktuelles, echtes Nutzerbild statt veralteter Personas
  2. Schnellere Kalibrierung von Hypothesen
  3. Besseres Gespür für Nuancen (die sich nur durch wiederholten Kontakt aufbauen)

Werkzeug: Opportunity Solution Tree (OST) — eine visuelle Struktur, die Outcome → Opportunities → Solutions → Experiments verbindet. Verhindert, dass Teams direkt von Nutzer-Feedback zu Lösungen springen.

Discovery unter AI-Druck

Mit KI-Tools wie Cursor und GitHub Copilot verschiebt sich die Frage: Wenn ein PM selbst bauen kann, braucht es dann das Engineering-Trio in der Discovery-Phase noch? Teresa Torres und Petra Wille argumentieren: Die Fähigkeit zum Bauen ersetzt nicht das Verständnis für was gebaut werden soll. Discovery bleibt menschlich — weil Nuancen in Kundengesprächen kein LLM verlässlich extrahiert.

Ihre aktualisierte Antwort auf die Rollenfrage ist Product Builder: weniger starre Übergaben zwischen PM, Design und Engineering, mehr gemeinsames Grundverständnis. Gerade deshalb wird Discovery wichtiger, nicht weniger wichtig. Wer schneller bauen kann, kann auch schneller am falschen Problem vorbeibauen.

Verbindungen

  • Teresa Torres — die zentrale Figur im modernen Discovery-Diskurs; ihr Buch ist der Ausgangspunkt
  • Petra Wille — trainiert Discovery-Praktiken in Product-Leadership-Kontexten
  • Product Builder — beschreibt die neue Rollenlogik, die unter AI-Druck aus Discovery heraus neu verhandelt wird
  • Lenny Rachitsky — publiziert regelmäßig empirische Daten über Discovery-Praktiken in Tech-Teams
  • AI Evals — Discovery-Haltung ist auch die richtige Grundlage für Eval-Design: beide beginnen mit echten Nutzerproblemen statt mit Annahmen

Quellen