The Challenge of Minimum Viable Product (MVP) Development

by Admin on October 13, 2011

Mark Wayman It’s conventional wisdom in start-up land to devise, build, test and launch your latest software venture in phases. It makes all the sense in the world to do so but it doesn’t mean that it’s something that is easy to do or that doesn’t come with many forms of pain. You are, by definition launching something that is far worse than you are able to create.

One of Reid Hoffman’s Ten Entrepreneurship Rules for Building Massive Companies states:

Rule #6: Launch early enough that you are embarrassed by your first product release.
With my first startup,, it took us nine months to launch the first product. That was a disastrous mistake. We wanted to have all the detailed functionality right away, including social controls to people could decide to connect or not with the people in their networks. We wanted everyone to “Ooh” and “Aaah” about how terrific the product was. We wasted a bunch of time and it put us months behind on more important problems that needed to be solved, such as how to get our product in the hands of millions of people. From that I learned, if you are not embarrassed by your first release, you’ve launched too late!

Full Article »

The phrase “Minimal Viable Product” (MVP) is often used to describe the bare minimum amount of functionality, user-interface and support systems necessary to obtain a worthwhile amount of client feedback. It makes sense from a purely academic perspective but that doesn’t mean it’s easy from a human perspective. It’s even challenging to think in an MVP way as it’s natural to want to create your best effort at your latest passion-fueled venture.

Here’s some great examples courtesy of VentureHacks:

  1. “If Apple can launch a smartphone without Find or Cut-and-Paste, what can you cut out of your product requirements?” – Sramana Mitra
  2. USV-backed foursquare uses Google Docs to collect customer feedback. No code, no maintenance.
  3. Fliggo sells it before they build it.
  4. Grockit puts up a notify-me-when-you-release form on steroids.
  5. Auto e-commerce site uses manualation and flintstoning for their backend.
  6. Semiconductor company uses 5 people and FPGAs to build a $100M semiconductor product line.
  7. Consumer company uses fake screenshots to sell their product.
  8. Allicator uses Facebook ads: “Ditch Digger? Feeling spread thin? Click here to complete a survey and tell us about it.”
  9. ManyWheels uses Microsoft Visio to build clickable web demos for prospective customers.
  10. Cloudfire uses a classic customer development problem presentation.

Just because it makes sense doesn’t mean however that it’s easy to achieve. Passionate “ideas people” don’t typically start something unless they think it has legs and might get some traction and have a chance of turning into something worthwhile pursuing. The ideas phase is always the best one as anything is possible limited only by imagination. With all the possible features, which ones not only make sense as a collective effort but also are enough to gain truly revealing usage data?

To be frank it’s also challenging to put something out there with your name on it that most early adopters, friends, colleagues, and family will think is missing most of the usual or desired functionality. Comments like “YOU did this? Really?” are hard to swallow.

So back to Reid Hoffman’s statement — “Launch early enough that you are embarrassed by your first product release.”

I took this approach with my latest venture, It’s important to note that MVP doesn’t necessarily mean quick and dirty rather it means just enough to prove your concept which may actually still be a lot of work. So, I decided to create just enough functionality to find out if there was a need, if enough (you can’t, and shouldn’t aim to please everyone) people liked the offering and if some of those people would be willing to upgrade from the free version to the paid version.

I’m happy to say that this exercise was successful but it wasn’t easy. Comments like “This is like [product X] but not as slick” are tough to hear however true that might be when comparing our current release. My natural reaction is to respond with “Maybe – but wait ’til you see what’s coming next!” or “But you didn’t use this feature or that feature that they don’t have.” etc.

At the end of the day it doesn’t matter. The point isn’t about being better than a potential competitor now, rather it’s about validation of an idea before investing more time and money into those next steps.

Happily lot’s of great things are happening for Follr based on the current release so we got it right and we’re charging ahead planning future phases. This brings it’s own challenges as there are so many directions to explore but that’s another blog post entirely.

Is creating an Minimum Viable Product release easy to achieve? No.

Does every fiber in resist launching it until it’s “better” or something you’re proud of? Yes.

Do I think that’s the right mantra for iterative software development? Absolutely!

Previous post:

Next post: