Problem Statements Are an Artifact, Not an Afterthought

Problem statements are an artifact, not an afterthought. A good problem statement is written in advance, owned by a real stakeholder, and pre-tested before the event opens. The discipline this principle names is the difference between an event whose participants spend their weekend solving a real problem someone needed solved and an event whose participants spend their weekend reverse-engineering what the organizer might have meant by "Build something for healthcare."

Richard Murby, who ran civic hackathons at the World Bank, formulated the working standard in a 2017 essay that has functioned as the canonical practitioner reference ever since. A problem statement must be three things: clear, actionable, and linked to impact. Clear means a participant reading the statement understands the problem within thirty seconds without prior domain knowledge. Actionable means the problem can be addressed within the event's time window with the resources participants have. Linked to impact means solving it matters to a real stakeholder who will still care about the answer when the hackathon is over. Murby goes further than the three-part test: by describing the problem rather than the desired solution, organizers free participants to apply their creative energy to finding a viable solution — but only when the problem statement is paired with an explanation of the operating environment the solution will have to work inside.

The artifact discipline is what separates problem statements from themes. A theme — "AI for good," "Sustainability," "Build something for healthcare" — is a frame for an event, not an artifact a team can work against. The deep treatment of what frames are for and when they do their work belongs to the-frame. The point relevant here is that themes are not problem statements, even when they appear under that label, and treating them as if they were is the most common way an event's organizers fail their participants. Aaron Schumacher's open-source hackathon.guide names the failure mode plainly: projects without a stakeholder solve a problem that does not exist. HackerEarth's organizer guide recommends a Nested Whys and Hows decomposition, walking from theme down through whys (why this matters, why now, why these constraints) and hows (how a successful solution would be recognized, how the operating environment shapes the answer) — a structured method for getting from theme to artifact when the theme is what the organizer started with.

The Book recognizes two valid architectures for getting problem statements into participants' hands, and the v0.3 of this principle sharpened the distinction. The first is organizer-issued. NASA Space Apps publishes a public Challenge Statement template requiring Background, Objectives, Considerations, Potential Considerations, and Resources sections, with each challenge co-authored by a NASA Subject Matter Expert who functions as the stakeholder Murby calls for. Smart India Hackathon operates the same architecture at national scale: more than a thousand problem statements per year, each owned by a specific Ministry or Public Sector Undertaking, each carrying institutional follow-through after the event ends.

The second architecture inverts the first: participant-authored problem statements written against an externally-provided frame, with the quality of that statement itself made part of the judging rubric. The Google Solution Challenge runs this model. Teams across more than 110 countries pick whichever of the United Nations' seventeen Sustainable Development Goals they wish to address, but every entry is judged against a fifty-point rubric whose first five Impact points explicitly evaluate whether the entry establishes a clear challenge, names which SDG targets the team chose, and explains why. Jimin Lee, an APAC top-three winner of the 2025 Solution Challenge, wrote a first-person account of the strategy from inside the format: the team's central work was not just shipping a solution but writing the problem statement well enough that judges could see why the solution mattered.

The participant-authored model works when participants are closer to the problem domain than any central organizer could be — a 2024 Indian student team writing about urban food waste, a Korean team writing about dementia care, a Nigerian team writing about preventable vision loss in Sub-Saharan Africa. The model shifts the locus of stakeholder from organizer to participant-as-embedded-in-context. The artifact discipline does not relax under this model. It tightens, because the participant has to do both the stakeholder work and the solution work, and the rubric scores both.

The discipline that holds across both architectures is the same. Specific about the problem. Intentionally underspecified about the solution. Co-owned by a stakeholder who will still care about the answer when the hackathon is over — whether that stakeholder is a NASA Subject Matter Expert, an Indian Ministry, or a student team writing about their own community. Pre-tested before publication: the working test is to ask three people in the target audience to read the problem statement and describe the problem back, and when their descriptions diverge significantly, the problem statement is unclear and needs revision before publication, not after.

The familiar failure mode is the theme-as-problem-statement. "Build something for healthcare" is not a problem statement. "AI for good" is not a problem statement. "Sustainability" is not a problem statement. These are frames for events, useful only to the extent that they constrain the project space. They become problem statements only when paired with a stakeholder who has named what they actually need, an operating environment description that makes the problem real, and the artifact discipline that turns theme into something a team can work against. The format taxonomy format-taxonomy shows which of the ten working hackathon archetypes lean toward which problem-statement architecture. The case studies nasa-space-apps, smart-india-hackathon, and google-solution-challenge work the most distinctive examples of each architecture in detail. The voices richard-murby and aaron-schumacher profile the practitioners whose framing has done the most to clarify the artifact discipline.