Ein Design Sprint presst Monate von Hin-und-Her in fünf Tage. LEGO hat ihn in einem einzigen Jahr 150 Mal eingesetzt, um einen kreativen Prozess zu reparieren, der ein Jahrzehnt lang feststeckte. Die Methode selbst ist einfach genug, um sie auf einer Seite zu erklären — auch wenn die Disziplin, einen wirklich durchzuführen, schwieriger ist. Wenn dein Unternehmen versucht, eine große Idee zu testen, bevor es Monate damit verbringt, sie zu bauen, ist das es wert zu verstehen.
Die Geschichte dahinter
Vor einigen Jahren lief LEGOs interne Kreativagentur seit etwa einem Jahrzehnt auf dieselbe Weise — und hielt nicht mehr Schritt. Anstatt schrittweise zu wechseln, tat die Person, die die Agentur leitete, etwas Drastisches: Die Produktion wurde 2017 für zwei Monate gestoppt — von April bis Juni — und ein großer Teil der internen Agentur legte die reguläre Arbeit beiseite, um stattdessen Design Sprints durchzuführen, wie die Person, die den Rollout leitete, später beschrieb.
In der ersten Woche liefen zehn Sprints gleichzeitig. Am Ende der zweimonatigen Pause hatten sie etwa sechzig durchgeführt. Innerhalb eines Jahres hatten sie über 150 abgeschlossen. LEGO baute die Methode dauerhaft in die Arbeitsweise seiner internen Agentur ein und nutzte sie, um die gesamte Teamstruktur neu zu gestalten.
Das ist eine extreme Version der Methode. Die meisten Unternehmen müssen sie nie in diesem Ausmaß durchführen. Aber der Grund, warum LEGO so weit gegangen ist, ist es wert, darüber nachzudenken: Eine Idee richtig zu testen — bevor man sie baut — ist meistens schneller und günstiger, als nach Monaten der Entwicklung herauszufinden, dass sie nicht funktioniert.
Was ein Design Sprint wirklich ist
Ein Design Sprint ist eine Methode, eine neue Idee in wenigen Tagen statt Monaten zu testen — mit einem kleinen Team und einem strukturierten Prozess, um das Ziel zu definieren, Lösungen zu skizzieren und sie mit echten Menschen zu testen, bevor die eigentliche Entwicklung beginnt. Die Methode wurde von Jake Knapp während seiner Zeit bei Google entwickelt und später im Buch „Sprint" veröffentlicht, das er zusammen mit zwei Kollegen von Google Ventures geschrieben hat.
Der Punkt ist nicht, das eigentliche Produkt in fünf Tagen zu bauen. Es geht darum, gerade genug davon zu bauen — einen klickbaren Prototypen, ein Mockup, eine grobe Version — um es echten Menschen vorzulegen und zu sehen, wie sie reagieren. Du findest heraus, ob die Idee funktioniert, bevor du die Zeit und das Geld aufgewendet hast, das echte Ding zu bauen.
Wie die fünf Tage meistens ablaufen
Die genaue Struktur variiert je nachdem, wer ihn durchführt — aber die Kernform sieht so aus:
Tag 1 — Das Problem verstehen. Das Team richtet sich darauf aus, was es wirklich zu lösen versucht, und wählt einen spezifischen Teil davon aus, auf den es sich für die Woche konzentriert.
Tag 2 — Lösungen skizzieren. Jeder arbeitet zuerst alleine und skizziert seine eigenen Ideen — anstatt direkt in ein Gruppen-Brainstorming zu springen, das dazu neigt, denjenigen zu bevorzugen, der am lautesten redet.
Tag 3 — Entscheiden. Das Team überprüft alle Skizzen und wählt die stärksten Ideen aus, um damit voranzukommen — ohne endlose Debatten.
Tag 4 — Einen Prototypen bauen. Keine echte, funktionierende Software. Nur genug eines Mockups, um sich real anzufühlen und auszusehen, wenn jemand versucht, es zu nutzen. Das ist dasselbe Rapid-Prototyping-Prinzip hinter vielen guten Produktentscheidungen: das Kleinste bauen, das es dir ermöglicht, die Idee zu testen — nicht das Ganze.
Tag 5 — Mit echten Menschen testen. Das Team beobachtet eine Handvoll tatsächlicher Nutzer, die den Prototypen ausprobieren, und reagiert auf das, was sie sehen — nicht auf das, was sie sich erhofft hatten.
Am Freitagnachmittag weißt du, ob die Idee standhält — bevor eine einzige Zeile Produktionscode geschrieben wurde.
Wann das für ein wachsendes Unternehmen sinnvoll ist
Ein Design Sprint ist es wert durchzuführen, wenn du kurz davor stehst, eine Entscheidung zu treffen, bei der ein Fehler teuer wäre. Ein neues Feature, das Monate zum Bauen brauchen würde. Eine neue Produktrichtung, bei der du dir nicht vollständig sicher bist. Ein Redesign, das etwas berührt, auf das Kunden bereits angewiesen sind.
In all diesen Fällen ist das Aufwenden von fünf Tagen, um herauszufinden, ob die Idee tatsächlich funktioniert, eine günstige Versicherung gegen Monate des Bauens des Falschen — und es ist dasselbe Denken dahinter, häufige Product-Market-Fit-Fehler zu vermeiden, bevor du echtes Budget in eine Richtung investierst.
Wann es wahrscheinlich übertrieben ist
Nicht jede Entscheidung braucht fünf Tage und einen Raum voller Menschen. Wenn die Korrektur klein ist oder das Team die Antwort bereits kennt, fügt ein vollständiger Sprint nur Zeremonie hinzu, ohne viel Einblick zu liefern. Es ist auch nicht das richtige Tool, wenn das eigentliche Problem darin besteht, dass sich niemand noch darüber geeinigt hat, was das Unternehmen überhaupt zu erreichen versucht. Das ist eine andere Art von Gespräch — über Ziele und Prioritäten, nicht über das Testen einer spezifischen Idee.
Design Sprint vs. Discovery Workshop
Sie sind nicht dasselbe — auch wenn die Logik ähnlich ist. Ein Design Sprint beantwortet meistens eine enge Frage: Wird dieses spezifische Feature oder dieser Flow funktionieren, getestet mit einem Prototypen und einer Handvoll Nutzern? Ein Discovery Workshop beantwortet eine größere: Was sollten wir wirklich bauen — und in welcher Reihenfolge — bevor irgendetwas davon spezifiziert wird?
Stell dir einen Design Sprint als das Testen eines Ziegels vor — und einen Discovery Workshop als das Herausfinden, was du mit allen davon baust.
Wo das in unsere Arbeitsweise passt
Beide existieren, um die teure Frage zu beantworten, bevor du das Geld ausgegeben hast, es auf die harte Tour herauszufinden. Wenn du eine Idee hast, bei der du dir nicht vollständig sicher bist — und sie direkt zu bauen sich wie ein Risiko anfühlt, das du lieber nicht blind eingehen möchtest — ist ein Discovery Workshop genau für dieses Gespräch gebaut.
