How Do You Write a Hackathon Problem Statement?

One paragraph a team can act on by Sunday. A hackathon problem statement describes a situation, names the gap in it, says who lives with it, why now and why it matters, and stops before any solution. It is the smallest unit of the hackathon's design: the theme sets the space, the statement sets the problem, the brief adds the deliverable and the criteria. In Innovation Mode 2.0, the theme “establishes the problem space where participants will innovate,” and “The clarity and specificity of your theme directly impact the quality and relevance of participant solutions.” The statement is where that specificity lives.

• The shape: a title in the form ‘who can't do what,’ a paragraph of five or six sentences, three lines on who lives with it, one sourced sentence on why now, two on why it matters; see the six parts
• A worked example: Readers can't check the AI answer they were given, from the hackathon pack of Ainna's Problem Radar: the situation (people take answers from a source they doubt), the gap (nothing lets them check at the moment they receive it), the sufferers, one figure, and no solution
• What it is not: a brief (that adds the deliverable, the criteria and the data), a theme (that is the space), or an idea (that proposes the fix). The book keeps these apart because “Problems are more compact and simpler than ideas”
• What it does for the team: it answers ‘what are we solving, for whom, and why would anyone care on Monday’ before the first line of code; the participant's side is in how to know whether your hackathon idea is good
• What it does for the judges: it is the yardstick. A project is judged against the gap it was asked to close, not against the loudest demo; see judging against the statement
• What it does for the company: a well-framed problem outlives the event. The book's point: “Stand-alone problems become assets in the innovation process”

The theme is the space; the statement is the problem. Organizers use the four words loosely and teams pay for it. A theme is the problem space the event explores (‘trust in AI answers,’ ‘water loss’). A track is a lane inside it, usually by domain or audience, with its own judges or prizes. A problem statement is one specific problem inside a track, with a sufferer and a gap. A challenge is a statement with a brief attached: the deliverable, the criteria, the data and the sponsor. One theme, a few tracks, several statements, each statement a challenge once briefed. Mix them up and you get a theme judged as if it were a problem, which is how ‘AI for good’ hackathons end.

• Theme: set “in collaboration with the leadership and the event's sponsors”; it may also name “relevant technologies or areas of interest for exploration.” It is a sentence and a paragraph, not a list of problems
• Track: a grouping for logistics and judging; the Problem Radar's facets (domain, scale) are tracks waiting to happen
• Problem statement: the unit of this guide; the three statements in the hackathon pack are three problems under one implicit theme, measurement gaps in physical and digital systems
• Challenge: the statement plus what a valid submission is; see the challenge brief
• Open track: the lane for teams who bring their own problem; keep it, and require the same statement format from them, which is the idea one-pager on the participant's side
• The vocabulary elsewhere: the innovation dictionary for problem framing, ideation and the rest

They hide a solution, or they hide the sufferer. The first failure is the statement that is an idea in disguise: ‘Build a chatbot that helps customers track orders’ has decided the product and left the team to decorate it. The second is the statement with no one in it: ‘Improve sustainability in our supply chain’ names a virtue and no person who suffers, so the team invents one. The third is the statement without evidence, which reads as the organizer's opinion. Innovation Mode 2.0 asks for the opposite in every framed problem: the current state with “statistics and references,” the “underlying causes” rather than the symptoms, and strategies described “without ‘solutioning’ or delving into specific implementations.”

• The solution in disguise: any statement that starts with ‘build,’ ‘create,’ ‘develop’ or ‘an app that.’ Rewrite it as the situation the app was supposed to fix, and let the teams decide whether an app is the fix
• The missing sufferer: if you cannot write the line ‘who lives with it,’ you do not have a problem yet; you have a topic. Every Problem Radar page carries that line, three groups at most
• The missing why now: a problem that was equally true in 2015 reads as a textbook exercise. One dated figure fixes it; see evidence without a report
• The theme judged as a problem: ‘AI for healthcare’ produces forty unrelated apps and a judging panel comparing a triage tool with a billing tool; see which is which
• The problem that needs a year: a statement at startup scale handed to a weekend; see how to scope for a weekend
• The statement nobody owns: no sponsor, no data, no person who will take the winner's work on Monday; the book's warning about hackathons done “out of context” is that they “may only generate short-term results”

