Friday, November 30, 2012

Expect Something


One of the hardest things to do as an entrepreneur is to have a reasonable expectation. Often you end up thinking one of three things: 1) this is going to be amazing (ie I’ll get 100,000 downloads, execute multiple biz dev agreements, will close a round of funding); 2) this will never work and is doomed for failure; or 3) I have no idea what will happen.  The problem with limiting yourself to these three outlooks is that you are missing the range of likely outcomes that actually inform strategy and tactics. For every action will have an outcome no matter what. Something WILL happen. Prediction is simple in hindsight, but true learning comes from making a concrete prediction BEFORE you know the outcome.
Taking Meetings
Remember that moment when you were hit by the brilliance of your novel idea to change the world? You wanted to share it with everyone? So you started to set up meetings with all of the smart, wealthy, well-connected people you knew? And how did those meetings go? My guess is, it went something like this: “Very interesting. What about these [insert risks and potential pitfalls]? But I do agree that [insert potential benefits]. Well, good luck and keep me posted.  And definitely let me know once you’ve [built the product/made a sale/inked a deal/raised a round] and gotten traction.” The reason these meetings were generic and vague and never seemed to produce anything tangible is that you likely had no realistic expectation about their outcome. In your enthusiasm to discuss your idea, you may not have asked these critical questions: what do I want from this person? what can they give me? what constraints prevent them from giving it to me? if they can’t give it to me, do they know someone who can? will they introduce me?
Similarly, when speaking to someone with specific expertise in what you’re doing, you should always have a hypothesis going into it. For instance, a close friend of mine is a medical resident interested in entrepreneurship. He got an introduction to a guy who went from residency to startup world, to founding his own companies to investing his own capital. The perfect contact! But what I told him was, if he doesn’t have a specific viewpoint before going into this meeting, then everything this guy tells him will be “right” and my friend can’t start the learning process of fixing his incorrect assumptions. This meeting is an opportunity to make mistakes and learn from him. To articulate a viewpoint that may well turn out to be dead wrong. But though he’ll feel sheepish when he completely inaccurately describes his perception of, say, the investment process, he’ll never make the same mistake again in future conversations. Because by forcing himself to articulate a set of views PRIOR to the meeting, he is guaranteed to better refine them for future meetings, of which there will be many. As my brilliant economics teacher told us, “I can tell you the right answer, but it’s only by diligently convincing yourself of all of the wrong answers that you will truly understand it.”
Predicting your launch
Here’s a nice piece about the day after you receive coverage in TechCrunch. It outlines that young entrepreneur’s disconnect between expectations and reality. We, as a team, had this problem early on. We’d say, “How many users are we going to get from PR.” And our answer was, “Well, there’s really no way to know until we do it.” That’s certainly true. There is no way to know. But certainly we have to have an EXPECTATION. Let’s say we expect only 15 people to show up. If we need 15,000 to have a successful launch and a viable business, then we better get back to the drawing board on what tactics might get us there. But if we expect it to be 15,000 and it turns out only to drive 15, then knowing that we were wildly off in our prediction will help us reevaluate our current plan (ie, get coverage in TechCrunch and Mashable and then put feet on desk and pop champagne may not be the right answer). So of course you will never be able to accurately predict the outcome - but you have to believe SOMETHING! Otherwise, why are you doing it in the first place?
Raising Capital
We all know it’s hard to raise capital and it takes a long time. But we also believe that, because we may be lucky enough to know a few millionaires or billionaires, that we don’t have to worry about the “traditional” fundraising process. We simply need to refine our idea and plan to near perfection and then, along with our inherent character, present it to this rich guy who has “known me all my life” and wait for the check to clear. The problem is, this is an unrealistic expectation. I often hear from friends that they have meetings with the one or two “whales” in their networks. It’s an exploratory meeting where they get lots of great advice, challenges on their core idea, and promises of future help and introductions. I ask them, “So, did you ask them if they would invest in you?” Invariably the answer is, “Oh no. Not yet. I’m not ready to do that. I have to work on my plan/product/thesis before I bring up that part of the discussion.” The problem with that thinking is that it ASSUMES that future investment hinges on having the idea ironed out and in a position where capital is the only barrier to execution; and that, furthermore, your relationship with this person, and how well they know you, will cement the investment. However, remember that this person is more than a pile of money. The reason you ask them, that day, if the would invest in YOU (not the half-baked idea, which they will evaluate at some point in the future on its investment merits) is that they may surprise you with their answer. They may say, “Oh, my money is locked in a trust that I have to get the judge to approve allocations from because otherwise my ex-wife will bring me to court. So, no, I don’t invest in early stage ideas.” Or “I love you, but I only invest in real estate since that’s all I understand.” Or “Perhaps, but I invest bi-annually, so ask me again in June because I’m done with allocations for the year.” The point is, who knows what their specific constraints are unless you ask? By determining that as early as possible, you can modify your story, timing and asks with plenty of time to spare.
Conclusion
Start-up life can be exhausting because of its inherent unpredictability. There are so many variables and so many unknowns that the futility of the process is enough to stop anyone from pulling numbers out of thin air. But the more disciplined you are at taking a specific view and then being comfortable being proven dead wrong - even if it’s by someone you want nothing more to impress - the more learning you’ll get early in the game. Because I promise that if you are talking to a well-respected VC, whom your uncle went out of his way to connect you with, and you brashly tell him that you’ll make 1.5x his money within two years, you’ll never, ever make that mistake again.
Avi Levine is co-founder and CEO of PhilterIt, a Google Chrome extension for Gmail.  You can find him on Twitter @alevine0.

Sunday, November 18, 2012

How To Build An Email Client


