Tiremesù
DE
Hackathons, Jams und ChallengesVergleich8 Min. Lesezeit

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.

Tiremesù-Redaktion

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 Canvas zur Kontextbeobachtung
Das Canvas zur Kontextbeobachtung

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.

Das Canvas zum Service Blueprint
Das Canvas zum Service Blueprint

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.

  1. 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.
  2. 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.
  3. 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.

Das Canvas zum Concierge-Test
Das Canvas zum Concierge-Test

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.