Your MVP is minimal, but is it viable?

In this day and age, when startups talk about MVP the emphasis is always on minimum.

Everyone encourages founders to not wait too long to launch, to get it out there, to get feedback, and to start learning from the market.

That is great advice in general, and I am personally a big fan of going fast vs going slow. Yet, to me there is a subtlety that is lost in the message, which leads to misinterpretation and bad outcomes.

The minimum product that comes out still needs to be viable.

If a product is too simple, and falls below the bar, it won’t be well received, and won’t be likely to take off. If the product is too simple, doesn’t solve the problem, and doesn’t activate and retain the customers, it is not an MVP. It may be a prototype, and there lies the difference.

MVP is good enough, and can be improved to be great one day. Prototype isn’t good enough.

Simple, but not simpler than it needs to be

Einstein said that everything should be made as simple as possible, but not simpler. He implied that difficult problems are just that – difficult, and ultimately, some things can’t be simplified.

A great MVP isn’t only simple, it is also sufficient.

It embodies the solution to the problem, or an elegant approximation to a solution that is good enough. Sure, it lacks features. Sure, it is raw and unpolished, but good MVP can be recognized as having the potential to be great – to fully solve the problem.

Viable literally means alive

If you look up the word viability in the dictionary you will see that it comes from the Latin word vita, meaning life.

Being viable literally means being alive.

How can a product be alive?

Products that we fall in love with have a vital quality to them. They feel great, respond right – they delight us with their UX, simplicity, and the way they solve the problem.

They feel different, they feel alive.

A branch of science called Complexity studies patterns across disciplines, and seeks to understand the dynamic of different systems.

Roughly speaking, Complexity distinguishes between systems that are in the state of chaos, dead and alive. Systems that are considered alive are close to the edge of chaos. They have enough interesting dynamic built in, but they aren’t out of control.


The analog for MVP is that you can have a product that has too many features – it’s chaotic and hard to understand. On the other extreme, you can have a product that just doesn’t have enough built in. It is not good enough, it is not alive.

It is in the middle that you find your great MVP. It is minimal and vital. And key to vitality are feedback loops.

How to think about your MVP

It turns out that the key to vitality is feedback loops. This is what makes natural systems alive and this is what makes great software alive as well.

Strive to create a minimal product that has correct feedback loops.

Step 0: Talk to customers and confirm verbally that you are on to something.
Do the unscalable things to validate the market.

Step 1: Map out MVP based on your gut and understanding of the market.

Repeat steps 2-4 until done:

Step 2: Remove features that feel unnecessary.

Step 3: Combine features that can be combined, simplify.

Step 4: Check the flows and feedback loops. Are you solving the problem you set to solve? Is the system dynamic enough? Will it be alive?

What you are doing is you are focusing on a minimal set of features, but not at the expense of viability. Sometimes after removing a bunch of things you may need to add some things back.

Viability for different types of businesses

How exactly to make your MVP viable is as much art as it is science. But there is science to it, for sure. Let’s take a look at different types of businesses to get the idea of what to look for.

Consumer utility/social: For consumer product activation and retention are two important feedback loops. The product is not immediately viable if users aren’t activated. Similarly, the product won’t be viable in the future if the users aren’t retained.

Activation for most consumer products is one or more actions that the user has to perform to become engaged and have potential to be retained. For example, on Twitter, an activated user may be expected to follow at least 10 other users and post a Tweet. To become retained, the user is expected to come back at least once a month and read a tweet.

Marketplaces: For marketplace the key thing is to enable liquidity. For example, for Airbnb, it wouldn’t be enough to just list the apartments or express a need for a rental. Both need to be in place. There needs to be a mechanism to match buyers and sellers. Most often it is done via Search and Discovery, but in different types of marketplaces matching can be done differently.

Again there needs to be the basic feedback loop around activation, and ultimately each successful seller and buyer need to experience the joy of the first transaction. What happens next is equally important for viability. Could Airbnb work if you removed seller and buyer ratings? Perhaps not. Maybe this feedback loop is critical to make sure that the marketplace can self-organize and weed out bad players. Including or not including ratings into the MVP is a critical decision.

