Hackathon, Design Jam oder Innovation Challenge: was zu Ihrem Ziel passt
Hackathon zum Bauen, Design Jam zum Neudenken eines Service, Innovation Challenge zum Finden fertiger Löser. Vergleichstabelle und wann was passt.

Hackathon, Design Jam oder Innovation Challenge: was zu Ihrem Ziel passt
Wählen Sie einen Hackathon, wenn das Problem klar ist und Sie einen funktionierenden Prototyp brauchen, gebaut von Menschen, die programmieren oder bauen können. Wählen Sie einen Design Jam, wenn Sie noch nicht sicher sind, welcher Service oder welches Erlebnis das richtige ist, und es schnell mit echten Nutzern herausfinden müssen. Wählen Sie eine Innovation Challenge, wenn die Lösung vermutlich schon irgendwo existiert – bei einem Startup, in einem Labor oder bei einem Lieferanten – und Sie sie finden, testen und beauftragen müssen.
Anders gesagt: Ein Hackathon beantwortet „Können wir es bauen?“, ein Design Jam „Was sollten wir bauen?“ und eine Challenge „Wer hat es schon?“. Der Rest dieses Artikels zeigt, wie Sie erkennen, welche Frage Sie wirklich stellen. Für die ganze Familie der Formate siehe Hackathons, Jams und Challenges: alle Formate erklärt.
Der Vergleich auf einen Blick
| Hackathon | Design Jam | Innovation Challenge | |
|---|---|---|---|
| Kernfrage | Können wir es bauen? | Was sollten wir bauen? | Wer hat es schon? |
| Typische Dauer | 1–3 Tage | 1–2 Tage (48 Stunden bei globalen Jams) | 6 Wochen bis 6 Monate, in Phasen |
| Wer teilnimmt | Entwickler, Maker, Fachleute | Gemischt: Beschäftigte, Nutzer, Designer, keine Programmierkenntnisse nötig | Startups, Forschende, KMU, Lieferanten |
| Ausgangspunkt | Definiertes Problem und Zugang zu Systemen oder Daten | Ein Thema oder ein breites Serviceproblem | Eine veröffentlichte Challenge-Fragestellung |
| Ergebnis | Funktionierender Prototyp | Getesteter Service- oder Erlebnis-Prototyp | Mit Ihrer Organisation pilotierte Lösungen |
| Erzeugte Evidenz | Technische Machbarkeit | Attraktivität: Wollen Nutzer das? | Tragfähigkeit: Funktioniert es in unserem Umfeld? |
| Vorbereitung | Hoch: Daten, Sandboxes, Systemzugänge | Gering bis mittel: Nutzer zum Treffen, Raum, Material | Hoch: Vertragsbedingungen, IP, Bewertung, Pilotbudget |
| Größtes Risiko | Eine Demo, die niemand übernimmt | Konzepte, die niemand baut | Ein langer Prozess, der in einem Bericht endet |
| Beste Verantwortliche | Produkt- oder IT-Leitung mit Budget | Service- oder Customer-Experience-Leitung | Einkauf plus eine Fachbereichsverantwortliche |
Wann ein Hackathon passt
Ein Hackathon passt, wenn drei Dinge zutreffen. Das Problem ist konkret genug, um es in einem Satz zu benennen. Die Systeme, Daten oder Materialien sind verfügbar und freigegeben. Und es gibt jemanden, der das Ergebnis übernimmt und die nächste Phase finanziert.
Typische gute Einsätze: einen manuellen Schritt automatisieren, den alle als lästig empfinden, ein internes Tool auf Basis eines vorhandenen Datensatzes bauen, zwei Systeme verbinden, die miteinander sprechen sollten, oder testen, ob eine neue Technologie eine echte Last bewältigt. In jedem Fall ist die Ungewissheit technisch, nicht menschlich.
Schlecht passt ein Hackathon, wenn niemand geprüft hat, ob Nutzer das Ding überhaupt wollen. Die Teams bauen beeindruckende Antworten auf die falsche Frage, und die Jury belohnt die beeindruckendste. Wenn Sie diesen Weg wählen, folgen Sie Wie Sie einen Hackathon organisieren, der etwas Echtes hervorbringt.
Wann ein Design Jam passt
Ein Design Jam passt, wenn es darum geht, wie Menschen einen Service erleben, und Sie nicht sicher sind, wo er bricht. Seine Stärke: Die Teams verlassen den Raum. Sie betreiben Kontextbeobachtung, sprechen mit Menschen, spielen den Service im Rollenspiel durch und testen noch am selben Nachmittag Papierprototypen.
Das bekannteste Modell ist der Global Service Jam, 2011 von Adam Lawrence und Markus Hormess ins Leben gerufen, und sein Geschwister für den öffentlichen Sektor, der GovJam: 48 Stunden, ein zum Start enthülltes Thema, am Ende offen geteilte Prototypen. Bei einem internen Design Jam verzichten Sie meist auf das geheime Thema und setzen stattdessen ein echtes Serviceproblem.
Typische gute Einsätze: eine Onboarding-Journey neu gestalten, wiederholte Besuche oder Anrufe reduzieren, einen Service für eine Gruppe neu denken, an der er derzeit scheitert, oder einem Team durch eigenes Tun vermitteln, wie Service Design funktioniert. Ein Jam ist zudem günstig in der Durchführung, weil niemand eine Entwicklungsumgebung braucht.
Schlecht passt ein Design Jam, wenn die Organisation am Ende Software erwartet. Stellen Sie sicher, dass der Sponsor weiß: Das Ergebnis ist ein getestetes Konzept, oft als grober Service Blueprint festgehalten, und der Bau ist ein separater Schritt. Einen Jam durchführen behandelt das Format ausführlich.
Wann eine Innovation Challenge passt
Eine Innovation Challenge passt, wenn Sie vermuten, dass die Fähigkeit außerhalb Ihrer Organisation existiert und der Eigenbau langsamer oder riskanter wäre. Sie veröffentlichen eine Challenge, erhalten Bewerbungen, erstellen eine Shortlist, unterstützen die Finalisten dabei, ihre Lösung an Ihr Umfeld anzupassen, und pilotieren eine oder mehrere.
Typische gute Einsätze: einen Technologiepartner für ein Problem finden, das Ihre ganze Branche teilt, Startups für ein Pilotprogramm gewinnen oder Hochschulen einladen, vorhandene Forschung auf ein operatives Problem anzuwenden. Es ist das richtige Format, wenn Sie Löser brauchen, die Jahre an dem Problem gearbeitet haben, nicht ein Wochenende.
Schlecht passt sie, wenn Ihre Prozesse in Einkauf, Recht oder IT-Sicherheit keinen Piloten mit einem kleinen Unternehmen bewältigen können. Die Challenge zieht gute Bewerber an und verliert sie dann im Onboarding. Klären Sie Pilotbedingungen, Datenzugang und geistiges Eigentum vor dem Start. Wie Sie eine Challenge-Fragestellung schreiben, die Menschen lösen wollen behandelt das Briefing; Zusammenarbeit mit Startups behandelt die Beziehung.
Kombinieren: die Reihenfolge, die funktioniert
Die drei Formate sind in Reihenfolge am stärksten, weil jedes eine andere Art von Evidenz erzeugt.
- Jam, um das Problem zu finden. Ein ein- oder zweitägiger Design Jam mit Nutzern zeigt, wo der Service wirklich versagt und auf welches Konzept Nutzer ansprechen.
- Hackathon, um zu beweisen, dass es sich bauen lässt. Ein fokussierter Hackathon mit engem Auftrag, abgeleitet vom besten Konzept des Jams, testet die technische Machbarkeit auf Ihren eigenen Systemen.
- Challenge, um mit externer Hilfe zu skalieren. Ist der Eigenbau nicht der richtige Weg, findet eine Challenge Partner, die im großen Maßstab liefern können – mit der Evidenz des Jams in der Challenge-Fragestellung.
Sie werden nicht immer alle drei brauchen. Aber sie in der falschen Reihenfolge durchzuführen – einen Hackathon, bevor irgendjemand einen Nutzer getroffen hat, oder eine Challenge, bevor Sie das Problem kennen – ist der häufigste Grund, warum diese Formate enttäuschen.
Beispiel
Illustrativ. Ein nationaler Bibliotheksdienst in Kanada wollte, dass mehr junge Erwachsene seine Filialen nutzen. Ein Vorstandsmitglied schlug eine offene Innovation Challenge für „die Bibliothek der Zukunft“ vor. Das Innovationsteam hielt dagegen: Es wusste noch nicht, warum junge Erwachsene wegblieben.
Es führte zuerst einen zweitägigen Design Jam durch. Die Teams verbrachten den ersten Vormittag in drei Filialen und zwei nahegelegenen Cafés, beobachteten und sprachen mit Studierenden. Der Befund hatte nichts mit Büchern oder Technologie zu tun: Junge Erwachsene wollten einen Ort, an dem sie abends lange lernen konnten, und die Filialen schlossen um 18 Uhr. Die Teams entwickelten einen Prototyp für einen betreuten Lernabend und testeten ihn in der Woche darauf mit einem Concierge-Test in einer Filiale.
Die Abende funktionierten, aber das Personal dafür kostete zu viel. Also führte das Team einen kurzen internen Hackathon zu einer einzigen Frage durch: Ließen sich Selbstbedienungszugang und Buchung über das bestehende Mitgliedersystem abwickeln? Es ging, mit Einschränkungen. Erst dann startete der Dienst eine Challenge und suchte einen Lieferanten, der sicheren Selbstbedienungszugang in vielen Filialen bereitstellen konnte. Jedes Format beantwortete eine Frage, die das vorherige aufgeworfen hatte.
Was Sie tun und lassen sollten
Tun
- Zuerst die Frage benennen: Können wir es bauen, was sollten wir bauen, oder wer hat es schon?
- Das Problem mit einem Problembaum und Wie-könnten-wir-Fragen rahmen, egal welches Format Sie wählen.
- Die Verantwortlichen auf das Format abstimmen: eine Produktleitung für einen Hackathon, eine Serviceleitung für einen Jam, eine Fachbereichsverantwortliche mit dem Einkauf für eine Challenge.
- Dieselbe Logik der gewichteten Entscheidungsmatrix für alle drei nutzen, mit Kriterien, die nach der Evidenz gewichtet sind, die das jeweilige Format erzeugt.
Lassen
- Einen Hackathon durchführen, um eine Frage danach zu beantworten, was Nutzer brauchen.
- Einen Design Jam durchführen und funktionierende Software versprechen.
- Eine Challenge starten, bevor Ihre Organisation den Gewinner tatsächlich beauftragen und mit ihm pilotieren kann.
- Das Format nach dem Fototermin wählen. Der offene Hackathon mit großem Preis ist der sichtbarste und für viele Probleme der am wenigsten nützliche.
Häufige Fragen
Ist ein Design Jam dasselbe wie ein Hackathon? Nein. Beide teilen das kurze, intensive Format, aber ein Hackathon wird danach bewertet, was technisch funktioniert, und ein Design Jam danach, ob ein Servicekonzept bei echten Nutzern standhält. Jams brauchen keine Programmierung und verbringen viel mehr Zeit außerhalb des Raums.
Ist eine Innovation Challenge für Startups besser als ein Hackathon? Meist ja. Etablierte Startups opfern selten ein Wochenende, um bei null anzufangen, aber sie bewerben sich auf eine Challenge, die einen echten Piloten bietet. Hackathons passen zu Menschen, die etwas Neues bauen; Challenges zu Menschen, die schon etwas haben.
Können wir einen Hackathon und eine Challenge gleichzeitig durchführen? Ja, aber halten Sie sie getrennt. Wer interne Beschäftigte, die bei null anfangen, mit Startups mischt, die bereits ein Produkt haben, schafft einen unfairen Wettbewerb und verwirrt die Bewertung. Führen Sie sie als zwei Tracks mit unterschiedlichen Kriterien durch oder nacheinander.
Wie es weitergeht
Für den Jam-Weg beginnen Sie mit Kontextbeobachtung und Service Blueprint. Um zu testen, was ein Format hervorbringt, nutzen Sie Papierprototyp und Concierge-Test. Alle Guides finden Sie in der Guide-Übersicht.