Wednesday, April 29, 2009

Releasing Something New, Every Week

I'm trying something new: For the next four weeks, reMail will be releasing a new feature or product every single week.

Pretty radical, eh? Here's why I'm doing this: I'm a perfectionist and need to be constrained by time rather than "good enough". Here are the three recent events that triggered this experiment:
  1. I organized a Post-YC dinner for my former batch and invited Dropbox Fouder/CEO Drew Houston to come and speak. He talked about Dropbox's private beta period, and how early audiences don't care about perfect; They care about new ideas and usefulness.
  2. I built reBoxed, an experiment in email prioritization, in 3 days, with that specific deadline in mind. Despite being a work-in-progress at launch, the result was successful and gave me plenty of new ideas.
  3. I need to start testing my hypotheses about email users (if you've been reading this blog, you know I have a lot of them), and there's no better way to do that than to give them a product to play with.

I have a couple of these products/features in various stages of completion, so I know roughly what I'll be doing for the next few weeks. I'm also thinking about charging for some of these products and features from the get-go, Eric-Ries-style. "Buy before you try", if you will. More on that later.

I'm leaving for a weeklong trip to Europe on May 26 to visit some friends, and that week will conclude this experiment. Until then, watch this space.

Tuesday, April 28, 2009

reBoxed: Global People Rankings

reBoxedI'm experimenting with a new feature for reBoxed, the email prioritization tool I built two weeks ago.

By having you and others vote on people's relative importance, reBoxed re-sorts your inbox according to the importance of senders in your inbox. But wouldn't it be interesting to see the most important contacts based on the votes of you and others? That's why I built a feature called "Global Ranking", which gives you the global importance of people in your inbox based on everyone's votes.

I'm enforcing two rules to protect everyone's privacy:
  1. You can only see the global importance of people you have communicated with from the Gmail account you're using.
  2. You can only see the global importance of people whom you've voted on yourself (either for or against). If you don't see enough people in your global ranks, you should re-play the reBoxed voting game a couple of times.
Additionally, Global Rankings will not show rankings for addresses you've marked as "not a person" - bulk senders, spammers, and the like - that adds a little more sanity to the page.

You can access the feature through your reBoxed Inbox, by clicking on "Global Rankings".

Give it a spin and let me know what you think! As always, you should report bugs on the reBoxed GetSatisfaction page.

Friday, April 24, 2009

Email Reply Behaviors

I found a great paper by Thomas Karagiannis and Milan Vojnovic at Microsoft Research Cambridge in my email this morning and thought I'd share some of the highlights with you.

In the paper, they surveyed email behavior in a large company, and analyzed how likely it was that emails will be replied to, and how long the replies would take. They looked at all the various factors - length of the email, number of recipients, time of day, and so on. I thought I'd paste in a couple of the highlights.

First of all, let's look at the relationship between the size of an email and average reply time. Anecdotally, I reply to short emails quickly, but if you send me a long email, you're going to have to wait for a reply. This is true in general:

Let's look at queue size vs. reply time. When I get lots of emails, some of them get pushed further and further down my inbox, and it will probably take me a while to get to them. This is a beautiful visualization of that effect:

Do replies get sent at particular times of the day? Heck yeah! The graph below shows time of day vs. replies sent, and you can see how they follow a clear awake / asleep pattern:

But a main takeaway for me is the following graph. I've always assumed that you'd reply faster to people above you in the company hierarchy - your manager would get replies faster than people at your level or below. You'd think you reply to Steve Ballmer faster than to Joe Intern. This does not hold true. On the graph below, dots to the left are "replies higher-ups", dots to the right are "replies to lower-downs". As you can see, more important people do not receive faster replies.

Here's the paper for people interested in more detail:

Behavioral Profiles for Advanced Email Features, Thomas Karagiannis and Milan Vojnovic, Microsoft Research, WWW-2009, Madrid, Spain [PDF]

Friday, April 17, 2009

48 Hours of reBoxed

reBoxedAnother quick update on reBoxed. I launched it a little more than 48 hours ago. Here's the visitor curve so far from Google Analytics - looks a lot like a hockeystick:

And this is what has happened since my last update:
  • reBoxed was covered in ReadWriteWeb and Lifehacker.
  • reBoxed now has 414 users - compare that to 128 users at this hour yesterday.

I expect that growth will fall off over the weekend, as fewer people use the Internet on weekends. I've decided that I'll take a few more days trying to incorporate user feedback and make the site more useful (rather than working on reMail's core product), but I'm taking part of the weekend off for my own sanity. Hopefully, you'll see new features on reBoxed sometime early next week.

reBoxed on ReadWriteWeb

Marshall Kirkpatrick writes on ReadWriteWeb:

Former Gmail engineer Gabor Cselle has been working on improving email for years. This week he built a new system for prioritizing all the emails in your inbox. It's called ReBoxed, and it relies on crowdsourced A/B preference voting on email senders, and Cselle built it in just 3 days.

Marshall points out some flaws in our current ranking algorithm (There any many, considering I wrote it so quickly), but closes with this:

ReBoxed is a small project that presumably could become a part of Cselle's larger email startup company, ReMail. That service is yet to launch but if this is the kind of creativity that will be included there, we're excited to see it.

I'll be working on reBoxed all day today and will keep you updated. Meanwhile, check out

Thursday, April 16, 2009

24 Hours of reBoxed

I launched reBoxed a little more than 24 hours ago, at 5 p.m. yesterday.

Since yesterday:
  • 128 people have signed up for reBoxed
  • 746 visitors have checked out the site. See the Google Analytics pic above.
  • I've made 34 checkins to our source code with bug fixes and new features

We've had some pretty good feedback so far, and users have also tweeted me with suggestions and bug reports - I've set up a GetSatisfaction site for the latter.

reBoxed also now has a "Delete all my data from reBoxed" feature. You can use that to delete all of reBoxed's knowledge of your contacts and email. You can find it at the bottom of your reBoxed Inbox:

Next, I'll be working on the reBoxed homepage. I want to make it more attractive, and I'll break it up into "Home" and "Learn More". I should have that done by tomorrow.

Wednesday, April 15, 2009

Should reBoxed have a "Skip" button?

reBoxed is growing - people are signing up! Pretty exciting to run the script that spits out the number of users. I'll give you an update on user numbers tomorrow (after I've caught up with sleep).

reBoxed lets you vote on your contacts and reorganizes your inbox based on your and everyone else's votes. This is what that looks like:

@andyy writes on Twitter:

@gabor repeatedly wanted a "can't decide/equally important" option - am I too apathetic? :) [...]

