How to Win A Hackathon: Lessons from a Four-Time Hackathon Judge

Why solving the right problem, understanding your users, and communicating your value can matter just as much as writing great code. In this post, you will learn how to win a hackathon: Lessons from a Four-Time Hackathon Judge

I’ve had the privilege of participating in several hackathons over the years, serving as a judge on four occasions, a technical facilitator twice, and a mentor on multiple occasions.

These experiences have given me the opportunity to observe hackathons from different perspectives: listening to teams pitch their ideas, evaluating their solutions, challenging their assumptions, and helping them turn concepts into working prototypes.

And one thing has become increasingly clear to me:

Building a working solution is not the same as building a solution worth adopting.

I’ve seen teams demonstrate impressive technical capabilities yet struggle to clearly explain the problem they are solving. Some present ambitious ideas aimed at almost everyone but fail to address the needs of any particular audience effectively. Others develop promising solutions but struggle to convince judges why anyone should choose their product over existing alternatives.

At the recently concluded Zecathon 6.0, where I served as both a Technical Facilitator and a Semi-Final Judge, I had another opportunity to observe how teams approach innovation under pressure.

Something particularly interesting happened during the competition. The teams that ranked first, second, and fifth in our aggregated semi-final scores eventually finished in those same positions in the final, despite presenting before a different set of judges.

That experience reinforced something I’ve come to believe: strong teams demonstrate their quality consistently. Their ability to understand a problem, articulate their solution, and defend their decisions is rarely accidental.

So, if you’re preparing for your first hackathon or hoping to improve your performance in your next one, here are some lessons I’ve gathered from my experience on the other side of the judging table.

1. If You Cannot Clearly Define the Problem, You Are Not Ready to Pitch the Solution

One of the most common situations I’ve encountered as a hackathon judge is listening to a team explain their solution for several minutes without clearly identifying the problem they are trying to solve.

Sometimes, I have to interrupt and ask a simple question:

“What exactly is the problem you are trying to solve?”

It sounds like a straightforward question, but you’d be surprised how difficult it can be for some teams to answer.

They can describe their application’s features, explain the technologies they’ve used, and walk you through the different screens. But when asked to define the problem in one or two sentences, they struggle.

Another variation of this problem is when teams try to build something for everybody.

Their solution targets students, businesses, professionals, government agencies, individuals, and practically anyone who might find it useful.

The ambition is understandable. They want to demonstrate that their idea has a large potential market.

But trying to solve everyone’s problem often results in solving nobody’s problem particularly well.

A large potential audience does not automatically make a problem significant.

Instead of starting with how many people could use your solution, start by identifying a specific group of people experiencing a meaningful problem.

Ask yourself:

• Who exactly experiences this problem?
• What are they trying to achieve?
• What prevents them from achieving it?
• How frequently does this problem occur?
• What happens when the problem is not solved?
• Why is this problem important enough to address?

For example, imagine a team pitching a platform that helps businesses manage their operations.

That description is too broad.

Which businesses are you targeting? What aspects of their operations are you trying to improve? And what specific challenges do they face?

Now imagine the same team saying:

“Small retail businesses struggle to maintain accurate inventory records because sales and stock updates are handled manually, leading to stock discrepancies and missed sales opportunities.”

Suddenly, the problem is clearer.

We know who is affected, what they are struggling with, and why the problem matters.

The team now has a foundation on which to build a meaningful solution.

My advice: Before you write your first line of code, make sure every member of your team can explain the problem you’re solving in one or two sentences without mentioning your proposed solution.

If you cannot do that, you probably need to spend more time understanding the problem.

2. Your Solution Must Be Designed for Your Target User, Not for Yourself

Identifying a problem and defining a target audience is a good start.

But it is not enough.

Another issue I’ve observed is that teams sometimes identify a specific user persona, only to design a solution that does not reflect that person’s needs, circumstances, or behaviour.

They know who their target users are, at least on paper, but the actual user experience tells a different story.

For example, imagine a team building a financial management application for small-scale traders who have limited digital literacy.

The team identifies these traders as its primary audience but goes ahead to build an application filled with complicated dashboards, technical financial terminology, and multiple steps to perform simple transactions.

The application might be technically impressive, but is it truly designed for the people it claims to serve?

Would those users understand it? Would they be comfortable using it? Does it fit naturally into how they currently work?

A solution is only useful when the intended users can realistically adopt it.

When you define a user persona, it should influence your design and engineering decisions.

Think about the user’s environment, digital literacy, access to technology, daily routines, motivations, and constraints.

These are not minor design considerations. They can determine whether your solution is adopted or ignored.

My advice: For every major feature you build, ask yourself: “How does this make life easier for the specific person we are trying to help?”

Your user persona should not exist only on your presentation slides. It should be visible in the decisions you’ve made while building your solution.

3. Stop Building Solutions Based Entirely on Assumptions

Hackathons are time-constrained, and I understand that participants do not always have the luxury of conducting extensive research.

However, limited time should not become an excuse for making unsupported assumptions.

I’ve encountered teams that make confident statements about their target users, the scale of a problem, the inadequacy of existing solutions, and the potential impact of their product without presenting much evidence to support those claims.

Sometimes, the entire solution appears to have been designed around what the team believes users need rather than what users actually experience.

There is an important difference between identifying a problem and validating that the problem exists in the way you think it does.

For instance, a team might assume that people are not using a particular digital service because the existing applications are too complicated.

But what if the real issue is trust?

What if users are concerned about transaction security, hidden charges, or unreliable service delivery?

Building a simpler interface would not necessarily solve those problems.

This is why research matters.

And no, research does not always have to involve weeks of interviews or an elaborate survey.

Depending on the competition rules and the time available, you can:

• Speak with a few people who experience the problem.
• Review credible industry reports and existing research.
• Study competing products and their customer feedback.
• Examine existing workflows and identify friction points.
• Look for evidence that users are already trying to solve the problem.
• Separate what you know from what you are assuming.

Even a few meaningful conversations with potential users can challenge assumptions that might otherwise lead your team in the wrong direction.

The same principle applies to your proposed solution.

Do not assume that because you’ve built a feature, users will find it valuable.

Do not assume that because a technology is innovative, it is the best choice for the problem.

And certainly do not assume that because your team likes an idea, the market will embrace it.

My advice: Make a list of your most important assumptions before building. Identify which ones could invalidate your entire idea if they turn out to be wrong, and prioritise testing those assumptions.

A hackathon may not give you enough time to validate everything, but you should be able to demonstrate that your decisions are informed by evidence rather than guesswork.

4. If Your Solution Already Exists, Give Me a Reason to Choose Yours

One question I frequently find myself asking teams is:

“Why would someone use your solution instead of what is already available?”

This becomes particularly important when teams are proposing business-to-business (B2B) solutions.

Imagine a team building a platform to help organisations manage employee attendance.

There are already products that provide attendance tracking, reporting, integrations, and workforce management capabilities.

So what makes this new solution different?

Is it designed for a specific industry that existing products do not serve particularly well?

These are the kinds of questions teams should be prepared to answer.

And even when your idea appears to be new, you still need to explain why your target customers would adopt it.

For B2B products, there is another important question:

“Why should an organisation pay for your solution instead of building something similar internally?”

This is where understanding your Unique Selling Proposition (USP) becomes essential.

Your USP should communicate the distinctive value your solution provides to your intended customers.

Saying that your product is “innovative,” “AI-powered,” “user-friendly,” or “scalable” is not enough.

Those descriptions do not automatically establish a competitive advantage.

You need to explain what your solution does differently and why that difference matters to your customers.

For example, perhaps your solution reduces the complexity of integrating with several existing systems. Perhaps it addresses a specialised workflow that general-purpose products handle poorly. Or perhaps it offers a level of domain-specific functionality that would be expensive for an organisation to develop and maintain internally.

Whatever your advantage is, make it clear.

Also remember that the alternative to your product may not be another software application.

It could be a spreadsheet, a manual process, an outsourced service, or simply continuing to operate as things are.

My advice: Research your alternatives, identify what they do well, and explain the specific gap your solution addresses.

Do not try to convince judges that no competition exists. Show them that you understand the alternatives and have a compelling reason for your solution to exist.

5. Don’t Just Tell Me Your Product Saves Time and Money. Show Me What I’m Paying For

Another recurring challenge I’ve observed is how teams communicate the commercial value of their solutions.

A team presents a product, introduces a subscription price, and then struggles to justify why customers should pay that amount.

When asked about the value customers receive, the answers often revolve around broad claims such as:

“Our solution will save time.”

“It will reduce costs.”

“It will improve productivity.”

These are legitimate potential benefits, but they are not sufficient on their own.

How much time could it save? Which costs could it reduce? What specific capabilities does the customer receive in exchange for payment?

And importantly, what evidence supports those claims?

Let’s imagine a team proposing a subscription-based platform for small businesses.

Instead of simply saying the platform saves time and money, the team could explain that subscribers receive:

• Automated inventory tracking.
• Low-stock alerts.
• Sales and inventory reports.
• Multi-user access with role-based permissions.
• Integration with an existing point-of-sale system.
• Data export and backup capabilities.
• Customer support.

Now the customer can understand what the subscription includes.

The team can then connect those capabilities to measurable business outcomes.

For example, automated stock updates might reduce manual reconciliation work, while low-stock alerts could help businesses avoid running out of popular products.

But these outcomes should not be presented as guaranteed savings without supporting evidence.

There is also an important distinction between what a product offers and the value those capabilities create.

Features explain what customers receive. Benefits explain why those features matter. Evidence helps establish whether those benefits are credible.

A convincing pricing strategy should bring all three together.

For B2B solutions, you should also understand who makes the purchasing decision, what budget the product might come from, and what makes the proposed price reasonable compared with the available alternatives.

My advice: If you’re presenting a paid solution, be prepared to answer three questions:

1. What exactly does the customer receive?
2. Why are those capabilities valuable to that customer?
3. Why is your proposed price reasonable?

You may not have a fully validated business model during a hackathon, but you should be able to explain the reasoning behind your pricing assumptions.

6. Your Pitch Should Make the Problem and Solution Obvious Within the First Minute

You may have built an excellent solution, but if the judges cannot understand what it does or why it matters, you are making their job unnecessarily difficult.

I’ve listened to presentations where teams spend too much time introducing themselves, describing the technologies they’ve used, or walking through a long list of features before explaining the problem.

By the time the problem becomes clear, a significant portion of the presentation has already passed.

Remember that judges may be evaluating several teams within a limited period.

They should not have to work hard to understand your idea.

A strong pitch should quickly establish three things:

Who has the problem? What is the problem? How does your solution address it?

For example, consider these two approaches.

Approach A:

“Good afternoon, judges. We are Team Innovators, and we’ve developed an AI-powered, cloud-based platform using React, Python, and machine learning to transform how businesses operate.”

That introduction tells me very little about the problem.

Now consider a different approach.

Approach B:

“Small retail businesses often struggle to keep accurate inventory records because sales and stock updates are handled manually. This can lead to stock discrepancies and missed sales. We’ve built a simple inventory management tool that automatically tracks stock levels and alerts business owners when popular products are running low.”

Within a few seconds, I understand the intended users, the problem, and the proposed solution.

The team can then proceed to demonstrate how the product works.

Notice that the second approach does not begin by mentioning the technology stack.

That is intentional.

The technology matters, especially when technical implementation forms part of the judging criteria. But the audience first needs to understand the value of what you’ve built.

I would recommend structuring your presentation around a simple sequence:

Problem → Target User → Solution → Demonstration → Differentiation → Impact

Start by explaining the problem and why it matters.

Introduce the people affected by it.

Show how your solution addresses their needs.

Demonstrate the most important functionality.

Explain what makes your approach different.

Then conclude with the impact you expect to create and the evidence you have to support it.

You can adjust this structure to suit the time available and the competition’s judging criteria.

My advice: Rehearse your pitch with someone who knows nothing about your project. After the first minute, ask them to explain the problem and solution back to you.

If they cannot do that, simplify your presentation.

Winning Begins Long Before the Final Pitch

One lesson I’ve learned from judging and mentoring hackathon teams is that technical implementation, while important, is only one part of a successful submission.

You need to demonstrate that you understand the problem, the people experiencing it, the alternatives available, and the value your solution provides.

You also need to communicate those things clearly enough that someone encountering your project for the first time can understand why it matters.

This does not mean that every technically strong team will win, or that presentation skills alone can compensate for a weak solution.

Different hackathons have different objectives, judging criteria, and expectations.

But regardless of the competition, teams improve their chances when they combine thoughtful problem selection, user understanding, credible research, focused execution, and clear communication.

And here’s something I believe is even more important:

Don’t build only to impress the judges. Build something that would still make sense after the hackathon is over.

Winning a hackathon can be a fantastic achievement. But building the ability to identify real problems, validate assumptions, make sound engineering decisions, and communicate value is a skill that will serve you throughout your career.

Whether you walk away with the trophy or not, those are skills worth developing.

This article is based on my experiences as a hackathon judge, technical facilitator, and mentor. In subsequent articles, I’ll explore more lessons on building effective teams, developing the right MVP, using AI responsibly, preparing compelling demos, and avoiding common mistakes during hackathons. But before then if you like this article, you can check out Lessons for Software Engineers or other articles in my blog.