You have probably heard the buzzword MVP and the myriad of benefits it can bring to your company. But considering the volume of articles written on the topic of the smart building of an MVP or the benefits of an MVP for your startup, the whole concept might seem shady. Why else would the industry mention it so many times and stress its importance unless there is a catch, right?
Minimum viable product development is at the peak of its popularity not because it is a new common phrase that investors like hearing about. They do indeed, but MVP is a truly useful concept that significantly facilitates the development of a business idea, strategy, and enterprise. If the development process were to be divided into distinct stages, MVP would be step #2 on the way to a fruitful and successful business. We discussed step #1 in our article on product discovery, so check it out before you jump into MVP development. Otherwise, here is a shortlist of information we will share today.
What is MVP?
MVP stands for a minimum viable product. In the product development process, it comes after a prototype, so let’s differentiate between the two to avoid any confusion.
A prototype is a version of your final product that demonstrates its advantages over the market competition. A prototype does not have to be a working one; it can also be created in the format of a slideshow or a graph that demonstrates how your product works and looks like. It might highlight some functionalities and show a particular feature of the final product, but this is a rare case in software development.
By MVP definition, it is a product, so it is some kind of a working model with a particular set of features. The main goal of MVP is to demonstrate to the end-users why they need to use your app or software, what’s in it for them, why your idea is unique, and which value it brings into their lives. In short, MVP is a working version of your final product with a limited set of features that satisfy the original problem for the end-users.
To put it into perspective, let’s look at examples of MVP in real companies.
- The Uber we know today is a service that connects drivers with passengers all over the world. Both just need an app to show their availability and interest in a ride. The payments can now be made with a card and even cash. But at the MVP stage, the company could only connect drivers to iPhone users, and only in San Francisco. That simple MVP had revenue of $3.2 billion last year.
- Today Amazon sells almost everything you can imagine. The company started small – they were selling only books back in 1994. As the popularity grew, they added more goods to the website to reach a net income of $21.3 billion in 2020.
MVP allows starting small and simple and then growing an idea into a more robust and successful company over the years. Yet, by giving your potential users an early start with a minimum collection of features, you can place a business two steps ahead of the competition.
Expectations of an MVP
Expectations always need to be carefully set and evaluated because aiming too high can inevitably lead to disappointment. Expectations are what stakeholders anticipate to receive from a minimum viable product. Here is what stakeholders can presume to get in an MVP and how to manage their hopes wisely.
- User expectations of an MVP
When a user opens your MVP app or software, they expect it to solve their problem. They believe that the process will be smooth and easy as if it was a final product. You need to be ready that even the most successful MVP would get negative feedback, and it’s completely normal. Simply learn to differentiate between constructive criticism and mere hate, and you will be fine.
To obtain the feedback, use both techniques – qualitative and quantitative. Ask your potential customers/users for an opinion on the quality of your new solution (does it solve their problem) and ensure that you collect as much feedback as possible. Ask specific groups of stakeholders to test the MVP features to validate whether they can complete the tasks you expected, or something needs changing.
- Tech team expectations of an MVP
MVPs are always the dark waters for the development team. The developers should learn about the product, your goals, user feedback, and then adjust their strategy to satisfy the needs. The tech staff of your product development expects that in the process of MVP development and polishing, you will also revise the brief created during the product discovery phase and set the new rules for the upcoming development and product improvement.
- Investor expectations of an MVP
These key stakeholders are the most interested party of the minimum viable product in a startup. But while the idea behind an MVP is important, in the end, the investors are interested in its profitability; the upcoming investment offers depend on it. So after you get an MVP and test it with potential customers/users, collect their usage data, demonstrate graphs of pre-payments/interest in payments, and ensure that you have built-in metrics tools to showcase your idea and ambitions. The actual growing number of users is the best way to meet investors’ high expectations of a startup.
What to include in MVP: stages and tips
Now that you know what an MVP is, your technical documents are prepared during the product discovery stage, you have your expectations and know how to manage them, it is high time to get down to business – the actual development of the first working model for your final product.
How to define MVP scope
At this point, you should already have a list of features your potential customers would like to see (because the market research was done during the product discovery). If this step has not been completed, then it needs to happen; you can read about the stages a bit further. When it comes to the features and scope of your first MVP, a couple of strategies can help make a decision.
- Must-have vs. nice-to-have. Differentiate between the core features of your next solution and those that would facilitate its use or can be a nice design move. Focus only on those that allow end-users to solve their main problem, then, in the upcoming iterations, polish the offering, add design, introduce new pages, etc. For instance, for Uber, the initial connection between the driver and the passenger is the core value. At the same time, a friendly interface or an option to pay with ten different payment methods are nice-to-have features.
- Focus on a small group. You cannot serve the whole world with an MVP. Technically, you can, but it will cost an arm and a leg. So select one segment of your target market and let them enjoy all the MVP benefits. Recollect on Uber: they started serving the San Francisco area only, then moved further to conquer the world.
- Compare yourself to the competition. It might sound a bit like market research, but it’s not. You have already done your share of research, and it’s time you compare your prospective product with the available market offering. This means that if you are creating not something unique but just a better version of the existing solutions, you need to find that pivoting feature that would make your MVP stand out from the crowd. So, again, don’t go into design or minor tweaks; focus on the significant features here first.
- Rely on customer feedback. It is a common misconception that you know best what the market needs. However, your vision of the MVP and the problem might differ from the actual problem your potential customers/users are facing. Instead of creating something useful in theory, rely on the market feedback and adopt a user-centric approach to minimum viable product development. And remember that the end-users are capricious and fluid; they go with the flow, so collect the feedback regularly to build an effective solution.
Key stages in the MVP development process
To reiterate, at this point, you already have:
- your project goals (the problem you will be solving)
- high-level description of the project
- defined and reiterated project scope (initial features, expected flows, etc.)
- defined and analyzed user needs based on the market research
- target audience (segmented for the MVP purposes)
- technical system specifications
- roles and teams required to launch the project
- lined up customer feedback and its initial analysis
This is a comprehensive list of data allowing your team to start coding and create your next revolutionary solution. So let’s move to the steps on how to build a minimum viable product.
You can find more strategies for defining your MVP scope. Most of them are based on creating a list of tasks and prioritizing them with a particular technique (effort and impact, bubble sort, or MoSCoW). However, prioritization is a part of the development technique, not a preparational one. Based on our 10+ years as a startup product development company, we advise sticking to the four points above. They would be enough to get started.
Step #1: Market research
Yes, we know that we had mentioned this one before and talked a lot about the benefits of thorough research back during the product discovery stage. But chances are you still skipped that step, so we include market research here again. If you have not validated your idea against the competition and potential target users’ demand, then it is now or never.
Market research helps to identify what your competition has, understand what your target users need, and define what’s so unique about your next startup. Just check the reasons why startups fail to understand that market research is a crucial step that helps a company not to fall into 42% failures that created a useless solution, 19% who created a non-unique product, or 13% that released a solution for a non-existing / past problem.
Here is what you need to do:
- Conduct several surveys, check forums, talk to prospective users to learn what they need.
- Verify existing market offerings. Check which ones address the needs of your target audience, or solve their issues. Pay attention to what they do, how they communicate with the users, what perks they provide, which business model they adopted (B2C or B2B), which traffic channels are used, etc.
- Now perform the SWOT analysis. Align your Strengths, cover your Weaknesses, define your Opportunities, and be ready to face the project Threats.
Step #2: Feature prioritization
You might be surprised to see this step as the next one, as other online resources would probably list “ideation” and “user journeys mapping” as steps two and three of the MVP development stages. Both of these steps are crucial since they shape your rough ideas into a unified product concept and define the core working principles of your solution. However, since this article is a continuation of our series after the product roadmap, we included both of them in the product discovery phase. This means that by the time you get to your MVP, you already have all this done and well-documented to start the actual development.
We are still putting tasks prioritization as a separate step here because it cannot be stressed enough that an MVP is just the first working version of your application that cannot include all the features, look stunning, and be fully functional and loveable. Remember what Rick Hoffman, the co-founder of LinkedIn and venture capitalist, said:
“If you’re not embarrassed by the first version of your product,
you’ve launched too late.”
This citation clarifies the essence of why startups need MVP: to get an early start and launch the first working version of a product.
During the prioritization stage, cut away any additional perks in the app, leave the bare minimum and move on. You will have plenty of time to polish and enhance your offer as launch is the most important part of the process.
So how to do it? Use the strategies that we have already mentioned: effort and impact or MoSCoW, and a few more.
- Prioritization matrix. It helps to easily categorize all of your tasks based on the set parameters, such as importance and urgency, effort and impact, or value and cost. All you need to do is fill in the matrix with tasks to prioritize them.
[img link but remove “impact” and “effort” words on the exes]
By doing so, you can quickly identify which ones you should be chasing, which ones you don’t need at all, and which ones are worth consideration at a later time. So here is how the matrix looks like.
- MoSCoW prioritization. Once you’ve got your tasks into groups, the MoSCoW method helps to put the prioritized tasks into an order for the dev team:
- M – must do
- S – should do: those tasks that you definitely need to do but that can be postponed a bit (if compared to the M-tasks)
- C – could do: you can add these on later, but if you skip them, nothing will change much in the app
- W – won’t do: just delete these tasks from your backlog and forget they ever existed
- ABCDE. This method is a bit of an extension to MoSCoW because here you have one more critical element:
- A – must-dos (like M)
- B – should-dos (like S)
- C – could-dos/nice-to-haves (like C)
- E – eliminate (like W)
- D – delegates: when you are looking for ways to embrace all the MVP benefits in an easy way, you can easily find the tasks that can be delegated or automated to speed up the development.
Steps #3-4: Development and testing
It is no accident that we combine development and testing together in the MVP development process. Technically, many subject-matter experts would differentiate between the two; however, providing mobile app development for startups for a decade, we know that these two elements are so closely intertwined on the way to the final launch that separating them would not be natural.
The actual MVP development stages include design, wireframing, and coding. But after the product discovery stage you are likely to have both designs and wireframes, even a prototype, so all that’s left is coding. We generally advise startup companies to go with the Agile approach to software development because it allows for many iterations, changes, and improvements on the way to the initial launch and, at the same time, it does not create a mess in the process.
When it comes to testing, it is usually performed at the end of the development cycle before the launch. And this is correct with a little “but.” Tests need to be undertaken after every cycle and every app deployment. The more features you test on the way to the final launch, the easier and faster will that final testing stage go. The end-game testing can be divided into alpha and beta tests.
- Alpha tests are performed by the internal team that ensures that the core features work and the application delivers the initially anticipated value.
- Beta tests are done by the focus groups (in most cases), yet you can also go with the actual end-users. Beta tests help to verify the application’s performance and also receive feedback on the usability, user experience, and overall app usefulness from the prospective users.
After testing the application, remember that you will get insightful feedback not only on bugs but also on your solution functionalities. Carefully review users’ opinions and make the final amends before launching the app.
Step #5: Launch, Learn, Repeat
Application launch is always a thrilling time because months of good and hard work finally come to a logical end. You release the app, put it into Google Play Store or AppStore, and breathe out. You’ve made it.
But this is not an actual end – it is just the beginning of the new phase: learn and repeat. After setting your app free and making it available to the public, you should be closely monitoring the app feedback and performance to ensure that you deliver the value expected by the end customers.
How to understand that your MVP is successful?
This question is probably the most important point after you launch a solution. As one thing is to release a product and another one is to continue improving and monetizing it. Here are the key metric factors to focus on:
- Churn rate: the percentage of users who stopped using your application in a week/month. Monitor this number to ensure that it does not increase uncontrollably. And consider asking for people’s feedback on the app before they unsubscribe or delete it. It will offer you greater visibility on the application gaps.
- Customer acquisition cost (CAC): the average cost of acquiring a customer. You are likely to be in business for money. So if you spend XX to acquire a customer and then earn X on them, then your business will go bankrupt pretty fast. Monitor this metric to ensure that your income grows.
- Monthly recurring revenue (MRR): the predicted revenue a company can expect to earn in an upcoming month. While the metric might seem dull, it is, in fact, very useful when you compare MRR for existing customers, for expansions, for downgrades, for reactivation, etc. By comparing the numbers, you will be able to understand the tendency (for instance, whether you get more renewals or contractions).
- Lifetime value of a customer (LTVC): the expected profit a customer can deliver while using your application. This metric helps to identify the long-term goals and strategies. If a user has not bought anything this month, it doesn’t mean they won’t spend twice the average rate in the next one. And your strategy for building an MVP needs to be long-going rather than here-and-now. Learn more about LTVC here.
- Average revenue per user (ARPU): while the above mentioned MRR also offers a similar insight, this metric provides information on more details when it comes to a user-centric approach. By monitoring this number, you can easily adjust your budget and pricing to the current market trends.
We collected the essential elements, steps, and metrics to assist you with developing and launching a successful MVP for your startup project. If you need more guidance, please check our mobile app development tips which can be of great help for the actual development of your next idea.
Remember that MVP is still not the final version of your project; it is the first working application that is used to continue your idea validation and capital raising. The MVP stage is a perfect way to test your development process, try out different outsourcing vendors, and create a dream-team for the upcoming product and business development. Never hesitate to ask for help when working on your dry run model. Verification, validation, and acceptance of the upcoming flows, development directions, and overall experience gain are the key reasons why startups need MVP.