I think that reBoxed should not have a "Skip" button. I want you to make a decision. Those two friends that you both value? Your sister vs. your brother? Make a choice. This might sound radical, but one of those people usually does write more important emails.

reBoxed is up!

reBoxedTry it now at:

reBoxed sorts unread emails in your Gmail Inbox by the importance of the sender. You start by voting on pairs of contacts - "whose emails are more important?". Your votes are then combined with your friends' votes. reBoxed's algorithm then sorts your inbox based on this input.

reBoxed is your inbox, sorted by your friends.

And we built all of it in just 75 hours. (Well, more like 77 - I needed an extra 2 hours to iron out some kinks at the end).

reBoxed - Almost done

It's 3 pm on Wednesday, which was my personal deadline for reBoxed. It's not quite there yet - still working out some kinks. But it should be up in the next hour or so.

Tuesday, April 14, 2009

reBoxed - Day 3

reBoxedI woke up to the sound of the alarm at 9:00 am this morning, and rushed to pick up a friend at SFO. Should've thought about that when I went to bed at 4:30 am ...

I only spent about 5 hours coding on reBoxed today, mostly fixing bugs and making the UI at least bearable. We spent hours discussing derivative ideas, and probably got a little too excited about the eventual potential of reBoxed. Then, we met with Paul Graham at YC office hours - he seemed optimistic about the idea, but pointed out some UI shortcomings that are going to take a lot of effort to improve.

He had one more point: reBoxed will require quite a bit of input from the user before reorganizing their inbox. I hope users will understand that we can't just reorg your inbox out of thin air, and won't get too impatient with the work we ask them to do.

The quality and speed of the UI, however, will continue to haunt me. I feel like I'm pretty good at designing and implementing UIs, but making them good takes takes enormous amounts of time. With my deadline at 6 pm tomorrow, there's just no time get to get the UI up to my personal quality standards.

Plenty of small work items remain, but I think we're on track to push the first version tomorrow Wednesday at 6 p.m. - Exciting!


P.S.: If you're wondering why I only coded 5 hours new today - The Winter 2009 YC founders decided to continue the Tuesday dinners even past the official YC dinners. Tonight, we had a little get-together at Cloudkick HQ in San Jose. I just got back from that.

P.P.S.: I just noticed my original post said I'd have V1 up by Wednesday 3 pm - So that's what I will aim for (instead of 6 pm). I'd say 6 pm is more realistic though.

Monday, April 13, 2009

reBoxed - Day 2

reBoxedWow, it's 4:10 am - I started working on reBoxed at 10:30 am today. Almost 18 hours and 1045 lines of code later, I have a crude prototype working, in line with my plan from yesterday.

reBoxed still seems like an excellent idea, but I've found that it's crucial to keep expectations down - since the reBoxed idea is so new, I still find myself being wildly enthusiastic about it. I typically get much calmer about a new idea after about a week or so.

The first version is going to suck. Especially the UI. I'm going to spend some time sprucing up the user interface on Tuesday, but I doubt it's going to look really good in the next 36 hours.

