Running a jam: 48 hours, a secret theme and real services

A jam is a 48-hour event where small, mixed teams design a new service from scratch around a theme nobody knows until the opening evening. To run one well you need four things: a theme kept genuinely secret, real people outside the room to research and test with, a hard deadline for a working prototype, and a plan for what happens on Monday. Code is optional; going out and talking to people is not.

The format has a clear lineage. The Global Service Jam was started in 2011 by Adam Lawrence and Markus Hormess of WorkPlayExperience, borrowing the shape of game jams such as the Global Game Jam (first held in 2009). Sister formats followed: the Global Sustainability Jam and GovJam, which applies the same approach to public services. In the global editions the theme is revealed by video on Friday evening, local time, and teams publish documentation of their prototype by Sunday afternoon, shared openly under a Creative Commons licence. You do not have to join a global jam to use the format, but its rhythm is a good default.

This piece is about running a jam specifically. For how jams sit next to hackathons and challenges, see Hackathon, design jam or innovation challenge; for the full map of formats, see Hackathons, jams and challenges: every type explained.

What makes a jam different from a hackathon

A hackathon usually starts from a defined challenge and ends with a pitch to judges. A jam starts from a deliberately vague theme ("hidden treasures", "waiting", "trust"), asks teams to find a real human need inside it, and ends with a prototype people can experience. Three consequences follow:

• Nobody can arrive with a solution. The secret theme stops people bringing a pet project and dressing it up.
• Research happens during the event. Teams leave the building, observe, interview strangers and come back with evidence.
• The output is a service, not an app. A role-played reception desk, a paper form, a storyboard of a new journey all count. Many good jam prototypes contain no software at all.

Global jams are not, at heart, competitions. If your sponsor wants a winner, ask whether a prize will simply push teams to polish pitches instead of testing.

How to run a jam, step by step

1. Decide why you are jamming (six to eight weeks before). Write one sentence: what should exist on Monday that does not exist today? Typical answers: forty staff who have each run real field research once; three service concepts in an area the organisation has avoided; a community of practitioners across departments. If the answer is "a solution to problem X", you probably want a hackathon or challenge instead.

2. Choose a theme that is wide, human and secret. Good themes are a word, an image or a short sound that can be read many ways. Bad themes are disguised briefs ("digital onboarding for SMEs"). Only two or three people should know it. Prepare the reveal: a short video or a single slide, shown at a fixed time on the first evening.

3. Recruit for mixture, not seniority. Aim for teams of four to six with different backgrounds: frontline staff, designers, developers, policy people, a few outsiders. Invite people as individuals, not as departmental delegations. Ask everyone to commit to the whole 48 hours; part-time jammers drag teams down.

4. Line up the outside world in advance. This is the step most organisers skip. Before the event, identify places teams can visit (a branch, a clinic waiting room, a public counter, a shopping street) and, where needed, get permission. Brief frontline staff that jammers may come and ask questions. Prepare a short consent script for interviews and photos. Without this, teams "research" each other.

5. Set the space and the materials. One large room with team tables, wall space, cardboard, tape, markers, a printer, props for role-play, and good food at sensible times.

6. Run Friday evening: reveal, react, form teams. Gather people with a short warm-up. Reveal the theme. Give ten minutes of silent, individual reaction (what does this word make you think of, who comes to mind). Ask people to pitch a human need or a question, not a solution, in one sentence. Let teams form around the questions people find most interesting. Close the evening with each team writing one How might we question they will investigate.

7. Run Saturday: out of the building, then build. The morning is research. Teams go out, observe and talk to real people, using a light service safari or short stakeholder interviews. By lunch they should have heard from at least five people who are not jammers. The afternoon is for synthesis and first prototypes: storyboards, role-plays, paper versions. Before dinner each team tests something rough with someone outside the team.

8. Run Sunday: test, iterate, document. Morning: one or two more rounds of testing and changing. Midday: freeze the prototype and document it so that a stranger can understand it (what need, what they learned, what the service is, what they tested and what happened). Afternoon: each team shows its prototype, ideally by letting the audience experience it rather than by presenting slides.

9. Plan Monday before Friday. Decide in advance who receives the outputs, how teams can ask for time to continue, and what a sponsor will do in the following fortnight. A jam that ends with applause and nothing else teaches people that innovation is theatre. See What to do after the hackathon; the same logic applies here.

Roles you need

• Host. Owns the whole event, keeps time, protects the rules. One person.
• Facilitators or coaches. One for every two or three teams. Their job is to push teams outside, ask "who did you test that with?" and stop endless discussion. They do not design for the teams.
• Domain helpers. Two or three people who know the real service (regulations, systems, frontline reality) and are available on call. They answer questions; they do not judge ideas.
• Documenter. Someone who photographs, collects outputs and makes sure every team's work survives the weekend.
• Sponsor. A senior person who opens the event, comes back on Sunday to experience the prototypes, and owns the Monday plan.

Illustrative example

Illustrative. A city transport authority in a mid-sized European city wanted staff from operations, customer service and IT to work together for the first time. It ran a jam over a Thursday evening to Saturday, so that staff did not lose a weekend. The theme, revealed on the first evening, was a sound recording of a station announcement fading out. Teams interpreted it as "being left uninformed", "the last train", and "travelling alone at night".

Before the event, the host had arranged access to two stations and a night bus depot, and briefed staff there. On the second morning, one team spent three hours at a late-night stop and spoke to eleven passengers and two drivers. Their prototype was not an app: it was a printed "if your connection fails" card, a scripted driver announcement and a role-played call to a night helpline. They tested it with six passengers at the same stop that evening and changed the wording twice.

On the final afternoon the operations director experienced every prototype in person. Two concepts were given a four-week trial, each with a named owner and a small team of jammers.

Do's and don'ts

Do

• Keep the theme secret for real. If people know it on Wednesday, half of them will arrive with a solution.
• Arrange field access before the event. Research is the heart of a jam, and it needs permission and a consent script.
• Make "show, don't tell" the rule for the final session. Let people experience the service.
• Feed people well and send them home at night. Tired teams make worse prototypes, not braver ones.
• Share the documentation openly. It builds trust for the next jam.

Don't

• Don't turn the theme into a brief. "Waiting" is a theme; "reduce queue times at branch 12" is a project.
• Don't let teams spend Saturday morning in the room. If nobody has spoken to a stranger by lunch, intervene.
• Don't fill teams with one department or one level of seniority. A director in a team of juniors will quietly own every decision.
• Don't judge on pitch quality. If you must award something, reward evidence from testing.
• Don't promise implementation you cannot deliver. Promise a real conversation with a real owner on a fixed date.

Questions people ask

How long should a jam be? Can we do it in one day? Forty-eight hours, spread across three days, is the classic shape because it allows one night of reflection and two rounds of testing. A one-day version works as an introduction, but you lose most of the field research and iteration.

Do participants need to be designers? No. Mixed teams work best, and frontline staff often bring the sharpest insight. What matters is a few facilitators who know the methods.

What should a jam team hand in at the end? A short, plain record: the need they found, who they spoke to, what they built, how they tested it and what changed. Photos of the prototype in use are worth more than slides. A simple feedback capture grid per team makes this easy.

Methods to use during the jam

On Friday, frame questions with How might we. On Saturday, go out with a service safari, then build with a storyboard or role-play. Teams that want to show how their service would really run can finish with a rough service blueprint. For the wider picture of formats, start with the hub guide to hackathons, jams and challenges.