Why MVP is Good for Startups?

My team and I have been busy with our MVP product, Gemoo Beta, for the past six months. Recently, we are about to launch the official version of Gemoo. Therefore, I think it’s time to share some of my simple insights on the development and validation process of MVP based on our journey.

I hope it can be helpful to your startup team.

Before starting the topic, I think it’s necessary to introduce what MVP is, as not everyone is familiar with it. Actually, before starting with Gemoo, I only had a very basic understanding of its concept and no in-depth knowledge of how to implement it.

What Is an MVP? 🤔💡

MVP stands for Minimum Viable Product, which means a product that solves the core problem of users. The MVP allows a team to collect the maximum amount of validated learning about customers with the least effort (cost). That’s why I think it’s a great way for startups, especially those without a large fund. 💸

🎯The purpose of building MVPs is to validate your assumptions quickly and improve the product, pivot, or abandon the project before losing any more resources. In my opinion, the illustration in the following image vividly demonstrates this process.

From the above image, it can be seen that MVP is a relatively low-risk product validation method that helps makers validate several key questions:

• Do people need that product?👌
• Can it generate a batch of followers and repeat customers?👨‍👩‍👧‍👦
• Is my idea to solve problems really what people need? 💭
• Are they willing to pay for it? 💰

For example, suppose you have a brilliant idea that most people like discounts, so you think that sending coupons to users, helps merchants get higher traffic, and finally take commissions from merchants. Then you immediately develop a platform to collect coupons for users, and then create a verification platform, transaction center, and settlement center for merchants…?

No🙅‍♂️, the MVP way is to create a simple website, collect some coupons, and then send them to users via email in PDF format. What about coupon verification, transactions, and settlements? The answer is manual reconciliation. Sounds unreliable, right? This is the first step of the group buying giant Groupon.

We need to remind ourselves at all times that before the product is launched and validated by users, we are making it behind the closed door, everything is just guesswork, just assumptions, and even the assumptions themselves may not be valid. When I am making a product, I always unconsciously make such mistakes. If you are like me, then you need someone in your team who can help you brake to avoid digging too much into your assumptions.

After all, what we ultimately need is for users to accept our products and pay for them, so we need to know as early as possible whether we are walking in the right direction and whether users are willing to pay for our services.

How to Take an MVP Validation?

The process of MVP development is all about the cycle of “Hypothesize-Validate-Feedback-Iterate”.

And commonly the process can be split into the following five actionable steps:

Step 1. Focus on the Problem You’re Trying to Solve🔍

We only want to solve a problem if we believe it’s valuable, and that’s the hypothesis we need to validate. There are two points that need to be validated:

✅If the problem itself is valuable?

✅Is our solution valuable?

What needs to be defined clearly is:

• Who the feature is solving the problem for?
• What problem they’re facing in what scenario?
• How to solve it?
• What value does it bring after solving it?
• What is the differentiation of the solution?

Step 2. Create a User Flow ⏳

Think clearly about what users need to do to solve this problem, and what the core behavior is.

Step 3. Build a List of Features 📝📋

To support the problem users need to solve, what related features does the product need to provide? We can brainstorm first and list all the relevant features.

Step 4. Prioritize 🚩

Prioritize the defined product features, combined with the coverage of user scope, frequency of use, value delivered, problems or risks if not implemented, and implementation costs.

To briefly explain the main goals of defining a product, defining the core behavior of users, defining the main features of the product, and prioritizing.

let’s take Gemoo as an example, the main purpose of Gemoo is to provide screen capture functionality for digital workers while improving the quality of long-distance communication.

For users, the core value is to be able to communicate with people from a distance like a face-to-face version without worrying about jet lag and scheduling conflicts. 💻💬

The core user flow is: app access ➡creates a visual message ➡shares it with the right person ➡waits for feedback ➡responds to feedback ➡close communication.

