Software for Product People

Check us out on Product Hunt

How We Hacked the Worlds Largest Hackathon

Posted by Niel on Dec 9, 2013 3:58:00 PM

There has been a lot of discussion recently about the $1M Salesforce.com hackathon and whether the winners of that hackathon did or did not deserve their top position. As the stakes in hackathons go up, more and more they are becoming serious events with serious teams. We thought it would be fun to outline the approach Team Ramen took when competing in Jason Calacanis’ LAUNCH Hackathon and how we beat out 1600 other developers and designers to win the top prize.

First, its important to say that hackathons attract a lot of different types of folks with lots of different goals. That is a good thing. Many teams go there with the intention of getting on stage and winning whatever prizes there are. Many attend simply for the fun of it (I ran into someone who had done 10 of them that year alone). Some show up to hack for a few hours and then go home on the first night. Some don’t even know what they are there for (free food?) and just sort of roll with it. It’s a delightful melange of incredibly smart, creative and driven folks all crammed into one room for arguably too many hours in a row. For Team Ramen however, we decided before we got on the plane that we were going there to try and win.

The following is a blueprint for what we did and how we approached the hackathon. I am sure many of the teams did some of these things and likely a few even did all of them. And in every case I think there was some luck involved. That said, I believe the combination of a great team, solid base idea, and the approaches I’ll outline below gave us as good a chance as any to win the event. Along the way we talked to a lot of people and I was really impressed with many of the ideas. We definitely had some stiff competition for the podium. Someday maybe we’ll to do it all over again and see if our approach proves itself out twice. As a side note, one of the offers now available on Ramen is for our whole team to come to a hackathon of your choice and apply these practices to your idea.

I have broken this post into two parts. The first focuses on high level philosophy about how to approach a hackathon as a winnable event. The second, coming later this week, is a more tactical play-by-play of what we did on the ground during our 48 hours. We’ll also be publishing a whole bunch of data about what we did while we were there. I think the data will show that complete products can be built in 48 hours if you’ve got a well oiled team.

We committed our first line of code at 8:01pm on Friday and our last at 3:59pm on Sunday. Team Ramen is a machine. I’m have been incredibly proud and lucky to see it in action.

Hack #1: Pick Your Audience

A lot of hackathon attendees take their own personal passion projects to hackathons. There is nothing wrong with this, but if you have a room full of sponsors and judges whose backgrounds and bios are published online ahead of time, it's silly not to work on an idea that would resonate with them. The LAUNCH team constantly updated their site with who would be judging and we poured over these folks, their backgrounds, their investments, and previous videos of events they had been involved in. We knew a lot about who our audience would be before we set foot in the Metreon and made sure it fit with what we wanted to build: a better way for software projects to start.

There are so many hackathons these days (a good list of them is published and organized by AngelHack) you can almost always find one that matches your passion. It can’t be understated how important this is to your chances of winning and also simply how much fun you’ll have. Other great hackathon sites include: Hackathon.io and Hacker League.

Hack #2: Play to the Crowd

For us, the crowd was 1600 awesome developers and designers. We knew all of them would wake up on Monday morning having just spent 48 hours of their lives working on something and 1596 would be asking “What next?”. Possibly the smartest thing we did was find a project that actually answered that question. One of the coolest parts of the judging process was when we were on stage presenting to the bleary eyed few who stayed till the end and a few folks hooted and hollered when we explained that we just built something that might help turn their weekend dream into a reality. I think we totally nailed this, and it's a subtlety many do not think about. One of the hackathon finalists from last year built a very cool iPhone to desktop connector app that allowed one button launches of scripts. All the scripts they showed off were for developer-centric tasks like deploys to the cloud, opening new files, etc.. basically what all the people in the audience had been battling against for the last 24 hours. This totally played to the crowd. Very smart.

Hack #3: Pick Your Project Before Hand

While there is an element of fun and genius showing up at a hackathon and saying “What should we build?” we believe we had an advantage having picked our idea about 3 weeks before the hackathon started. Sometimes just letting things stew a while goes a long way.

Hack # 4: Know the Rules

There has been a lot of consternation recently over the Salesforce.com hackathon judging process and outcome. This all comes down to understanding the rules and how to use them to your advantage. The basic rules of the LAUNCH hackathon were no coding or design assets before the start, but planning and wireframes were acceptable. There is a huge amount of subtlety built into hackathon rules that you can use to your advantage. For example, while no coding was allowed, one of the things we did was explore possible APIs like LinkedIn, Stripe and AngelList that we thought we might use during the hackathon. We used some of them, others we skipped due to time constraints, but the research into them before hand saved us hours of going down a path and having to back up and explore something new. Executing hackathons is all about efficiency of time.

Additionally as wireframe prep was allowed, we spent about 4 hours over a couple sessions wireframing and discussing what we wanted to build. It’s amazing how powerful a whiteboard and a wireframe is for surfacing philosophical discussions that would take hours to debate in the heat of battle. You simply don’t have that time during the hackathon. By aligning the team on the steel thread of product philosophy, we saved hours of debate or even worse forcing someone to be King Solomon at 3:30am. Emotional wounds are almost worse than technical when the pressure is on.

