Anatomy Of A Failure: Lessons Learned

This post was written by guest contributor Paul Bragiel, founder of Meetro, a location-aware instant messaging platform that was DeadPooled last month. Bragiel is also the founder hosted forum solution Lefora. See our coverage of these two companies here, along with our first post on Meetro in August 2005. Also see our post titled What To Do With Failed Startup IP?.

In the spirit of openness, I write this post on what we did wrong at Meetro – a post mortem of sorts. You don’t see this often enough in the startup world even though the majority of startups go belly-up. Hell, there are probably a few today that will go away with a whimper. So much knowledge is lost. If you’ve had similar experiences, I encourage you to share them over at Lefora.

To those of you not familiar with Meetro, we were one of the first location-based social networks. We figured out where you were physically and then we would tell you else was around you in real-time. You would then be able to instant message with them, check out their profiles, and hopefully meet up. Other functionality included telling you about restaurants close by, media created nearby, and various local information that pertained to your location. We also supported all your various instant messaging protocols (AIM, MSN, Yahoo) and a slew of other social features.

Even with a robust product we simply couldn’t capture enough market share. So here are the major problems we had that, in the end, we couldn’t overcome. There were, of course, mini fires and random things but every startup goes through those. I have a feeling some of the other location-based startups out there right now are experiencing the same things.

Most importantly, there was a “location problem”. It’s really hard to grow a product that’s 100% focused on where you physically are. Tons of companies have tried this before and most of them have died. We, of course, were cocky and had to give it a try. There was just something so sexy about the idea that you could load up a piece of software and it would tell you about someone nearby who was interesting to you. Someone will crack this and make billions of dollars on it. I can only hope to be involved in some shape or form, since it’s an itch that hasn’t gone away for me.

A perfect example of this difficulty was our community in Chicago. We launched our product and got all of our friends in Chicago on it. We then had the largest papers in the area do nice detailed write-ups on us. Things were going great. We had hundreds of active users and you could feel the buzz around it. We threw a few parties that continued to support the good mood all around. Hell, our CTO Sam even met his current girlfriend at one of them.

The problem we would soon find out was that having hundreds of active users in Chicago didn’t mean that you would have even two active users in Milwaukee, less than a hundred miles away, not to mention any in New York or San Francisco. The software and concept simply didn’t scale beyond its physical borders.

I would also cite a theoretical Idaho example. No matter how slick Meetro was, if you opened it up in the middle of Idaho and no one else was nearby using it, the service simply wasn’t that interesting. We did do a few things to address this, such as including “random” people and the whole Meetro team in the application. I must say, this did create some great friendships and kept some people around, but in the end it just wasn’t enough.

So how do you overcome the location problem? The way I see it, a Meetro-like application will succeed with one of the following strategies.

1. A product with a HUGE audience turns it on. I’m talking about a MySpace, Facebook, etc. Something that has a really rabid audience, where it would be a great feature addition. It still wouldn’t be easy. You would have to do it properly right out of the gate. There are just tons of privacy and personal issues that come into play when you are talking about physical location.

I remember vividly being pissed that MySpace didn’t work with us (read: buy us) after talking with them off and on. I was naive, the more I think about it. It would have unleashed pure anarchy and it wouldn’t have been worth it in the short-term. Plus, at the time they were dealing with their own scaling issues and moving over to .Net. However, I still think it’s something that should be on the roadmap of one of these big players.

2. A company has a really long term vision and builds it out city by city. This is similar to the approach taken by Yelp. They know it’s not easy and I know first hand that they are putting a lot of effort into fostering their communities. It’s an ongoing job. You simply can’t establish a city and then let it fend for itself.

We had this happen to us in Meetro. After we got the Chicago community going, we up and moved our company to Palo Alto. We weren’t there anymore to be the face of the community, organize events, etc. While the service continued and had a core bunch of people using it, by no means was it as rabid as it was at its peak. By the time I realized this, it already was a bit too late and we had shifted our focus to getting a community going in San Francisco.

3. Someone creates a viral product that grows like crazy but location isn’t the core feature. It just happens to be part of the bigger whole and as people use it more and more, they realize that the location piece built into it has become increasingly valuable for them. I don’t know what this product is, otherwise I would be building it right now.

Next, the “download problem”. This one is obvious now but when we started in 2004, Web 2.0 hadn’t quite happened yet and some download apps were still growing (e.g. Skype). Plus we needed a download for the application to work. Having worked with phone carriers for years, I had decided early on that we simply weren’t going to wait for the carriers to get their act together on location. They still haven’t done it properly 4 years later.

So to get around them we decided we would build out our own location technology. We filed patents and everything. Simply put, we were counting on the continued growth of WiFi. When you launched Meetro we would scan for all the WiFi networks out there. We would then crosscheck what was out there with what we had in a huge global database (it had grown to 4+ million hotspots when we stopped). If it was in the database, then we would do some trilateration to figure out where you were. If not, we would ask you to enter your location. We would save this info and use it later to crosscheck and verify it against similar data.

This data grew quite fast. We averaged around 5 wifi routers found per location, and in dense cities like New York, I remember averaging 9.6. I remember being quite excited since a key part of our business plan was to build an alternate GPS of sorts and use Meetro as a vehicle to gather and refine this data. The best part was that the technology was self-healing, so if some router was replaced or moved our system, we would learn about it very fast.

In the end, though, the dropoff that happened once people had to download and install Meetro was HUGE and didn’t help us at all. If I recall, it was something in the 80 to 90% range. It crushed adoption rates.

Lastly, the “realtime problem”. This one is similar to the location problem in that if someone wasn’t online when you were online, they were no good to you. While the realtime chat aspect of the application made for some really serendipitous meetings, it also made it harder for people to gauge the activity of their communities, especially if they logged in at odd hours, people were set as away, etc.

I can still feel the magic of when I was on layover in the Denver Airport, I met one of our users, and we grabbed a beer. This is what I dreamed Meetro would be about all the time, but those moments were too few and far between. We did fix this in the end but it was too little too late. So, to anyone tackling this problem in the future, make sure you have some type of persistence built-in, be it “people here previously” or “most common visitors to the area” etc.

Compound these 3 problems and the writing was on the wall. So how would I do things differently today?

1. I would wait until location is all clean and dandy with the carriers and build on top of that. Loopt has been doing the huge business development cycle and has been waiting it out for the past few years. It seems as though they’re seeing the light at the end of the tunnel. I’m not really following who else is doing this stuff right now, but I’m sure they’re out there.

2. I would take our technology, create an API, and plug it into existing applications that have already been downloaded and given low-level access to the hardware our technology needed. I’m thinking about something that would run on top of AIM, Skype or Firefox, for example. Act as a friendly parasite on top of these apps that are already well established. Expect some licensing announcements soon concerning our IP on this front.

3. The other option is to build out something that just allows you to “check in” where you are at. Kind of like Twitter meets location (Dodgeball did this). However, this in my mind compromises the ultimate use case of a Meetro-like concept.

We could have gone about trying to fix Meetro but the team was just ready to move on. Raising money on the flat growth we had was nearly impossible. Plus I knew that in order to keep the tight-knit team we had built together, we needed to shift focus for sanity sake. People (myself included) just felt beat up. We knew that fixing these issues would involve a complete rearchitecturing of the code, and people just weren’t excited about the idea enough anymore to do it right.