How Hackathons Helped Us Build a Company with 50 Employees in Just 18 Months
As Thanksgiving came by this year, it reminded me about all the wonderful things for which I’m thankful, from my family and friends to the amazing team that built Branch. It’s hard to believe that just 18 months ago there were just four of us, alternating between squatting on campus to attending every available hackathon so that we could exchange ideas with other teams struggling to grow their app businesses. Today, have a team of 50 and our SDK is in thousands of apps like Pinterest, Buzzfeed and Instacart. We went from handling 0 to 900 million users in such a short period of time by helping developers grow their apps and deliver better user experiences.
How did we do it? Many of the things that helped us grow fast are lessons we learned from our early days going to hackathons.
From Angelhack, to the Stanford BigHack, to Launch to the Techcrunch Hackathon, we have attended them all. Here are the things we learned while building prototypes and becoming a team:
Good enough is better than perfect. By forcing yourself to do a hackathon, you have a limited amount of time to build something. This forces you to build quickly and get something complete, even if it’s not perfect. While that may not be what you ultimately release, you’ll be amazed at how much progress happens in a day when your team is focused. Moreover, if you keep practicing your execution will improve over time.
Just start building. Instead of roadmapping all your products, sometimes it’s good to force yourself to committing to a hackathon, during which you’ll build an initial rev. Sure, you’ll have to redo it, but it’s a start in the right direction. And if you fail, keep going and keep building, as my co-founder Alex writes about in his post on our company inception.
Team building and different perspectives: Hackathons force you to think about things more deeply and in a different light (and with different viewpoints) than you’d normally get in everyday work. That’s because you’re not focused on your existing projects or KPIs, so you get to form new teams with different people to achieve a different type of task. We believe in this so much that Branch now has started internal hackathons. By having people work together who otherwise never interact, we force new ideas and perspectives that exponentially accelerate the progress of an idea.
This process helped us transition from building prototypes to building our first product, an app called Kindred Photobooks. Applying this same process to building and growing Kindred, we were able to abstract learnings as app developers that formed the idea for Branch.
Putting partners first: Our growth would have not happened without partners. We call app developers that use Branch partners instead of clients, because we actually see what we do as a collaboration. Together we are building products that help improve mobile growth and makes in-app content more discoverable, making links to app content behave like the web. Having partners reminds us every day how grateful we are they use our service.
Sure, Branch has thousands of partners now. In the early days our partners helped provide invaluable feedback and new ideas that helped the product improve dramatically over time. We will forever be grateful to early partners like Vango and Gogobot, whose support and feedback helped us make our product better.
It’s also important to note that being a partner doesn’t end with incredible support times or prioritized feature requests. To us it means supporting our partners’ products (our first piece of office art was bought on Vango, our first partner, we use Instacart for all our office deliveries and book our rooms when we travel with Hotel Tonight) and helping build a mobile growth community so that they can also have a place to discuss and test new ideas like we did at hackathons.
Building a team — using forcing functions: When I look at how we moved so fast, I know that we couldn’t have done it without the right team. It starts with understanding how we built our founding team and how we tried to keep the same culture as we grew to 50.
We formed as a team in a d.school class at Stanford called Launchpad with a very different idea — Fitbit for Dogs. We iterated quickly, built a product, made $2k in pre-sales and abandoned the idea at the end of 10 weeks when we realized it wasn’t the right one for us. But going from ideation to building and selling a hardware product in 10 weeks does something amazing to a group of strangers — it made us into a team.
This experience helped us as we moved through new ideas, launching the Kindred Photobooks app and creating Branch from that experience. Adding deadlines and external pressure to launch forced us to work quickly,learn how to adapt, distribute tasks efficiently and quickly get to a result. As we grew the team, we continued to apply these lessons by attending hackathons as a team initially and creating our internal hackathons to test new products we want to launch into the market.
The other important part in building a great team is transparency. When we were small, we started by sharing our calendars and having meetings where we were very upfront about what we could do to change or to make the team better. Now, it means we create email groups for each team within Branch that is CCed on most internal and external communication that anyone can subscribe to. It means we present the board slides to the whole company and that every other Monday each team goes through their KPIs to share their accomplishments with the company.
Execution:
Lastly, growing fast comes down to execution. And building things fast has become what we do best. We plan fast and we focus and making things happen even faster. We learned how to delegate and prioritize in those early days spent at hackathons and today, when our team is a bit larger we try to keep the same spirit. That means we don’t say no to ideas very often — we usually try everything and measure it — from new features, to new marketing campaigns, to side projects to help developers grow. We then measure the results and decide to stop or double down on an initiative and keep going.
Conclusion
After 18 months, we are still early. We have a lot of learning and growing to still do, but for those out there trying to start something, I suggest building a small team and going to hackathons, and to just start building things. There is no better way to learn how to build a team and execute fast than the forcing mechanism of having to bring something to life in what seems like an impossibly short amount of time. You’ll be surprised with what you can accomplish.