Additionally while design assets (e.g. screen mock ups) were not allowed, there are an incredible amount of resource libraries out there now that you can browse through and share as a team to facilitate discussions around aesthetic, UX interactions you like, etc.. Even concepts like flat design versus more traditional, color palettes, and things we liked about comparables (in our case a pretty wide mixture of influences like Kickstarter, Pivotal Tracker, Assembly, 99 Designs, Dribbble, etc..) generated a lot of alignment in the team before we even set foot in the Metreon Center.

Ironically, my favorite project I encountered at the hackathon was a team from Denver who was building this exact process as their project. It was an app for agencies to work with their clients to identify sample design elements online that resonated with the client. I was surprised they did not place actually as this process which we did by hand saved us probably 5-10 hours during the hackathon. Great project idea I hope they turn it into a product or launch it on Ramen!!

Hack #5: Team Composition

One of the things we really liked about the LAUNCH hackathon is that you had to validate your credentials as a developer or designer to even be allowed to participate. To some extent this directly informed the core “three c’s” thinking in Ramen, one of which is “credibility”. We knew we could take up to 4 people, so we did. We took 2 developers, 1 designer, and one developer-turned-project manager/cat herder/infrastructure/content writer. More on hackathon project management later, but I think we may have been one of the few teams that invested a large part of one of four precious resources into this role.

An interesting side note is that only one of us had ever been to a hackathon before (one of the developers). A second interesting side note, he won his two other hackathons!

Hack #6 : Story Driven Development

While the core team was getting all the infrastructure up and running, I played content creator, sat down and wrote out the story we’d like to tell to the judges. We started to call this story-driven development and it came in incredibly handy in many places along the way. When you’re on a tight deadline, you need a lens through which to prioritize features and work. Having your storyline as this lens is very useful.

There was one point where we were 4 hours into building a Ramen project input screen like Kickstarter has, and it just wasn’t working. I asked “Is this even in our story? Why are we working on it?”. We all agreed it wasn’t and dropped it immediately. We decided to use plain old HTML instead which had the additional benefit that we didn’t need to consume development cycles building, designing and tweaking it. We jettisoned a lot of functionality like this along the way which saved us tons of time. Just for kicks here are the 5 stories that we wrote on Friday afternoon that framed the whole rest of the experience. You’ll see we played with a lot of angles including some blunt ones. In the end I’m really happy with what we picked (you can read our general philosophy on the project page of Ramen). This is copied word-for-word from one of the docs we wrote in the first few hours of the hackathon.

Standard

Our goal was to build something for every team at this hackathon.

Once everyone goes home, you will be faced with an even more daunting challenge than staying up for 48 hours bringing your idea to life: finding the first 100 customers who will use it. To make matters worse, even if you can find those 100 customers, how will you work with them to find the MVP you could launch a company around? Ramen solves this problem.

Ramen is the first funding market specifically designed for software startups. Many of you will be thinking, “okay, Kickstarter for software,” but that’s really not it. The fundamental difference is how Ramen follows through where Kickstarter stops; at the point where a project is backed. In Kickstarter, once you’re funded, your supporters are basically not involved. In Ramen, its quite the opposite. Let’s show you the difference.

Aggressive

Almost everyone builds software the wrong way. We build it and hope they will come. How many of us just spent 48 hours building something without ever asking a potential customer for feedback. But, we’re not the ones to blame. Millions if not hundreds of millions of dollars have gone into software startups that were never vetted by a potential customer.

Wasted time and wasted money and too much failure. The projects that succeed start with the customer. Ramen is here to change the game for everyone. Ramen is the unprecedented convergence of online funding, early adopters interest, and collaborative iterative design…

Kickstarter Sucks For Software

Kickstarter sucks for software. Its missing the three most important things that software startups need to get off the ground: customers, credibility, and collaboration. Ramen is the first funding platform built from the ground up for software startups. We focus on the whole software development process from validating the basic product need through customer pre-orders to finding the MVP feature set with a special platform designed for project teams to collaborate with their first early adopter customers.

Ramen is the way that all software should be built. No more wasted hours, not more wasted investment dollars. Let us show you how you can start building on Ramen...

Kickstarter Meets AngelList

Every time we work on a software project, we wish Kickstarter and AngelList had a love child. Kickstarter provides unprecedented access to pre-funding while AngelList provides the social proof requires to gain momentum with a new startup. Ramen is the perfect blend of both.

Ramen focuses on the three most important things to getting a software startup off the ground: credibility, customers, and collaboration. When you put your software project on Ramen, not only do we help you find pre-orders from your first 100 customers but we give you a platform to engage them in the development of your MVP. No more wasted hours on features no one wants, no more wasted development dollars trying to find product market fit.

Let us show you why the best startups begin with Ramen…

The 3 C's

