Crazy? Awesome? or crazyawesome?
Only time will tell.
Most startups wait until right before–or even after–they run out of money to finally answer the question, “How are we going to make enough money for this to be self-sustaining?” At clippPR we wanted to solve this problem before the runway ends. But, pretending like there is no more money in the bank is nearly impossible unless you create an environment that feels almost as desperate.
So, we decided to ship as many revenue generating features and products as humanly possible, by doing seven 52 hour hackathons in one month.
A couple random details before I describe our process:
- In case it needs to be said, this is an insane schedule for a very specific amount of time, we normally have a more sustainable schedule. But, sometimes, startups have to do things that aren’t sustainable.
- This obviously doesn’t leave much time for test coverage, scaling, or refactoring. But, sometimes, startups have to do things that don’t scale.
- One of the reasons we can do this right now is because the main product has high test coverage, and is built on top of a solid internal API. And, sometimes, startups have to do things that are crazy and fun.
So, the process:
- find things that have immediate revenue attached
- cherry pick low hanging fruit
- validate quickly
- and show off progress
We started by reviewing all the feedback and insights we captured through our customer development and ongoing conversations with existing customers. (I can write more about that if you like?) At the end of that process we had collated and refined a clean list of five things our customers and potential customers would say to, “clippPR is good and I like it. But, if you could just __________ it would be great and I couldn’t live without it. Please take my money.”
Then we did a massive dump and sort of all the ideas we could imagine would solve those problems. Everyone had 10 minutes to fill as many post-it notes as possible with their ideas. Then we threw them all on the white board and stacked up the notes that were the same. Then we grouped similar solutions into little piles. Then we pulled off all the piles that couldn’t produce real revenue within three months, to save for later. We were left with 29 piles, and gave each one a product/feature name.
Next, we created a quadrant with an x-axis of estimated time required to build and a y-axis of amount of estimated revenue within 3 months, and plotted out all the ideas. So, the ideas that have the highest potential revenue but shortest amount of time to build were in the top right, and the ideas with the lowest potential revenue but longest amount of time to build were in the bottom left.
The scary part was looking at the calendar. Our hackathons would start at 11am the first day and finish at 5pm on the third day. We needed a FULL day off after each hackathon to catch up on sleep and get a little break from one another, and we would need a recovery day for any bug fixes, integration with the live product, and deploying. We ended up with 7 slots. We filled in the slots with the low-hanging-fruit first, and then added the bigger projects last.
My wife made a quick run to costco to pick up some hackathon vittles, I invited some folks to our first demo night, and then we got started.
I am writing this on the second morning of our third hackathon, so I’ll save the review for the very end. But, I can tell you a few things:
- We’ve already shipped 5 new features/products to live, and it feels amazing. There is something inspiring and motivating and very tangible about shipping so much new stuff.
- Most of these shipped around Thanksgiving, so I don’t really get to start showing everything off to the larger group of customers until next week. But, the alpha testers who have already seen things and helped test during the hackathons are really excited.
- I work with an amazing team who can do magic.
Update: Zack Miller asked a great question that made me realize I left out a very important point: The value is not so much about getting no sleep, and more about having a single focus and purpose for the entire team, all-hands-on-deck solving one specific problem, and having the time constraints to force us to ship the first version of things that actually work.