Two years ago, I started working on Front, a multiplayer version of Gmail.
Today, I’m sharing thoughts on email that I would have wanted to know before at the time, but had to learn the hard way. If you’re thinking about innovating in the email space, hopefully it’ll help you too!
Email is harder than you thought
Nowadays, the consensus when trying to bring something new to the market is to build a Minimum Viable Product, or MVP. The reasoning goes like this: start with something small, no bells or whistles, but provide enough value for people to use it. That way you can determine whether or not people actually want your product , without you wasting a ton of time on a full-fledged version.
Unfortunately, in the email space, this approach does not work. Reaching MVP status is very hard, for two reasons.
The technology is hard
Email has been termed “the last unowned piece of technology.” It’s true: email doesn’t belong to any one company. It’s just an open standard, drafted more than fifty years ago. Any developer can implement it and owe nothing to anyone. This is a great feature of email, but it also has big negative side-effects. Providers have been implementing the email standard for decades now, supplementing it with their own technology as they saw fit: a proprietary email format here, a bizarre way of quoting previous messages there, etc. If you want your product to integrate nicely in the email ecosystem, you have to accommodate for all those edge cases.
Of course, the standard is slowly evolving. But because email is an open standard, no provider is forced to implement the newer features. Until a majority decides to make the switch, every developer has to assume the feature is not available. Closed systems owned by a single company can avoid this chicken-and-egg problem, but email moves only as fast as the majority of the network.
User expectations are high
Everybody is an email expert. We’ve all been doing it for so long, we expect it to work perfectly. We have a clear idea of what an acceptable email experience is. Other types of software can get away with bugs and flaws, as long as they deliver a big enough core value, or a sufficiently novel functionality. But we don’t tolerate that with e-mail.
Here is a non-exhaustive list of those expectations:
- Ultra-high reliability. Delayed reception, unsent messages, or plain old downtimes are total deal breakers.
- Many core features: message composer, attachment handling, drafts, conversation threading, archive / trash, etc. These are the basics.
- Email doesn’t stop at sending and receiving text messages. A lot of the experience is not in the standard, but around it: a good contact manager, a powerful search, a great spam filter, a reliable “undo send”, highly flexible labelling and sorting, intuitive keyboard shortcuts. To be done right, each of them could keep a team busy for weeks.
- Intuitive, almost magical onboarding. Your product should feel familiar (all the while being innovative, obviously), because if your users haven’t found their marks within 5 minutes of using it, they’ll go back to their previous provider.
- Banking-level security and confidentiality. Maybe not 100% of users want that badly, but those who do are very vocal about it.
On top of that, users would very much like your product to be multi-platform, working with IMAP, Gmail, Exchange or Yahoo! Mail. And of course it should be available on the web, desktop, mobile and tablet.
Everybody is also a spoiled kid. Corporate giants (Microsoft, Google, and Apple to name a few) have been investing heavily in the space, but offer most of their products for free. It’s not like you can offer a less complete experience but make up for it with a lower price — unless you’re ready to pay your users 🙂
Don’t try to kill email, try to fix it
Even though many products have launched with a promise of being the “email killer”, people don’t really want email dead. It’s just too good.
Email is open and interoperable. As I said before, no company owns email. Instead, new companies come along, with a different idea of what a good email experience should be. They implement this idea, and it works with the rest of the email network. That’s the resilience of email, and the reason it has survived throughout the years. Email sent with Outlook on a Windows XP computer can be read on the latest iPhone’s Mail app, even though Microsoft and Apple made no concerted effort to get there.
Email is neutral. Anyone can reach anyone else, provided they have an email address. You don’t need to “add them to your network” or ask for permission. In 1989, the New York Times explained that email let you communicate with other people “regardless of rank,” something that wasn’t common at the time and is still amazing even today. This could have been the death of email, because it’s exactly the feature that spammers exploit. Once they have your address, nothing is stopping them from sending you junk. But thanks to email’s resilience, spam filters were eventually developed and saved us from the spam apocalypse.
Those two traits alone are enough to make me skeptical about any attempt to replace email with something radically different. Companies have promised to kill email before, but for the most part those attempts have ended in cruel irony, with notifications from so-called “email killers” piling up in email inboxes.
Killing email would leave a big void that would probably end up being filled by something similar. It might get a different name, but it will look a lot like the current version: an open, standardized protocol for text communication between people. The core of email is not what needs fixing: rather, the problems lie in all the issues around it. Email is so good that we’ve been using it too much, for too many different tasks. When one of these processes becomes unmanageable, we blame email as a whole.
Many things can be fixed. Do one thing and do it well
People use email for literally everything: 1-1 messaging, group chat, updates, customer support, marketing, to-do, file sharing, scheduling events, and much more. Email is a handy tool to quickly take care of all of this, but it isn’t always ideal.
Making just one thing better is enough to “win” at fixing email.
- Mailbox fixed the “mobile experience” of email clients. They were the first to take advantage of simple gestures to quickly sort new emails on-the-go.
- Rapportive fixed the lack of context of email. Who is sending this email? Is it urgent that I reply now? By aggregating details on the sender and displaying it inside the inbox, Rapportive saved many hours of manual searching.
- Boomerang reminders greatly reduce the mental strain of email management. No more emailing yourself with to-dos and follow-up, you can schedule it once and forget about it.
Or you can take a step back and approach the problem differently. Some of the things we do in email shouldn’t even happen there in the first place. By offering a better alternative, you can fix email without having to integrate with the email network. That’s the Slack way of fixing email. Within an organization, people would always default to email for everyday notifications and requests. Slack’s chat-like approach to internal communication eliminated the need for most of this email, effectively uncluttering the inboxes of their users. Scheduling, file-sharing, notifications are other areas where a non-email solution could improve the overall email experience of everybody.
Make money (or die not tryin’)
As a closing thought, I’d like to emphasize the importance of revenue for a successful company in the email space. Getting traction on a free product can get you acquired, as Mailbox or Accompli have demonstrated in recent years. As we’ve seen already, building an email product requires multiple expertises, so much so that if you build a promising product, used by lots of people, you’re very likely to get an offer.
But it won’t save your product.
For the products the trend is rather bleak: they all got shut down, sometimes without even having their features integrated into the buyer’s suite. Acquisitions of email companies seem to take one of two different roads. In the first one, the product is maintained, but isn’t a priority anymore. Improvements are dramatically slowed down, until they just stop. That’s the Mailbox-to-Dropbox scenario. In the other, the team gets to work on the buyer’s existing product, while the acquired product is taken off the market. That’s what happened when Sparrow joined Google and when Accompli joined Microsoft.
I’m not saying it cannot happen, but there is no good track record of email products surviving an acquisition. So if you want to keep your independence, you need to demonstrate your sustainability.