A hackathon problem statement is the foundation of a successful hackathon. It explains the real-world problem participants must solve, who experiences it, what outcome is expected, and how submissions will be evaluated. A clear statement gives teams enough direction to build quickly without prescribing one narrow solution.
For organisers, the goal is not to describe an entire industry or ask for a vague innovation. The goal is to frame a specific, meaningful challenge that can be understood in minutes and explored deeply over the event. This is especially important for AI hackathons, where unclear goals, inaccessible data, and unrealistic expectations can prevent teams from producing useful prototypes.
What Is a Hackathon Problem Statement?
A hackathon problem statement is a concise description of a challenge that participants are invited to solve within a fixed time, usually by creating a prototype, technical demonstration, workflow, or minimum viable product.
A strong problem statement answers five questions:
- Who has the problem?
- What problem do they face?
- Why does it matter?
- What should participants build or demonstrate?
- How will the solution be judged?
For example, “Build an AI app for healthcare” is too broad. A more effective version would be: “Develop a multilingual AI assistant that helps community health workers identify common maternal-health risk indicators from structured patient information and provide an explainable referral recommendation. The prototype must support at least two Indian languages and clearly display uncertainty.”
The second version identifies the user, use case, expected capability, context, and important safety requirements while leaving room for different technical approaches.
Why the Problem Statement Matters
The quality of the challenge directly affects participation, solution quality, judging consistency, and the practical value of the outcomes.
It attracts the right participants
A specific statement helps participants determine whether their skills match the challenge. Developers, designers, data scientists, domain experts, and product builders can quickly understand what is expected.
It prevents wasted effort
Hackathons operate under severe time constraints. If teams do not know whether to build a prototype, train a model, integrate an API, or conduct user research, they may spend valuable hours solving the wrong problem.
It improves judging fairness
When success criteria are explicit, judges can compare different solutions against common standards instead of rewarding presentation quality or familiarity with a particular technology.
It increases post-hackathon value
A problem statement grounded in a genuine operational need is more likely to produce a prototype that can be piloted, funded, or developed further after the event.
Anatomy of a Strong Hackathon Problem Statement
A reliable structure makes it easier to write and review a challenge before publishing it.
1. Challenge title
Use a short, outcome-oriented title. It should communicate the problem without revealing only one implementation method.
Weak: “Use a BERT model for crop disease classification”
Better: “Help smallholder farmers detect crop disease earlier”
The better title focuses on the user outcome. Participants can decide whether computer vision, retrieval-augmented generation, edge inference, or another approach is appropriate.
2. Context and background
Explain the situation in two or three paragraphs. Include relevant operational, social, business, or technical context, but avoid turning the statement into a research paper.
Useful context may include:
- Current workflow and its limitations
- Number or type of users affected
- Existing tools or processes
- Geographic or language considerations
- Why the challenge is urgent
- Constraints such as connectivity, privacy, or cost
For an India-focused hackathon, context may involve multilingual users, low-bandwidth environments, public-sector workflows, UPI or Aadhaar-related privacy concerns, rural access, local governance, or uneven digital literacy. Include only details that influence the design of the solution.
3. Core problem
State the problem clearly and neutrally. Describe the gap between the current and desired state.
A useful format is:
> [User group] struggles to [complete task or achieve outcome] because [root cause], resulting in [measurable or meaningful consequence].
Example:
> District-level public health teams struggle to identify emerging disease patterns from fragmented weekly reports because data is submitted in inconsistent formats, resulting in delayed investigation and resource allocation.
This format prevents organisers from describing a solution before they have defined the actual need.
4. Target users
Specify primary users and, where relevant, secondary stakeholders. A system for a frontline worker may also affect supervisors, citizens, administrators, or auditors.
Describe users by role rather than by generic labels. “A person using an app” is not enough. “An ASHA worker with an Android phone, limited time, and intermittent connectivity” provides actionable design context.
5. Expected outcome
Tell teams what they should submit or demonstrate. The outcome could be:
- A working web or mobile prototype
- An AI model with an evaluation report
- An API and reference client
- A dashboard with sample data
- A workflow automation tool
- A simulation or digital twin
- A validated user journey and clickable prototype
Do not require a production-ready platform if the event duration supports only a proof of concept. Specify the minimum viable scope and distinguish mandatory features from optional enhancements.
6. Constraints and assumptions
Constraints make a challenge realistic. They also stop teams from winning by using unavailable or inappropriate resources.
Potential constraints include:
- Maximum inference latency
- Cloud or compute budget
- Offline or low-bandwidth operation
- Supported languages
- Data residency requirements
- Privacy and consent rules
- Open-source or licensed-model requirements
- Hardware availability
- Accessibility standards
- Integration with a specified API or data format
For AI challenges, state whether participants may use public foundation models, synthetic data, pretrained embeddings, external APIs, or human-in-the-loop review. If external services are allowed, clarify whether teams must disclose cost and dependency assumptions.
How to Write an AI Hackathon Problem Statement
AI challenges require more technical precision than general software challenges because model performance depends heavily on data, evaluation design, and deployment conditions.
Define the AI task
Avoid saying only “use AI.” Identify the task where AI may add value, such as:
- Classification
- Forecasting
- Information extraction
- Semantic search
- Document question answering
- Speech recognition
- Image segmentation
- Anomaly detection
- Recommendation
- Optimisation
- Generative assistance
Keep the approach open unless a specific method is part of the learning objective.
Describe the available data
Mention the data modality, approximate volume, format, labels, and access method. If real data cannot be shared, provide a representative sample, schema, synthetic dataset, or sandbox API.
Teams need to know whether they can train a model or should focus on retrieval, prompting, rules, fine-tuning, or system integration. A challenge requiring model training but offering no usable data is usually poorly designed.
Define evaluation metrics
Select metrics that reflect the actual use case. Examples include:
- Precision, recall, F1 score, or AUROC for classification
- MAE or RMSE for forecasting
- Exact match, citation accuracy, or groundedness for question answering
- Word error rate for speech
- Intersection over Union for segmentation
- Latency, throughput, and memory usage for deployment
- Task completion rate and user satisfaction for product prototypes
For imbalanced datasets, accuracy can be misleading. In a medical triage or fraud detection scenario, false negatives and false positives may have very different consequences. Explain how these trade-offs will be considered.
Include responsible AI requirements
AI hackathon problem statements should address safety from the start. Depending on the use case, require teams to demonstrate:
- Data privacy and consent handling
- Bias and subgroup performance analysis
- Explainability or evidence citations
- Human review and escalation
- Confidence thresholds
- Abuse and prompt-injection protections
- Monitoring and audit logs
- Clear limits on automated decisions
In high-impact domains such as healthcare, finance, education, employment, and public services, position the prototype as decision support unless the event has the governance, validation, and regulatory basis for automation.
Hackathon Problem Statement Template
Organisers can use this reusable template:
Challenge title
[Action-oriented title describing the desired outcome]
Background
[Explain the users, current workflow, and why the problem matters.]
Problem
[State the specific gap or difficulty participants must address.]
Target users
[Identify primary and secondary users, including relevant constraints.]
Challenge objective
[Describe what participants should build, test, or demonstrate.]
Available resources
[List datasets, APIs, documentation, hardware, SDKs, or sample workflows.]
Requirements
- [Mandatory capability 1]
- [Mandatory capability 2]
- [Technical or domain constraint]
- [Privacy, accessibility, or safety requirement]
Evaluation criteria
- Problem relevance: [weight]
- Technical quality: [weight]
- User experience: [weight]
- Impact and scalability: [weight]
- Responsible innovation: [weight]
Deliverables
[Repository, deployed demo, presentation, documentation, model card, test results, or video.]
Example Hackathon Problem Statements
Example 1: Multilingual citizen-service assistant
Problem: Citizens often struggle to understand eligibility requirements and application steps for public schemes because information is distributed across complex websites and documents in multiple languages.
Challenge: Build a multilingual assistant that answers questions using an approved document collection, provides citations, supports at least two Indian languages, and escalates uncertain or case-specific queries to a human helpdesk.
Evaluation: Citation accuracy, answer completeness, language quality, latency, usability, and resistance to unsupported claims.
Example 2: Small-business cash-flow forecasting
Problem: Small businesses may lack accessible tools for predicting near-term cash-flow shortages from invoices, expenses, and payment patterns.
Challenge: Create a forecasting dashboard using the supplied anonymised data. The system should show a forecast horizon, confidence interval, key drivers, and an understandable warning when data quality is insufficient.
Evaluation: Forecast error, calibration, interpretability, usability, and robustness to missing data.
Example 3: Crop advisory for low-connectivity environments
Problem: Farmers and field advisors may not receive timely, localised guidance when connectivity is unreliable and crop symptoms are described in regional languages.
Challenge: Develop an offline-first prototype that accepts text, voice, or images and produces a ranked set of possible crop issues with recommended next steps. The prototype must communicate uncertainty and avoid presenting a diagnosis as certain.
Evaluation: Task completion, offline performance, regional-language usability, recommendation relevance, and safety messaging.
Judging Criteria for Hackathon Submissions
Publish judging criteria before the event. A common weighted rubric includes:
- Problem understanding and relevance — 20%: Does the solution address the stated user need?
- Functionality and technical execution — 25%: Does the prototype work reliably within the available scope?
- User experience — 15%: Is the workflow clear, accessible, and appropriate for the target user?
- Impact and feasibility — 20%: Could the solution be adopted, operated, and scaled?
- Innovation — 10%: Does it offer a meaningful improvement over existing approaches?
- Responsible technology — 10%: Does it address privacy, fairness, security, safety, and transparency?
Adjust the weights according to the event. A research hackathon may prioritise methodological novelty, while a startup-focused event may emphasise customer value, deployment feasibility, and a credible path to adoption.
Common Mistakes to Avoid
Being too broad
“Transform education with AI” is a theme, not a problem statement. Add a target user, workflow, and measurable outcome.
Prescribing the technology
Requiring a particular model or framework can limit creativity and produce technology-first solutions. Specify the need and constraints unless the technology itself is the subject of the challenge.
Hiding the evaluation method
Teams should not discover after submission that latency, citations, accessibility, or business feasibility mattered. Publish the rubric and required evidence in advance.
Providing unusable data
Check data quality, licensing, labels, schema documentation, and access permissions before the event. Test the complete onboarding process with an external participant.
Ignoring deployment reality
A solution that works in a notebook may fail in a mobile, low-bandwidth, or public-sector environment. Include operational constraints and require teams to explain deployment assumptions.
Confusing a feature with a problem
“Build a chatbot” is a feature request. The problem is the user’s unmet need; the chatbot is only one possible solution.
Pre-Publication Checklist
Before publishing a hackathon problem statement, confirm that:
- The target user is specific.
- The problem can be explained in one sentence.
- The challenge is feasible within the event duration.
- Participants have access to required data and tools.
- Mandatory and optional requirements are separated.
- Success metrics are measurable or consistently assessable.
- Privacy, security, accessibility, and safety requirements are documented.
- Judges can evaluate different solution types fairly.
- Deliverables and submission deadlines are unambiguous.
- A domain expert has reviewed the assumptions.
Frequently Asked Questions
How long should a hackathon problem statement be?
The main challenge should be understandable in two to five minutes. A complete page is often sufficient, with links to separate technical documentation, datasets, APIs, and policies.
Should a hackathon problem statement include a solution?
It should describe the desired outcome and constraints, not dictate one implementation. Include an example workflow if participants need clarification, but allow alternative technical approaches.
What makes an AI hackathon problem statement good?
It has a concrete user need, accessible data or a realistic data substitute, defined evaluation metrics, feasible scope, deployment constraints, and responsible AI requirements.
Can a problem statement be based on a business challenge?
Yes. Business challenges work well when organisers anonymise sensitive information, provide realistic inputs, define the decision or workflow being improved, and clarify how commercial feasibility will be judged.
Where can Indian AI founders find grant and funding opportunities?
Indian founders can explore relevant programmes, funding pathways, and support opportunities through AI Grants India, especially when a hackathon prototype is being developed into a scalable AI venture.
Apply for AI Grants India
If your hackathon prototype addresses a meaningful problem and you are building an AI venture in India, explore funding and support opportunities through AI Grants India. Apply today to connect your technical work with the next stage of growth.