The concept of creating a minimum viable product (MVP) prior to a full-scale product originates from the best practices of agile development. This approach stipulates step-by-step product evolution keeping in mind user feedback. It also corresponds to the philosophy of ‘ship early, repair late’ supported by many notable minds including Reid Hoffman, the founder of LinkedIn, as well as Eric Ries.

Actually, it was Eric who first introduced the MVP technique in his “The Lean Startup”. Since that time, the developer community has become obsessed with this advanced mindset. In the meantime, obsession led to the emergence of widespread misunderstanding of what the MVP is meant for and what benefits it brings to startups. The term became rather polemical in digital product development, and various misconceptions associated with it jeopardize the evolution of ideas that entrepreneurs and startup founders want to implement in their products.

As a product studio, Railsware has expertise and experience in both making our own MVPs and leading the development of client’s products. In most of our case studies, we covered the whole product development process from minimum viable product to mature solution. At the same time, not all of our clients had a clear understanding of the MVP’s value. The most common misconception we’ve encountered was that it should be a bare-bones product version built for cheap and ready for the market. It’s not the only off-base interpretation of this term, and you should be aware of other myths that may lead you off track.

Common myths about MVP

Minimum viable product software development is mostly meant to solve the core business goal and bring core benefits for target users. It acts as a software validation tool, which attempts to provide an answer to the question “Is my idea worth doing?” Yet, some newcomers, as well as existing product owners, may have the wrong impression of the concept that brings in many misconceptions. Watch “MVP Myths vs. Facts” video prepared by Railsware Academy. Or read forward to review the most common MVP misconceptions.

MVP lean startup

There is a popular misconception that MVP is the heart of a lean startup. This idea is mostly pushed forward by enthusiasts that put technology before everything. But in fact, the keystone of any startup with a lean methodology approach is user validation and development. Most successful products put significant attention on this. Facebook is a good example. At first, the core idea of this startup was to provide college students with a communication tool. The MVP’s role was to validate the feasibility of this idea. The rest is a story. MVP is not a lean startup and not even its heart or soul. It’s a useful and efficient tool to validate your business idea before hitting development at full speed.

MVP pulls customers and money in

It’s not enough to build a minimum viable product app and mark a checkbox in your startup’s To-Do list. That won’t be a landmark event signalizing success and blossom. Of course, if your MVP manages to attract users, it is a small but important win. Nevertheless, you’re only at the very beginning. A lot of iterations lie ahead, and your MVP is the best tool to learn and pilot-test your ideas. Customers will bring their money only if the product you offer delivers value, and the MVP’s role is to make sure this value will be in demand on the market.

MVP is a product with one valuable feature

It’s much easier to implement the bare-bones version of the product with one epic feature. The focus is not dissipated between other jobs-to-be-done, and the MVP delivers well-targeted feedback. Let’s imagine a regular CRM tool where you have ten or more valuable features. Try to pick the most fundamental one! It’s quite difficult, for that reason, startups aimed at vast functionality for users require much more time and effort to create and deliver the MVP.

MVP contains as many features as you can afford

It’s understood that an MVP has a limited set of features, which are mostly basic ones. However, the importance of a minimum viable product is not to demonstrate the work of the features you have money to build. The focus should be on product value validation rather than playing with features. Therefore, the most efficient MVP is oriented entirely on the core business goal for the available budget. Further on, your product will gradually co-opt the features that bring additional value to customers and drop the unviable ones.

If the MVP is not successful, the product is doomed to fail

Nobody wants to believe that his or her idea may be ill-starred. And every product owner dreams about reaching the pinnacle of the market. However, statistics say that nine of ten startups drown, and it takes maximum effort to make it into this 10% of lucky survivors. At this point, a failed MVP is not a metric of a failed product. In The Lean Startup book, there is a mention that entrepreneurs can pivot. It means you can always turn off the wrong track and onto a winning one. As for this MVP misconception – it’s always difficult to accept that the value you expect from your product just isn’t there. However, that reveals the major task of creating a bare-bones product – to find out whether people need this sort of value. If they don’t, you can always try to change the focus and opt for another vision of your idea.

To learn more about what comes after an MVP, check out our in-depth guide.

MVP is a fit for building a small product for cheap

This is the most popular misinterpretation on the web. Indeed, every startup would like to get a combination of speed, low price and good quality in one go. Unfortunately, good and fast won’t be cheap, fast and cheap won’t be good, and good and cheap won’t be fast. We cannot treat an MVP as a small functional product or even a prototype. With MVP, startup founders get a tool to learn about their target user segment. The emphasis is placed on customer acceptance rather than fast and cheap time-to-market.

All features in the MVP are must-haves

