I’m saddened to hear the news that EventVue has closed up shop. It’s never fun watching other entrepreneurs have an exit like this knowing full well how much of themselves they put into it. The good news is the EventVue guys clearly have learned huge lessons and will be in a much better position to win in round two.

The one point they brought up as a lessoned learned was that they didn’t focus on learning and failing fast until it was too late, which reminded me of a quote from Joi Ito I recently heard at a conference.

“Want to increase innovation? Lower the cost of failure.” — Joi Ito

This is absolutely crucial. As a startup you need to fail and fail often. Not a lot of people know that SimpleGeo was, in fact, born of failure. Matt and I originally started the company as a location-based gaming company. Due to market realities (investors rarely invest in gaming companies in the seed stage), personnel realities (neither Matt nor I had built games), and other factors we had to have what I call our “come to Jesus” moment. Since then we’ve focused on small, quick iterations and quickly scrapping or moving on from our failures (or in many cases simply adjusting our assumptions).

Easy to say, but how are we doing it?

1. We use a loose approach to Agile development with two week sprints. This means that, worst case scenario, we’ve wasted two weeks of effort in order to find out if a tweak, product, etc. is going to fail. I can’t emphasize how important this is. If you push your team 6 months and release a giant product only to find out users hate it or don’t use it, you’re screwed. 6 months is a lot of opportunity cost for a startup.
2. We actively engage our user feedback. If users don’t like something we abandon it. If users are demanding something we move it up the priority list. For instance, we thought for sure that people wanted location-based search first and foremost after storage. Turns out, users actually wanted better tools for accessing and managing the data they’re sending us. So we’ve focused on churning out more SDKs and tools for managing data.
3. We use Amazon EC2. Specifically, for testing and prototyping, we use spot instances. It’s an extremely cost efficient way to destroy servers during testing.
4. We start small. Our current product offering is probably only 10% of what users expect from us long-term as far as pure number of features go. That being said, we picked the initial use-case and, I think, nailed it. The reality is 60% or more of the use cases for our users is simply storing millions of points and running radius queries on those points quickly. It’s also the foundation that all of our other products will be built on. So we’ve spent time focusing on building and iterating on that use-case. As a result, we’re multi-homed in three datacenters (actively serving data from all three), redundant across all three (meaning your data is stored in every datacenter), searches are extremely fast (under 50ms in some cases if you’re on EC2), and all points are backed up to S3 in YOUR account (it’s your data after all).

We’re not perfect by any means, but I think Matt and I realized early on that we need to be most efficient at recognizing and owning our failures and deficiencies. If you focus on minimally viable products, small iterations, and prioritizing user feedback you, too, can fail fast and often.

“Failure is useful.” — Larry Page