Anatomy Of A Failure: Lessons Learned by Meetro

Anatomy Of A Failure: Lessons Learned by Meetro

meetro_logo.png

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.

>BackTrack

Leave a Reply