MVP for Beginners.
TL; DR An MVP is a litmus test for demand validation and learning.
MVP stands for Minimum Viable Product or Minimum Valuable Product, whichever you prefer is fine. You probably 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, my job here is to leave you not only with a good grip of what an MVP is but also capable of applying 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?
- Why building an MVP is unsexy?
- After your MVP, what next?
- And many more
But guess what? This will not be all theory; we will build a quick-fire 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 not learn from the first version of your product because you can’t even get enough people to use it, it probably isn’t an MVP.
Here are some familiar examples of popular MVPs.
Imagine the myriad of features that are now present these MVP’s went live.
Building A Product Is Science.
Idea → Hypothesis → Experiment → Proof → Reality
Assumptions, Not Reality.
There is a saying: nobody knows tomorrow. Importing that analogy, we can say nobody knows if users would want that product you are building. We often pretend that we do, but just like everybody else, we have no clue whether it would succeed. An MVP is the best way to solve this uncertainty.
MVP to the Rescue.
An MVP is how you test your hypothesis. Is your hunch that users are experiencing this problem the right call? Do they care enough? Will they pay for it if it is a paid product?
Naturally, you will figure this after your product launch; 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 maybe lesser effort? This way, we waste less time, money, and effort. Moreso, we 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 right.
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 had 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 people will buy books online at Amazon.com because of the ease and convenience it affords them.
Here is another example. Imagine you are the Product Manager of a trading app, and you discover that users are leaving because they do not understand how trading works. This problem is hurting your growth. After discovery, you come up with a hypothesis is that a demo account will educate your users, make them less confused and reduce churn by a certain percentage. Then you build an MVP of the demo account feature to help you validate your 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 shown 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 PMF. The presence of PMF gives us confidence that we are moving in the right direction, that users want this thing we are building.
Check out the hunt for PMF by Sachin Rekhi and how to know if you have got PMF by Lenny Rachitsky. These articles have done an outstanding job, so I would not be going deep into explaining.
Building an MVP
Understand The Problem
Understanding the problem is one of the most talked-about, but least implemented concepts in product management.
More often than not, you — the product manager — assumes that you are the user and then see things from your lense. When this happens, we rely on feedback from ourselves and build based on our tastes.
One way to avoid this pitfall is by listing your assumptions about the user and going ahead to talk to a prospective user. Ultimately, the goal of developing an MVP is to test the assumptions you have about the user and her problems. However, to avoid going totally in the wrong direction, you need to start talking to prospective users from day one.
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 should happen continually. Being out of touch with the needs of your user at any point in time can be disastrous. We add 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 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, to-do lists. Instead of thinking only about all the apps on play store that your prospective users might go for, you forget that most people still rely heavily on pen and paper. That is an alternative, and this is where you start.
Most of your audience has a habit built around the alternative with specific actions, workflows, and motivations. Build with that information in mind if you want to win over users.
Brain Balfour
A good framework 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 hire to get the job done.
The workarounds that your customers are needing to do can become genuine sources of insight.
Brain Balfour
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 take part in an audio call.
Customers rarely expect delighters, 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 could 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 e.g. 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 and fast rules for 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 MVP Isn’t 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, why build an MVP to test if customers will want it or not.
In most cases, we have solutions in search of actual 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 entire purpose of building the MVP in the first place was to learn. Here are some suggestions on how to maximise your learning.
- 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 say ‘the sign-up process needs to take six seconds so we can reduce drop-offs’. Instead of ‘we need to increase engagement’ you should say ‘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 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. Sometimes, 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 learn and build together with you folks because I believe that way building an MVP would be practical and freaking fun. Until then.
