Sunday, February 28, 2010

"Brilliant Only in Tiny Bursts"

I'm reading Seth Godin's new book Linchpin. Great snippet:

"The more value you create in your job, the fewer clock minutes you actually spend creating that value. In other words, more of the time, you're not being brilliant. Most of the time, you do the stuff that ordinary people could do.

A brilliant author or businesswoman or senator or software engineer is brilliant only in tiny bursts. The rest of the time, they're doing work that most any trained person could do.

It might take a lot of tinkering or low-level work or domain knowledge for that brilliance to be evoked, but from the outside, it appears that art is created in a moment, not in tiny increments."

So true. The time you spend building the element of a product that's truly game changing is often just a small fraction of the total. Most time is spent on mundane tasks, vanilla code, and things everyone else has already done.

Tuesday, February 23, 2010

Great Niche App Idea

"Why isn't there an app that tells me question types for various positions and then lets me benchmark answers in relative and absolute terms?

It could propose simple to hard verbal math problems for engineers and biz people to test problem solving. It could let me time responses."

(via Marc Pincus)

Interviewing people is hard. Making sure you're consistent with previous decisions is even harder. If marketed well to tech companies, this app could be quite a money maker. If someone's already made this app, let me know. I'd love to try it out.

Sunday, February 21, 2010

"You just need to find the people who don't give up"

I was having dinner with Immad yesterday. He said:
"Angel investing is easy. There are plenty of smaller exits, and anyone who's smart can achieve a decent outcome. You just need to find the people who won't give up."
Of course, picking those people is the hard part. A portfolio of companies that don't give up will probably outperform the stockmarket over any time period.

Thursday, February 18, 2010

If you're a Googler ...

You should consider following me on Buzz to know what I'm up to. I'm super excited to be back!

If you're not a Googler, don't worry: I'll keep updating this blog regularly. I have a bunch of stuff I've been meaning to write about but haven't gotten around to.

Wednesday, February 17, 2010

reMail Acquired by Google

I'm thrilled to announce that Google has acquired reMail! I will be joining Google in Mountain View as a Product Manager on the Gmail team.

Gmail is where my obsession with email started as an engineering intern back in 2004, and I'm thrilled to be coming back to a place with so many familiar faces. reMail's goal was reimagine mobile email, and I'm proud we have built a product that so many users find useful. Still, I feel like we've only seen the beginning of what's possible. Google is the best place in the world to improve the status quo on how people communicate and share information. If you have what it takes to make these changes happen, I encourage you to reach out and come join me.

You might be wondering what will happen with reMail's product. Google and reMail have decided to discontinue reMail's iPhone application, and we have removed it from the App Store. reMail is an application on your phone. If you already have reMail, it will continue to work. We'll even provide support for you until the end of March, and we've enabled all paid reMail features for you: You can activate these by clicking "Restore Purchases" inside the app. reMail downloads email directly from your email provider to your phone, and your personal information, passwords, and email are never sent to or stored on our servers.

I want to take this opportunity to thank the people that helped make reMail a success. Fabian Siegel, Einar Vollset, Sridhar Srinivasan, Paul Bohm, Marissa Coughlin, Erol Koc, Matt Ronge, and Stefano Barbato have all contributed to building a great product. Our investors saw the potential in improving mobile email and took a bet on reMail in the darkest days of the recession. I couldn't be more grateful to YCombinator: Paul Graham, Jessica Livingston, Kate Courteau, and Trevor Blackwell all have provided invaluable guidance. Paul Buchheit and Sanjeev Singh endured my slide deck on our multi-step plan for global email domination, and pointed out that instead I should build something small, simple, and useful. It worked.

reMail Selected for SXSW

reMail was accepted as a finalist at the South by Southwest conference's Microsoft BizSpark Accelerator program!

Sunday, February 07, 2010

When you start to build something new ...

When you start to build something new, think about the what could be, the what may be, and the what will be. Don't settle, don't give up, don't get stuck in a box built by other people's misguided interaction paradigms. The internet is open and free, and that means there are no rules.

-- Dustin Curtis, The Manifesto

Friday, February 05, 2010

reMAP Meetup at SXSW?

Joshua Baer (founder of email startup OtherInbox) and me are thinking about putting together a meetup for people interested in replacing IMAP.

