How to Write a Problem Statement Worth Solving

A problem statement is the artifact a hackathon team builds against. The Manifesto principle problem-statements argues that problem statements are an artifact rather than an afterthought — written in advance, owned by a real stakeholder, and pre-tested before publication. This entry takes that position as established and walks through what the artifact discipline looks like operationally: the test a problem statement has to pass, the two valid architectures for getting problem statements into participants' hands, the operational mechanics of writing one, and the failure modes that recur often enough to name.

Murby's three-part test

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. The three are operationally distinct, and a problem statement that fails any one of them needs revision before publication.

Clear means a participant reading the statement understands the problem within thirty seconds, without prior domain knowledge. The working test for clarity is Murby's three-readers protocol: ask three people from the target audience to read the problem statement and describe the problem back in their own words. If their descriptions diverge significantly, the problem statement is unclear and needs revision. Domain jargon is the most common cause of failure here — phrases that read as natural to the stakeholder author but as opaque to participants who do not share the stakeholder's background. The fix is not necessarily to remove the jargon (sometimes the jargon is precise in a way the lay terms are not) but to define it inline at first use.

Actionable means the problem can be addressed within the event's time window with the resources participants have. A problem that requires three months of fieldwork before any code can be written fails the actionable test, even if the underlying problem is real and worth solving. The working test for actionability is whether a strong team, on Friday evening, can describe a credible Sunday-afternoon deliverable that would represent meaningful progress on the problem. If the description requires hand-waving about what a deliverable would even look like, the problem statement is not actionable for the event's window.

Linked to impact means solving the problem matters to a real stakeholder who will still care about the answer when the hackathon is over. The stakeholder requirement is the load-bearing piece of this criterion, and Aaron Schumacher's hackathon.guide names the failure mode plainly: projects without a stakeholder solve a problem that does not exist. The working test for the impact link is whether the stakeholder will follow up on the winning submissions six weeks after the closing ceremony. If the follow-up is not credible, the impact link is not real, regardless of how the problem statement is worded. See stakeholder.

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. A problem statement that names the desired solution as part of the problem is no longer a problem statement; it is a specification, and it forecloses on the creative range that justifies running a hackathon in the first place.

Two valid architectures

The Book recognizes two valid architectures for getting problem statements into participants' hands, and the v0.3 of the Manifesto 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 architecture works when the organizing institution has access to stakeholders deep enough in their domains to author problem statements participants would not be able to construct on their own, and when the institution has the capacity to vet the statements before publication.

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 architecture works when participants are closer to the problem domain than any central organizer could be, and the rubric tightens rather than relaxes the artifact discipline because the participant has to do both the stakeholder work and the solution work.

The five operational sections

NASA Space Apps' Challenge Statement template is the working template for what an organizer-issued problem statement looks like in publishable form. The template has five sections, and adapting it to events at smaller scale than NASA Space Apps' is a matter of adjusting section length, not section structure.

Background is two to four paragraphs naming the world the problem lives in. Who experiences the problem? What is the current state? What has been tried and what has failed? The background section is what makes the problem real to participants who do not already know the domain, and it is the first place the artifact discipline pays back the effort of writing it carefully — a participant reading a strong background section starts thinking about the problem from inside the domain rather than from outside it.

Objectives is two to four bullets describing what a successful solution looks like at the high level, without naming the implementation. "Reduce the time community health workers spend on triage paperwork by half" is an objective; "build a triage paperwork app with offline sync" is a specification.

Considerations is two to four bullets naming the constraints the solution has to operate inside. The operating environment, regulatory constraints, ethical considerations, edge cases the solution will encounter in practice. The considerations section is what makes the problem statement a working problem rather than an abstract one; problems described without their constraints tend to attract solutions that work only on the constraints' easy cases.

Potential Considerations is three to six optional bullets listing tools, datasets, frameworks, or starting points participants might use without prescribing them. The discipline of this section is suggestion rather than instruction — the participants choose whether to use the suggestions, and the rubric does not penalize work that goes a different direction.

Resources is three to ten links to datasets, documentation, prior work, and contact information for the stakeholder. The stakeholder contact is the load-bearing piece — a problem statement whose stakeholder cannot be reached during the event is operationally less useful than one whose stakeholder is accessible for clarifying questions.

From theme to artifact

