Minimum Viable Product (MVP), Vision, and CRUD

If I were to define my own definition for Minimum Viable Product (MVP) to be used in a textbook it would be the following: The set of features that is necessary to gain and maintain early users.

It doesn’t sound that hard, does it? Twitter? Users should be able to post messages, they should be able to follow other users, and they should have a feed where they see posts from users they follow. Stack Overflow? Users should be able to ask, vote on, answer, and comment on questions. A todo list app? Users should be able to create tasks and be able to check and uncheck them.

Creating MVP is hard because of one reason: Vision.

Vision

The creator of a product has a vision for what they want their product to be, what features it should have, and how it’s going to improve its users’ lives. It’s good to be ambitious and want a lot of features but it makes launching so much harder. Let’s look at Twitter again. Let’s assume the creator had the vision for retweeting and hashtags when they first created Twitter. To them, all these features are part of their vision of how great the website will be. “Imagine not having to copy and paste a Tweet to share it!” or “Imagine clicking any tag and seeing all the other tweets that have the same tag! Wouldn’t that be cool‽”.

To be able to create a realistic MVP, one must be able to put their vision aside and focus on the users and their needs. Of course users would love to have all these features but is it necessary to have them all at launch for Twitter to be successful? No. Users just need a platform to share short text posts on.

The challenge here is putting aside vision. How does one ignore the desire to create the best product possible? It’s the fruit of their labour. They will have spent months on it before they launch it. They want it to be the best it can be. Anything short of that is a compromise.

The answer, in my opinion, is simply to realize that the choice is not between launching with feature X or without it. Rather, the choice is between launching with the right set of features and seeing their vision come to reality slowly or being late and seeing their vision fail miserably.

Without this realization, there are no consequences to adding more features. Throw more features in. The more the merrier! Now, there is a risk associated with adding features that they can do without initially. That ought to make it easier to accept that their product will launch without their full set of features.

The CRUD Problem

Once the creator decides on an MVP, they might realize that their application does nothing more that create, read, update and/or delete (CURD) entities. CRUD is seen as being very basic. It’s almost an insult to call an application “CRUDy”. A task that’s “CRUDy” in nature is seen as simple and low effort. Back to Twitter. The basic set of features described above is very CRUDy. Users should be able to CREATE post messages, they should be able to CREATE follow relationships with other users, and they should be able to READ a feed where they see posts from users they follow. Of course they can DELETE posts too.

The problem arises when, after spending months working on an application, the creator realizes they have nothing but a CRUDy application to show for it. What were those months spent on? Was it all a waste of time? Were they slow? Are they inefficient? Probably not.

The likely reason for the application taking a long time is all the details that need to be ironed out. How many characters should a tweet be limited to? How are tweets in feeds sorted? You get the idea. And, if, at some point during development, they realize they need to change one of these details, the changes might not be trivial.

I’m afraid the solution to this is another realization: Users do not care what goes on behind the scenes and whether the product is “CRUDy” or not. All they care about is features. Build a product people want and they will stick around.