I wasted some time today by deciding to look into fancy machine learning algorithms for reBoxed. I dusted off my copy of Data Mining (the only ML book I own that isn't with my parents in Switzerland). But after 45 minutes or so, I abandoned all of that and went with something really simple.

People have emailed and asked reBoxed - it's a combination of a number of ideas, some of which I've written about in A Model of your Inbox and How Researchers are Reinventing your Email Client. You'll find out soon enough.

Ok, off to sleep now.

reBoxed - Day 1

reBoxedI'm working on an idea called reBoxed and want to launch the product by Wednesday night.

Day 1 went pretty well. I spent an hour setting up a test server, and then most of my time was spent learning Oauth, which I'm going to need to use for getting access to some data I need. I decided to use Leah Culver's Python Oauth code and adapt it for my purposes. I was going to write a Design Doc but decided to just scribble something down for lack of time. This will likely come back and bite me. I was up until 3 am last night and started working at 10:30 am this morning.

So far, on target for Wednesday.

Sunday, April 12, 2009

reBoxed - An Experiment in Rapid Development

reBoxedI have a little bit of free time on reMail's main product right now and I've decided to implement a possibly great idea I've been thinking about over the last couple of weeks. reBoxed is a new take on inbox prioritization - and I'll build and launch it in the next 3 days - 75 hours. My deadline is to have it done by Wednesday 3:00 pm Pacific time.

My timeline is something like:
  1. Today Sunday: Learn a technology I'll need to understand for reBoxed to work. Write a Design Doc.
  2. Monday: Implement all functionality but keep the UI super crude.
  3. Tuesday: Brush up the UI. Meet with PG at office hours in the afternoon to get his feedback.
  4. Wednesday: Write deployment tools and deploy to a server. Launch.

Don't set your expectations too high: The first version of reBoxed will likely suck. reBoxed is an experiment in how quickly I can develop and launch a mail-related product. And a way to prove out a possibly great idea.

I'll post a daily update on this blog.

Friday, April 10, 2009

Experiment: Positive Thoughts on Posterous

I've started an Experiment: I now have a Posterous blog at where I'm going to try to post one inspiring / uplifting quote a day (Plus random photos from my iPhone).

Being an entrepreneur is hard because it's a rollercoaster ride of ups and downs. Without any substantial or factual change at all, you'll feel awesome one hour, and awful the next. Sometimes it's enough to just load one positive thought into your brain's state and it'll all work out fine.

Many of the quotes I'll post might be lifted straight from Barack Obama, Paul Graham, VentureHacks, Jessica Livingston's Founders at Work, or something that a speaker at YCombinator might have said.

Mail me any good quotes you might find - my email is on my homepage.

Why did I choose Posterous? Because Garry Tan is a cool guy and because Posterous lets you blog via email. And everyone knows how much I like email.

Stay subscribed to this blog, though - this is where I'll be posting original thoughts and content.

So - here it is:

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.

Monday, April 06, 2009

"It's the Small Steps"

Here's one of my favorite blog posts. I have no idea how I found it in the first place, but I've kept it bookmarked in my browser for those moments when I'm feeling overwhelmed: Patricia Handschiegel - It's the Small Steps:
"After an hour of talking, the reporter said, 'Wow, I’m really surprised at how long and hard you worked, Patricia. You always assume when somebody has success, it was easy.' There is absolutely nothing easy. Any success, however you define success, is going to make you work harder than you could have ever imagined. Add in a start-up, and the to-do list can be enormous. This is why I constantly tell those I advise or mentor to create a list of their goals, a timeline for those goals and then, from there, the individual, small steps to get to each of them. Doing this makes the work easier, more digestable and less overwhelming. [..]

If I were to try to do everything I want to do at once, nothing would get done. I focus on the small things and so far, pretty much everything I’ve set my mind to has happened."

Friday, April 03, 2009

What Specs are Good For

I'm reading Making Things Happen by Scott Berkun. It talks about how to best manage software projects. I'm a big fan of writing and iterating specs because I believe that thinking about building something is way cheaper than actually building it. I liked this list from the book:

"Here's a list of the importance things specs do for a project:
  1. Describe effectively the functionality of what will be built
  2. Help designers clarify decisions by forcing them to be specific
  3. Allow the review, questioning, and discussion of detailed plans before full implementation begins
  4. Communicate information from one to many
  5. Create a team-wide point of reference for plans
  6. Provide a natural milestone to focus the team
  7. Create insurance against author(s) getting hit by a bus
  8. Accelerate, improve, and increase the frequency of healthy discussions
  9. Give leaders an opportunity to give feedback and set the quality bar
  10. Add sanity and confidence to the team
Things specs cannot or should not do:
  1. Eliminate all discussions between team members
  2. Prove to the team how smart the author is
  3. Prove how important a feature is
  4. Convert people to a philosophical point of view
  5. Be a playground for the author's Visio or UML skills
In my professional experience so far, projects that did not have a spec written before writing the majority of production code have consistently failed, were late, or didn't meet quality standards. "Just hacking it up" almost never works for complex projects. Especially junior developers often lack the discipline to write a spec, even though they would benefit from it the most. Maybe this list will nudge some people in the right direction