E-commerce: For e-commerce business, the ability to find and buy products is critical. Purchase is the feedback loop. But a bunch of other things need to work correctly. For example, imagine an e-commerce site without the search capability. It might be fine if you have a handful of products, but not if you have a large catalog. Should search be part of your MVP?

For retention, you need to decide what will make the users come back. Is it promotions? Is it personalization? Perhaps subscription? Maybe a mix of all of it? What is the minimum investment you make in MVP that maximizes the chance of users sticking with you and coming back for more?

SaaS: For SaaS business, activation is signup and retention is non-churn. The first one relies on building features that are needed, and the second relies on repeat usage. The second feedback loop is a lot harder to get right in MVP, but it’s pretty important.

Unlike consumer businesses that don’t charge, SaaS products are paid. The fact that you are paying for something is already an incentive to use it, but it is not a guarantee.

For more details on building your MVP go read this awesome guide. Below is the image from the post.


Compute your MVP

There is a method to great MVP. It captures and brings to life the minimum, yet sufficient version of your solution to a business problem.

Don’t rely on luck or minimalism to get you to YOUR MVP. Compute it.

MVP is a product computation on a napkin or a whiteboard. MVP is not about furiously typing code. Rather, a great MVP is about rigorously thinking.

We can’t predict the future, but we can do better than roll the dice.

We can be intelligent about our MVPs, make them simple, build in feedback loops, and make sure they have a shot at being alive.

Please share your MVP experiences here. What worked / didn’t work for you in your business?


  1. Alex, definitely inspiring in its explanation and spot on with my experience. Two mistakes I made in my past was not building a finished “enough” core product (step 0-4). When you then subsequently start building platform features around the basically non viable core product (mostly by not listening to feedback from early tests), it creates the state of chaos you describe.

    Another problem that many lean/agile organizations fail from is to create a final product from a list of features by following an agile approach. I was very inspired by “User Story Mapping” of Jeff Patton that puts a roadmap on top of the backlog of features that lead to a product that has a lot of features but no meaning.

    I had to smile at your example of ecommerce and the necessity of search. In our case of ZeroLight we are redesigning the car configurator of the future by allowing full 3d exploration and configuration as a core product. This however needs a rethink of explore and find and purchase together with our partners that can be compared to the change of going from a list site (like Yahoo originally was) towards Google (based on user input). Only then can we come to a final MVP beyond replacing the old.

    Liked by 1 person

    1. Glad you liked the post Barry, and thank you for sharing you experience.


  2. petergatsby · ·

    @Alex, nice post. Perhaps have a look at Templeton Compression and Sequoia’s model of the Sales Ready Product (SRP), which they position as a contextually viable alternative to the MVP. It’s bare-bones but interesting.

    Liked by 1 person

    1. Great point Peter. I think there is a refinement in that customer viability isn’t the same as sales/revenue viability.


  3. […] week we talked about MVP, and that it is important for MVP to be actually […]


  4. […] digunakan sebelum memutuskan sebuah produk diluncurkan. Alex Iskold, Managing Director, Techstars mempunyai sudut pandang menarik mengenai MVP. Dalam sebuah tulisan di blog pribadinya, ia menuliskan bahwa […]


  5. […] Alex Iskold of Techstars details how to think about your Minimum Viable Product and how to tell if it’s still only a prototype in “Your MVP Is Minimal, But Is It Viable?” […]


  6. […] digunakan sebelum memutuskan sebuah produk diluncurkan. Alex Iskold, Managing Director, Techstars mempunyai sudut pandang menarik mengenai MVP. Dalam sebuah tulisan di blog pribadinya, ia menuliskan bahwa […]


  7. What is the difference between a prototype and a minimum viable product (MVP)?

    Here is an amazing answer to this from Alex Iskold: In short… “MVP is good enough, and can be improved to be great one day. Prototype isn’t good enough”


  8. A Very Solid Post, Alex. John B. Petersen III’s answer at Quora brought be here and I’m glad it did. I’m in the early Stage phase of my Web Startup (Pre Launch Splash Page about to go live) and at STEP 1 now. This post on MVP solidified all my assumptions and strategies.

    Thank You and Very well done! Shared already!


  9. Omnis autem minus in error illum, exercitationem labore doloribus expedita repellendus. Numquam.