So schreiben Sie ein Challenge Statement, das Menschen lösen wollen

Ein gutes Challenge Statement benennt auf einer einzigen Seite ein echtes Problem, die Menschen, die damit leben, warum es gerade jetzt zählt, was ausgeschlossen ist und was der Owner mit einer guten Antwort tun wird. Es ist konkret genug, dass Teams am ersten Morgen loslegen können, und offen genug, dass es die Lösung nicht vorgibt. Mit den sieben Schritten unten kommen Sie in etwa zwei Wochen Vorbereitung dorthin.

Was ein Challenge Statement leisten muss

Das Challenge Statement ist das wichtigste Dokument jedes Hackathons, Jams oder jeder Open Innovation Challenge. Es entscheidet, wer sich anmeldet, woran gearbeitet wird, wie die Jury bewertet und ob überhaupt etwas die Veranstaltung überlebt. Die meisten Statements scheitern in eine von zwei Richtungen:

• Zu breit. „Das Kundenerlebnis verbessern.“ Die Teams verbringen den ersten Tag damit, ein Problem auszuwählen, und am Ende stehen zehn zusammenhanglose Ideen, die sich nicht vergleichen lassen.
• Zu eng. „Einen Chatbot für das Callcenter bauen.“ Die Lösung steht schon fest. Die Teams werden zu unbezahlten Dienstleistern, und die besten Ideen tauchen nie auf.

Das Ziel liegt dazwischen: ein klares Problem, eine klare Person, echte Einschränkungen und Freiheit beim Wie. Das ist die Challenge-Variante der Arbeit, die wir in So schreiben Sie ein Problem Statement beschreiben – mit dem Unterschied, dass ein Challenge Statement für Fremde funktionieren muss, die Ihre Organisation nie von innen gesehen haben.

Sieben Schritte zum Challenge Statement

1. Beginnen Sie beim Owner, nicht beim Thema. Finden Sie die Person, die mit dem Problem lebt und befugt ist, auf eine Antwort hin zu handeln. Interviewen Sie sie eine Stunde lang. Fragen Sie, was immer wieder schiefläuft, was schon versucht wurde, was sich nicht ändern lässt und was sie am Montag mit einer guten Idee tun würde. Wenn niemand auf diese Beschreibung passt, hören Sie auf: Eine Challenge ohne Owner produziert Arbeit, die niemand entgegennimmt – genau das ist der erste Punkt in 9 Hackathon-Fehler, die Veranstalter immer wieder machen.

2. Gehen Sie eine Ebene unter das Symptom. Was der Owner zuerst beschreibt, ist meist ein Symptom: „Die Beschwerden nehmen zu“, „Anträge dauern zu lange“. Nutzen Sie einen Problembaum oder eine Runde 5-Why-Methode, um die Ursache zu finden, die real ist und sich in der verfügbaren Zeit bearbeiten lässt. Aus „Anträge dauern zu lange“ wird vielleicht „Antragsteller reichen unvollständige Unterlagen ein, und der Fall liegt in einer Warteschlange, weil ein einziges Dokument fehlt“. Dafür kann ein Team gestalten.

3. Benennen Sie die Betroffenen in einfachen Worten. Eine Challenge ohne Person bleibt abstrakt. Wer genau erlebt das Problem, in welchem Moment? „Erstantragsteller, die das Formular auf dem Handy ausfüllen, meist abends“ ist weit nützlicher als „Kunden“. Zwei oder drei Stakeholder-Interviews mit diesen Menschen, auch kurze, liefern Sprache und Details, die das Statement greifbar machen. Ein Point-of-View-Statement (Nutzer, Bedürfnis, Erkenntnis) ist eine gute Form, um das festzuhalten.