Specific about the gap, silent about the fix. The test is whether two strong teams reading it would attack the same problem with different solutions. Too vague, and they attack different problems; too specific, and they build the same thing. The Problem Radar's statements sit at the right altitude: recyclers can't tell what's inside before they shred it names the binding constraint (“identification rather than chemistry”) so teams aim at the right layer, and leaves open whether the answer is a label, a scanner, a database or a marketplace. That is the book's “directional advice without constraining creativity or prescribing particular solutions.”

• Specific: the situation, the moment the problem bites, the sufferer, the constraint that makes it hard, the evidence. These narrow the problem
• Silent: the technology, the form factor, the business model, the feature list. These narrow the solution, which is the team's job
• The constraint line: the most useful sentence in a statement names what is actually hard: in the data center problem, that the information needed to move the work “lives in a different system from the scheduler”; see the full statement
• Hints are allowed: the book permits naming “relevant technologies or areas of interest for exploration” at the theme level. Put them in the brief as data and constraints, not in the statement as the answer
• The altitude test: list five solutions a team could propose. Fewer than three, the statement is a solution; more than ten with nothing in common, it is a theme
• For AI hackathons: the temptation is to specify the model; resist it; see statements for AI hackathons

Six parts, one page at most. The Innovation Mode problem-framing template describes a problem through its environment, its history and dynamic, its current state, its ideal state and the strategies open to it, “without ‘solutioning.’” A hackathon statement compresses that into six parts a team can hold in its head: the situation (what happens today), the gap (what is missing at the moment it bites), who lives with it (three groups at most), why now (one sourced figure), why it matters (what changes if it is solved), and what a good weekend result looks like (the ideal state at hackathon scale). The Problem Radar's pages are this template in print.

• 1. The situation: two sentences on how things work today, in the sufferer's terms. From the data center problem: work is scheduled “around deadlines and cluster availability, almost never around what electricity costs or emits at that hour”
• 2. The gap: the sentence that names what is missing at the moment the problem bites; from the AI-answer problem: “the absence of anything that lets a reader check an answer at the moment they receive it”
• 3. Who lives with it: the people and roles, as a list: “Anyone getting news through an assistant,” publishers, educators. If a group benefits from the problem, say so; the book notes that “certain classes of users may be suffering while others, ironically, may be benefiting”
• 4. Why now: one dated, sourced figure that shows the problem is growing or newly solvable; see evidence without a report
• 5. Why it matters: the ideal state in one or two sentences, “expressed in terms of impacted metrics and success criteria,” and who gains
• 6. A good weekend result: what the organizer would be pleased to see on Sunday: a working check on one kind of answer, a classifier on one device category, a scheduler that moves one job. This is the line most statements lack and the one that decides the scope

Yes: six lines to fill in, and a worked example to copy. Title: [who] can't [do what] [when]. Situation: two sentences on how it works today, in their terms. Gap: the one thing missing at the moment the problem bites. Who lives with it: up to three groups, and who benefits from the status quo if anyone. Why now: one figure, its source and its year, linked. Why it matters: what changes if the gap closes, and for whom. A good weekend result: the slice a team can show on Sunday. Fill the six lines, read them aloud, and strike any word that names a product. For the long form behind the short one, the Innovation Mode Problem Framing Template adds the environment, the history and the strategies.

• Title: Readers can't check the AI answer they were given
• Situation: use of AI assistants for news is rising while stated trust in them stays very low; people take answers from a source they openly doubt because it is faster than the alternative
• Gap: nothing lets a reader check an answer at the moment they receive it without abandoning it and starting a separate search
• Who lives with it: anyone getting news through an assistant; publishers whose work is summarized without attribution; educators teaching source literacy
• Why now, and why it matters: a 2026 report across 48 markets puts trust in news from AI chatbots at 20% while weekly use rises; doubt without a remedy is where trust products get built, and nobody serving that moment owns it yet. The full page: the AI-answer problem on the Problem Radar
• A good weekend result: a working check on one kind of answer, for one kind of reader, that runs in the thirty seconds after the answer appears; this line is the organizer's to write, the Radar page leaves it to the team

