Five Lessons Learned at The Reinvent Business Hackathon

Last weekend, two of my colleagues and I participated in the Reinvent Business hackathon in San Francisco. I’ve participated in Hackathons in the past where code with its sophistication and originality was the main focus. It was different this time around; the Reinvent Business hackathon was primarily a non-technical event focused on innovative business solutions as opposed to purely innovative technical solutions.

The experience was extremely fulfilling with many learnings to be shared. Here’s a list of the top 5 learnings we gleaned from the event:

1. Frame the Problem: Hats off to the organizers of this hackathon! frog and LRN did a bang-up job with the logistics and the flow of the event. I liked the fact that spaces in which opportunities for business reinvention and innovation where clearly called out.  The 160 participants were then asked to state issues that need to be addressed under each space. The frogs (i.e. employees at frog) then took all those participant-generated statements and coalesced them into clearly articulated problem statements. The participants then organically gravitated toward the problem statements they wanted to solve, and in turn, meeting other likeminded individuals, which made it easy to form teams.  State the problem and let people come up with the solution.

   

   

2. Inspire Don’t Direct: Dov Seidman, CEO at LRN, delivered the keynote speech.  He was absolutely inspirational. He challenged us to “innovate in humanity” by making business personal. He’s a master storyteller and got everyone stoked and ready to hack away!  To get people to care and do their best, you have to inspire them, not direct them.

   

3. Less is More: I noticed that the teams that did well had not more than 5 members.  This reaffirmed my belief that the less people you have in a team (ideally between 3-5,) the better the product, the team and everyone involved for it. I believe this goes to the fact that smaller teams don’t suffer much from the “too many cooks in the kitchen” syndrom and will also likely to focus better. Obviously, there are many large teams that do very well, but those are the exception to the rule.
4. Team Roles = Accountability: I know this firsthand since our team failed to assign clear roles like Team Captain, tech lead, …etc. Our team, on the human level, was awesome! But the fact that we didn’t have assigned roles meant that we did everything by committee. Design by Committee and Decision by Committee, both of which proved detrimental to our success. Assigned roles it clear what each member’s responsibilities are. With responsibility comes accountability and in turn focus to deliver and eventually success.
5. Storytelling is Everything: No one cares about how awesome your code is or how complex your software architecture is. People care about the human story your product creates. Why is your product good for people? Why do they want to use it? How will it impact their lives? Our team built a mobile web app that illustrated our idea, but when it came time to sell the idea (i.e. pitch it) we focused more on the product than the people that would benefit from it. Ironically, the winning team had an identical idea to ours and no prototype. Yet they won and they won because they told a compelling, very engaging story about why their product is good for people and for business.  We didn’t win because we couldn’t agree on how to pitch our product and tried to accommodate every opinion.