December 2010 Archives for 2011 is a great, free tool by Kissmetrics that lets you kickstart the customer development process in a matter of seconds. The survey is already done. You literally just click a button and then send out your link (or embed it in your product/feedback process). I've recommended it a lot to people, but haven't used it myself until now.

This year was the first year I put a sustained effort into blogging. At the beginning of the year, I set a goal of 100+ quality posts in 2010 (I did 34 in 2009 and 28 in 2008). 

With 115 posts this year, I feel I accomplished the goal. And it was really a proxy for a more important goal that I also feel I achieved, which is forming both a workable blogging routine and an audience with which to interact.

So I'd really appreciate it if you'd take a minute or two to answer a few questions so that I can better serve you in 2011:

I don't dwell on the past


When my first company (learnection) failed, I took it pretty hard. In fact, I took it really hard. It was the first time I had failed at something big.

The closest thing previously was probably a B+ I got in statistical mechanics in college, but it was hard to get more than annoyed about that one given that I was hardly paying attention. That class was in my last semester and my mind had already moved on from Physics into a brief stint with apathy and then onto startups.

I had hired five of my friends to work with me, and even convinced one (and his girlfriend at the time) to move up to Boston after college (from North Carolina). When the money ran out a year later, they all moved on and the company was as good as dead. 

That was the point when the failure really hit me for the first time. I'm a very optimistic person, but for a few weeks there I was very unhappy. The company didn't end though. I let it linger via my nights and weekends for another year and half or so, while I essentially dwelled on the past. 

Continuing to think about it and tinker with it was certainly preventing me from moving forward onto bigger and better things. It was essentially a complete waste of time.

I had trouble letting go. And then one day everything changed. It wasn't an explicit decision I can remember, but more of a shift in state of mind. If anything, the trigger may have been moving my server and losing some of the files such that I couldn't easily get the learnection code running again.

In any case, I no longer dwelled on the past. Since then I've failed a lot of times to really no bother. 

It's not that I don't care about my projects. Quite the opposite. If you don't care, I think your probability of success is minimal.

Instead, I think that I am able to separate my identity from my work. Perhaps it is a defense mechanism at its core. 

I feel it is more enlightening though. I also think that's why my parents seem to take these failures harder than me--they wrap my identity into the projects even though I do not.

I don't try to forget about the failures. Nor do I feed upon them. There is actually no explicit process. When appropriate, I move on. I draw on past experiences when relevant, but otherwise I just don't dwell on the past. It's that simple.

For startups in particular, I view failure as a natural process in a startup career path. If you're serious about startups, you're most likely going to fail many times. Promising features will die. Products within your startups will flounder. And whole startups will die. That's the life you're choosing.

Update: some good comments on HN.

Viral Cycle Time

Another often overlooked viral loop concept is cycle time. That's the average time it takes to complete one loop, e.g. the cycle from sending out an invite to the person who was invited sending out an invite. 

In other words, Viral cycle time is the wavelength of viral loops. It's often overlooked (at least initially) because the focus is usually on just getting exponential.

Cycle time is important because along with the k-factor, cycle time determines growth trajectory. You can be exponential, but still grow really really slowly. A decent analogy would be radioactive material with a really long half life. It could take you a while to double...

Like anything, though, there are opportunities to optimize. For example, if your viral loop is based on email (often is), you can send out varying kinds of reminders at opportune times. You can also try to create a sense of urgency. 

Another way to optimize is to shorten the times between sign up and invite, e.g. by making it part of the process and/or by making it accessible from every page. And finally, the third part of the cycle is the time from click through to sign-up, which can be reduced by forcing sign-up to get access to content and/or again creating urgency to sign up. 

Cycle times are pretty important in other areas too. For example, the lean startup movement talks about reducing the cycle time of getting code out the door and into customers' hands, based on the idea that the faster you iterate, the faster your product will achieve market penetration.

Viral Pockets

When you're serious about engineering a viral loop, you meticulously measure each loop component, and the overall k-factor. A factor greater than one means you are in exponential growth territory. 

However, you can see exponential growth with an average k-factor less than one. I've seen it happen several times now, e.g. in my last company and now in two of my portfolio companies. 

This phenomenon is due to what I call "viral pockets." These are subgroups of your users that are experiencing exponential growth, i.e. pockets of virality. The overall average k-factor is still less than one, but your service is nevertheless growing at a rapid rate fueled by internal dynamics.

The takeaway is that you should be looking at subgroup statistics to spot these pockets as well as trying to engineer them via subgroup landing pages, emails and other particulars of your viral loop. Once identified, you can focus on optimizing these parts of your user base that you can get to go viral, which by their very nature will start to take over your entire user base.

Testing DuckDuckGo CDN performance via Cedexis Radar

A few weeks ago, I ran a test on DuckDuckGo to see if CDNs would help the search engine perform better (and, if so, which CDNs in particular). I did the testing with Cedexis, a startup I know via prakash from HN.

