TL; DR An MVP is a litmus test for a demand validation.

MVP stands for Minimum Viable Product or Minimum Valuable Product, whichever you prefer is fine. Chances are that you heard about it and added it to your list of buzzwords not understanding what it entails as I did some years ago. Not to worry as my singular job here is to leave you not only having a good grip of what an MVP is but being able to apply what you will learn.

I intend to cover areas like:

What an MVP is not?
Why build an MVP?
How to go about building an MVP?
What distracts us away from building an MVP?
After MVP what next?
And many more…

But guess what? This will not be all theory; we will be building a quickfire MVP together!

What an MVP is not?

Here are a few wrong assumptions about what an MVP is:

An MVP is not the least appealing version of your product: A product that is deficient in essential features and unappealing will struggle to get users.
An MVP is not necessarily the first version of your product: If you can’t learn from the first version of your product because you can’t even get enough people to use it then it isn’t an MVP.

Here are some familiar examples of popular MVPs.

Facebook

https://www.firstversions.com/2015/04/facebook.html

Youtube

https://www.firstversions.com/2016/01/youtube.html

Amazon

https://www.firstversions.com/2016/07/amazon.html

Twitter

https://www.firstversions.com/2015/07/twitter.html

Imagine the myriad of features that are now present since their respective MVP’s.

Building A Product Is Science.

Idea → Hypothesis → Experiment → Proof → Reality

Assumptions, Not Reality.

Photo by Anjali Mehta on Unsplash

There is a saying that ‘nobody knows tomorrow’; importing that analogy into the subject of product development, we can say nobody knows if users would want that product you are building. We often pretend like we do but just like everybody else we have no clue as to whether it would succeed or not. An MVP is the best way to solve this uncertainty.

MVP to the Rescue.

An MVP is how you test your hypothesis on whether users have the problem you are talking about and if they will care about and in most cases are willing to pay for the value you got to offer.

Naturally, you will figure this out later when the product has been launched to the public; but sadly by then, it might be too late.

So, can we experiment to figure out the future outcome in less time, with fewer expenses and lesser effort? This way you save time, expenses, effort, reduce uncertainty while increasing confidence. Imagine putting in loads of hours (not only yours), money, and resources only to discover that no one cares about what you got. Oops! Hurtful isn’t it.

Let’s walk through an example; Amazon was not an online store for buying everything at the initial start. The hypothesis that people would prefer digital commerce because of the convenience needed to be proven. What better way to prove it than to sell books online.

The results came out positive and that was the proof needed that users wanted the product. And now the reality is that people will buy books online at Amazon.com because of the ease and convenience it affords them.

Here is another example. Assuming you are the product manager of a trading app, you discover that users are confused about how to use your product which is affecting your weekly engagement rates (i.e active users).

The hypothesis after discovery is that a demo account will educate your users thereby making them less confused and more engaged every week. Then you go ahead and build an MVP of the demo account feature to help you validate our hypothesis; the experiment.

PMF

PMF, which is another buzzword, means Product Market-Fit. It serves as a check for if the market wants your product i.e has the market show enough buy-in. A product that has attained PMF has lots of users that want the product. In a short time, the product becomes an integral part of the lives of its users. If your MVP gets you PMF then your hypothesis holds.

So, we can say that an MVP is a test for the presence of PMF. The presence of PMF is what gives us confidence that we are moving in the right direction, that users want this thing we are building.

The presence of PMF is an indication that the MVP worked which means users want this stuff we are building.

There are a whole bunch of articles on how to achieve PMF and so I won’t be going too deep into that. Check out the hunt for PMF by Sachin Rekhi and how to know if you have got PMF by Lenny Rachitsky.

Building an MVP

Understand The Problem

Understanding the problem is one of the most talked-about, but least implemented concepts in product development.

This is because, more often, you — the product manager — will assume that you are the user and then see things from your lense. You rely on feedback from yourself and build according to your tastes, rather than tailoring things to fit your user’s needs.

Avoid this pitfall by listing your assumptions about the user and then talk to a prospective user. Ultimately, the aim of developing the MVP is to test your assumptions about the user and her pain-points. However, to avoid going totally in the wrong direction you need to start talking to prospective users from day one. You need to know and understand your user’s problems.

As any practising scientist will tell you, the best way to get a useful experimental result is to go in with a strong hypothesis.
Alexander Cowen

Personas are a great tool when trying to understand your users. Day in the life of your customer is another helpful tool.

Keep in mind that knowing the customer is something that happens in a continuum. Being out of touch with your user's needs at any point in time can be disastrous. We inculcate tiny assumptions about our users into our product every day and so working with wrong assumptions can sometimes take us in the wrong direction before we know it (without our consciousness).

Think In Alternatives Instead Of Competitors.

It is a common practice to focus on the competition but thinking in terms of alternatives will allow you to look at your what motivates your user better.

Take for instance todo lists, instead of thinking only about all the apps on play store that your prospective users might be using you forget that most people still rely heavily on pen and paper. That is an alternative and this is where you start from.

Most of your audience has a habit built around the alternative with very specific actions, workflows, and motivations. You need to build against those things to break the habit with the alternative and establish it with your product.
Brain Balfour

A great tool for thinking and finding the alternatives your customers are currently using to solve their problems is the Jobs To Be Done Framework. It is basically about the other products that your customers are hiring to get the job done.

