How to write a challenge statement people want to solve

A good challenge statement names a real problem, the people who live with it, why it matters now, what is off the table and what the owner will do with a good answer, all on one page. It is specific enough that teams can start on the first morning, and open enough that it does not dictate the solution. The seven steps below get you there in about two weeks of preparation.

What a challenge statement has to do

The challenge statement is the most important document in any hackathon, jam or open innovation challenge. It decides who signs up, what they work on, how judges score and whether anything survives the event. Most statements fail in one of two directions:

• Too broad. "Improve the customer experience." Teams spend the first day choosing a problem and end up with ten unrelated ideas you cannot compare.
• Too narrow. "Build a chatbot for the call centre." The solution is already chosen. Teams become unpaid contractors and the best ideas never appear.

The target sits between: a clear problem, a clear person, real constraints and freedom on the how. This is the challenge-level version of the work we describe in how to write a problem statement; the difference is that a challenge statement has to work for strangers who have never been inside your organisation.

Seven steps to a challenge statement

1. Start with the owner, not the topic. Find the person who lives with the problem and has the authority to act on an answer. Interview them for an hour. Ask what keeps going wrong, what they have already tried, what they cannot change and what they would do on Monday with a good idea. If nobody fits that description, stop: a challenge without an owner produces work nobody receives, which is the first thing covered in 9 hackathon mistakes organisers keep repeating.

2. Go one level below the symptom. What the owner describes first is usually a symptom: "complaints are up", "applications take too long". Use a problem tree or a round of five whys to find the cause that is both real and workable in the time teams have. "Applications take too long" might become "applicants submit incomplete files and the case sits in a queue waiting for one missing document". That is something a team can design for.

3. Name the people affected, in plain words. A challenge without a person is abstract. Who exactly experiences the problem, in what moment? "First-time applicants filling in the form on a phone, usually at night" is far more useful than "customers". Two or three stakeholder interviews with these people, even short ones, will give you language and detail that make the statement feel real. A point of view statement (user, need, insight) is a good way to hold it.

4. Turn it into a question that invites many answers. Rewrite the problem as a how might we question. Test it: could ten different teams give ten genuinely different good answers? If only one answer fits, it is too narrow. If any answer fits, it is too broad. "How might we help first-time applicants submit a complete file the first time?" passes. "How might we build an upload checker?" does not. "How might we transform public services?" does not either.

5. Write the constraints honestly. Constraints are not the enemy of creativity; vagueness is. List what cannot change (legislation, core systems, budget ceiling, timelines), what is available (data sets, APIs, staff time, real users on call) and what is explicitly out of scope. Teams will respect a hard line. What frustrates them is discovering it at the pitch, when a judge says "we could never do that".

6. Say why it matters and what happens next. Give one or two sentences on why this problem matters now, ideally from the people affected rather than from strategy documents. Then state plainly what the owner commits to: a pilot on a named service, a 90-day build with a team, a funded test. This is what makes people want to solve your challenge rather than someone else's. If the commitment is modest, say so honestly. Teams prefer a small, real next step to a vague promise of "potential implementation".

7. Test it with someone outside. Give the draft to two or three people who know nothing about the problem, ideally the kind of people you hope will participate. Ask them to explain the challenge back to you in their own words and to name the first idea they would try. If they misunderstand it, or every idea is the same, rewrite. An assumption map of what the statement takes for granted is a useful last check.

A one-page template

Use these headings, in this order, and keep the whole thing to one page:

1. The challenge — the how-might-we question, in one sentence.
2. Who it affects — the people, the moment, one quote if you have one.
3. What we know — three to five facts or observations, with where they came from.
4. Why now — one or two sentences.
5. What you can use — data, systems, people on call.
6. What is off the table — the honest constraints.
7. What good looks like — the judging criteria, published now (see judging criteria that pick the right winner).
8. What happens next — the owner's commitment, named.

Do's and don'ts

Do

• Write in the language of the people affected, not the language of your strategy.
• Include at least one fact teams could not have guessed.
• Publish the criteria and the post-event commitment in the same document.
• Have the owner present the challenge in person on the first morning.

Don't

• Don't name the technology. "Using AI" or "with blockchain" in the question narrows the answers before anyone has thought.
• Don't hide constraints to make the challenge look more exciting.
• Don't combine two problems into one statement to please two sponsors; write two challenges or choose one.
• Don't use internal acronyms or department names outsiders won't know.

Illustrative example

Illustrative. A city library service in a northern European country wanted to run an open challenge on "the library of the future". The first draft read: "How might we reimagine the library for the digital age?" Testing it with three students produced three versions of the same app.

The team went back to the head of branch services, who owned the budget for branch changes. In an hour they learned the real issue: evening visits by teenagers had dropped, while the branches stayed open until eight with staff who had little to do. A five whys session with branch staff pointed to one cause: teenagers saw the library as a place for quiet study during exams and nothing else.

The revised statement read: "How might we give 14–18 year-olds a reason to come to their local branch on an ordinary weekday evening?" Constraints: no building works, existing staff only, a small materials budget. Available: two branches willing to test, five teenagers on call during the event, visit data by hour for the last two years. Commitment: the head of branch services would run the winning idea in two branches for one school term. Twenty-two teams entered; the ideas ranged from a homework-help swap to an evening repair café. Every idea could be compared against the same question.

Questions people ask

What is the difference between a problem statement and a challenge statement? A problem statement describes what is wrong, mainly for the team that owns it. A challenge statement turns that problem into an invitation for people outside the team: it adds the question, the constraints, the resources and what will happen to a good answer.

How long should a hackathon challenge statement be? One page. The question itself should be one sentence. If you need more than a page, you probably have two challenges or you are explaining your organisation rather than the problem.

Should I give examples of possible solutions in the challenge? Usually not. Examples anchor teams, and many will simply build the example. If you must, give two very different ones and say clearly that they are illustrations, not expectations.

Where to go next

The challenge sits inside a wider design; see how to run a hackathon that produces something real and the map of formats in hackathons, jams and challenges: every type explained. To do the preparation well, use the problem tree, five whys, point of view and how might we guides.