Discovery Sprint

Ein Discovery Sprint ist ein kurzer, streng begrenzter Arbeitsabschnitt in der Produktentwicklung. Ein kleines Team nimmt sich eine offene Frage vor und beantwortet sie in wenigen Tagen. Typisch ist eine Woche, manchmal auch nur drei Tage. Die Frage lautet nicht „Wie bauen wir das?“, sondern „Sollten wir das überhaupt bauen?“. Am Ende steht keine fertige Software, sondern eine Entscheidung: weitermachen, umbauen oder verwerfen. Das Wort Sprint betont dabei den festen Zeitrahmen, nicht die Hektik.

Warum sich eine Woche Bremsen auszahlt

Der teuerste Fehler in der Softwareentwicklung ist ein Produkt, das niemand braucht. Ein Team kann sechs Monate sauber arbeiten und trotzdem am Ziel vorbeibauen. Solche Monate kosten Gehälter, Serverkosten und vor allem Zeit, die die Konkurrenz nutzt. Ein Discovery Sprint verschiebt die unangenehme Frage nach dem Nutzen an den Anfang. Dort ist eine falsche Antwort billig.

Besonders wichtig ist das bei KI-Funktionen. Viele Unternehmen wollen gerade irgendetwas mit Sprachmodellen bauen, also mit Programmen wie ChatGPT, die Texte erzeugen. Ob Kunden diese Funktion aber wirklich benutzen würden, weiß vorher niemand. Ein Sprint macht aus dieser Vermutung eine überprüfbare Aussage.

Für Investoren und Manager hat das noch einen zweiten Nutzen. Ein Discovery Sprint erzeugt ein sichtbares Zwischenergebnis nach kurzer Zeit. Man muss also nicht ein Jahr lang auf Vertrauen setzen, sondern kann früh nachsteuern.

Der Ablauf von der Frage bis zum Nutzertest

Am Anfang steht eine scharf formulierte Annahme. Ein Beispiel: „Kleine Handwerksbetriebe würden monatlich 30 Euro zahlen, damit eine KI ihre Angebote schreibt.“ Diese Annahme ist konkret genug, um falsch sein zu können. Genau das ist der Punkt. Vage Ziele wie „besseres Kundenerlebnis“ taugen nicht als Sprint-Frage.

Danach sammelt das Team Lösungsideen, meist erst einzeln, dann gemeinsam. Aus den Ideen wählt es eine aus und baut einen Prototyp. Ein Prototyp ist eine Attrappe: eine anklickbare Bildschirmfolge, die aussieht wie eine App, aber innen leer ist. Manchmal sitzt sogar ein Mensch hinter der vermeintlichen KI und tippt die Antworten. Diese Attrappe entsteht in ein bis zwei Tagen statt in Monaten.

Der letzte Tag gehört den Nutzern. Fünf bis sechs Personen aus der Zielgruppe bekommen den Prototyp und lösen damit eine echte Aufgabe. Das Team beobachtet, wo sie stocken und was sie ignorieren. Fünf Testpersonen wirken wenig, decken aber erfahrungsgemäß die meisten groben Probleme auf. Wichtig ist die Trennung: Ein Discovery Sprint klärt das Ob, ein normaler Entwicklungssprint danach das Wie.

Discovery Sprints in Startups und Konzernen

Populär gemacht hat das Format Google Ventures um 2016 unter dem Namen Design Sprint. Heute nutzen es Startups, Banken, Versicherungen und Agenturen. In Stellenanzeigen für Produktmanagerinnen oder UX-Designer taucht der Begriff regelmäßig auf. Auch Beratungen verkaufen Discovery Sprints als eigenständiges Angebot, meist als Paket über eine Woche.

In Wirtschaftsmeldungen begegnet dir das Format eher indirekt. Wenn ein Unternehmen erklärt, es habe eine KI-Idee „nach ersten Nutzertests eingestellt“, steckt oft genau so ein Vorgehen dahinter. Umgekehrt gilt ein Sprint, der eine Idee bestätigt, intern als Argument für Budget.

Ein verbreiteter Irrtum ist, ein Discovery Sprint spare Entwicklungsarbeit. Das tut er nicht. Er verhindert nur die falsche Entwicklungsarbeit. Und er funktioniert schlecht, wenn die Chefetage die Entscheidung längst getroffen hat und den Sprint nur als Bestätigung erwartet.