4. Machen Sie daraus eine Frage, die viele Antworten zulässt. Formulieren Sie das Problem als Wie-könnten-wir-Frage. Prüfen Sie sie: Könnten zehn verschiedene Teams zehn wirklich unterschiedliche gute Antworten geben? Passt nur eine Antwort, ist sie zu eng. Passt jede Antwort, ist sie zu breit. „Wie könnten wir Erstantragstellern helfen, beim ersten Mal vollständige Unterlagen einzureichen?“ besteht den Test. „Wie könnten wir einen Upload-Checker bauen?“ nicht. „Wie könnten wir öffentliche Dienstleistungen transformieren?“ ebenfalls nicht.

5. Schreiben Sie die Einschränkungen ehrlich auf. Einschränkungen sind nicht der Feind der Kreativität – Unklarheit ist es. Listen Sie auf, was sich nicht ändern lässt (Gesetze, Kernsysteme, Budgetobergrenze, Zeitpläne), was verfügbar ist (Datensätze, APIs, Arbeitszeit von Mitarbeitenden, echte Nutzer auf Abruf) und was ausdrücklich außen vor bleibt. Teams respektieren eine klare Grenze. Was sie frustriert, ist, sie erst beim Pitch zu entdecken, wenn ein Jurymitglied sagt: „Das könnten wir nie umsetzen.“

6. Sagen Sie, warum es zählt und was danach passiert. Erklären Sie in ein oder zwei Sätzen, warum dieses Problem gerade jetzt wichtig ist – am besten aus Sicht der Betroffenen statt aus Strategiepapieren. Dann sagen Sie klar, wozu sich der Owner verpflichtet: einen Pilot in einem benannten Service, eine 90-tägige Umsetzungsphase mit einem Team, einen finanzierten Test. Genau das bringt Menschen dazu, Ihre Challenge lösen zu wollen und nicht die eines anderen. Ist die Zusage bescheiden, sagen Sie das ehrlich. Teams ziehen einen kleinen, echten nächsten Schritt einem vagen Versprechen „möglicher Umsetzung“ vor.

7. Testen Sie es mit jemandem von außen. Geben Sie den Entwurf zwei oder drei Menschen, die nichts über das Problem wissen – idealerweise der Art von Menschen, die Sie als Teilnehmende gewinnen wollen. Bitten Sie sie, die Challenge in eigenen Worten wiederzugeben und die erste Idee zu nennen, die sie ausprobieren würden. Wenn sie sie missverstehen oder alle Ideen gleich sind, schreiben Sie neu. Ein Assumption Mapping dessen, was das Statement als selbstverständlich voraussetzt, ist ein nützlicher letzter Check.

Eine einseitige Vorlage

Verwenden Sie diese Überschriften in dieser Reihenfolge und halten Sie das Ganze auf einer Seite:

1. Die Challenge — die Wie-könnten-wir-Frage in einem Satz.
2. Wen sie betrifft — die Menschen, der Moment, ein Zitat, falls Sie eines haben.
3. Was wir wissen — drei bis fünf Fakten oder Beobachtungen, mit Quelle.
4. Warum jetzt — ein oder zwei Sätze.
5. Was Sie nutzen können — Daten, Systeme, Menschen auf Abruf.
6. Was ausgeschlossen ist — die ehrlichen Einschränkungen.
7. Woran wir gute Arbeit erkennen — die Bewertungskriterien, schon jetzt veröffentlicht (siehe Bewertungskriterien, die den richtigen Gewinner küren).
8. Was danach passiert — die Zusage des Owners, namentlich benannt.

Do's and Don'ts

Do

• Schreiben Sie in der Sprache der Betroffenen, nicht in der Sprache Ihrer Strategie.
• Nennen Sie mindestens einen Fakt, den die Teams nicht hätten erraten können.
• Veröffentlichen Sie Kriterien und die Zusage für die Zeit danach im selben Dokument.
• Lassen Sie den Owner die Challenge am ersten Morgen persönlich vorstellen.

Don't

