Thursday, April 09, 2009

Our Productivity during YCombinator

Here's a chart that you might find interesting: reMail's productivity graph during the past YCombinator batch.

We're using Pivotal as our bug tracking system. In Pivotal, you assign points to features and bugs. Roughly, the points represent the time and difficulty of completing each item.

During YCombinator, we had weekly iterations of reMail ending on Tuesday nights, when the YC dinners take place. We'd scramble to have something new version to install, or a new feature to show off every Tuesday. Pivotal shows how many points you finished in each iteration, which yields this graph (click to enlarge):

  • In the beginning, we made little measurable progress because we were learning technologies that would let us do more powerful things on the phone. While we learned a lot, that learning wasn't expressed in points.

  • The demo we showed on prototype day looked great and was well-received, but we had taken a lot of shortcuts to make it look good. Prototype day was a huge boost for us because after it, the pressure was on to deliver what our demo had promised. We installed our first alpha a few weeks after.

  • Investors loved us on Demo Day. But little product work got done immediately before and after the event. We spent many days getting our presentation into shape, and rehearsed the talk ten or twenty times. Also, we took a few meetings in the week after Demo Day, which were inspiring but caused a huge drop in terms of Pivotal points.

  • Fueled by the enthusiasm of Demo Day, we got a lot of stuff done. In the iteration afterwards, we started a huge push to tie up the loose ends of our Alpha version. Yet, that spike looks a little too high because Pivotal doesn't (and shouldn't) let you do half-points - there were many small things we fixed that only took a few minutes each.

This graph might not generalize to any YCombinator startup. This batch had multiple companies that had already launched when the program started, and their curves would probably look very different. Others that launched during the program would have their spike earlier on, etc. But this might give you an idea of what happens when heat is on to deliver every single week.

Update 1: The graph doesn't reflect that an estimated 50% of each week's points would be completed on Monday and Tuesday, before the YC dinner. The YC dinners add an enormous amount of pressure to deliver. Wednesdays were usually slow days as a result of that.

Update 2: While the shape of our curve doesn't generalize, there are two effects that probably do: After prototype day, we had a pretty good read of what needs to improve and that sped up things. Also, the post Demo Day productivity slump due to follow-up meetings was probably something that every startup experienced.

Update 3: After reading some of the comments on Hacker News, I'm now thinking that a better measure might be "number of net lines of code produced per week". Maybe I'll post that graph here at a later point.

1 comment:

Adam Milligan said...

'a better measure might be "number of net lines of code produced per week"'

Probably only if you graph productivity as the inverse of this graph.