I was not a developer (or a designer) when I signed up for my first hackathon. In fact, the people I met kept asking what I did for a day job and I couldn’t find a concise way to say I was a consultant but had already quit my job and was seeking product opportunities at startups and learning development. Anyways, I hope to shed light on what one does and how one adds value as a non-developer at a hackathon and help to reduce any anxiety or uncertainty holding you back.
Be ready with ideas or find someone who is
You’re at a hackathon for christ’s sake. It’s all about execution and not about spending time you don’t have doing market or user research. Come in with some ideas, or if you’re like me, come up with ideas on the fly based on everyday pain points. If you play more beta, it is absolutely ok to not have ideas and join a person/team that does.
Figure out your role on the team
This was probably my second biggest aha. So I went into the experience assuming I’d be pretty useless because I couldn’t design or develop. I pretty much thought I’d just get in the way and have many stfu moments. Turns out, there is a lot of stuff that goes into building products that even designers and developers need help with, including:
- Ideating and strategizing — high-level what you are building to solve what problem, and what features and visuals would be good to create for your target users. This is where you get people on board with your vision
- Talking through UI/UX design and user flow with the designer — it’s beneficial for you to be a sounding board for your designer, especially if you’re the visionary. Very rapidly talking through how you expect a user to interact with the product and how best to display the information. We had a lot of back and forth on our team, especially because the idea kept evolving. I also supported the designer by searching and downloading icons to use for the app and giving feedback on color choices and user flow
- Supporting the developer — treat Google as your best friend (this is almost more of a life/startup tip than a hackathon-specific one). For our app, we had to aggregate data from different sources and I was in charge of downloading the data for the developer. Then we realized that the available data only came in XML format whereas he wanted them in JSON. Without asking what the heck XML and JSON were, I tried to help by using an online convertor/parser. That resulted in some errors that I fixed, and then some invalid JSON code that I couldn’t fix and had to rope the developer back in
- Liaising between the designer and developer — sometimes not everyone on the team gets along. Be prepared to be the go-between/peacekeeper and communicate with both to keep them on same page regarding progress and changes
- Conducting user research — so I knocked it earlier because of lack of time, but you do have time to ask random people wandering around what they think of your product/concept. Of course, you take what they say and choose the bits you want to implement (which likely ends up being none of it. Let’s be real, you know your product and resources and constraints the best) but at least you get validation and can drum up some support for your idea
- Managing time — don’t assume people will stick to a deadline and know that the timeline will constantly change as your product evolves and problems crop up. Be flexible (e.g., if the developer needs 1 more hour than you had planned) but only because you built in time cushions to begin with. Keep people aware of how much time they have left and what is required to finish on time
- Creating the presentation — developers don’t use powerpoint — they’d rather throw up a text editor or just demo the app/site. Designers don’t use powerpoint, though some can make presentations. Either way, figure out who on the team is least sucky at creating presentations. There’s an art to them — you have to tell a compelling story (try to make it personal and relatable) to hook the audience, then how you went about solving the problem, then demo the app/site, then go into next steps “if we had more time, this is what we aspire to do…” If you do this part well with lots of audience engagement (shown via intense Q&A), it’ll push you to the next level. It’s all about the packaging, people
- QA-ing — the second day when we were finalizing the app and presentation, our developer decided to not show up. So it was just me and the designer spending a few hours polishing everything. Once we were done with our respective deliverables, we swapped and I QA-ed his prototype (making sure all the buttons connected to the correct pages, etc.) and he QA-ed my presentation (making sure the story and wording made sense)
- Presenting/demoing — some people are naturally gifted at giving presentations and connecting with an audience and eliciting laughs. We actually got quite a few laughs for ours and afterwards people came up to us and said they had experienced the same pain points. But I can honestly say I can’t remember the last time I publicly spoke and it is definitely not a strength of mine. But do it regardless, you won’t regret it. It is one thing you can only learn through iteration and it’s cool to be able to practice in front of a room full of strangers
As a note, unless there’s an explicit team leader, there’s no one telling you what you should or could be doing. You need to figure out what you can do and what needs to be done and play in the center of the Venn diagram. Or you can play project manager and run the show. Just don’t sit there useless or idle — there is ALWAYS something that needs doing.
Shit changes. Quickly. Shit goes wrong. Often
What you set out to build in the beginning — that grand, shining vision — most likely will have changed 5-10 times by the deadline. In the real world, you have more time to hash out ideas, sleep on it, and run it by multiple people. At hackathons, the time you spend deciding what you want to build and how to build it cuts into time that could be spent actually building it. So, some obstacles you should be prepared to deal with:
- Your original idea was too grand — you started building and realized some things take longer than you had anticipated and you have to cut back or risk not finishing at all
- Problems with development — all developers run into issues. Some they cannot solve or have already wasted too much time solving. Just cut, re-group, move on
- What you built is not what you had conceived — this happened to us. We were solving this data problem with this cool aggregation idea, but once the app had been halfway built, we realized the solution was frankly really boring. So we stood back to re-evaluate the app and came up with this fun feature that of course we didn’t have time to actually connect a backend to, but it added this level of usefulness and delight for users and elevated the app from snoozeworthy to something worth talking about
- Someone decides to not show up or not deliver — this happens and you either have to package the presentation differently and/or work with what you have. This happened to us — there were some things we wanted to add/change the second day, but the developer dropped out, so we re-designed things a little so that you wouldn’t notice the missing bits
Shit, I learned a ton in 24 hours. And unexpectedly walked away with a trophy and a friend ☺
But my whole reason behind participating was that startups don’t take people who have no experience for test runs. The exchange usually goes like: you’ve never shipped a product? Dude, I’m not gonna place life/death of my startup on your lack of experience. No matter how you good you think (or know) you are, show me proof. (Actually the real exchange happens in the recruiter/hiring manager’s head and you just get dead silence.)
So, this hackathon was the first of my many steps. Hackathons seem way more scary written out like this. Learning while doing is infinitely easier than trying to learn by reading through this, I swear. So sign up for a hackathon and go at it yourself!
@xinisterlayer