You should look at the workarounds that your customers are needing to do. it becomes a real source of a lot of insights.

Why are your users hiring this alternative and for what job? Understand this and build your product with that in mind.

Prioritisation Is Key.

Building a minimum viable product is easier said than done. Finalizing on what is “minimum” can sometimes be a daunting process. Prioritization is vital if you want to build an actual MVP as opposed to something else. Focusing on a singular use case(there are always many in your head) helps but isn’t always that straightforward either.

A popular framework PM’s use for prioritising is the Kano Model. It is used to prioritize features or solutions based on how delighted their presence would make the user against the potential implementation investment required.

The model categorises features into basic, performance (satisfiers) and delighters. Basic features are needed for your product to be complete and users expect them too. Without them, user dissatisfaction will be high. Performance features are those that on investment causes a proportional increase in customer delight. For an audio call application like WhatsApp that would be increasing the number of people that can participate in an audio call.

Delighters are not expected by customers but if you have them they cause a disproportionate increase in user delight. They just can’t stop talking about it. Think of when Snapchat introduced stories and the extreme user delight it caused.

For an MVP basic features are non-negotiable. Are there delighters that require not so much effort as regards implementation that can be added to the MVP? Are there performance features that will give you a competitive advantage on investment? Focusing on adding lots of delighters that would require so much effort (investment) because you believe the users would immediately fall in love with you is a trap that you shouldn’t fall for.

Let’s say investment opportunities are difficult to come by for non-professional investors and you plan on solving that with your product; an investing app. A basic feature would be the ability to purchase an investment; a performance feature could be increasing the number of investment options beyond securities to real estate, agriculture etc. A delighter would be an algorithm that predicts the market and provides guaranteed returns that users can decide to opt-in.

You probably want to focus on the basic and performance features for your MVP and less on delighters. A maximum of one delighter at this stage is enough. Look out for performance features that would give you a competitive advantage such as when Gmail gave free 15GB to its users and that got people literally knocking at their doors.

Minimum Viable Problem

Define your value proposition, pick a small subset and solve the problem for them.

Let’s use the example of a one-page website builder. The problem is that professionals find building an online presence stressful. We could solve this problem for lots of people from blue-collar to white-collar professionals but we will decide to focus on white-collar professionals first (maybe even professionals in industries that building an online presence in is important eg. finance, technology, law).

This would affect the features we roll out and reduce the time needed for our MVP to be ready.

Some interesting areas in the development of an MVP that I didn’t cover are user interviews and prototypes. The former is necessary for getting to understand your user and the latter is a feedback mechanism used early in product development to make sure product teams are on the right path.

There are no hard or fast rules when it comes to building an MVP. Some schools of thought classify MVP into different types such as the Concierge MVP, Wizard of Oz MVP and Prototype MVP. These all serve the purpose of helping product teams deliver value to customers fast so we can validate our hypothesis early.

Why Building an Isn’t MVP Sexy?

Solution Bias

According to Ash Maurya, starting with a solution is like building a key without knowing what door it will open. You can try testing your key on lots of doors or you can start with a door you want to open.

Solution bias causes a fixation on the solution such that we just want to build without being concerned about whether the users would want our solution. If you believe it is the solution already then why build an MVP to test if customers will want it or not.

In most cases, we have solutions in search of real problems which is not what the user wants.

Love the problem, not the solution
Ash Maurya

Big Product Vision.

A big product vision is very tempting and can influence you into ditching the whole MVP thing. This is because it does not depict the (big) vision you have for the product.

The Myth of Sophistication.

This myth can be summarised as “The more features a product has, the more users will want it”. The truth is simplicity is the ultimate sophistication. More value doesn’t necessarily always mean more features.

Blind Optimism.

Sometimes it is just blind optimism. Optimism founded on nothing but ambition that your customers would love the product when you are done building.

Time To Learn

Once your MVP is ready the next thing is to launch and learn. Not learning from your MVP would be disastrous because the whole purpose of building the MVP in the first place was to learn. Here are some suggestions on how to maximise your learnings.

Talk to Customers: The importance of talking to your users when you release your MVP cannot be overemphasized. One caveat here is to not ask them for feature suggestions but to focus on their problems and how your product has or hasn’t solved them. (how are they currently using your product to solve their problems).
Testable Narratives Going Forward: Instead of ‘the sign-up process needs to be faster’ you should be saying ‘the sign-up process needs to take six seconds’. Instead of ‘we need to increase engagement’ you should be saying ‘we need to increase engagement by 5%’. Proscribing a solution without considering why it would work and how you would know if it worked can be dangerous. If you think improving onboarding would increase retention then sharing with your team what thought process made you arrive at that solution and how they would know if it was the right solution is vital.
Data to Insights: Not only is data collection vital at this point, looking for insights and understanding the why behind every data point is crucial. Most times, the data (metrics you are focusing) might tell you that things are bad but not why. It is up to you to figure out why. In some cases, this might require that you carry out some learning experiments.
Paying Attention to Actionable Metrics: Paying attention to metrics that don’t tell the full picture and propel you to action ala vanity metrics will only harm the product.

In the next series of posts (that might span months) I would be building an MVP together with you folks because I believe that way learning would be practical and freaking fun. Until then.