It’s always tricky for a product owner to prioritize the functionalities the product has to offer at early stages. In most cases, everything seems to be necessary and must-have. However, if you try to push all the features into the MVP, there is a risk of spending all of your cash and failing. It’s like going all-in with just a 2-pair in your hand. If you’re not a gambler, make sure to pick the features the MVP must have at most. Railsware applies the MoSCoW methodology. It allows us to prioritize all our must-haves, should-haves, could-haves, and would or would-not-haves. Circles of focus are also good to emphasize the most necessary functions/features required to get user feedback.

There are plenty of other misconceptions like stuffing an MVP with features is a good approach (also known as the feature fallacy) or that MVPs are good for consumer-oriented products only. These myths usually originate from people who are not familiar with the lean method. Unfortunately, these illusions lead to dead ends. Therefore, it is essential to understand what a minimum viable product framework means to make the best of it.

MVP – a solution to pave the way to your product

Google gives a lot of answers to the question “What is MVP?” and it might be challenging to find the clearest one. Here is what Railsware thinks in this respect.

A product can be called minimally viable if it has some features to be validated within the market and brings the core value for early adopters. That’s what most product managers have in mind under this term. From the consultancy viewpoint, MVP may be treated as a pioneer product version with raw functionality and features. It’s not a first or fundamental layer of the cake, it’s just a piece of it, which you can give users to learn their opinion.

Most of the notable products including Airbnb and Twitter started their way as MVPs and have been gradually evolving into trendsetting startups. Meanwhile, newbie entrepreneurs may doubt the necessity and feasibility of this concept and prefer to skip the MVP stage. Such a decision may have an irreversible outcome, and your startup may end in disaster. Let’s take a look at why this can happen.

MVP goal

The above-mentioned misconceptions show that MVP’s goal is not to get a stripped-down software version for cheap. Startups need it to validate their opportunity hypothesis and get the green light for developing a full-fledged product. In other words, you essentially ask target users whether they need your product or not. Though it’s functionally-constrained and raw in the appearance, it is meant to deliver the core value and get feedback to move on.

MVP benefits

What would have happened if the founders of Uber or Spotify had entered the market without a preliminary evaluation of their MVPs? It’s more than likely that we would have not even known about their products. But they made the right choice and leveraged the lean startup tactic, in which the MVP’s role is fundamental.

• Resources optimization
  Your idea might be brilliant in your head, but the market may reject it for various reasons like tough competition, inadequate value proposition, and others. As a result, tons of hours, not to speak of funds, appear to be spent for the unwanted product, and your dreams about ROI are vain. The MVP gives you a chance to avoid this scenario and try out your opportunity hypothesis with actual users. If the market accepts your bare-bones product, the chances of success with the fully-functional solution are quite high. If not, you avoid the risk of wasting time/money and get an opportunity to shift focus or fix the value proposition of your startup.
• Early customer acquisition
  MVP is a lean version of a product you’re going to release to the market. Though it lacks some top-notch features and advanced functionality, it does provide value to users and hence acquires early adopters. Of course, the main goal of such an immature product release is to gather feedback to validate the value proposition. Nevertheless, it does not prevent you from starting to work with key startup metrics and make up a customer base.
• Value proposition focus
  The last but not least answer to the question “why is minimum viable product important?” is the ultimate emphasis on the value you’re going to deliver with your product. The MVP lets you understand different problems your future customers need to solve. You can take advantage of using the value proposition canvas*** to get a graphical expression of customers’ needs vs. product’s offers.

The range of benefits you get with the MVP is rather long. With this concept, startups are capable of creating an appealing bait for investors, checking their product’s vision on the market, optimizing resources to be spent on market research, tailoring a product market fit strategy and so on. Meanwhile, a particular benefit depends on which type of a lean product version you’re dealing with.

Types of minimum viable product development

We managed to dig up 18 types of MVP on the web! We believe that this number could be even bigger due to different misconceptions that may arise among startup founders. Nevertheless, the best option was to classify them into two groups, each of which is meant for a particular range of tasks. If you prefer video format, watch Railsware Academy tutorial on types of minimum viable product.

High-fidelity MVP

This category is definitely a fit for the product owners who are in pursuit of the following objectives:

• Defining and optimize a marketing strategy;
• Testing the value proposition, communication channels, and CTA;
• Defining potential strategies for growth;
• Acquiring early adopters and assert a product on the market;
• Learning the demand in the product.

High-fidelity minimum viable product examples are digital prototypes, 3D models or mockups which allow you to examine user interface, experience and engagement. Some types of this category might need a lot of manual work like it was with Quora, when its team had to write Q&A themselves to attract users. Here are the most widespread high-fidelity MVPs:

