7 Rules for Winning Hackathon Ideation

Gabriel L. Manor
The Startup
Published in
5 min readSep 16, 2020

Hackathon is a great chance to embrace your internal entrepreneur and maybe get a chance to work on a super-interesting product that you initiate for a long time.

Unfortunately, many Hackathon ideas failed not because of a bad product idea, but because something was missing on the way it is represented. In the following post, I’ll share seven rules that I gathered from participating in many Hackathons last year (and won some of them).

First, before listing rules for winning ideas, let have criteria for a winner. My criteria include 3 principles:

  1. Win the Hackathon, grab the prize and go yachting the Bahamas :)
  2. The ability of the idea to get into production. It seems like every Hackathon winning idea will continue to be a winning product. Unfortunately, most of the ideas going waste before someone used them
  3. Giving you and the team credit for a long time. Some ideas do not belong to the team anymore just after they go to the standard development path

Now, when protocol defined, let's have some rules that will make your ideas worthy

1. Think about the problem, not the solution.

For us, as humans, it’s much easier to think about how we solve things. Unfortunately, when we need to make other humans connected to our ideas, we need to make them think they solve something themselves.

When you’ll need to represent your idea either for the potential team members or to the judgment circle you’ll want to speak about the problem in low details and the solution at the high level. There is no thumb rule for that, but I’m usually trying to have 70% of the deck describe the problem and only 30 for the solution.
The way of representing a well-defined problem will bond them with your way. So when the solution is there it will be a simple answer to why should they go with you.

To do not constraints your brain and since ideas start as solutions, do not look to find problems for the next Hackathon, problems will be anyway just anywhere. The rule is to refine a well-defined problem out from your brightest solution idea.

2. Production-ready MVP

The only time the team will work seriously on the idea will be the Hackathon timeframe itself (this is the reason I wouldn’t say I like to participate Hackathons with no dedicated timeframes)

Because of that, you’ll want something can go to your real customers with minimal effort

The easy way to make it is thinking how you are adding the idea to existing product/process and yet keeping the solution innovate as it was planned earlier

3. Don’t build cups

“Try to add something valuable from its side — like you have a glass for water and you add a round handle to it without changing the glass, and you get a cup” — Oleg Pekar

To bring something to production including real customers, you’ll need a lot of stakeholders. Especially if you are part of a huge corporate where sales are completely separated from R&D, program separated from the product, etc.

Shortest way is, you’ll need to think about how to add your bright idea into exiting products or processes. This way will ensure that every stakeholder you’ll get in touch after the Hackathon will find some time to break the daily routine and help you get customers

4. Turn your single sit into a round table

When you think about an idea, it’s just a natural process that you’ll think how will be easy for you to sit and do it alone or with team members that you fill comfortable with
To make your idea worthy to the real world, you’ll need a round table of different skills that can take it from idea to continuous product.

It’s not always easy, you can (as an example) think on your Hackathon time frame which the other side of the table can break the process. Yet, if you think as someone who wins already and customers using its products, you’ll understand that better done than perfect.

5. Listen

One of my long-winning ideas won just because only judges understand the real product potentials. This idea couldn’t win if the judge's factor was less than 80%
After a demo that no one in the audience (except the judges) understand what I’ve done, I decide to have a learning path to find my little failure
And, surprise. The people I discuss after was the exact people that I need to talk with them before ☺️

Your head is constrained to your thought process and if you do not share your thoughts, it became a mind prison. Think about a prisoner that held phone store, go to jail in 2006, and went out in 2014. He couldn’t even imagine how to re-open his store after the smartphone revolution.
Be open; it’s worth it

6. DARE TO SUCK

Don’t shut yourself or anyone else down because you think an idea sucks or is dumb — yeah, maybe it is, but come up with the next idea, come up with another one!
Even if 9 out of 10 ideas suck, that 10th one could be awesome!

The thing is, imagination is like a muscle — you have to exercise it, and it gets stronger. That is actually what I think is the most important aspect of doing hackathons regularly, to focus on creativity and imagination specifically

Special thanks to Mark Basinski for pointing this out!

7. Continuous process

As I wrote, people work on the idea by Hackathon timeframe and then it becomes easy to forget
You’ll want to find some stuff that will make people want to continue work with you. There are many ways to do it. e.g. for engineers, work technologies that not using in the group earlier and people want to learn. In this way, after the Hackathon, you can make people committed to your idea because they want to continue being part of the process

Still here? Thanks for reading, good luck in your next Hackathon.
I’ll be happy to hear for you on your secret spices, just please add them in the comments so I can make this article a continuous product 🤪

--

--

Gabriel L. Manor
The Startup

Sharing my insights on developing healthy and stable relationships with developers (aka DevRel). Engineering Director, Growth & DevRel @ Permit.io