Who can't do what, and when. The title of a problem statement is a sentence, not a topic: “Readers can't check the AI answer they were given,” “Recyclers can't tell what's inside before they shred it,” “Utilities can't find leaks in pipes they never metered.” Each names the sufferer, the thing they cannot do, and the moment. A topic title (‘AI transparency,’ ‘E-waste,’ ‘Water loss’) tells the team nothing about where to start. The pattern is old and works because it forces the writer to find the person and the moment before the first draft; if you cannot complete ‘X can't Y when Z,’ you are not ready to write the paragraph.

• The subject is a person or a role, never a technology or an industry: recyclers, readers, utilities' engineers, not ‘the recycling sector’
• The verb is an inability or a cost, not an aspiration: can't tell, can't check, can't find, lose, pay twice, wait. ‘Need a better way to’ is an aspiration
• The moment: “before they shred it,” “at the moment they receive it,” “when the road subsides.” The moment is where a weekend prototype can intervene
• Length: under twelve words; the Problem Radar's titles run six to ten. A title that needs a comma is two problems
• Test it on a stranger: read the title alone; if they can guess who suffers and roughly why, keep it
• Then the paragraph: the title is the promise, the paragraph the evidence; see the six parts

One figure, one source, one date. A problem statement needs enough evidence to prove the problem is real and current, and no more; the team will do its own research on Friday night. The Innovation Mode template asks the current state to carry “statistics and references,” and the Problem Radar's “why now” line shows the dose: one figure from one named report, dated, with the number that makes the case. For the AI-answer problem it is a 2026 survey of trust in news across 48 markets; for e-waste, the 2024 global monitor's tonnage and recovery rate; for data centers, an energy agency's 2024 consumption figure and its 2030 projection. Each is a sentence, each is checkable, and none tells the team what to build.

• Choose the figure that shows a trend or a threshold, not the biggest number: use rising from 7% to 10% in a year, or 22% formally recycled, over a market size
• Name the source and the year in the sentence, link the page, and quote its words rather than paraphrasing a statistic; the rule in AI market research applies: every figure traces to a page you can open
• One figure for why now, one for why it matters, at most. A third belongs in the brief's data pack
• Prefer primary sources: the institute, the agency, the regulator; a vendor's survey in a vendor's press release is a weak anchor
• Let AI find candidates, not facts: an assistant can list the reports; a person opens each one before the figure goes in; see AI brainstorming for the division of labor
• If no figure exists, say so and give a first-hand observation: ten support tickets, a week of logs, a sponsor's quote. Evidence is not only statistics

Cut a slice, not a smaller problem. Most good problems are too big for a hackathon, and the wrong response is to shrink them into trivia. The right one is to keep the problem whole and define the slice a team can show by Sunday: one user, one moment, one input, one output. Utilities can't find leaks in pipes they never metered is a funded-startup problem on the Problem Radar; its weekend slice is ‘turn one district meter's night-flow data into a ranked list of pipe segments to inspect first.’ The problem keeps its stakes and its sufferer; the slice gives the team a finish line. The book's minimum required deliverable does the same job from the other end: it “defines a valid submission.”