• Concierge MVP: This is a product which uses manual guiding of users instead of an automated algorithm. This type is a fit for projects based on recommendation engines or even machine learning techniques. The MVP is not powered by complex algorithms, and the core functionality is performed by real humans.
• Wizard of Oz MVP: A kind of enhanced concierge MVP. This type of product also uses the human-powered functionality, but it looks and feels like a real solution. For example, Zappos, an online shoe and clothing retailer, was launched as the Wizard of Oz MVP and most of the functions were manual until it took off.
• Piecemeal MVP: With this type of product, a significant share of functionality is also manually powered. However, some of the missing features are emulated with existing services. We can look at the example of Steve Blank, who advised a startup aimed at the production of agriculture drones. His idea was to use an HD camera and a helicopter to collect the necessary data and sell it. It was not a drone-driven technology at the outset, but it validated the idea and even brought some income to its founders.
• Single-featured or one painkiller feature MVP. The hallmark of this type is the focus on one feature. You need to provide users with a clear understanding of what the product is meant for. Later on, the set of features might (and probably will) expand, but not at the MVP stage.

Low-fidelity MVP

This category of MVP options matches the following goals:

• Learning the practical value of the product;
• Finding out the most effective solutions the customers are in need of;
• Getting a better understanding of customer’s needs;
• Niche analysis – whether or not the problem is worth solving.

To build a low-fidelity MVP, it is not necessary to do programming in Ruby or Java or any other tech stack. Sometimes, even an explainer video or a survey is enough to achieve your goal and understand your customer. This category is often referred to a smoke test as well. For example, you can create a landing page MVP like those at ProductHunt, and launch it for users. Another option is to build a slide deck or a mock-up, which might be idle on the web, but suitable for some sort of sales meetings. The following list contains possible low-fidelity MVPs:

• Blogs;
• Forums/communities;
• Surveys/questionnaires;
• Landing pages;
• Explainer videos;
• Advertising campaigns;
• Mockups/slide decks/presentations;
• Crowdfunding campaigns;
• Idea spotting networks.

Each type of MVP matches a particular project. Sometimes, you can opt for several types in one go (combine the release of a concierge MVP with a survey to be held on a specialized community or forum). Regardless of the chosen option, you shouldn’t confuse a minimum viable product with other specific terms like proof of concept or prototype.

If you want to dive deeper into these types of MVP, we’ve got you covered!

MVP ≠ prototype, MMP, PoC and other confusions

You already know the goal and benefits provided by the minimum viable product approach. This knowledge is essential to differentiate from other product iterations and pipeline stages. In our opinion, the MVP is located somewhere between the prototype and the minimum lovable product.

In case you’re more of a reader, don’t worry. Here’s MVP vs Proof of Concept vs Prototype explained in more depth just for you.

You’re free to relocate MVP according to your thoughts. But its place is not as important as the purpose, which differentiates it from other terms typical for the product pipeline.

PoC

Unlike the MVP, proof of concept is not a customer-focused task. It is an exercise or a test of some idea or assumption. For example, when you’re building a single-page app, PoC will show whether a particular tech stack like Node.js is a fit to implement your project from a technology standpoint. As a rule, the proof of concept is executed to decrease technology risks and prove the feasibility of doing a particular task. Startups may leverage it to validate their financial viability.

Prototype

The PoC answers the question “Can we build that?”, and the prototype gives an answer to “How can we build that?” To some extent, prototype and MVP are very close in their purpose, because both deliver a ground for learning from user feedback. That’s the reason why they’re often confused with each other. However, they aim at different target audiences. The early adopters of a prototype are usually the people involved in its creation. Meanwhile, a scrum minimum viable product goes public. In most cases, the prototype acts as bait for investors and underlies the MVP.

MLP

The minimum lovable product (MLP) is frequently called an alternative to the outdated MVP concept. They differ in purpose: MVP craves for user feedback on the product value, and MLP focuses on love it can bring to the users. For example, your MVP validated that the idea is worth evolving, but it has not generated much buzz. The MLP makes the users talk about your idea and share it with others. According to one of HubSpot’s founders, Dharmesh Shah, “The minimum lovable product does not make users happy, but makes happy users”.

MMP

The minimum marketable product (MMP) is another solution containing a basic set of functionality. However, it’s not meant for validating your ideas like the MVP is. The MMP is needed to collect data about user needs to build an adequate user experience. Its goal is to reduce time-to-market and let you launch the product faster. With this concept, product owners can understand which features are fundamental for the ultimate UX. Generally, the MMP is the step following the MVP.

MMF

Following up upon the MMP, we have the term of the minimum marketable feature, which is aimed at validating the value of one particular feature.

Pilot