• Nennen Sie keine Technologie. „Mit KI“ oder „mit Blockchain“ in der Frage verengt die Antworten, bevor jemand nachgedacht hat.
• Verschweigen Sie keine Einschränkungen, um die Challenge spannender wirken zu lassen.
• Packen Sie nicht zwei Probleme in ein Statement, um zwei Sponsoren zufriedenzustellen; schreiben Sie zwei Challenges oder entscheiden Sie sich für eine.
• Verwenden Sie keine internen Abkürzungen oder Abteilungsnamen, die Außenstehende nicht kennen.

Illustratives Beispiel

Illustrativ. Eine städtische Bibliothek in einem nordeuropäischen Land wollte eine offene Challenge zur „Bibliothek der Zukunft“ ausschreiben. Der erste Entwurf lautete: „Wie könnten wir die Bibliothek für das digitale Zeitalter neu denken?“ Ein Test mit drei Studierenden ergab drei Varianten derselben App.

Das Team ging zurück zur Leiterin der Zweigstellen, die das Budget für Veränderungen in den Zweigstellen verantwortete. In einer Stunde erfuhr es das eigentliche Problem: Die abendlichen Besuche von Jugendlichen waren zurückgegangen, während die Zweigstellen bis acht Uhr geöffnet blieben – mit Personal, das wenig zu tun hatte. Eine Runde 5-Why-Methode mit dem Zweigstellenpersonal deutete auf eine Ursache: Jugendliche sahen die Bibliothek als Ort zum ruhigen Lernen in der Prüfungszeit und sonst nichts.

Das überarbeitete Statement lautete: „Wie könnten wir 14- bis 18-Jährigen einen Grund geben, an einem ganz normalen Wochentagabend in ihre Zweigstelle vor Ort zu kommen?“ Einschränkungen: keine Bauarbeiten, nur vorhandenes Personal, ein kleines Materialbudget. Verfügbar: zwei Zweigstellen, die testen wollten, fünf Jugendliche auf Abruf während der Veranstaltung, Besuchsdaten nach Uhrzeit für die letzten zwei Jahre. Zusage: Die Leiterin der Zweigstellen würde die Gewinneridee ein Schulhalbjahr lang in zwei Zweigstellen umsetzen. Zweiundzwanzig Teams machten mit; die Ideen reichten von einer Hausaufgaben-Tauschbörse bis zu einem abendlichen Repair-Café. Jede Idee ließ sich an derselben Frage messen.

Häufige Fragen

Was ist der Unterschied zwischen Problem Statement und Challenge Statement? Ein Problem Statement beschreibt, was falsch läuft, vor allem für das Team, dem das Problem gehört. Ein Challenge Statement macht aus diesem Problem eine Einladung an Menschen außerhalb des Teams: Es ergänzt die Frage, die Einschränkungen, die Ressourcen und was mit einer guten Antwort geschehen wird.

Wie lang sollte ein Challenge Statement für einen Hackathon sein? Eine Seite. Die Frage selbst sollte ein Satz sein. Brauchen Sie mehr als eine Seite, haben Sie wahrscheinlich zwei Challenges – oder Sie erklären Ihre Organisation statt des Problems.

Sollte ich in der Challenge Beispiele für mögliche Lösungen geben? Meist nicht. Beispiele setzen einen Anker, und viele Teams bauen dann einfach das Beispiel nach. Wenn es sein muss, geben Sie zwei sehr unterschiedliche und sagen Sie klar, dass es Illustrationen sind, keine Erwartungen.

Wie es weitergeht

Die Challenge ist Teil eines größeren Designs; lesen Sie So führen Sie einen Hackathon durch, der echte Ergebnisse liefert und die Formatübersicht in Hackathons, Jams und Challenges: alle Formate erklärt. Für eine gute Vorbereitung nutzen Sie die Guides Problembaum, 5-Why-Methode, Point-of-View-Statement und Wie-könnten-wir-Fragen.