The way it works is they collect real-time statistics using DNS on all the CDN providers (they call this Radar). CDNs covered include Akamai, Amazon Cloudfront, BitGravity, CDNetworks, ChinaCache, Cotendo, Edgecast, Highwinds, Internap, Internode, Level3, Limelight, Ngenix, Prime Networks, and Yacast (here's the full list).

It's done via JavaScript so that it completely reflects the userbase in question, in this case DDG. It's also private (i.e. in line with DDG's strict privacy policy), which I confirmed in writing before doing the test.

Here's what I learned. The top 3 countries from which DuckDuckGo got Radar traffic are the US (48.38%), UK (15.72%) and Canada (5.13%). The countries that make up ~80% of DDG traffic are: US, UK, Canada, Germany, Australia, Spain, Netherlands, India and France. 

In the US, it turned out that DDG is faster than most CDN's. In the UK, for more than 80% of end-users, DDG is faster than most CDN's. In Canada, for ~35% of end-users DDG is the fastest, and for the rest of the users Internap, BitGravity and Limelight are the fastest depending on the network.

CDN speed varies by DNS provider. For the US, that DNS provider breakdown is ATT (12.44%), Google (9.57%), OpenDNS (6.51%), Verizon (5.47%), and Level 3 (2.9%). For the UK, OpenDNS has 61%, followed by Btnet (8.85%), Ntl (7.04%) and Opal (2.72%)--others are listed in the spreadsheet linked to below.

By country, here is the speed of out servers (avg. HTTP response time). All our servers are in the US, and you can see how response slows as you get farther away.

On any given day, Radar determined which provider "won" in a given country and DNS provider. Their more advanced product actually uses this data to route users to the best CDN at any given time.

The summary of all this data is in this spreadsheet (Google doc). It declares a winner (over the whole time period) for country and DNS provider, and lists average response time for each CDN across those variables. For example, here is the US breakdown. For the full data, check out the spread sheet (I made it public).

DuckDuckGo uses DNSMadeEasy for DNS and is on the Verizon FIOS network. See this (somewhat outdated but largely accurate) post on DDG architecture for me details on our setup.

My takeaway from this is moving to CDNs is not super-pressing at the moment. It would be better to have some local servers.

Prakash has also told me that he'd be happy to do a similar free evaluation for anyone else from HN. You can email him at

DuckDuckGo/WOT search partnership



DuckDuckGo (the search engine that I founded) has been a leader in removing spam, protecting privacy, and using crowd-sourced info to improve results. I'm happy to announce a partnership with Web of Trust (WOT) that further extends all three of these focuses.

WOT maintains reputation ratings on over 30 million sites. They crowd-source these trust scores from their community of over 15 million users of their tools, which help people stay safe when browsing the Internet.

Now DuckDuckGo is one one of those tools. We have a new setting option where you can replace the site icons next to results with WOT's intuitive traffic-light ratings (look for 'Site icons').

Recently the New York Times highlighted a problem in algorithmic search, whereby bad actors can rank highly. These aren't strictly spam sites in the usual sense, but sites that look legitimate until you interact with them off-line.

DuckDuckGo+WOT is the perfect solution to this problem, enabling you to search with peace of mind. It works especially well for shopping and downloads.

I'm still exploring other ways to integrate WOT, e.g. having both favicons and ratings, easily being able to switch between the two, and removing very dangerous sites from the index altogether. As always, I'd appreciate your feedback.


Increasing Series A financing risk for software/Web startups

There is an angel bubble. There isn't an angel bubble. It doesn't so much matter to startups per se. What matters is the effect of the changing angel dynamics on startups. 

More startups are forming and more are getting initial funding, which increases their average life-span. Both of these factors increase the amount of startups out there at any given time.

At the same time, the VC industry is probably shrinking and also probably starting to invest less in software/Web. Even if those things were not true, the # of deals in software/Web are not increasing at nearly the same rate as the increase in startups mentioned above.

This means that while startups can get angel rounds done easier, they're going to find it harder and harder to close their first bigger round. It's simply a numbers game. 

Therefore, at the moment I see an increasing Series A financing risk for software/Web startups getting started today. It could go away if somehow VCs start doing a lot more of these financings, but I don't see any signs of that yet from anywhere or anyone.

So where does that leave you, new startup? I think you have essentially two choices.

Choice #1: go big or go home. Raise a big angel round, prove all your assumptions, find a traction vertical (customer acquisition channel) that you can pour money into, and then make it a no-brainier to get a big round of financing from a VC. 

It's a high-flying strategy. If you fail, you're done.

Choice #2: focus on profitability from the get-go. Raise an angel round required to get you to break even with a plan to do so. Move slower, but methodically. The money should stretch, but at the end of it you've beaten the financing risk because you don't strictly need another round.

Of course, you may end up at the same point as the first strategy, where you found a channel to pour money into, and you end up raising VC to do so. You won't be forced to though.

On the face of it, these choices seem like they could be one in the same. In both cases, you're of course looking for traction. The difference is two-fold.

First, different types of startup ideas will generally fall into the different buckets. The go big strategy is all about building $100M+ companies that are by definition interesting to VCs. You (generally) need to raise big angel rounds to prove those assumptions. These are often empire plays.

The other strategy is more like $20-50M ideas that may not ever be that interesting to VCs. You may end up with a nice bank loan though to fuel growth. You could always come out with other product lines, etc., but on the face of it, we're talking about smaller opportunities. Note, however, that smaller opportunities does not necessarily translate into smaller pay-days.

Second, you're going to spend money differently. In the go big strategy, you're hiring right away, you're spending on building platforms and other big stuff like that. Profitability is not in your vocabulary. In the other strategy you're generally tinkering with processes and business models from the get-go to get you to profitability.

As an angel investor, I'm all about the latter strategy, unlike most of my peers (exception: hacker angels). I'm looking for investments where the financing risk is inherently diminished because of the type of startup and its strategy.