Similar to the MVP, this pipeline stage is aimed at getting user feedback. However, the pilot testing is performed with a full-fledged product mostly before beta deployment. During this stage, developers obtain a better understanding of product readiness and refine it if necessary.

Alpha/Beta version

Another popular belief is that the MVP is an alpha or beta version of the product. In fact, both options denote working versions of a prototype to be tested with a small group of adopters. The alpha version is usually tested internally and aimed at getting early feedback on design, and functionality. MVP is usually compared to a beta version, which is meant for public testing and focuses on understanding the user experience.

MAP

So far, we’ve been talking about minimum products that are either viable or lovable or marketable. The next one on this list will be the minimum awesome product, which is predicted to replace the MVP in the future.

The digital revolution has already brought and continues to deliver great benefits to human society. Startups used to enter the market by offering some minimum value to be enhanced step-by-step. However, users are getting accustomed to that minimum and have overblown expectations for new products. That’s where the MVP is being transformed in the MAP because users anticipate something one of a kind and awesome.

Simply put, MAP means the MVP with an improved UX. So, the focus covers not only the functionality of the product but also the design, because the minds of modern users are design-oriented. So, if a basic set of functionality and features is enough for the MVP to deliver enough value, the MAP needs to add design, as well as speed and fluidity to its minimum. The awesomeness of your bare-bones product usually depends on the alternatives in your target niche. If your startup is a groundbreaker, the MAP will be equal to the MVP. At the same time, if the chosen niche has a bunch of competitors, be prepared to upgrade your MVP to make it awesome.

You’re unlikely to confuse the MVP with anything else if you know its major attributes like value-orientation, strict prioritization of functions, a relatively short timeframe for release, and focus on user feedback.

It’s also important tho let you know that this process doesn’t have to be complicated or expensive, and there are also ways to build a no-code MVP. Feel free to learn how on our blog.

And now, let’s narrow the MVP’s scope to a single company, which knows loads about how to build successful products.

How Railsware treats MVP

This chapter is not a kind of “About Us” section, but a look at the actual use cases about how to build a minimum viable product. We’ll mostly focus on Railsware flagship products – Mailtrap and Smart Checklist for Jira. The MVP of each of them was meant to solve some minimum task for a user in the best way. Later on, it allowed Railsware to check whether it is worth investing funds in developing those products.

Mailtrap

The idea of Mailtrap was introduced by Railsware’s CEO. The team of developers needed a tool for testing email notifications without spamming real users. It was not a startup or a money-seeking endeavor. Originally, Mailtrap was a solution meant to help to test and develop products containing databases and email sending functionalities. There was no intention to sweep the market. Once the internal issue was solved, we decided to validate this idea and introduced the MVP.

Having only one epic feature (preventing emails from being delivered to the real customers when testing), Mailtrap attracted users with easy configuration, usability (a couple of clicks to embed the code in an app), a free version, and a landing page with a humorous flytrap plant depicted on it. The MVP began to increase the customer base and collect feedback. We also conducted several surveys to understand the feature set the customers would make use of. With that data, we were ready to enter the market and monetize the product. At the same time, we have not abandoned the free subscription plan. It is still available along with the paid options.

Smart Checklist for Jira

Similar to the above, the origin of Smart Checklist lays in the necessity to solve one of our internal tasks. The Railsware team needed a usable solution to make long To-Do lists in Jira. It took us two days to write a piece of code and build a minimum viable product with the ability to convert Markdown into checklist items as an epic feature. Sometime later, we made it available on the Atlassian marketplace for free with no particular plans on monetization. It was an internal solution, which was good at solving our tasks.

As soon as we began obtaining numerous user stories and requests, we understood that the demand for our bare-bones product was rising. Therefore, it was decided to start the product evolution namely to make it better and monetize. At that time, we had two or three competitors that offered products with some similar functionality. Nevertheless, all they lacked the value we put emphasis on – the markdown editor.

Today, Smart Checklist feels integral in Jira, and users seeing it for the first time may not even notice that it is an add-on. The MVP has definitely solved our business goal and also brought benefits for target users.

Wrapping up

In conclusion, let’s sum up what we’ve learned about the concept of the minimum viable product agile development and its common misconceptions.

• MVP is a pioneer product version with raw functionality and a basic set of features;
• MVP is not a way to build a small product for cheap;
• Product owners must avoid stuffing their MVPs with all the functionalities they can afford;
• The goal of the MVP is to validate an opportunity hypothesis and deliver the core business value to the target user;
• Prototype and MVP are different notions though they have some similarities;
• MLP and MAP are the future direction vector for startups;
• MVP is what your business idea should begin with.

*** Value Proposition Canvas is designed by Alex Osterwalder, Strategyzer.com.