Discovery vs. Delivery
Discovery vs. Delivery beschreibt die Trennung zweier Arbeitsweisen in der Produktentwicklung: herauszufinden, was gebaut werden sollte, und es anschließend sauber zu bauen. Beide Aufgaben brauchen unterschiedliche Methoden, unterschiedliche Fehlerkulturen und meist auch unterschiedliche Zeitpläne.
Wer ein digitales Produkt entwickelt, steht vor zwei sehr verschiedenen Fragen. Die erste lautet: Was soll überhaupt gebaut werden, und will das jemand haben? Die zweite lautet: Wie bauen wir das zuverlässig, schnell und ohne Fehler? Für die erste Frage hat sich der englische Begriff Discovery eingebürgert, also Entdecken oder Erkunden. Für die zweite Frage steht Delivery, also Ausliefern. Die Gegenüberstellung Discovery vs. Delivery erinnert Teams daran, dass beide Fragen nicht dasselbe sind und nicht mit denselben Methoden beantwortet werden.
Warum gute Software am falschen Problem scheitern kann
Ein Team kann technisch hervorragend arbeiten und trotzdem etwas völlig Nutzloses abliefern. Das passiert immer dann, wenn niemand geprüft hat, ob das gewünschte Feature ein echtes Problem löst. Sauberer Code an der falschen Stelle ist verschwendete Zeit. Genau davor soll die Trennung schützen.
In der Praxis wird das oft mit Zahlen unterlegt. Große Produktfirmen berichten, dass ein erheblicher Teil ihrer neuen Funktionen die erhoffte Wirkung verfehlt. Manche Studien nennen Größenordnungen um zwei Drittel. Ob die Zahl im Einzelfall stimmt, ist zweitrangig. Wichtig ist die Einsicht dahinter: Ideen sind billig, aber ihre Umsetzung ist teuer.
Für Firmen ist das auch eine Geldfrage. Ein Entwicklerteam kostet pro Monat einen sechsstelligen Betrag. Drei Monate an einer Funktion zu arbeiten, die niemand nutzt, ist eine teure Fehlinvestition. Ein paar Tage Discovery vorher kosten dagegen fast nichts. Deshalb taucht der Begriff auch in Quartalsberichten und Investorengesprächen auf, wenn es um Effizienz geht.
Zwei Spuren, die nebeneinander laufen
In der Discovery arbeitet man mit Annahmen. Man spricht mit Nutzern, baut grobe Klickattrappen und testet Ideen an wenigen Personen. Das Ziel ist nicht ein fertiges Produkt, sondern Erkenntnis. Fehler sind hier ausdrücklich erwünscht, denn ein früh verworfener Irrweg spart später Monate.
In der Delivery gilt das Gegenteil. Hier zählen Verlässlichkeit, Tests, Sicherheit und ein Zeitplan, auf den sich andere verlassen können. Fehler sind teuer, weil sie echte Nutzer treffen. Wer beide Haltungen im selben Meeting vermischt, bekommt entweder ängstliche Experimente oder schlampige Auslieferungen.
Der gängige Lösungsansatz heißt Dual Track. Beide Spuren laufen gleichzeitig im selben Team weiter, nicht nacheinander. Während die Entwickler an bereits geprüften Funktionen bauen, untersucht das Team die nächsten Ideen. Ein häufiger Irrtum ist, Discovery für eine einmalige Phase am Projektanfang zu halten. Tatsächlich ist sie ein Dauerbetrieb, weil Nutzer und Markt sich ständig ändern.
Der Begriff in Stellenanzeigen und KI-Projekten
Am häufigsten begegnet man den beiden Wörtern in Stellenausschreibungen. Wenn eine Firma eine Product Managerin mit Discovery-Erfahrung sucht, meint sie jemanden, der Nutzerinterviews führt und Ideen prüft. Auch in Projektberichten liest man Formulierungen wie Discovery-Sprint oder Delivery-Team. Dahinter steckt immer dieselbe Unterscheidung.
Bei KI-Produkten hat die Trennung besonderes Gewicht. Ob ein Sprachmodell für eine bestimmte Aufgabe gut genug ist, weiß man vorher nicht sicher. Man muss es ausprobieren, also gehört ein Prototyp klar in die Discovery. Erst wenn die Qualität überzeugt, lohnt es sich, an Skalierung, Kosten pro Anfrage und Datenschutz zu arbeiten. Viele gescheiterte KI-Pilotprojekte sind Delivery-Versuche ohne vorherige Discovery.
Abgrenzen sollte man den Begriff von agilen Methoden wie Scrum. Scrum organisiert vor allem die Delivery, also den Takt der Umsetzung. Discovery füllt die Lücke davor und beantwortet, womit dieser Takt sinnvoll gefüllt wird. Beide widersprechen sich nicht, sondern greifen ineinander.