How Viable Does a Product/Service Need to Be?

In 2005, Flock (aka the “social browser”) launched to much excitement. It bombed because it was an ambitious project prematurely launched as an alpha.

Earlier this year, Research in Motion unveiled the PlayBook. It was a half-baked product rushed out the door. Now, you can buy a PlayBook for peanuts because there is so little demand.

These are just two examples of products that weren’t viable enough to capture the imagination of consumers. In a fickle world, you only get one shot to impress. If the world goes “meh”, you’re DOA.

There a lot of discussion these days about how baked a product or service needs to be, focused around a concept called “Minimum Viable Product”, or MVP. It’s based on the idea that it’s better to launch a product early to a small group of users, who will provide feedback and real-world information so improvements can be made before a broader launch.

It’s a fascinating product development and marketing balancing act because the world moves so fast it can be difficult to wait until a product is totally ready for prime time. At the same time, a product or service that launches but doesn’t delight can be savaged, and it can never recover because consumers quickly move on.

For entrepreneurs, the challenge is figuring out when to pull the trigger on a launch. This is exacerbated by how quickly new digital services can be created and unveiled. Drinkify, for example, was put together over a weekend.

With “rapid development” becoming a part of the competitive landscape, there is more pressure for start-ups to launch their products, even if they’re not ready.

Given there are many start-ups that sadly failed the “delight” test, I believe there is more danger in launching too early than waiting a bit longer. Consumers are too fickle, quick to criticize and impatient to tolerate products or services that don’t meet the mark. It’s yet another hurdle that entrepreneurs need to overcome.

For more thoughts, Seth Godin had a blog post recently about when “MVP” doesn’t work. Eric Reis, one of the leading proponents of MVP, had a guest post on TechCrunch about how the wildly successful Dropbox was started as a MVP product.

Subscribe to "This Week in Canadian Startups"

A weekly newsletter delivered to your inbox!

http://www.benwise.ca Ben Wise

Great post Mark. I understand the idea behind MVP, but I worry that it sets entrepreneurs into the mindset of ‘good enough’. I have an MVP that I will take to market when it is ‘good enough’. As you mentioned in your post, there are lots of examples where this results in a half-baked product that dies in the market (although again, I really like my PlayBook).
I think the question is how do know when you’ve create an MVP that delights customers? This could be either because you’ve launched in beta very quickly and get customer feedback in a somewhat public forum (which could hurt your reputation) or because you took a long time before launching while privately getting that feedback so you could tweak and improve your product. I don’t know the answer, but would love to hear what you think is the best route? Which path would you advise your client?
Cheers
Ben
http://folkwolf.net Matt Rose

I think you’ve got the wrong idea about MVP. MVP doesn’t mean unpolished, or unfinished. If you look at Fog Creek, or 37 Signals (pretty much the inventors of the concept), their products are not incomplete, they’re highly polished, but highly focused. They don’t add features lightly, and when they do, they make sure that they fit with the overall idea of the product. It’s a reaction against the kind of feature-itis that gives us MS Office.

The two examples you give are particularly bad examples of MVP. Flock wanted to be the complete social browser. It could do everything. It was more a collection of features than an actual product, and hence, like all jacks of all trades, it was master of none.

The Playbook could be considered an MVP, in that it wasn’t nearly ready to be released, but it was still a huge grab bag of features. The problems there was that they placed their emphasis on all the wrong features. I mean, it could run Flash, but couldn’t do standalone email?

There are plenty of MVPs out there that failed, because they were a little too minimalist.

Let me give you an example: A friend started up a shared document service that was great at solving the problem of documents being emailed around, comments being made in email, and then somebody having to incorporate those changes, then sending it around again, starting the whole thing again. A natural for a web-based service, that solved a real problem.

I got an email a couple of weeks ago saying he was shutting down the service. He’s involved in other projects now, and there’s nothing his service could do that Dropbox couldn’t do better.