Anatomy Of A Failure: Lessons Learned | Hacker News Reader

Anatomy Of A Failure: Lessons Learned

techcrunch.com

26 pointsnickb11 comments

I hope more startups do this. As PG wrote in one of his essays, if you can figure out a lot of possible ways to die, and avoid them all, you'll probably succeed

One thing that stood out for me is the lack of actual description of problem they were solving.

Location can be a solution to "too many online friends, I want to select a subset" problem, but that problem clearly was not attacked head-on (not sure if it even exists...).

Location could be a solution to "I have several offline friends but we're so busy we don't meet often, only when we bump into each other. Would be nice to bump into each other more often, eh?". Clearly this problem was not targeted either.

It seems they were trying to address problem of "how do I meet strangers on the street". That problem does not seem to exist, as most people do not seem to want to meet strangers on the street.

Any traction that they have had seems to be of "I want to belong to an exclusive club of cool people like me" kind of thing. It's real problem and while competition is strong market is very open due to its nature. Of course you really have to work on maintaining exclusivity and feeling of being "special", which it seems they neglected.

They should have figured out problem definition, that always helps.

The Meetro guys gave me a place to stay when I went to Startup School in 2005. I'm sorry to see them shut down. I think it was about the time they were trying to talk to Myspace, as I remember the topic coming up. Partnering with somebody like Myspace might have given them a userbase, but I think Myspace tried launching its own IM service, which never went anywhere.

The biggest problem I saw then is that nobody wants another IM network, and Meetro seemed bent on using their own protocol. Support was added for the major protocols eventually, but I don't think it was ever a big enough focus. I think making the protocol a Jabber extension and encouraging other people to implement it might have increased adoption, but wouldn't have helped the company.

Great post. There's as much to be learned from a failure (maybe more) as from a success. Thank you, Paul. I don't imagine an article like this is very easy to write.

Interesting that customer demand is never mentioned. Have we become so enamored by the idea of building the next killer app that we never bother to find out if anyone even wants it?

Determining if there is going to be demand for something that folks have a hard time "getting" is very tough. Surveys are hard because if people don't get it, they can't answer the question in a meaningful way.

For example, after watching my wife use the thumb wheel on her Blackberry, I probably would have answered "no" if asked if I would want a touch-screen phone (takes two hands to use). The survey wouldn't have been able to transmit the "coolness" of the iphone.

I would love to hear/discuss how to overcome this problem. I am facing it right now--I have to present a market survey researching my next product, and I am fairly well lost!

I've never liked surveys because they don't dig deeply enough.

Instead of the superficial opinions of 100, I'd rather have the deep insight of 5.

How to do this? Dig, Dig, Dig. Deeper. Beat the hell out of it. Keep asking questions. Why? What about if we did this? Or that? How about this?

We do this all the time among ourselves when we design and code. We just need to find a handful of power users or early adopters and do it with them when we conduct analysis.

What about when you are trying to decide whether or not to throw effort at a concept? Before the alpha/beta/ etc?

All the more reason.

Getting deep insight from half a dozen key people takes no more effort than many other kinds of "basic research". IMHO, it's an excellent expenditure of resources. Good feedback -> all the more reason to go gung-ho, bad feedback -> save yourself a lot of grief later.

How many excellent products never saw the light of day because of lack of demand? I'd do everything I could to prevent that from happening.

That's why it's super important that you can hack up a prototype very quickly. It may help to learn a RAD tool, or Lisp.

Absolutely. I consider "hacking up a prototype" part of analysis, not development.

I would also like to add a big THANK YOU to Paul Bragiel for spelling out the lessons. Humanity advances the fastest by pooling knowledge and Paul has certainly contributed his fair share.

Reply on news.ycombinator.com