Corporate hackathons: taking a prototype to a pilot

My experience with this format began at Shawee and continues to guide the work I am building today. Explore the journey from Shawee to NewHack and the lessons on hackathons and communities.

In a corporate hackathon, teams work on company challenges over a defined period, with support to develop and present solutions. The format concentrates collaboration and experimentation around those problems.

I have been advocating for hackathons as environments for exchange, co-creation and testing use cases. In the NewHack series in 2024, I discussed how this format brings business and technology people together to experiment with the possibilities opened up by AI. That ability to learn together is an important part of the gathering's value. NewHack EP. 016, from 04:50.

When the objective includes applying a solution within the company, it is useful to design the transition to the work that follows. The roadmap below is a practical proposal for organizing that continuity.

This execution builds on the discussion about how large companies can connect with startups to innovate.

Start with a decision the company needs to make

“Reducing factory downtime” opens up too many possibilities. A more useful challenge defines a task and the question that needs answering: can a tool bring together similar failure reports to help the maintenance team identify recurring issues?

This focus makes it possible to identify who knows the problem, where to look for examples and how to recognize a useful response. It also helps choose participants: the people performing the task, those who understand the data and those who can build and assess the solution.

Before the event, record how the work happens today. This could be the time spent on a step, the frequency of rework or the difficulty reported by users. That baseline will serve to evaluate the pilot. If the process is not yet measured, the first test can include learning how to measure it.

Separate what has been demonstrated from what remains to be discovered

A prototype shows an idea working under certain conditions. A pilot puts a defined version in front of users and situations close to real work, with monitoring. Deployment expands that responsibility to include operations, support, maintenance and integration into daily routines.

For the hackathon deliverable, ask each team to show three things: what it managed to test, what evidence it found and what still depends on an assumption. A demonstration may use prepared data, a simulated integration or manual review. Recording those conditions helps determine the scale of the next step.

This also changes evaluation. Beyond presentation quality, judges can assess the problem's relevance, the soundness of the test and the feasibility of continuing. The criteria need to appear in the brief so teams know what to develop and document.

Choose a pilot that can answer the main question

Imagine a hypothetical example: a team develops a tool that groups maintenance reports by possible failure type. During the event, it organizes a few prepared records well. The next question is whether it helps technicians identify recurring issues in operational records.

The pilot can begin with one equipment category, an authorized set of records and groupings reviewed by technicians. The test would compare the analysis effort and record incorrect groupings, relevant incidents that were left out and situations the tool could not interpret. Volume and duration need to reflect how often these cases occur.

If a technician spends less time organizing reports but needs to correct almost every grouping, that is an important signal to investigate. If the tool works well and nobody uses it, the team needs to understand how it fits into daily routines. Quality, use and operational effort help explain the result together. In this test, maintenance decisions remain with the responsible team.

For AI agent projects, Microsoft recommends assessing business impact, technical feasibility and user interest, as well as defining metrics to guide whether to continue, adjust or stop the initiative. These criteria help plan the transition from experiment to pilot. Microsoft guidance.

Complete a continuity brief

Before starting the pilot, gather the answers on one page:

• Problem and audience: which task will be improved, and who is participating in the test?
• Hypothesis: what needs to happen for the solution to be considered useful?
• Current baseline: how is the task performed and measured today?
• Scope: which cases, data and integrations are included in this stage?
• Owners: who monitors users, quality and technical operation?
• Decision criteria: which evidence indicates that the work should continue, be adjusted or end?
• Resources and timeline: how much time can the team dedicate, and when will it review the results?

This brief is a suggested template that can be adapted to the context. Its role is to make commitments visible. For a pilot to begin, someone needs to have real availability to monitor the work, gather feedback and make decisions.

Does the winning project have to be deployed?

The decision depends on the hackathon's objective and the available evidence. One team may produce valuable learning and discover that the solution requires unavailable data or a larger process change. Another may present a simpler proposal that already enables a useful test.

Awards and continuity can have different criteria, provided that is clear from the outset. Ending a hypothesis after testing it can also prevent a poorly directed investment. The care lies in documenting the reason for the decision and sharing that learning with the people involved.

If your company is preparing a challenge, it is useful to discuss the problem and the expected follow-through before finalizing the event format. Learn about NewHack's work in hackathons and corporate innovation.