in Articles

Minimum Viable Product revisited – the MVP Curve?

My professor once introduced me to a concept he called FRUST - an acronym for frustration. Its premise is that products should be built solving a problem or pain for the customer. So is the minimum valuable product (MVP) a systematic, disruptive approach to product marketing. Google, Twitter and Spotify apparently get it. Say no more.

At its shortest, Eric Ries coined the minimum viable product:

.. the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

In this Venture Hacks interview with Eric Ries, it is put even more simple:

The minimum viable product (MVP) is often an ad on Google. Or a PowerPoint slide. Or a dialog box. Or a landing page. You can often build it in a day or a week.

More recently, voices of the Customer Development/Lean Startup community have made an excellent effort in elaborating the idea, e.g. Andrew Chen; Minimum Desirable Product and Ash Maurya; How I built my Minimum Viable Product.

If a picture is worth a thousand words, then the minimum viable product would deserve its own least common multiple. Adapting the Featuritis Curve, here is a conceptualization as a basis of discussion.


The MVP Curve questions whether resonance with Early Adopters is relative to the number of features or amount of complexity offered. The minimum viable product does not necessarily mean that the product should be dead simple. Rather, the resonance with customers should peak when the product offering is designed to solve their core problems or jobs-to-be-done, as suggested by Clay Christensen. In accordance with the Customer Development model, this implies not only listening to the customer, but getting out of the building and carefully studying the customer.

I leave to you the question whether the minimum viable product can be conceptualized. In different use cases, what would be the pitch of the curve? Further, the curve might be tested by applying metrics to it: how to measure resonance with early adopters over features, and are there alternative variables?

Did you like this post? Please, feel free to subscribe or follow me on Twitter.

Write a Comment



  1. i don’t think this curve is correct…it assumes that incremental features beyond MVP will not increase resonance with early adopters…think about it like this…the mvp of a classigied site would basically be a feature set that enables buyers to connect with renters…a feed of pricing data is not essential to enable that transaction, and therefor does not fall under the definition of MVP, but addition of that feature does not reduce resonance (as your graph suggest)…in fact it should increase resonance…

  2. wouldn’t the curve asymptotically go horizontal after the MVP point is reached? i.e. MVP isn’t the peak viability point – it’s just the point where you get most viability for your time spent. I see no reason for it to peak and them drop off until way too many features are added. Maybe this is a plug to ‘feature bloat’ as clearly there is a point where too many don’t help, but I think this is past the MVP peak.

  3. Just scribbled this up quickly:

    Isnt this a little closer to MVP?

    (one note, I put a ‘?’ to the right because more features don’t necessitate more resonance.)

    BTW: I think your note of “The MVP Curve recognizes that the Resonance with Early Adopters is relative to the number of features or amount of complexity offered. The minimum viable product does not mean that the product should be dead simple.” May be in disagreement with MVP and thats why your graph is a separate idea from MVP.

  4. Makes sense and is certainly a curve we’ve seen before, just in a different context.

    I agree with Christensen on Features, Innovation, and Scalability.

    Featuritis is another context where we’ve seen this curve.

    Indeed, Lean Thinking can help us avoid Featuritis.

  5. Thanks for feedback. There certainly are some good points here, and I have already taken some into consideration. I continue to explore your ideas and catch up with you.

  6. This post really resonates with me right now. I’m currently developing a web app and have kept pulling back from delivering everything under the sun to now getting something released quickly with basic functionality. I completely agree with getting something out there quickly with the main functionality.

  7. pretty insightful! I’m about to use this in my next venture idea to test the waters and see what the MVP is!

    How good is that, now I don’t need to stress about finding features to add, but rather to slowly stack them up and see the results.

    • Indeed, sometimes removing things from the table is way harder than bringing them on. Keep me posted about your ventures :-)

  8. The Y axis should be “gain in learning” or using your same language “incremental difference of resonance”. Basically the curve is diminishing rate of return over number of features.