To meet the core value of users, the product needs to provide related functional modules, and the priority is determined comprehensively based on personal understanding of functional priority, user coverage, frequency of use, value delivered, problems or risks if not implemented, and implementation costs.

And, the above is only our hypothesis and needs to be validated by users.

Step 5. Start validation – Build, Measure, Iterate

Once the MVP is ready, it‘s time to ship it out to your early adopters. These early adopters will have plenty of highly valuable feedback regarding your app – feedback is the fuel for the next iterations of your product, no matter if your MVP is internal or external.

Also, start collecting data and analyzing it from the moment your first user launches your app. Data analytics together with user feedback from tickets and reviews will be the foundation for further development.

Once your main hypothesis is validated and your product gains traction, don’t throw whatever money comes into rapid feature expansion. Make new feature assumptions based on the feedback and data — before working on developing new features for the next product iterations, validating them first.

Approaches to do MVP validation

There are two approaches: one is to build the MVP and the other is to ”do nothing at all“.

That is to say, we could build a version that contains only the minimum necessary features and cut out other features. Alternatively, we could try a small event to test the waters, validate it through a simple webpage, and then improve it for a permanent feature. Just like what Gemoo did.

Initially, we only developed the most basic features of screen recording with cam, voice, and annotation tools to verify whether people have the desire to record themselves and their screens for communication purposes. Later on, we learned from user feedback that they needed a place to store and organize recorded videos for easy reuse of previous recordings. This led us to create the Gemoo beta web app, the first app we launched.

Through multiple rounds of validation, user feedback collection, and evaluation, Gemoo has evolved to include video recording, multi-functional screenshots, online documentation, online note-taking, multi-view content organization, quick sharing, data tracking, and many other features. These functionalities make Gemoo a versatile product that can meet the visual communication needs of different users in various work scenarios.

The approach of “doing nothing” is not about simply lying down and waiting for customers to come knocking but rather refers to only verifying through some demos or promotional materials, without reaching the stage of actual production.

For example, in usability testing, we could validate functionality through a prototype or high-fidelity prototype. Or we could create a graphic, text detail page, and promotional video, and determine whether to continue based on feedback from promotional materials, just like Reddit List.

Some products also do crowdfunding or presales. Regardless, all of these methods are about finding ways to validate assumptions with the smallest possible cost.

What to Do After Your MVP 🚀

If your MVP is gaining increasing traction on the market, focus your efforts on two main things: 📈growth and 🔁retention.

The two can never be separate from each other. Unfortunately, many product owners pour out all of their resources into growth activities, while neglecting retention.

Your existing user base is sacred — never forget about them, no matter how quickly you’re growing. There’s always a chance that something happens on the market and your core and loyal userbase will save your product.

Conclusion

Although MVP is a great way to develop a product for startups, it also has its limitations.

👉Firstly, MVP solutions may be rough and may not receive accurate feedback. Additionally, a small sample size during testing can affect the results’ accuracy, which can then affect subsequent decisions.

Assuming there is a need for further optimization and iteration, we may not know if the problem lies with the problem itself or with the current solution to the problem, and this will require continued experimentation.

👉Secondly, MVP is generally suitable for short iteration cycles, low iteration costs, and a repeated transaction model; if the cycle is too long and it is difficult to see the test results or if the cost is too high, MVP may not be worthwhile. If there is only one transaction, and it is not done well at the start, there may be no chance later.

However, the idea of verifying hypotheses with minimal costs is still applicable. Taking hardware as an example, before mass production, there are demo designs, small-scale production, and small-scale sales to a limited audience, only after all of which are verified as OK, will there be large-scale mass production and market promotion.

I understand MVP as a change in mindset from “I am right” to “How do I know I am right?”. Before verifying an idea, keep changes as much as possible and find ways to verify the idea with low costs. Our goal is to try as much as possible at low costs without being eliminated.

Hope you enjoy reading it and I’ll continue to post more of my startup journey.

If you found my sharings helpful and would like to make connections with me, please reach out to me on Twitter.