Why
Hackathons are the cheapest reskilling program you can run.
Workshops teach concepts. Hackathons teach reflexes. When my team needed to ramp up on AI tooling in 2025, I stopped running 90-minute training sessions and started running two-day hackathons every quarter. The shift in fluency was immediate. People do not learn AI tools by watching a Loom. They learn by sitting next to someone who is already using them and trying to ship something real on a deadline.
The secondary effect is cultural. A team that has shipped a working prototype together in 48 hours trusts itself differently. The next product review feels less abstract. Designers who were quietly avoiding AI tools because they did not want to look slow in front of their peers get over that fear inside one cycle, because the hackathon makes it normal to fumble through new tooling out loud.
Setup
Pick a real problem. Pair designers with engineers. Cap it at 48 hours.
The single most important rule is that the output has to be a working prototype, not a slideshow. Force teams to demo the thing running. The minute you allow slides, you let people hide.
A few logistical calls that consistently make or break the event. Block calendars hard. If people are dropping into other meetings, the hackathon becomes background noise. Pick a physical or virtual room with a clear start and end time. Order food. Give every team a Slack channel and a shared doc on day zero so they are not scrambling for tools at hour one. Boring, but the teams that get these basics wrong always underperform their potential.
- Choose a problem the product team has actually been struggling with. Not a fake brief. Real ones make the work matter.
- Pair every designer with at least one engineer or PM. The point is shared reflexes, not solo heroics.
- Cap the work at 48 hours. Time pressure is what forces people to use the tools they have been avoiding.
- Provide a baseline stack (Cursor, Lovable, Claude, Figma, a working dev environment) so nobody loses day one to setup.
Day One
Frame, fork, and force a working spine by end of day.
Day one has one job. Every team has to have something running by end of day, even if it is ugly. The morning is for framing: the team picks the slice of the problem they are going after, names the user, and commits to one outcome they will demo. The afternoon is for building a spine. A working prototype that does the thing badly is infinitely more valuable than a beautiful Figma file at the same point in the timeline.
Your job as the leader on day one is to walk the floor and unblock. Not to design. Not to PM. Just to remove specific blockers: a missing API key, a stuck install, a team that is two hours into debating scope. The teams that win are usually the ones that closed scope by lunch on day one and spent the rest of the time iterating.
Day Two
Polish what works, kill what does not, write the story.
Day two is where the work either compounds or quietly dies. The morning is for ruthless triage. Keep the parts of the prototype that demo well. Cut the parts that do not. The afternoon is for two things at the same time: making the demo path bulletproof, and writing the one page story (what we built, why it matters, what we learned about the tools). The story matters as much as the prototype. Teams that ship a great demo and skip the writeup get forgotten inside a week.
Three of the last five hackathons my team ran turned into shipped features within the same quarter. Including one that produced 3 million dollars in monthly revenue.
The Demo
Invite product, eng, and leadership. Run it like a real review.
On the last afternoon, every team demos to the broader product org. Ten minutes each. The audience asks questions like they would in a normal product review. Two outcomes follow. First, the team gets honest signal on which ideas are worth taking forward. Second, leaders across the org see what their teams can do with two days and the right tools, which is usually enough to unlock funding for the real version.
A small format choice that matters: do not give awards. Awards turn the hackathon into a contest and quietly punish risk taking. Instead, end the demo block with a leadership commitment. Name the one prototype that will get a real sprint in the next planning cycle, and name the leader who will sponsor it. The room shifts immediately from "that was fun" to "that was real."
After
Pick one prototype to ship. Write down what the team learned.
The week after the hackathon is where most teams quietly waste the energy. Make it explicit. Pick one prototype to take into the next sprint. Write a one-pager about what the team learned about the tools (what worked, what broke, what to do differently next time). Share it with the broader org. Repeat the hackathon next quarter. Three or four cycles in, you have a design team that operates with reflexes most orgs are still trying to train through workshops.
Keep a public log of what each hackathon produced and what it cost. Two days of designer and engineer time per cycle is not free, and the only way to keep getting permission to run them is to show the ROI in plain terms. The math is usually overwhelming in favor of doing more of them, but you have to write the math down.
Common Failure Modes
The five reasons hackathons stop working, and how to fix each one.
- Fake briefs. Fix: only run them on real problems the team will recognize from the roadmap.
- Solo heroics. Fix: enforce pairing and cap solo entries.
- Slide-based demos. Fix: require a live, working flow during the demo block.
- No follow through. Fix: name the sponsoring leader and shipping team before the room empties out.
- Quarterly cadence drift. Fix: put the next four dates on the calendar at the end of the current event.