Many problem statements begin life as themes — a domain area the organizing institution wants the event to address, but not yet a specific problem within the domain. HackerEarth's organizer guide recommends a Nested Whys and Hows decomposition for getting from theme to artifact: walk from the 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). The decomposition is structured rather than intuitive, and it forces the organizer to surface assumptions the theme hides. A theme like "AI for healthcare" survives the first level of whys but fails the second (why now, why these constraints) without the specifics that turn the theme into a problem statement. The decomposition is the work the artifact discipline depends on, and it cannot be skipped without producing problem statements that fail Murby's three-part test in subtle ways. See theme and frame.

Failure modes that recur often

Three failure modes recur often enough to name. The first is the theme-as-problem-statement: organizers publish a theme and call it a problem statement, leaving participants to construct their own problem within the theme without the rubric structure that the participant- authored architecture provides. The fix is to either commit to the organizer-issued architecture and publish real problem statements, or commit to the participant-authored architecture and rubric-grade the participant-written statements. Hybridizing the two without the rubric discipline produces incoherent judging.

The second is the bureaucratic problem statement, common in Government Civic Challenge events when the agency authoring the problem statement optimizes for procurement-document conventions rather than for participant clarity. The statement passes internal review at the agency but fails the three-readers test with participants. The fix is to test the statement with three participants from outside the agency before publication; if their descriptions diverge, the statement is not yet publishable.

The third is the unfalsifiable outcome: a problem statement whose "linked to impact" criterion gestures at impact in language that cannot be checked. "Improve outcomes for community health workers" without specifics is not an outcome; "reduce average triage time per patient by 20% relative to the current paper-based workflow" is. See outcome. The unfalsifiable outcome failure mode is the one that most often passes surface inspection and fails on close reading, because the language sounds responsible until a reader asks how the team would know whether they had hit the target.

A worked example

The pattern below is what a problem statement passing the three-part test looks like in compact form, drawn from a hypothetical Class A event in the Government Civic Challenge format. The example is not from any specific real event; it is an illustration of what the artifact discipline produces.

Background. Community health workers in rural Andhra Pradesh conduct emergency triage for patients in villages without immediate physician access. The current workflow is paper-based: workers fill out triage forms by hand, photograph the forms, and send them via WhatsApp to district hospitals when connectivity is available. Connectivity is intermittent — often unavailable for hours at a time — and the asynchronous workflow introduces delays that occasionally matter clinically.

Objectives. A successful solution lets community health workers capture triage information in a structured format that syncs to district hospitals when connectivity is available, surfaces the highest-priority cases at the receiving end without requiring the worker to label them by hand, and degrades gracefully across hours of offline operation.

Considerations. Workers use Android phones in the price range of ₹8,000 to ₹15,000, with limited storage and no guarantee of recent OS versions. Patient data is subject to Indian medical privacy regulations. The receiving district hospitals have intermittent staffing — the surfaced priority cases must be actionable without a physician available, sometimes for hours.

Potential Considerations. Local language support (Telugu) for patient-facing prompts. Offline-first sync libraries. ML-based priority surfacing trained on anonymized historical triage data.

Resources. [Anonymized triage dataset link]. [Andhra Pradesh Department of Health contact]. [WhatsApp Business API documentation]. [Stakeholder: Dr. Padma Rao, AP Department of Health].

The example is short — fewer than 250 words — but it passes Murby's three-part test. Clarity: a participant reads it and knows the problem within thirty seconds. Actionable: a strong team can describe a credible Sunday deliverable. Impact link: the stakeholder is named, and the follow-up after the event is a real possibility because the stakeholder has the institutional position to act on the work.

Where the rest of the craft lives

The format taxonomy format-taxonomy shows which of the ten working hackathon archetypes lean toward which problem-statement architecture — Government Civic Challenges and Internal Corporate events lean organizer-issued, the Google Solution Challenge and similar Platform Ecosystem Challenges lean participant- authored. The framing principle the-frame covers what themes are for once problem statements are in place — they are the constraint that bounds the project space, not a substitute for the artifact. The goal principle the-goal is the principle the problem statement operationalizes: the goal is a stakeholder plus an outcome, and the problem statement is what makes both visible to participants. The case studies nasa-space-apps, smart-india-hackathon, and google-solution-challenge work the canonical examples of each architecture in detail when the full case studies are written.