How to run a use-case hackathon that actually ships something

The internal AI hackathon has a bad reputation, mostly deserved. Done lazily, it's a fun afternoon that produces nothing: toy demos on fake data, a winner's mug, and no change whatsoever to how anyone works on Monday. Done properly, it's the single fastest way I know to surface a firm's real use cases, build genuine capability, and leave working prototypes behind — because the people building them are the people who'll use them, on their own tasks, with their own files.

The difference between the two outcomes is decided almost entirely before anyone enters the room.

01The prep is the product

For every hour of hackathon, expect several hours of preparation. This is what that looks like:

• Meet the team first. Before the event, sit down with the people who'll attend — or at least their leads. Understand what a normal week looks like, where the drudgery is, what's been tried before. The best use cases are usually complaints in disguise.
• Inventory the tools, honestly. What do attendees actually have access to on the day? Which models, which connectors, which integrations — can the AI reach SharePoint, email, the deal drive? What's blocked? A hackathon designed for tools people don't have is a demo, not a hackathon. This audit also tells you what's realistically operationalisable afterwards.
• Write out the candidate use cases in advance — and verify them. Collect ideas from the team beforehand, write them up properly, then test-drive each one against the firm's actual stack before the event. Nothing kills a session's energy like a team discovering at minute 40 that their idea needs a data source nobody can reach. You want a bench of pre-verified ideas ready for any team that arrives without one.
• Pick the teams deliberately. Two or three people per team, and think about composition. Sometimes you go vertical — a whole team from one function (legal, finance, the investment team), working on their shared workflow. Sometimes horizontal — mixed seniority and mixed functions, which spreads capability and surfaces cross-team use cases. Both work; choose based on what you want out of the day. What doesn't work is random assignment.

02Open with 30–60 minutes of training

Don't skip straight to building. The opening session sets the ceiling for everything after it, and it needs to cover exactly three things:

1. Core principles. What the tools are genuinely good at (first drafts, synthesis, reformatting, structured output) and where they bite (overconfidence, context gaps). Plus the golden guardrail for anything factual: if it's not in the documents, say Not Found.
2. Get the AI to help you build. The single most useful habit on the day: before doing anything, ask the model to plan the approach with you. We give every attendee a starter prompt for exactly this (below).
3. What's connected. Show which integrations are live — files, email, internal document stores — so teams design use cases around what the AI can actually reach.

Prompting fundamentals matter more than any feature walkthrough, and you don't need to invent the material — Anthropic's applied team has a solid, free 25-minute version worth stealing from^[1]:

03The run of show: 80 minutes, one real task

The brief to every team is the same: pick something from your actual day-to-day — a report, a summary, a brief, a review — and build it with AI during the session. Real task, real files, real output. Here's the clock:

Show and tell is strict: three minutes per team, four beats — the title, what the task was, a walkthrough of what they built, and the honest question that turns a demo into a pipeline: what would it take to operationalise this — or is it ready to use now? That last answer is the real output of the day. It becomes the prioritised backlog for the build phase that follows.

04Go deeper, not wider

Teams that finish early always want to start a second use case. Don't let them. The value curve bends upward as a single use case climbs four levels:

Level 2 is where the compounding starts: a prompt that worked becomes a saved skill anyone can run with one click — a pattern Anthropic has since formalised as an open standard, with pre-built libraries for financial services you can borrow from rather than starting cold^[2][3].

05Seed ideas by team

Every team is told "feel free to bring your own" — but a pre-verified menu means nobody stares at a blank page. A sample of what we put on it, by function:

06Why this works when top-down programmes don't

MIT's enterprise AI research found that deployments succeed when adoption is driven by the people who own the workflows — line managers and their teams — rather than a central lab pushing tools outward^[4]. A hackathon is that finding turned into an event: the team picks the use case, builds it on their own work, and presents it to their own colleagues. Ownership is baked in from minute one. And because the ideas were verified against the firm's real stack in prep, the distance from prototype to production is short — which is the whole point.

If you want the honest version of this for your team — prep, facilitation, and the follow-through that turns the winning prototypes into operational workflows — that's exactly what I do.