• One user, one moment: not ‘readers,’ but a reader who has just received an answer and has thirty seconds; not ‘utilities,’ but the engineer choosing tomorrow's inspection route
• One input, one output: name the data that will be available (a sample, a public dataset, a sponsor's export) and the form of the result (a ranked list, a flag, a one-screen comparison)
• Keep the whole problem in the statement, put the slice in the sixth part, a good weekend result; the team sees both the mountain and the next foothold
• Scale is a facet, not a verdict: the Problem Radar tags each problem by what it would take, a hackathon, a side project, a funded startup or a moonshot; a hackathon can take a slice of any of them
• Match the deliverable to the slice: a concept pitch for a moonshot slice, a working prototype for a hackathon-scale one; the book notes that a requirement for functional code “naturally orients the event toward engineering teams”
• Say what is out of scope: one line. Teams waste Saturday on the part you did not want

The innovation agenda, the customers and a problem index, not a brainstorm the week before. In Innovation Mode 2.0, framed problems live in the company's problem space and are “exposed to the innovation community through the innovation agenda,” which answers “What problems are we solving and why?” A corporate hackathon should draw its statements from there, so the winners have somewhere to go on Monday. The second source is the front line: support tickets, sales calls, field engineers, the complaints nobody has time to fix. The third is a public index of framed problems; Ainna's Problem Radar publishes problems worth solving with their statements, sufferers, evidence and scale, and a hackathon pack of the ones a team can take on in a weekend.

• The agenda first: a hackathon connected to the agenda feeds “opportunities to the corporate innovation knowledge base,” the book's connected hackathon; one disconnected from it produces projects nobody owns
• Sponsors bring problems, not products: ask each sponsoring executive for one problem in the six-part format, and send back the ones that arrive as feature requests
• The front line: an afternoon with customer support or field service yields more honest problems than a leadership offsite; the problem framing discipline turns them into statements
• Public problems for public hackathons: an open index gives a university or community event problems with real stakes and evidence already gathered; every Problem Radar page ends with how to take it on
• Reuse across events: an unsolved statement is not a failed one; the book's “Stand-alone problems become assets” means a problem can run again with a better slice
• Reward the framing: the book counts “framing problems worth solving” as “an essential innovation behavior that should be recognized”; a prize for the best problem submitted is cheap and changes what people bring

One theme, three to seven statements, one open track. Fewer than three and the event is a build contest on one brief; more than seven and the judges compare incomparable things while half the statements go unchosen. The number should follow the size of the event and the number of sponsors who will own a problem: one statement per sponsor who will take the winner's work on Monday is a sound rule. The open track catches the teams who arrive with a problem of their own, and it should demand the same six-part statement from them, which doubles as the filter.

• Small event, under ten teams: three statements, one theme, no tracks
• Mid-size, ten to thirty teams: five to seven statements in two or three tracks, judged per track, plus the open track
• Large or public, more than thirty teams: tracks by domain with three to five statements each; a statement with no takers after registration is withdrawn and kept for the next event
• One sponsor per statement: the person who answers questions on Saturday and takes the winner's work on Monday; a statement with no sponsor is a theme
• Weight the statements equally: teams choose problems, not prizes; if one problem must attract more teams, say why in the brief, not with money
• Count the results: the book asks for success defined upfront as “numeric targets attached to specific metrics,” and statements chosen, slices delivered and opportunities carried forward are three of them; see hackathon success criteria

Eight questions, all answered yes, by someone outside the organizing team. Is there a person or role in the title? Is the verb an inability or a cost, not an aspiration? Could two strong teams attack it with different solutions? Is it free of product nouns (app, platform, chatbot, dashboard)? Does it carry one dated figure with a link? Is a sponsor named who will take the winner's work forward? Does it say what a good weekend result looks like? Would the problem still be true if the hackathon were cancelled? The last one is the test of a real problem against an event prop. The book's rule for the evaluation method applies to the statement too: it should be “well thought through, tested, and proven.”

• The stranger test: give the statement to someone who was not in the room; if they ask ‘so what do you want us to build,’ the gap is not clear; if they ask ‘for whom,’ the sufferer is missing
• The solution scan: search the text for build, create, develop, platform, app, dashboard, chatbot, AI-powered; each hit is a solution leaking in
• The evidence check: open the source of the figure yourself, the day you publish; a figure nobody opened is a rumor with a decimal point
• The scope check: write the weekend result as a sentence a judge could verify on Sunday; if it needs a quarter, cut the slice again; see scoping for a weekend
• The sponsor check: the sponsor reads the final text and agrees to answer questions on Saturday; a statement the sponsor has not read is the organizer's problem, not the company's
• The fairness check: no statement should quietly favor one team's existing project; the book asks for judges “not influenced by the team or other ‘political’ dimensions of the submission,” and the same goes for the problems

Add the deliverable, the criteria, the data and a name. The statement says what the problem is; the brief says what a valid answer looks like and how it will be judged. In Innovation Mode 2.0, the minimum required deliverable “is the artifact that defines a valid submission,” from “a concept pitch video to a functional demo or working software,” and the evaluation method must be “objective, consistent, and transparent.” A brief is one page: the statement on top, then the deliverable, the assessment criteria with their weights, the data and constraints, the sponsor who answers questions, and the slice that counts as a good weekend result. The book's Workshop Designer builds the hackathon page from “the initial event brief”; this is that brief, one problem at a time.

• The statement, unchanged, with its link to the full problem page if one exists
• The deliverable: what a team must submit to be judged, and what is optional; a two-minute demo and a one-page note on what they learned about the problem beats “working code” for inclusiveness
• The criteria and weights: published in advance; the book's transparency rule is that participants “understand the criteria, the weight factors, and the business reasoning”; see assessment criteria
• Data and constraints: the sample data, the APIs, the systems that cannot be touched, the privacy rules; for an internal problem this is where most of the value of a brief lies
• The sponsor: a named person, reachable on Saturday, who will take the winner's work forward; the hackathon setup template has the event-level fields
• The pre-read: the book's advice for workshops applies: “a single pager describing the motivation and desired outcome and a clear articulation of the problem statement,” sent before the event, not read aloud at the kickoff

Score the understanding of the problem first, the demo second. A judging sheet that rewards polish produces polished answers to the wrong question. Put the statement at the top of the sheet and ask, in order: did the team address the gap as stated, for the sufferer as stated; what did they learn about the problem that the statement did not say; does the slice work; could it be carried forward. Innovation Mode 2.0 asks that projects be “assessed against predefined criteria, according to a robust process, by experts who are not influenced by the team,” and that the method be robust enough that “a different group of judges applying the same evaluation process on a given set of projects should produce similar rankings.”

• Problem fit, weighted highest: the project solves the stated gap for the stated sufferer, not a neighboring problem the team preferred
• Insight: what the team found out on Saturday that the organizer did not know on Friday; the best projects change the statement
• The slice delivered: the good weekend result from the brief, demonstrated, not described
• Evidence over claims: a test with five users beats a roadmap slide; see hackathons as validation contests
• Carry-forward: who would own this on Monday and what it would take; the sponsor scores this line
• One model across events: the connected hackathon scores projects with the idea assessment model, so “projects can be compared and ranked across hackathons”; Ainna's Judge applies ten dimensions to every submission the same way; see how judging changes when AI builds

The demo is cheap, so the statement sets the bar on the problem. When any team can turn a description into a working application in an hour, the hackathon no longer tests who can build; it tests who understood what to build. Innovation Mode 2.0 describes the shift: “AI prototyping and no-code development make hackathons truly inclusive since non-technical members and teams can create fully functional applications with zero coding.” The statement has to respond: more weight on the sufferer, the moment and the evidence; a deliverable that includes what the team learned about the problem; criteria that score insight and validation above polish; and a sponsor who can tell a real answer from a fluent one.

• Raise the deliverable from “a demo” to ‘a demo and a finding’: one page on what the team learned about the sufferer, the data or the constraint
• Expect forty working prototypes: the differentiator is which problem slice each chose and what it proved; judging has to be built for that; see judging when AI handles the building
• Write the constraint line carefully: AI will happily build around a constraint it was not told about; the brief's data and constraints are now load-bearing
• Give the data, not the answer: a sample dataset and an API make the slice real; a reference architecture makes every team build the same thing
• Ask for the research: a team can summarize the market with AI in minutes; ask for the five conversations with sufferers that AI cannot have; see what AI cannot do for a first product
• Let AI write the first draft of the statement, then take it away from it: the book's intake experience “guides the user in creating valid, insightful problem statements using the problem-framing template”; the person still has to find the sufferer and open the source

Name the problem, not the model. An AI hackathon fails in a specific way: the statements are written about the technology (‘use a large language model to…’) and the problems are chosen because they fit it, so the event produces demonstrations of a capability rather than answers to a need. Write the statements exactly as for any hackathon, problem first, and put the technology in the theme (‘problems where language models change what is possible’) and in the brief's data and constraints. The Problem Radar's AI-answer problem is the model: AI is in the situation, not in the solution. Innovation Mode 2.0 is firm on the order: the framing template comes before any solution, and the problem space answers “What are we innovating on?”

• Problem first: the problem-first rule for AI investments applies to a weekend as much as to a budget
• AI in the situation is fine: many of today's best problems exist because of AI: unverifiable answers, agents on websites, fakes that pass checks. Those are problems, not use cases
• Specify the data, not the model: what the team may use and must not use; whether real user data is available; what the privacy rules are. The model choice is theirs
• Add the AI questions to the criteria: does it fail safely, can a user check it, what does it cost per use; the AI product management guide has the questions
• Watch for the capability demo: a project that could be about any problem is about none; the statement's sufferer and moment are the test
• Reuse: a good AI-era problem outlasts the model that inspired it; keep it in the index for the next event