Hackathon, design jam or innovation challenge: which one fits your goal

Choose a hackathon when the problem is clear and you need a working prototype built by people who can code or make. Choose a design jam when you are not yet sure what the right service or experience is and need to find out with real users, fast. Choose an innovation challenge when the solution probably already exists somewhere, in a startup, a lab or a supplier, and you need to find it, test it and contract it.

Put another way: a hackathon answers "can we build it?", a design jam answers "what should we build?", and a challenge answers "who already has it?". The rest of this article shows how to tell which question you are really asking. For the full family of formats, see every type of hackathon and jam explained.

The comparison at a glance

When a hackathon fits

A hackathon fits when three things are true. The problem is specific enough to state in a sentence. The systems, data or materials are available and cleared. And there is someone who will take the result and fund the next stage.

Typical good uses: automating a manual step that everyone agrees is painful, building an internal tool on an existing data set, connecting two systems that should talk to each other, or testing whether a new technology can handle a real workload. In each case the uncertainty is technical, not human.

A hackathon fits badly when nobody has checked whether users want the thing. Teams will build impressive answers to the wrong question, and judges will reward the most impressive. If you choose this route, follow how to run a hackathon that produces something real.

When a design jam fits

A design jam fits when the problem is about how people experience a service and you are not sure where it breaks. Its power is that teams leave the room. They do contextual observation, talk to people, act out the service with role-play, and test paper prototypes the same afternoon.

The best-known model is the Global Service Jam, started in 2011 by Adam Lawrence and Markus Hormess, and its public-sector sibling GovJam: 48 hours, a theme revealed at the start, prototypes shared openly at the end. For an internal design jam you usually drop the secret theme and set a real service problem instead.

Typical good uses: redesigning an onboarding journey, reducing repeat visits or calls, rethinking a service for a group it currently fails, or teaching a team how service design works by doing it. A jam is also cheap to run because nobody needs a development environment.

A design jam fits badly when the organisation expects software at the end. Make sure the sponsor knows the output is a tested concept, often captured as a rough service blueprint, and that building it is a separate step. Running a jam covers the format in detail.

When an innovation challenge fits

An innovation challenge fits when you suspect the capability exists outside your walls and building it yourself would be slower or riskier. You publish a challenge, receive applications, shortlist, support finalists to adapt their solution to your setting, and pilot one or more.

Typical good uses: finding a technology partner for a problem your sector shares, sourcing startups for a pilot programme, or inviting universities to apply existing research to an operational problem. It is the right format when you need solvers who have spent years on the problem, not a weekend.

It fits badly when your procurement, legal or IT security processes cannot handle a pilot with a small company. The challenge will attract good applicants and then lose them in onboarding. Settle pilot terms, data access and intellectual property before launch. How to write a challenge statement people want to solve covers the brief; working with startups covers the relationship.

Mixing them: the sequence that works

The three formats are strongest in sequence, because each produces a different kind of evidence.

1. Jam to find the problem. A one- or two-day design jam with users identifies where the service really fails and which concept users respond to.
2. Hackathon to prove it can be built. A focused hackathon, with a narrow brief taken from the jam's best concept, tests technical feasibility on your own systems.
3. Challenge to scale with outside help. If building it in-house is not the right path, a challenge sources partners who can deliver at scale, with the jam's evidence in the challenge statement.

You will not always need all three. But running them in the wrong order, a hackathon before anyone has met a user or a challenge before you know the problem, is the most common reason these events disappoint.

Illustrative example

Illustrative. A national library service in Canada wanted more young adults to use its branches. A board member proposed an open innovation challenge for "the library of the future". The innovation team pushed back: it did not yet know why young adults stayed away.

It ran a two-day design jam first. Teams spent the first morning in three branches and two nearby cafés, observing and talking to students. The finding was not about books or technology: young adults wanted somewhere to study late, and branches closed at 6 pm. Teams prototyped a staffed late-study evening and tested it with a concierge test in one branch the following week.

The evenings worked but staffing them cost too much. So the team ran a short internal hackathon on one question: could self-service entry and booking run on the existing membership system? It could, with limits. Only then did the service launch a challenge, looking for a supplier who could provide secure self-service access across many branches. Each format answered a question the previous one had raised.

Do's and don'ts

Do

• Name the question first: can we build it, what should we build, or who already has it.
• Frame the problem with a problem tree and how might we questions whichever format you choose.
• Match the owner to the format: a product lead for a hackathon, a service lead for a jam, a business owner with procurement for a challenge.
• Use the same weighted decision matrix logic across all three, with criteria weighted for the evidence each format produces.

Don't

• Run a hackathon to answer a question about what users need.
• Run a design jam and promise working software.
• Launch a challenge before your organisation can actually contract and pilot with the winner.
• Pick the format for the photo opportunity. The open hackathon with a big prize is the most visible and, for many problems, the least useful.

Questions people ask

Is a design jam the same as a hackathon? No. They share the short, intense format, but a hackathon is judged on what works technically and a design jam on whether a service concept holds up with real users. Jams need no coding and spend much more time outside the room.

Is an innovation challenge better than a hackathon for startups? Usually, yes. Established startups rarely give up a weekend to build from scratch, but they will apply to a challenge that offers a real pilot. Hackathons suit people building something new; challenges suit people who already have something.

Can we run a hackathon and a challenge at the same time? You can, but keep them separate. Mixing internal staff building from zero with startups that already have a product creates an unfair contest and confuses the judging. Run them as two tracks with different criteria, or in sequence.

Where to go next

For the jam route, start with contextual observation and service blueprint. For testing what any format produces, use paper prototype and concierge test. All guides are in the guides index.