Converging on a Project When the Hackathon Has No Direction
The hardest part of a hackathon is often not the coding — it's day one, everyone around a whiteboard stuck on "so what do we build?" This is how this project converged from scattered ideas into something both doable and worth doing — a method any small team can reuse.
The starting point
A team of four (1 PM, 2 editors, 1 engineer) with one shared context: everyone works in the same content industry. Nobody knew what to build at the start — and that's normal, and the point: a good project isn't dreamed up, it's filtered out.
① Diverge first, don't rush to focus
The first step isn't "find one good idea", it's lay out a batch of directions — no fear of too many or of overlap. We listed several angles — some leaning toward content production, some toward information-gathering, some toward playlist curation, some toward scheduling.
The only discipline here: quantity first, no judging. Criticizing too early kills ideas before they grow.
② Filter by real pain, not by what's coolest
Convergence isn't about "which is flashiest", it's which hits what everyone actually struggles with daily. Laying out each person's pain, one shared theme kept recurring:
Past a certain volume of content, "is the content itself well understood and findable" becomes the bottleneck — classifying, searching, organizing all snag on the same thing, seen from different roles.
→ Once aligned to pain, the line "make content understood + findable" surfaced immediately, while flashy-but-painless directions (scheduling, cross-channel rewriting) sank on their own. Three people hurting over the same thing from different angles is a strong signal.
③ After voting, merge instead of either/or
More than one option landed close in the vote. We didn't force an either/or — we looked at which ones stack into the same main line: combining "automatically understand the content" and "find content on demand" into one system that feeds itself, rather than two half-built features.
Many teams get stuck on "is it A or B?" Often the answer is "A as the core, B as support" — treat closely-ranked options as stackable layers, not mutually exclusive walls.
④ Lock the project with feasibility and scope
Late in convergence, two reality checks set the boundary:
- Can this be built within the hackathon? Keep what's medium-difficulty and prototypeable; anything needing heavy scraping + scheduling automation gets marked "later, if there's time".
- What's the minimum to prove? Rather than piling on features, get the "core experience" to a demoable state first.
→ Constraints aren't the enemy. "What we won't do right now" often frames the project faster than "what we want to do".
⑤ Carve out the smallest verifiable scope — and dare to cut
Finally, split into "core first / rest parked":
- Core (what actually got built): auto-tagging, semantic search, and the curation/awards organizing that extends from them
- Extension (listed but cut): the real-time information-gathering line — heavy on work, not the core experience, deliberately dropped to concentrate time on the demoable main line
Listing something in the proposal and then cutting it isn't failure, it's focus. A hackathon's most common death is wanting to do everything and finishing nothing. Only when you can cut does the project come out clean.
And divide the work on the spot — who owns data, who owns UX, who tests quality, who defines the category standard. A project you can carve an MVP from and split into roles — that's when convergence is actually done.
Five steps, in one line
List many → filter by real pain → merge the close-ranked → frame with feasibility → carve an MVP and dare to cut.
A hackathon's time is short; the half-day spent picking the right project beats three days heads-down in the wrong direction. The best project is usually the intersection of three things: the team genuinely hurts over it, it's technically buildable, and nobody's done it yet.