Friday, March 13, 2009

The Three Startup Email Modes

I'm very interested in how people deal with email, and have been watching my own behavior.

Since starting this new company, I've shifted into switching between three disjoint types of behavior:

1. Batch Mode Surrender

I love hearing from readers of this blog, or users, interesting people, potential investors, and the like. Strangely, even though I've been laying low in the past months, the volumes of all of the above have increased to the point where I just can't deal with all of it a timely manner anymore, which I feel really bad about. Because I keep these emails unread in Gmail, there is tremendous pressure I try to answer them. Thus once or twice a week I just surrender and try to process as many of them as possible in batch mode.

2. Constant Vague Anxiety

I spend most of my breathing hours coding, but every once in a while an email appears out of the blue that seems so important that in needs to be dealt with immediately. Sometimes it can be feedback from early users of our product, something work-related (like an exception stacktrace) that I know is holding up other members of the team. They have to be Answered Now, and just knowing that these types of emails will unquestionably keep showing up at random times of the day, I feel the need to check my Gmail about once every 30 minutes. Really, I shouldn't be doing that because it exposes you to emails that should be dealt with in Batch Mode, and creates that vague feeling of anxiety: I can't just LeechBlock my Gmail, but I can't keep it open all the time either.

3. Mobile Panic

When I wake up, or on the way to a meeting, or sitting in a so-so presentation, I pull out my iPhone and check my email. I should know not to do that. The mobile email experience is just so incredibly low fidelity: The emails have no context, priority, or structure. All those emails from (1.) are sitting there unread. It's easy to get overwhelmed and panic. The one thing that I absolutely need to stop doing is reading my email in bed in the morning. I can just feel how the clean fresh state of mind gets wiped and replaced with the noise du jour.

I guess that doing the hard, focused work that a startup requires really makes those email emotions come to light.

Sunday, March 08, 2009

Recommended: Pivotal Tracker

I've been recommending Pivotal Tracker to everyone who cares to listen. I originally read about it on Venturehacks and we've been using it for the last 3 months. Keeping bugs and new features neatly organized can make the difference between a successful project and a failed one. Pivotal is better than anything I've tried before: Bugzilla, Jira, Trac, Fogbugz, Retrospectiva, etc.

The best thing about Pivotal is that everything is on one page. I remember hour-long triage sessions with Jira, moving bug fix targets between releases. Page reloads are a timesuck. On Pivotal, there's one page with three colums:
  • Current has everything you're likely to get done in the current iteration, based on the team's velocity.
  • Backlog is the "nice to have, but probably next week" column.
  • Icebox is where we queue up bugs for upcoming releases.
It took me a while to get used to this, and it took Pivotal a while to get its velocity estimates right for our team. But now it works great!

The problem with bug trackers, of course, is that switching costs are huge, so I won't recommend that you switch right now. But keep this one in mind for your next project.

Monday, March 02, 2009

An Opaque Startup Update

Since I spend most of my waking hours thinking about our startup, it only makes sense to share some of those thoughts with you guys. The time isn't right yet to make any big announcements, so I'll have to keep it pretty opaque.

I took a trip around the world last September. During that trip, I wrote a comprehensive 36-page business plan that laid out the products, strategy, and potential target markets. Best thing I ever did, as it forced me to methodically think about my next thing.

But ultimately, we axed most of it: The product we're working on right now was little more than a footnote in the original plan, and filled less than one of those 36 pages. What reduced the 36 pages to one? We did a lot of market research, talked to scores of potential users - we wanted to make sure we'd make something people want. And fortunately, we were all very enthusiastic about this one product we're building today, which made axing the rest less painful.

This first product won't appeal to everyone, but will be super useful for certain subset of email warriors. We built some elegant technology that solves a pressing, but underrecognized need. That's about as much as I will say for now.

What did I learn so far?

Hard choices: In a startup, you have to make hard choices: Things like who you choose as your cofounder. Or having to say goodbye to a product idea that you were very fond of but didn't test well with real users. Or saying "no" to meetings prominent investors because your time is better spent working on the product. It's easy to say yes to every idea, person, or investor, or drag out important decisions, but that's often plain wrong.

Work hours: The pre-launch stage we're in is exhausting and fulfilling at the same time. We're putting in around 50 (maybe 60?) net hours per week, and I try take time to relax on the weekends (I'm writing this on the way back from a snowboarding trip with the gf).

Effectiveness: Since we're not putting in the cliche 100 hours a week, we have to use our time wisely. I'm a believer in "big design up front", and instead of spending night and day coding, I try to get everyone to write a design doc, evolve it, write some unit tests, write code, and refactor (red-green-refactor style). That style of work is much more appealing to me than spending hour after hour of writing one sloppy prototype after another. And way more effective.