The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Robert Fedoruk
Tera Sage
Tera Sage

Now that you have no excuses from attending, lets discuss the end-game:   Victory.   Having competed in 5 hackathons, with 4 final four finishes, and 3 wins, here's a few things I've learned.

1 - Think big, then think bigger

Almost every hackathon win starts with a *much* smaller idea revolving around a feature.   Your job is to think of progressively bigger consequences and applications to the feature.

  • "Hey, wouldn't it be cool if people could vote on projects?" turned into a complete rebuild of Kickstarter in ServiceNow, complete with skill / cash donations, and buzz aggregation.   We challenged the way an enterprise could propose AND decide AND fund AND staff their projects.
  • "Can we integrate with twitter" turned into a social media asset management system, with campaign automation.

Forcing yourself to think bigger and bigger will ensure a few things

  • your solution is framed inside a problem that people can feel
  • you expand your own horizons on the platform capability
  • you produce more angles to tell your story
  • you aren't dismissed as a "cute" feature that doesn't really do anything

2 - Story telling and development are equally important

None of it matters unless you can develop it.   But even if you develop it, you need someone to tell its story.   Lets not kid ourselves about human decision making.   For the most part the feelings rule, and the mind compensates.   Whatever it is you develop, your audience has to *feel* it.   In many ways this is a hack all on its own.   How do I maximize the *emotional* impact of whatever it is I'm doing.

Look, at K13 there were *far* more impressive technical feats than what we won with.   Turning ServiceNow into a blackjack game?   Biometric scanning integration?   FAR harder to pull off.   The only reason we won is we capitalized on the cold patronage of the modern corporation.   "Hey, isn't it bullsh!t that so few people influence what projects are actually done at a company?"   "You're right!   That *IS* BS!".   They were bought into our story before they even saw the product.

Another example?   At K15 our team didn't even finish, and I STILL have red hand prints on my back from the kudos we received.   It wasn't our product, it was the story we were (attempting) to tell.

3 - It *only* has to work

This was my hardest lesson over 5 hackathons.   Your application will *not* be used.   In only a matter of hours, it will cease to exist.   The care we take in our daily lives is to ensure the tool works reliably for the longest duration possible.   You, my readers and only friends, have a one-way trip to a single point in time (the pitch).   Cleanliness doesn't count.   There is no such thing as "proper".   "Done" is only measured by "did it work at the pitch".

Remove all safety measures.

(Practical and specific pro tip:   Don't put your app in a scope for hackathon, unless you're specifically hacking app scopes)

4 - Know your storyteller ahead of time

Not every one has their story made up before they get to Hackathon.   Statistically, 75% of all participants will be building someone else's idea.   It *is* advantageous to know who the story alpha is before you get to Hackathon.   You're not supposed to pre-develop or migrate code into the Hackathon, and I thoroughly agree with that.   But if you can deconstruct and plan the work ahead of time, you'll save yourself some churning guts.

1 Comment