Every software startup needs three things: cash, customers, and collaboration. Ramen is the first funding site design for software startups. By building a community of early adopting customers and providing project teams with collaboration tools to work with those customers through to MVP, we are revolutionizing the way software startups are built. No more wasted hours on features no one wants, no more wasted development dollars trying to find product market fit, and no ideas left behind because the project team didn’t have the network to find their first 100 customers. One of the things i was fascinated by was at 4:15p on Sunday, 15 minutes after pencils-down on development, many teams were huddled in corners with notepads trying to write their demo scripts. I was very impressed that so many teams knew this was an important part of the process. It dawned on me that 99% of teams would be squeezing whatever they had build into a the best story they could tell from it rather than having spend their time building as much of the story they wanted as possible. I’d rather have 48 hours to do perfect a story then 48 minutes to make one up.

Hack #7 : Design First Development

Once we had our storyline down we then committed to designing everything first. Our designer started spinning up core assets, grids, and general layout of pages. We then worked systematically through each page in our product designing first and debating about the design before we waded into code. This proved incredibly useful as it provided a level of cohesiveness to the overall product we created as well as the ability to parallelize work once the first mock was done. We also had a beautiful storyboard of what we were building when the judges started coming around.

There was a moment where we showed off each of the well designed screens to a judge and it was pretty and she said “Wow that’s amazing, so when will this be done?”. We bit the bullet and gulped and committed to having it all running by judging time. But we had already won an important early battle around making an impression and being able to visually share the whole vision with a judge. This is sort of like the storyboards that get made for movies. The director will have a shot-by-shot book of sketches of exactly what is going to happen before the camera rolls and the expensive stuff happens. Design is similar. It’s a lot cheaper and smarter than using your developers to start scorching earth and having to rework code.

One of the things we noticed is that not a lot of teams put much emphasis on design in their projects. We thought this was a greatly missed opportunity because so many projects were technically brilliant. When it comes to the demo, the more you have to wave your hands and say “imagine this”, the harder it is for someone to fall in love with your project no matter how brilliant the code is. One of the finalists, FinalRev did a gorgeous job of emphasizing design in their project. Some of their project functions overlapped with a edge of ours and I was envious of how 48 hours dedicated to those pieces of the puzzle made even our great design look very mediocre.

Hack #8 : Content Matters

Almost every single project required some sort of content in it. If it was an app that showed street listings in San Francisco, you needed pictures of houses or descriptions of property. If it was a review app you’d need review content and star ratings and different user pictures and profiles. In Ramen, we needed all the underlying project descriptions of the example projects in our marketplace. Rather than just toss in Lorem Ipsum (dummy text) or leave them blank, we actually wrote out three complete project writ- ups that we’d accept today into Ramen complete with screenshots and technical specifications. Each was between 750 and 2000 words! On top of that, our story emphasized real people, so we needed content around them. Who were the project backers? Champions? Etc. We scraped LinkedIn content for profiles and information and populated the system with live profiles of people so the system seemed alive. Our designer put a lot of work into making our final content look beautiful and one of the things it did was simply make our product look way more polished to the judges. So many project teams got up there with awesome ideas and basically unpopulated content and it really diminished the impact of how powerful their presentation could have been.

As an example of how much effort we put into this, here is one of the complete project descriptions I wrote during the hackathon. As Kevin on our team likes to point out (because I use a Lenovo), I probably wrote it in Times New Roman, HTML 1.0, by hand with no syntax highlighting, in Microsoft Word 97 (3 of these 4 things are actually true).

Hack #9 : Focus on a Whole Product and Launch It

One of the things we were determined to do was build a complete end-to-end product. This would not be possible without everything I mentioned from planning to wireframes to story driven development to content. Our story allowed us to tell a thin but complete story. And we also decided we wanted to launch it. And we did. At 3:59pm, one minute before the cut off. We then hammered our networks to get some attention to it and we actually got about $1000 of funding into Ramen before we ever talked to a judge. Few of the teams built complete products, most built features. Even fewer actually launched something to the public. This goes all the way back to knowing your audience.

While we totally understand that hackathons are not meant only for teams who go there to win, if you do want to win, it's probably useful to know a bit about the sponsors. If you listen to Jason talk about LAUNCH and the hackathon, he has stressed over and over that his mission is to actually launch products during the hackathon. This seems to be lost on almost everyone. But we totally played to this, and it was a lot of the reason we got early attention. When we first gave Jason a glimpse of what we were doing on Saturday (an opportunity offered to all and taken by only a few - another topic I’ll cover in part II) we committed to him we would launch this by the end. And we did.

That’s a lot for now. We’d love to hear your questions or comments below. Part II is coming soon which will be a play-by-play of how we executed everything from 8:00pm on Friday night to 3:59pm on Sunday evening.

How can you help?

1) We're currently backing Ramen on Ramen. If you believe in us, please consider backing us. We hit our goal. Thanks everyone!

2) Share this post (just click to tweet)!

3) Join the Invite List and we'll keep you updated on Ramen!

 

Topics: Development, Design

About Ramen

Ramen is the best way for SaaS Product Teams to have true "Product Success" by making it easy to learn about their customers, ask those questions targetted questions, and discuss features and product ideas with them.

Subscribe to Email Updates