Teams lose more hackathons in the first hour, when they pick a problem statement, than in any hour that follows - and the mistake is almost always picking based on the wrong criteria.
The instinct to avoid
The natural pull is toward the most ambitious-sounding problem statement, the one that would make the best story if you pulled it off. Smart India Hackathon's own guidance to participants pushes directly against this instinct: pick a problem statement your team can meaningfully demo in the time given, not the most ambitious one on the list. This isn't specific to SIH - it holds for essentially every hackathon with a fixed build window. A working partial solution to a realistic problem beats an unfinished attempt at an ambitious one almost every time a judge compares the two.
What actually matters when choosing
Can you demo the core value in the time you have? Before committing, sketch the smallest version of the solution that would still convincingly show the idea works. If that smallest version still feels like more than your team can build and test in the available hours, the problem statement is probably too large regardless of how good the underlying idea is.
Does your team already have relevant strength here? A problem statement that plays to skills your team already has (a domain one of you understands, a technical stack you're already comfortable with) lets you spend your limited hours building instead of learning from scratch. Novelty is appealing, but a hackathon window is rarely long enough to learn a new domain and execute well in it simultaneously.
Is the scope actually testable? Some problem statements are vague enough that "success" is unclear even to the team attempting them. If you can't articulate what a working demo of this specific problem would concretely show a judge, that ambiguity will cost you time mid-build when the team disagrees about what "done" means.
What data or resources does it actually require? A problem statement that assumes access to data, hardware, or APIs you don't actually have lined up is a scope risk hiding in plain sight. Confirm you can get what you need before committing, not after you've already started building around an assumption.
A practical way to decide as a team
Give every team member five minutes to independently sketch what the smallest working version of each candidate problem statement would look like, then compare notes. If multiple people land on wildly different scopes for the same problem statement, that's a signal the problem itself is ambiguous - a bad sign regardless of how interesting it sounds. Pick the problem where the team converges quickly on a shared, buildable interpretation.
Once you've picked
Choosing well is only the first decision - how to split roles across your team and protecting time for integration and the pitch (not just building) both matter just as much once the clock actually starts.
Where to find hackathons with well-defined problem statements
Amazon's ML Challenge and most company-run hackathons on Brabble's upcoming feed publish problem statements or datasets upfront rather than leaving scope entirely open, which makes this kind of pre-commitment scoping easier to do well.