Well over two years ago, I was bitten by the “email is broken” bug.  You know that one - your inbox is clogged and exploding, you’re tired of the text, you hate labels and folders and you just want it to stop screaming at you.  Or maybe you’ve never been bitten by that bug - you’re a Gmail ninja, an Outlook pro, are super-efficient or buy nothing and have no friends.

Nonetheless, I assumed that I wasn’t alone in feeling this, so my co-founders and I set out to change the world for my 3.5 billion email using brethren.  I’d say that’s pretty noble of us.  Well, I’ll spare you the suspense and tell you that perhaps a new client ISN’T the answer.  But while I wrote about the challenges from a user perspective, I’m proud to say that we were able to hack together a pretty robust client using some nice new technologies and thinking creatively about how we handled certain issues.  And, we must’ve been on the right track, considering AOL decided to flatter us by releasing an almost identical product five months after we launched (us and them).

A Little Background on Email Messaging

Email is one of the oldest protocol’s on the internet and not much has changed since Ray Tomlinson sent the first ARPANET message in the early 70s.  With the rise of IMAP, email service providers made it easy for customers to retrieve emails from any address to any email client that supported it (see this easy primer on IMAP v POP3).  So, for us innovators, we can access the goods without requiring users to change their email addresses.  All we have to do is build a better front-end experience.  Easy, right?

To Rails or Not To Rails?

We all know and love Rails for its ability to prototype new projects in weeks rather than months. We chose Rails, because all we had was a concept and it was imperative that we build something substantial and quickly that would allow us to justify our first entrepreneurial plunge. Working part-time with 1.5 developers during nights and weekends, we built a working prototype with Rails in just over 30 days that would fetch IMAP messages from Gmail and Yahoo and automatically filter the messages against a rudimentary database of matchers (with Charlie as our brand logo stand-in).

The prototype was a big success for us, leading to us raising an initial round of outside funding. Perhaps equally important, it also demonstrated that we had a lot to learn about email. With a database chock full of our personal email messages and a Ruby-based daemon constantly fetching new mail, we were introduced to the dual challenge of ensuring email security and application scalability from Day 1. New users would certainly expect that we would be passionate protectors of their data. Furthermore, every new user who would sign up, even if she never signed in again, would become an active, concurrent user of our application. We had raised money, but we were still on a budget and horizontally scaling Ruby by itself was not going to be cost-effective.

We Know What We Node(.js)

In October 2011, we migrated our email daemon to Node.js. Contrary to what some may say, it is not a Rails killer, … but it kicks some righteous ass at performing thousands of concurrent calls to a remote IMAP server and gracefully handling those responses asynchronously. A single server instance of Node 0.6.x series literally gave us the fire power that we needed to support thousands of concurrent Gmail, Yahoo and AOL users with refresh cycles occurring every 5 minutes, which could have been pushed to every 1 minute if we didn’t have to worry about hitting too many concurrent connections from a single IP address.

To be fair, it wasn’t all sunshine and rainbows. Callback soup was a bit of a pain in the ass at first and finding mature libraries who could act like grown-ups (POP3 we’re looking at you) was a bit hit or miss. But life in server-side JavaScript land was quite productive once we solved those problems with JQuery Promises, experimented with what was out there on Github, and politely told Hotmail users that we felt terrible about not being able to support them (not really).

After 6 months of working with it, our belief is that Node is like having a pair of vise grips in your toolbox. You certainly won’t use them as often as your hammer, but they are really useful in specialized applications.

The Devil’s In the Details

In a little over 6 months, we built a comprehensive, sleek, and powerful email client that could sync up to 10 accounts from Gmail, Yahoo, and AOL; allowed the user to compose, send, receive, reply, reply all, view sent messages and drafts; synced read/unread messages with the underlying email client; supported attachments; and, of course, offered our differentiated, value-added filtering and visual icons.  And wouldn’t you know it, they wanted MORE!  And why shouldn’t they?  Because who thinks about the importance of supporting email signatures - an easy add - or archiving messages - an easy add - or chat - a medium add - or threading - a tougher add - or….well, you get the point.  And then mobile, calendar, tasks and a lot of easy “adds” add up to a level of development complexity that means you’re running full sprint just to make it to the starting line.  It reminds me of what Andrew Wiles said when he was working on his solution to Fermat’s last theorem (I’m quoting from memory here), “It’s like trying to fit a carpet that is too big for the room.  You go push down one corner, only to see another corner pop up.  So you deal with that corner, and the corner you just set, pops up.”  The email ecosystem is so complex and so important to the user in so many different ways, that you better be ready to tackle a lot of corners.

Mama, I’m Coming Chrome

Fortunately, building a new email client is not the only option for innovators.  Anyone who attended this year’s Inbox Love conference in Mountain View would have learned about a number of exciting new enhancements to email.  Sure, there’s Outlook.com and AOL’s aforementioned Altomail, but there is also an entire suite of web apps (such as OtherInbox and Sanebox) and browser extensions (such as Rapportive and Boomerang). With PhilterIt, we’ve taken the Chrome extension path (and will soon add other browsers), leveraging our node.js back-end and using backbone.js on our front-end.  We’re extremely pleased with how seamlessly we’ve been able to integrate our visual filtering within Gmail, and how much control/functionality the user retains. Also, if you’re building a new email product, check out Context.io, recently acquired by ReturnPath.  You could even win some money.

So best of luck to MinboxMail-PilotGlider.ioContur and all of the other inbox warriors out there. It’s going to be a ride.
Avi Levine is co-founder and CEO of PhilterIt, a Google Chrome extension for Gmail.  You can find him on Twitter @alevine0.
Related Posts Plugin for WordPress, Blogger...