People usually don’t believe me when I tell them how fast it took to build the first version of Flightcaster. Remember, Flightcaster was not a trivial piece of technology. We were one of the first production applications to use Clojure. And, we launched (insanely I might add) with a research infrastructure, website, iPhone app and Blackberry app simultaneously. And all of this was done in just over three months, from first line of code to launch.
At the time, it was the most productive any of us had ever been in our lives. It was awesome.
We were in the summer 2009 Y Combinator batch. One of the truly powerful aspects of being in Y Combinator is that the date of demo day is set for you. Paul Graham doesn’t go around asking each startup when would be a convenient time for them to be ready. The date is set and every company has to do what it takes to be ready in time.
This concept of setting the time limit first and adjusting the scope second is really powerful.
I don’t know why we ever stopped doing it.
Nothing was really accomplished in the hundred days after demo day. Oh, yes, we were absolutely dealing with all the technical debt we had cost ourselves, but the reality is we didn’t accomplish very much the hundred days after that either. I don’t care how much technical debt there was, it was not enough to justify a drop of productivity lasting six months.
Without any clear ambitious goals, we simply drifted towards a less productive state – scope would be added way too easily, design iterated on too many times, code perhaps more polished than it needed be. The result was we went from a sprinter’s pace to a jogger’s pace, and when our product ran into trouble we were simply too slow to react.
When we got into Y Combinator for 42Floors, we had no code written.
The entire first version of 42Floors was built in that three-month period. We built a complete platform for commercial real estate in under 10 weeks. Once again, we achieved a level of productivity that had seemed impossible at the beginning.
Setting deadlines first and then choosing ambitious goals is the key. The deadline becomes a forcing function that wipes away distractions. There’s simply no time for extraneous features. Failed experiments end much earlier. Hacked together solutions get tested much faster because there’s no time to build the scalable version.
After Demo Day this time, I bought a 100-Day Goal calendar.
And it worked. It worked incredibly well then and still does. We’re now on our 6th consecutive 100 day countdown books.
So, if you find yourself suffering from not enough direction, I highly recommend you give this a try. Here are a few suggestions for doing it the first time:
Tips for Creating a 100 Day Goals
Set the deadline first
This is seriously the most important step. If you think about scope and then try to predict a deadline, you are always going to be in this mindset of time estimation. But when you pick the deadline first and then try to pick the goal, you begin to see how ambitious you can really get.
Once we decided that the New York launch was our hundred day goal, we told our investors and partners about the launch date. We didn’t mention that it was part of some hundred day goal program; we just told them with certainty when the date of the launch would be so that they could count on it, which in turn put even more pressure on us to make sure that we hit that deadline. When you talk about the efficiency of a team working together, it really helps when everyone believes the deadline will hold – and nothing like external pressure to help with that.
Make it front and center
Deadlines don’t work unless people can see the days. What I love about this countdown booklet is that we have this morning ritual of ripping another day off. It’s not buried in a monitor with all our other metrics. It serves as this conversation piece for anyone who walks in the office – people want to know what is happening in 27 days, and we tell them. And in doing so, we remind ourselves that we have a goal to accomplish; we need to get to work.
Delay the wouldn’t-it-be-cool-ifs
We are never short on good ideas. But good ideas are not what we need; more important is having the discipline to stay focused. With our hundred day goal method, we have a real easy process for dealing with “wouldn’t-it-be-cool-if” conversations. We simply push them to our next hundred day planning session.
And in doing so, this raises the bar on what it takes to introduce a change to the middle of the hundred days. It’s not that we won’t deviate from our plan – we deviate from plans all the time – it’s that we will only do so when it is actually really important and not just interesting.
When we hit our hundred day mark, it feels awesome. Alison, our Director of Vibe, plans something big to celebrate; we all go out and take stock of the accomplishment. The last 20 days of a 100 day segment are really stressful. Nothing wrong with working hard. It’s immediately followed by some much needed rest.
We’re in our 6th 100 day countdown book. I have enough data to say that this system has worked without burning us out. Give it a try. Let me know how it works for you.
Discuss on Hacker News.