Is Creating an MVP Before Building an App a Good Idea? (Why & Why Not)
Is Creating an MVP Before Building an App a Good Idea? (Why & Why Not)
Last Updated on July 29, 2020
Building an app is not for the faint-hearted. They are expensive and time-consuming to develop and difficult to maintain. Even if you create the best App in the world, it may not guarantee success. As per Statista in Q1 2020, there were 2.56 million apps on Google Play, while Apple’s App Store had approximately 1.85 million apps. History is littered with tales of well-researched app concepts that failed to take off and were buried under the depth of the play stores. As per the latest survey by Statista, 25% of apps downloaded by users were only accessed once!
Launching a fully developed app takes about 6 to 8 months, and will cost somewhere in the range of $200,000. Once the final version of the App is released, the agonizing wait for results user feedback starts. If the App doesn’t appeal to users, the time and money spent on developing are wasted. So, how to avoid falling in this trap? Before you move full steam with creating a new mobile app, you should consider launching a minimum viable product (MVP).
What is an MVP
Many entrepreneurs waste precious resources by starting on the wrong foot: they want to build a perfect app or product, even before they establish its viability. Some of these entrepreneurs believe that they understand what customers want, desire, and value. After spending a significant amount of hard work and dollars, building a product only to find that customers couldn’t care less about it. As per the research conducted by CB Insights, a whopping 42% of startups fail because there was no market need for the product launched, 14% of them cited ignoring customers as the reason for failure, while 13% mentioned mistimed product as the reason for the fiasco.
MVP means building a product with a minimum but essential set of features that allow you to release it to the market immediately. At its core, the MVP is a scaled-back version of a product released for test and validation of its viability in the market. An MVP provides you a low-risk and high reward method of testing your concept before investing your resources in it.
The term MVP was coined by Frank Robinson and popularized by Eric Ries in his book The Lean Start-up. As per the book, the viability of the product and business model need to be proven for every product. The initial focus should be on learning and determining viability for startups launching new products, not profits or revenue. Ries described the “Build-Measure-Learn loop.”, where learning is validated by measuring data and accelerating it by applying that data as the product is developed. According to Ries, “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning with the least effort.”
MVP lets you release the bare-bones version of the App swiftly, get real-time feedback, and iterate or add features based on the feedback, instead of assumptions. The only way to know what your app needs is to see how people are using it. The core methodology is “Build. Measure. Learn.” An MVP is built to get user feedback that will help you avoid the fate of many failed product launches.
The MVP method speeds up the product’s launch since only essential features are required to get real feedback on the concept. MVP design and development generally take 1 to 1.5 months and MVP cost a fraction of the overall product development. Developing an MVP is becoming a norm in mobile application development. An MVP helps you received early feedback that validates users’ interest in your product. Positive results in the MVP phase can give you the confidence to move full steam to build the full version.
In business parlance, viability is about delivering enough value to users and is one of the critical aspects in the development of an MVP. Where the “what” becomes more important than the “how.” As per research, about 60% of the functionality of apps are seldom used, which is an unnecessary waste of development resources. A viable product meets user demands by performing the primary function which it is targeting.
Try remembering the first time you used Facebook. Did it look and worked like it does today? Do you think that Mark Zuckerberg, a Harvard student, envisioned developing all the cutting-edge features that exist on Facebook now? No! As a matter of fact, today’s technology incorporated by Facebook was not even available back then. Then, how did Facebook become a social media behemoth that it is today?
Initially, Zuckerberg rolled out the prototype “The Facebook” to Harvard students, and it was tested for user feedback. For making Facebook successful, they did not build a product, “take it to market” it and then sat back while the moolah came in, they had a concept, they validated its need in the market and evolved as they moved forward. One of the driving forces behind Facebook’s success is that they’re constantly assessing, iterating, and evolving.
Benefits of MVP
- Building and testing an MVP allows you to:
- Validate your concept before spending too many working hours
- Test your assumptions about the product and its viability on the minimum investment
- Understand your buyer intent, persona and their preferences
- Get user feedback which can be incorporated in your product
- Get the product on the market faster as compared to waiting for the full App to be developed
- Give yourself more room to work out the hitches in the final product
- Save time and money from building the wrong features
- Acquire a potential user base and find early adopters.
- Focus on the core proposition
- A tested idea which gained traction by users, allows you to attract investors who could aid in the rest of the development process
An Example: Uber, which transformed personal transportation, was launched as an MVP in 2010. Known as Ubercab, the App did not have some of the fancy features it contains today, such as shared rides, real-time location of drivers; initially, there was no app build for the drivers. The core function of the app was that it allowed customers to find drivers. Initially, Uber’s CEO Travis Kalanick used to cold call cab drivers, meet them and sign them up for the service.
The aim of developing an MVP is to deliver the App’s essential functionality to show users how it can solve their problems and receive feedback that teaches you about your product viability; however, it is not as simple as it sounds.
Big feature List – entrepreneurs are passionate about their idea, while the development team wants to showcase their technical prowess, which results in stacking one idea on top of another. It is critical to push back or decline ideas which are good but are not the most core feature of the product
Deciding customer segment for rolling out the App – The end product might be targeting a broad base of customers; however, the MVP needs to be developed, keeping in mind one set of customers and their preferences.
Platform Dependence – With a comprehensive option of platforms (Google Play, iOS, Web) it is enticing to build the MVP for all platforms, but you need to ensure that it is the targeting the most relevant segment, and deferring the other platforms for later stage
Small but best – The challenge is to showcase the utility of the App, at the same time, maintaining standard user experience. Users might not want to use apps that are difficult to use or do not have an excellent user experience.
Why Should You Build an MVP?
The primary objective of an MVP is to release a basic version of the product early and gain insights from the feedback. Accelerated learning should be the primary objective, and MVP is your best method for achieving this end.
Releasing a bare-bones MVP allows you to know what your customers value, test, and validate all underlying assumptions. It’s essential not to get caught up in cosmetic details such as branding while launching an MVP.
One of the common concerns associated with an MVP is that releasing a half-baked app will alienate customers, and you’ll lose them forever. However, this assumption works when the market already validates your idea, you are aware of your customers, their pain points, and how much they care about the solutions that they would be turned off forever if they did not receive the perfect solution.
This is vastly different from reality, and launching a full-fledged app needs a serious rethink. Developing your solution idea in a silo for a long time in anticipation of a “Big Reveal” is not considered smart anymore, especially in the cut-throat competition, where there is a glut of solutions launched every single day.
Need An MVP Before Creating Your App?
Defining an MVP is difficult considering its broad contours. While building an app, where do you start? Where do you stop? What functions to include and what to exclude in the initial launch?
Avoid unnecessary automation – Automation should only be applied to the most critical aspect. For example, a custom-built automated customer service platform would be great to handle customer queries. However, since you cannot expect massive traffic in the initial days, it would be better to launch the MVP with a phone number or email id for users to contact customer service.
Implementing change needs to efficient – When an MVP is launched as a beta version to gain user feedback and learn from experience, it should be agile to keep iterating based on the learning. If consumers face any challenges, it should be swiftly resolved to maintain and improve user engagement.
Zero in on the core product offering – The MVP should break down what the product does and why users need it, what problems it solves for the consumer. Before launching the MVP, you need to be clear about its general purpose and value and ensure that it at least address one core problem faced by customers.
Back in 2011, Uber dropped “cab” from its name and branded itself an on-call private driving service. This allowed the company to offer certain luxurious perquisites to customers they might not otherwise have been able to afford. Although Uber, as present now, is a different iteration of the initial day, it is evident that early user feedback assisted the owners and developers to focus on critical areas and build from there.
Identify your Customer – While MVP is cheaper and faster to develop, it does not mean that it will not cost you time and resources. You need to confirm that there is market interest in the product and define who your target user is. You need to zero-in on the demographics, location of the targeted segment to test and get feedback on the product. You should also ensure that there’s a demand for the product, and the targeted segment would be able to afford the product once you start monetizing.
For example, Uber was initially tested in San Francisco before being rolled out to the broader areas. They developed the capacity of the App as they increased the base. Similarly, Facebook was initially launched only to Harvard students.
Find your actual minimum – Eric Ries provided the formula for defining the minimum features of your MVP: # of minimum features you think you need / 8 = The True Minimum
The formula may sound a bit daunting, but you need to understand that the MVP should be as ingenious as it can be without being useless. Once you release the product to customers, you may receive a range of feedback:
They hate the product – Customers complain about a particular feature or the product fell short of their expectations. This is precisely what you want to gain from the feedback, for the audience to share what exactly they need, enough consistent feedback will allow you to have a list of must-have features that need to be incorporated in the next iteration of the App.
A bit Meh- Again, it’s all right if they are not 100% blown away by the offering. You have shared a product for them to see the promise in it. Allow them to share their likes and dislikes about the product. Focus on strengthening those weak points and include other features that make it a compelling offering.
Blown by the Product – Ideally, it’s unlikely to happen in the first roll-out; however, if there are very few complaints and tweaks required, you could release the product to a broader audience. This would have helped you save time and resources by focusing on the core functions.
Define Viability – You need to determine how to measure the success of your MVP
Consider the following:
- The number of users coming on the landing page?
- How many of these signed up for the beta?
- How many users continue to use the service over a set period (1 month, three months, etc.)?
- How many people provided feedback? Is the input insightful enough to help make critical decisions about the product design and features in the future?
- Did the demographics of your user set match the targeted audience it was designed? Yes, Why? No, Why?
- The average amount of time spends over the App? Which specialties did they spend the most time? Which features were ignored or used the least? Which features received the most favorable feedback? The least?
- Gather all the relevant information from the landing page, beta testers, usage data, and try to identify what the data is telling you about the MVP?
Once you receive the data, what will be your primary course of action? Will you leave it as is? Develop a full product based on customer requirements? Is the data showing signs about how difficult it would be to attract and acquire customers? Would you be able to retain those users? Do you want to keep the App as a browser-side instead of in native form?
How much can and should you charge for access to the product? How much profit do you expect to generate? Would it breakeven in a short time, or it is difficult to monetize?
User feedback is invaluable to the process of building an MVP and is the primary way to understand whether the product is capable enough to release in the market or it needs to be taken back to the drawing board.
Why you should not build an MVP
MVP’s was quickly embraced by the software industry, especially with the advancement in technology and lower barriers to product development. MVP allowed the development team to release a stripped-down product, test it with real customers, and measure its success in the marketplace, saving time and money.
But over time, a new problem has arisen the term MVP has been abused extensively and is now considered overrated by some sections in software development. Today every Tom, Dick & Harry is an expert in building MVP; build less with the hope of saving time and money. Many startups and enterprises build an “MVP” to meet a deadline or get more (development) work done faster with less attention to quality.
Perhaps the definition is misunderstood, from a minimum viable product to a minimum valuable product. MVP has been used as an excuse to cut corners, remove features, and sacrifice the user experience in the name of “staying lean,” sacrifice quality, and sound design for quick delivery.
We need to clearly define that MVP is a learning tool, not the whole product itself.
MVP is not necessarily the best route to take for developing every App or product. For example, you are developing an app based on an existing app, and the idea is to improve it further. You are already aware of the market potential, and the idea is to deliver a superior product offering at competitive prices. Sometimes it’s better to learn from competitor’s mistakes. Ask Facebook or Apple, who did not offer the first social media network or smartphone; instead, they learned from the competition, improved the offering, and dominated the market. In such a case, MVP may not play a significant role and may end up delaying the final product launch.
Some of the areas where building MVPs are suboptimal:
Building a sustaining innovation product – the more sustaining your innovation, the more the market is understood or, at least, understandable. The problem and solution are knowable. Customers are smart. They know the problem and believe in the solutions. The features they ask for likely to represent their actual needs. To achieve viability, the minimum offering must be capable enough to battle against existing competition as well as have some additional features to differentiate from the existing solutions.
Revolutionary Product – If an app is turning this market on its head, a full-blown product may not be required in the initial stages. Early adopters will jump at the chance of using an imperfect product due to the value provided by the product offering. PayPal revolutionized the payment processing market, and people used the product despite a sub-optimal user experience.
You achieve product-market fit – Product-market is achieved when the value proposition is proven by a substantial number of market transactions that create business momentum. The objective of the MVP is validated learning. If you have achieved product-market fit, it means the product is viable, and hence there is no need to worry about the minimal. Viability is a threshold. There’s no such thing as maximum viability.
Once you achieve a P-M fit, quickly pursue the development of the whole product to dominate the competition.
Viability is determined by the market, not by assumptions. Equipped with the right understanding of MVP, you can minimize your risks and maximize your investment. However, it is tricky to execute a minimum viable product launch. Entrepreneurs are wary that the MVP may alienate the potential customers if an unfinished product is released in the market?
There is a misconception that an MVP is unpolished or unfinished. That is not true, an MVP may not have all the features you dreamed of, but it has all the functionality the customers may need.
Bear in mind to release the MVP to a select group chosen carefully. Once you’ve learned, execute what you’ve learned, while also maintaining new learning.
Looking for a company to develop an app MVP? Oyelabs will help you create a prototype of your app. Contact today.