Wednesday, April 29, 2009

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:

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.

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.

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

I'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:

You can only see the global importance of people you have communicated with from the Gmail account you're using.

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

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.

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.

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 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 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 just75 hours. (Well, more like 77 - I needed an extra 2 hours to iron out some kinks at the end).

Tuesday, April 14, 2009

I 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

Wow, 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.

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.

Sunday, April 12, 2009

I 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.

Tuesday: Brush up the UI. Meet with PG at office hours in the afternoon to get his feedback.

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.

Friday, April 10, 2009

I've started an Experiment: I now have a Posterous blog at gaborcselle.posterous.com 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.

Thursday, April 09, 2009

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

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

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:

Describe effectively the functionality of what will be built

Help designers clarify decisions by forcing them to be specific

Allow the review, questioning, and discussion of detailed plans before full implementation begins

Communicate information from one to many

Create a team-wide point of reference for plans

Provide a natural milestone to focus the team

Create insurance against author(s) getting hit by a bus

Accelerate, improve, and increase the frequency of healthy discussions

Give leaders an opportunity to give feedback and set the quality bar

Add sanity and confidence to the team

Things specs cannot or should not do:

Eliminate all discussions between team members

Prove to the team how smart the author is

Prove how important a feature is

Convert people to a philosophical point of view

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

About Me

Gabor Cselle
San Francisco, CA

I work at Google, where I'm a Partner at Area 120. Previously, I worked at Twitter on trends, the logged-out homepage, and on MoPub. Twitter acquired our startup Namo Media in June 2014. Before Namo, I was a Product Manager at Google working on Google Now, Android and Gmail. I started reMail, a mobile email startup which was acquired by Google in February 2010.

Before reMail, I was the VP Engineering at Xobni, where we invented a popular plugin for Outlook, and a Software Engineer at Google. I have an MS degree in Computer Science from ETH Zurich in Switzerland.

Views and opinions expressed here are mine and not those of my employer Google/Alphabet.