# How Do You Write a Hackathon Problem Statement? URL: https://ainna.ai/resources/faq/hackathon-problem-statement Markdown: https://ainna.ai/resources/faq/hackathon-problem-statement.md Title: How to Write a Hackathon Problem Statement: Template Published: 2026-10-01 Updated: 2026-10-01 Read time: 25 min read Audience: Hackathon Organizers, Innovation Program Managers, Heads of Innovation, University and Community Hackathon Organizers, Chief Innovation Officers, Hackathon Sponsors Summary: Guide for hackathon organizers on writing problem statements that teams can act on in a weekend. Built on Innovation Mode 2.0 (the hackathon theme as the problem space, the problem-framing template, the minimum required deliverable, the evaluation method) and on Ainna's Problem Radar, whose published problems serve as worked examples. Covers what a hackathon problem statement is; the difference between a theme, a track, a challenge and a statement; why statements fail (a solution in disguise, no sufferer, no evidence); how specific to be; the six parts of a statement; the problem sentence; evidence without a report; scoping for a weekend; where problems come from; how many statements per event; the challenge brief; judging against the statement; what changes when teams build with AI; and statements for AI hackathons. Key takeaway: A hackathon problem statement is one paragraph that names a situation, the gap in it, who lives with it, why now and why it matters, with evidence and without a solution, plus a line on what a good weekend result looks like. Write it from the innovation agenda or a problem index, not from a brainstorm the week before; keep the theme as the space and the statement as the problem; scope it to a slice a team can show by Sunday; attach a deliverable and assessment criteria that reward understanding the problem over polishing the demo, which matters more now that AI makes the demo cheap. Key concepts: hackathon problem statement, problem space, hackathon theme, focus areas, challenge brief, problem framing, Problem Framing Template, current state, ideal state, who lives with it, why now, minimum required deliverable, evaluation method, idea assessment model, Problem Radar, innovation agenda, connected hackathon, Workshop Designer What you'll learn: - What a problem statement is, and theme vs track vs challenge vs statement - Why most statements fail: a solution in disguise, no sufferer, no evidence - The six-part template, the problem sentence, and worked examples from the Problem Radar - How to scope a problem for a weekend, where problems come from, how many to run - The challenge brief, judging against the statement, and what AI changes ## What a Problem Statement Is For The job of the statement, the vocabulary, why most fail, and how specific to be. ### What is a hackathon problem statement? One paragraph a team can act on Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#what-is-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” Key takeaway: Write the statement so that a stranger can read it in a minute, name the sufferer and the gap, and start. If it needs a presentation to explain, it is a theme. ### Theme, track, challenge or problem statement: which is which? Theme is the space, statement is the problem Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#theme-track-challenge-or-problem-statement 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 Key takeaway: Say the words in the brief and in the judging sheet: this is the theme, these are the tracks, this is the problem you are solving. Teams will stop solving the theme. ### Why do most hackathon problem statements fail? They hide a solution, or the sufferer Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#why-hackathon-problem-statements-fail 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” Key takeaway: Read the draft and strike every verb that names a product, then add the person who suffers and the figure that says it is now. What is left is a problem statement. ### How specific should a hackathon problem statement be? Specific about the gap, silent about the fix Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-specific-should-a-hackathon-problem-statement-be 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 Key takeaway: Name the gap and the constraint; never the fix. If the statement already contains the demo, the hackathon is a build contest with extra steps. ## How to Write One The six parts, the problem sentence, the evidence, the weekend scope, where problems come from and how many to run. ### What goes into a hackathon problem statement? Six parts, one page at most Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#what-goes-into-a-hackathon-problem-statement 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 Key takeaway: Six parts, in that order, on one page. The first five come from the framing template; the sixth is what makes it a hackathon statement rather than a research brief. ### Is there a hackathon problem statement template? Yes, six lines to fill in Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#hackathon-problem-statement-template 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 Key takeaway: Six lines, filled in from the sufferer's side, with one figure and no product noun. The template is the discipline; the example is the altitude. ### How do you write the problem sentence itself? Who can't do what, and when Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-write-the-problem-sentence 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 Key takeaway: Write the title last and test it first: who can't do what, and when. If the sentence does not exist, the problem is not framed yet. ### How do you add evidence without writing a report? One figure, one source, one date Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-add-evidence-to-a-problem-statement 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 Key takeaway: The statement proves the problem exists and is now; the team proves the solution works. One figure, one source, one date is the whole evidence budget. ### How do you scope a problem for a weekend? Cut a slice, not a smaller problem Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-scope-a-problem-for-a-weekend 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 Key takeaway: A weekend cannot solve the problem; it can prove the first move is possible. Write the problem whole and the slice precisely. ### Where do the problems come from? The agenda, the customers, an index Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#where-do-hackathon-problems-come-from 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 Key takeaway: Problems come from where the pain is recorded: the agenda, the front line and an index built for it. The week-before brainstorm produces themes. ### How many problem statements should a hackathon have? Three to seven, plus an open track Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-many-problem-statements-per-hackathon 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 Key takeaway: Three to seven, each with a sponsor, under one theme, with an open track that uses the same format. The number of statements is the number of people who will act on Monday. ### How do you check a problem statement before you publish it? Eight questions, all answered yes Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-check-a-problem-statement-before-publishing 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 Key takeaway: Eight yeses from a stranger, the source opened, the sponsor signed. Then publish, and do not edit the statement after registration opens. ## Running It The challenge brief, judging against the statement, what AI changes, and statements for AI hackathons. ### How do you turn a statement into a challenge brief? Add deliverable, criteria, data and a sponsor Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-turn-a-statement-into-a-challenge-brief 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 Key takeaway: Statement, deliverable, criteria, data, sponsor, slice: one page per challenge, published before registration. Teams choose better when they can see the whole brief. ### How should judges assess projects against the statement? Score the understanding first, the demo second Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#how-to-judge-against-the-problem-statement 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 Key takeaway: The statement is the yardstick; publish it on the judging sheet. A team that understood the problem and showed one true thing about it should beat a team that shipped a prettier answer to a different one. ### What changes in the problem statement when teams build with AI? Cheap demos, so the problem sets the bar Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#what-changes-when-teams-build-with-ai 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 Key takeaway: When building is free, the problem statement is the hard part of the hackathon. Spend the design time on it, and judge the understanding, not the finish. ### How do you write a problem statement for an AI hackathon? Name the problem, not the model Anchor: https://ainna.ai/resources/faq/hackathon-problem-statement#problem-statement-for-an-ai-hackathon 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 Key takeaway: Write the problem as if the technology did not exist, then say in the brief which technologies the teams may use. The best AI hackathon problems would still be problems without AI.