10 karma · joined May 18, 2013
Your users are not all the people who visit your site because of the "launch" but those for whom you can solve "the problem" well. I will definitely go back to a product that solves my problem, even if it has a lot of bugs. As proof, I've used buggy UML tools, code editors, video/audio editing software for years because they're very good in at least one aspect I value.
A lower-risk approach: Suppose you list out the benefits of a "launch" (example: growth from 0 to 10K users, investor interest, attract/keep talent) and then separate out the components of a launch (example: Techcrunch release, beta mailing list, investor reach-out). You may be able to de-risk by going after individual components and only building whatever is necessary for each individual component. For example you can attack the mailing list first without worrying about scale to handle traffic that a press release would bring.
I definitely have productivity swings (and I make myself feel better by saying they're akin to moood-swings and out of my control!) Productivity is highest for me when I'm in a highly structured environment. I've churned out insane amounts of code when
a) I knew exactly what needed to be done and b) Had a sharp timeline to complete it
#a happens externally sometimes, when requirements are crystal-clear. For example, when you build stuff on http://community.topcoder.com/tc Otherwise, my approach is to spend as much time as needed in order to clarify requirements. I simply do not bother to code unless I'm sure about the end-goal.
#b can be seen in hackathons, or when a team / startup has committed to a demo-day (it can also be artificially imposed by managers)
When both #a and #b are externally satisfied, I can code all day long without problems. Things like headphones (to prevent interruptions) are useful but not necessary unless the environment is extremely distracting.
When #b is satisfied but not #a, I try to reduce the uncertainty around requirements - otherwise jumping in to code and then having to throw it away can be killing. At some point, the RoI in trying to achieve more certainty will get negative, at which point I start coding with whatever I have.
When you have #a but not #b, it is very easy to procrastinate. Of late I'm inspired by www.structuredprocrastination.com (brilliant, short read) to still maintain productivity.
Finally, having neither #a nor #b is the worst. Being in startup mode for the last few years I've seen how difficult that is. I'm making my own version of productivity pr0n, inspired from Marc Andreessen's blog post http://pmarchive.com/guide_to_personal_productivity.html The most effective thing for me is to plan a day ahead and then actually log what happened in the day. Just the act of measurement goes a long way in lifting mood and productivity.