In this post, I shall talk about MVP and how we do it in my company.
The acronym MVP stands for Minimum Viable Product. It is more like a small working prototype of the proposed solution, by ‘small’ I mean regarding feature set.
The primary purpose of MVP is to validate our idea, however since we only include essential features in it, it also avoids risks like burning money and time. MVP is a great way because we get feedback from our target audience, which helps us to identify if we are on right track.
The story of Zappos.com, a shoe selling e-commerce company is a great inspiration for MVP. When they started, they just had a dummy website with photos taken from other brick and mortar stores around their area, and every time Zappos received an order they used to purchase it from the actual physical store and ship the customer. Slowly, when they observed good interest from people for this online model, they then decided to make it as a real business. The good thing is that they validated their idea without worrying about logistics, inventory, storage space and almost without investing anything other than the time for building a simple website. All this is way back before e-commerce boom.
To be honest, it looks straightforward and the first time it may not seem like any process. But since it’s vital to stay focused and not end up with a lot of resource wastage we do it in a prepared manner.
My founder, while working in Yahoo noticed that they had to rely a lot on in-house developers to get data from one app to another app. Marketing team uses an application like Hubspot for their needs while Sales team use CRM software like Salesforce. However, records should move from marketing funnel to sales funnel to convert a prospect into a customer.
So, the problem is data fragmentation due to different cloud apps and dependency on in-house developers to automate or hire someone for data entry job. The solution is to automate this data movement across different cloud apps.
As mentioned in the beginning, the idea behind MVP is to identify if this problem and solution is a good combo and if so are people are ready to pay money for it.
In the above point, all I wrote can be my founder’s assumptions or only he might have felt that it as a serious problem. So let’s list what all may be reasonable assumptions -
In general, the riskiest assumption will be assuming that my customer has such a problem. If that assumption is wrong, then no one will adopt the product we build, so we first need to attack the riskiest assumption.
In this, we make the statements such that we can take some action from it. So it should answer -
Below is a simple template statement that puts us focused:
We believe subject has a problem because reason. If we action, this metric will improve.
Example: We believe Shopify users who use QuickBooks has trouble maintaining their accounts correctly in QuickBooks because recording each transaction detail in QuickBooks takes 5 minutes and Shopify users are not expert CPAs to handle accounting. If we automate the data flow between Shopify and QuickBooks, this New MRR will improve.
Having criteria is very helpful because so that we product managers don’t get biased to what we believe in irrespective of what our validation metrics on test indicate about our hypothesis. Also, many a times results may be ~50-50, which puts us in a situation to take the tough call whether we are building it or not.
Yes, there will always be people who like what we build and also who doesn’t like.
Formulating criteria can be done in many different ways and below is one simple approach -
Note : The above one is just for an idea and remember that it can be done in many different ways.
Here, metrics like Customer Satisfaction (CSAT) will be known only after step-4 because we are yet to measure the interest from customers in what we are about to build. So we only come up with criteria for now, and cells are populated later.
There are several ways we can test the interest from public in our product:
⚩ Landing Pages: We showcase details about our product and ask for user details to get notified when it’s launched. On the back, we measure traffic and number of signups.
⚩ Emails: We do research, and somehow get email ids of people who could be our potential customers for a new product. However, if it is a new feature in the existing product, then we segment customers and send them an email about the feature. On the back, we track clicks on the link to that feature in the email.
⚩ In-app showcase: We show the feature in the app and when they click, show it as ‘coming soon’!
⚩ Talk to early adopters: There are always a set of customers who want to express their problems and open to help us validate our solution. We need to identify them and seek their help.
⚩ Discussion Forums: We can ask thoughts about the product/feature we are planning in online community forums and collect the data. At times, a video is also prepared walking through product features, so the external audience thinks that product is live already, and real users show interest.
No matter, what strategy we take but we need to measure if this will product/feature be successful and are people out there ready to adopt it.
Say following is what we get in end -
In this case, maybe we have to go ahead with second user-story.
Then on we keep iterating and making improvements.
The challenges here for a product manager would be identifying what is that essential set of features. Of course, we do customer interviews and all, but we never get same from every interviewee even though they all go into the same persona. So decision-making step would be pointing to us. As a product manager, I learned that if there are several options choose the one who needs little effort but creates enough impact, however, most importantly that chosen one should be changeable easily to another choice.