I recently had the pleasure of meeting two MBA students with big ambitions: they want to redefine online shopping. I sat back in my chair and listened closely as they pitched their ideas for an entirely new online shopping experience. 3D this, interactive that, Web 2.0 the other thing.

As they laid out the extensive feature set they envisioned and the millions of dollars in venture capital they were hoping to raise to build this product, I was struck by an interesting realization: the concept of a Minimal Viable Product (MVP) is actually quite counterintuitive. Don’t you want your product to be as awesome as possible? Features are good, so how could fewer be better?

Manhattan is full of gorgeous skyscrapers. No self-respecting person walks around thinking to themselves “Gosh, if I were going to build a skyscraper, I’d want mine to look like shit.” That just doesn’t happen! Instead, we have a natural tendency to want to ‘one up’ the status quo: “I’m going to build a skyscraper out of gold!”

But in software, version 1.0 of your product should look like shit! Reid Hoffman, founder of LinkedIn famously said: “If you’re not embarrassed by the first version of your product, you’ve launched too late.”

The heart of the issue is that very few of these minimal viable products exist in the real world. Why? They rarely stick around! Customer feedback quickly drives additional improvements and features. Soon, memories of the mediocre original product completely fade away!  How many of us realize that the original iPhone didn’t have apps?! It wasn’t until July 2008, an entire year after the iPhone debuted, that the app store launched.  But today we only see the final product.

In a world of beautiful skyscrapers and impressive technologies, thinking small seems futile. But in this economic environment, a minimal viable product is more than just a nice concept. It’s a requirement.

Possibly Related Posts:


  • http://www.venturevoice.com gregory

    All the more reason to base a startup in Dumbo. Most of the buildings look more like what v1 of your product should look like.

  • http://greghills.com greghills

    Great explanation of the value of MVP. It definetly seems like the right approach if you have an inhouse development team. But what if you're working with freelancers on a contract basis? Isn't it harder to do the iterative MVP process, since you're spending time reengaging and renegotating with the freelancer for each iteration? Or have you found this to not be a problem?

  • http://twitter.com/generationg Graham Lawlor

    Love that Reid Hoffman quote. I'm definitely embarrassed by aspects of the 0.1 version of my latest project – http://brightmap.com/ I did make the conscious decision to put it out there to get early feedback rather than wait for it to be perfect first.

    Great advice, thanks Jonathan

  • http://blog.jwegener.com Jonathan Wegener

    Thanks for the comment, Greg.

    I think the MVP concept is even MORE powerful when you're working with
    an outside freelancer (or an outsourced development team). MVP is
    about discipline and shortening release cycles to make better and
    faster product iterations. And take it from me, nothing is more
    disciplining than when you're spending your own hard earned money–it
    truly causes you to cut out every bit of excess fat and keep things as
    slim as possible!

    I think your concern about contracts and negotiations isn't a huge
    sticking point. Either you're paying a freelancer hourly (so the cost
    simply scales as you develop the product further and nobody blinks
    twice if the project specs change) or you're working with fixed bid
    contracts. If this is the case, you should presumably (hopefully)
    have developed a good enough working relationship that you can just
    informally ping the person and say “hey, I like working with you and
    want to add these new features– can you quote me a fair price?” if
    you have to 'negotiate' the price, that shouldn't be any more work
    than just saying “Hmm, that price sounds higher than I was hoping
    for. Would you be ok with $___?”. It shouldn't be a time consuming
    and terribly difficult process!

    And if you eventually develop enough trust you can just tell them to
    let you know what's a fair price at the end after the work is done.
    That's how I've been working with the Exit Strategy graphic designer
    lately.

    I think the more interesting point is that while paying someone
    (versus having a tech partner working for free/equity) imposes more
    discipline, it also can make you more conservative and less willing to
    take risks when there's a dollar cost to experimentation. I'll
    probably write a longer blog entry on this subject at some point, but
    i think the large percentage of startups with technically talented
    founders speaks to this point.

    (Sent from iPhone)

  • http://greghills.com greghills

    Thanks, that makes a lot of sense. I look forward to reading the
    longer blog post that you mention.

  • http://twitter.com/semel Lee Semel

    That is typical of how MBAs think. PowerPoint before prototype, financing over features.

  • Ray

    That was incredibly insightful. It's interesting to think that your product can come to be defined by a feature or characteristic completely absent in its initial incarnation, as in the iPhone. It may be helpful, though, to first expose your product to a group of enthusiasts or experts before taken a plunge head-on. Consider smartphone apps. You have groups like NY App Meetup (http://www.meetup.com/NY-App-Meetup/calendar/12…) who are mad over the appspace. Getting feedback at a less risky level seems to expedite this path to excellence.

  • Jacob Easterly

    This is an interesting philosophy and one I generally agree with. Others that I also respect such as 37Signals also tout this philosophy in their Getting Real Book. I think that in reality, launching and failing/succeeding quickly is the right way to go about things online in general but the opposite approach can sometimes pay off too. http://www.dirtyphonebook.com for instance seemed to launch with a fairly feature-packed version 1 with toolbars and widgets and almost everything you'd expect from a fully polished site. It depends on context though. In some situations (probably most) launching quickly might be the best idea. In other situations, maybe a limited number of them, waiting until you've got a killer product might be the right idea. In general though, JWeg and 37Signals and most of the rest of the guys advocating quickly launching a simple product have the right idea.