We would meet sometime around the SXSW Interactive festival in Austin, Texas (March 12-16). Exact time is still unclear, but Joshua has kindly offered up his company's offices, which are just a few blocks from the event.

Who's interested?

The IMAP Compatibility Matrix

There's a great discussion going on in the comments of my post about replacing IMAP, and also on YCombinator's Hacker News.

One frequent point made about my proposal is that IMAP already has a number of extensions that do things I suggested, such as the THREADS, SEARCH, and IDLE commands for conversations, search, and long polling ("push").

Commenter Bron (who works on a popular IMAP server) writes:

Also, IMAP plus a random mix of extentions becomes a HUGE compatibility matrix, and you have to offer fallback from all the nice stuff to really shitty workarounds just in case the server doesn't support a feature that makes your life bearable.

So - I'd love to see a decent competitor to IMAP as a protocol. If nothing else because it would reduce the compatibility matrix. Alternatively, I'd be happy for an IMAP5 to be defined which included all the good extentions - so anything which advertised support for IMAP5 had to support them.

Defining an IMAP5 standard might be a good alternative than something like reMAP, and adoption might be much faster. However, a potential IMAP5 would still remain a protocol inaccessible to many developers so it might not unleash the storm of creativity I'm hoping for.

Keep those comments coming.

Tuesday, February 02, 2010

How to Replace IMAP

IMAP is a complex and difficult protocol. Its original design, RFC 1730, dates back to 1994. Here's a sample IMAP session that shows you all of IMAP's quirks: It's a stateful protocol where you login and select a mailbox to operate on, it has an unconventional parenthesis-heavy representation for structured data, and fetching messages is a multi-step operation.

Design Outline

One of these days, I'll write up a spec for the mail access protocol of my dreams. I'm planning to call it the "reimagined Mail Access Protocol" (short: reMAP) which is handy because reMail already owns the domain name.
I would aim for a RESTful design with the following properties:
  1. All communication over HTTP / HTTPS: Pure TCP connections are great, but for transferring large amounts of email, HTTP is the way to go. Problems like security, parallel downloads, persistent connections, caching, compression, download continuation via ranges, and so on have already been solved. There is no reason to solve them again.

  2. Stateless: There's no reason to introduce state like IMAP does with its selected mailboxes. All you need is a HTTP session cookie used for authentication purposes. Session cookies also allow for things like OAuth. OAuth would let third parties get your permission to access your email without having to give them your username and password.

  3. JSON and UTF-8: All data that's ever sent to or received from the server would be in JSON format. JSON is much more human-readable than XML. UTF-8 would be the only encoding allowed, since it is able to represent any character in the Unicode standard.

  4. Conversations as first-order objects: Gmail, the iPhone SMS app, and Facebook's messaging system have shown the value of viewing messages not individually but in the context of conversations. In reMAP, the server would be responsible for grouping together messages. While you could still access individual emails, the first-order unit of data would be a conversation.

  5. Labels, not folders: Labels are much for flexible than folders. Each conversation should have multiple labels, and the labels would be included when you request the message, rather than having to scan all folders for the message via IMAP.

  6. Stable and unique IDs: IMAP has a UID for each message, but it changes the moment you move the message into a different folder. An IMAP server can also declare all UIDs to be invalid at any moment throughout the session. No more! reMAP would have stable and unique IDs for all conversations, emails, and attachments.

  7. The beginning of the end for MIME: Yes, you could still get the MIME representation of each message that is sent. But MIME is a messy and complex beast. Instead of requesting the MIME-encoded message parts, you could just ask the server to give you the message as represented in plain text or HTML. Attachments can be downloaded in separate HTTP calls.

  8. Push built in: The two prevailing methods for implementing push email are the IMAP IDLE command (not widely available in IMAP servers) and Microsoft's ActiveSync, which requires developers to purchase a license from Microsoft. In reMap, clients could just call an HTTP endpoint on the server which returns as soon as new messages are arrive.

  9. Full-text index on the server: reMAP servers would need to maintain a full-text index of the contents of all messages. There's no reason clients should be required to download and index everything in order to do an exhaustive full-text search of your email.

Enormous Potential

I believe that one of the reasons for the lack of innovation in the email space is the lack of a simple yet powerful email access protocol. Every developer that wants to try something with email needs to first jump through the hoops of IMAP and MIME, or worse, the Outlook Object Model and MAPI. A new protocol like reMAP would lift this burden off their shoulders. We've seen what open, simple standards can do for innovation with Twitter's and Flickr's API. Now imagine unleashing the same sort of creativity to the vast ocean of data that is email. Let me know what you think. My goal with this post was to encourage a discussion about this topic, and your comments are much appreciated. If you liked this, consider following me on Twitter where I often tweet about email-related topics!

"A good email client, please."

My friend Patrick Collison writes on Facebook:

"Gmail proved that, despite the apparently high switching costs, a new webmail client can quickly get a lot of traction. There’s room now to do to Gmail what Gmail did to everything else. The replacement should have some concept of workflow (”archive, but remind me to respond tomorrow”, “send, and alert me if I don’t get a response within a few days”), some concept of teams and colleagues (allow threads to be shared as a first-class object, rather than flailing around with forwards and CC lines), be some way smart about mining the semi-structured mails going through the system (flight booking emails should be automatically annotated with .ics files), know something about prioritization (I like Twitter DMs because of the assumption that they’ll go to a mobile device. If I’ve sent more than 20 emails to someone, they should have the option of copying their mail to me as an SMS).

Potentially most powerfully of all, developers should be able create their own plug-ins that run on the server. There should be an agreement between plug-in developers and the webmail provider that creating a plug-in automatically grants a royalty-free perpetual irrevocable worldwide (etc.) license to the provider, and that the source code to any plug-in may be merged into the main product. Though plug-ins have niche appeal, this could be a good source of new features, and a strong competitive advantage. I’d just fix Gmail if I could.

I’d happily pay for any service that got this stuff right."


Some good ideas in here. Server plug-ins could work in a manner similar to Google App Engine. A lot has been tried around better triage and data mining, with no clear winners yet. Also, there's a danger of feature overload somewhere in here. I'm not sure if we should replace one variant of feature overload (Microsoft Outlook) with another (integrated SMS / Twitter / Facebook / email). Maybe SMS, Twitter, Facebook, and email should instead all just be replaced with one thing that is the combination of all lessons learned with those protocols.

Mobile Advertising needs Rich Media and Better Targeting

Mobile advertising is a $2.2 billion business. Advertisers put up mobile ads for two reasons: (1) Building brand awareness and (2) generating leads, whether to download their iPhone Apps or sign up for their service.

Two possible improvements:


Two possible improvements:

Rich Media

All ads you see today on your phone are static text or images. Brand advertising works by playing to emotions, and to do that, you need animations and sound. I know you dislike those Flash ads on websites, but they're how the content gets paid for.

Those ads are static for a reason: iPhone doesn't support Flash, and the ads need to be small in size due to limited bandwidth. I'm sure one of the players in this space is already working on building technology to show great-looking, animated, interactive ads - whether with proprietary technology or some sort of browser plugin. Rich ads, rich CPMs. Even the bandwidth problem can be solved: There are plenty of ways to preload ads and cache them for later display.

Better Targeting

If you've tried putting up an AdMob ad, you know that the targeting options are pretty limited: You can narrow down by country, device (iPod Touch / iPhone), and connectivity (Wifi/3G).

There's one type of ads that could unleash dramatic growth in mobile advertising: Imagine you're on the way to lunch at Pete's Burgers, and your iPhone shows you a coupon for Joe's Burger Shack. You go to Joe's and show them the coupon you just clicked on. The ad just generated a verifiable lead, and the advertising network just made a bunch of money.

For this type of application to work, targeting needs to get better: We need street-block level targeting, time of day ("only run this ad at lunchtime"), and likely user activity ("user likely walking to lunch").

I imagine that local ads like that could be bigger than the $20 billion / year search advertising business (e.g. Google AdWords), which makes money by generating leads for people to buy stuff online. The number of real-world transactions and the amounts I spend on them are much higher than what I spend online. Done right, mobile advertising could be much bigger than that.

Monday, February 01, 2010

One of these Days

One of these days, I'll go through my Blogger console and just hit "Publish" on every one of those unpublished drafts I've been nursing. Many of them lack just one final insight, a few just lack a little bit of polish. No reason to pull a Hank Moody [*] on you guys.

Just post it or nurse it to quality? That is here the question.

[*] And by Hank Moody, I'm referring to writer's block, not bad parenting or tooling around in a Porsche.