What do Facebook, Airbnb, and Uber have in common? Yes, they all are exceptionally successful companies. But there’s more to it: they all started as minimum viable products and it wasn’t so without rhyme or reason. Building an MVP first comes with a number of benefits: it costs less, takes less time, helps focus on the most valuable features, and figure out whether a business idea is worth scaling. It’s no surprise that the masterminds behind these world-renowned brands decided to put the “Rome wasn’t built in a day” rule and begin the software development process with an MVP. In this article, we’ll show you how your venture may benefit from following this rule as well.
Read on to find answers to the following questions:
- What are the different MVP-related concepts and some of the most common misconceptions?
- How to pick the features for a minimum viable product?
- What can you expect from a software house when you start working on building your minimum viable product together?
Table of contents
What is a minimum viable product (in theory and in practice)?
Different approaches to building an MVP
Minimal marketable product (MMP)
Minimal marketable release (MMR)
Minimal marketable feature (MMF)
What is not an MVP?
Why is MVP building important for a startup?
How to pick the features for a Minimum Viable Product easily?
How to build an MVP: a proven process
Should you outsource your MVP?
Building MVP with a software development company: Autium case study
What is a minimum viable product (in theory and in practice)?
In theory, theory and practice are the same. In practice, they are not.
This saying perfectly corresponds with the challenges startups face when they decide on building a minimum viable product. That’s not surprising if we take into account how many different definitions of an MVP there are. But let’s start from the beginning.
Back in 2001 when Frank Robinson coined the term Minimum Viable Product, what he meant was a product “big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky”. In this sense, developing an MVP would give the biggest possible return on investment (ROI) with the lowest possible risk. Today, we would not call it a minimum viable product but rather a minimum marketable product. We’ll talk about the difference between these two later in the article.
Then, in 2011, Eric Ries came to play with the concept of an MVP as a tool for validated learning and an imperfect (although not sloppy) version of a product that allows a startup to get something tangible in front of their potential users and learn what they really want. That’s how most ventures and software companies understand an MVP now. That’s also what we’ll refer to when talking about MVP in this article.
What makes Robinson’s and Ries’ definitions different is that the former assumes you’re going to build a real product that will eventually become successful, while the latter leaves room for experimentation and testing different non-product approaches as long as they help you learn. These are in fact two different concepts.
The discrepancies between theory and practice in the context of MVP show as soon as we start discussing what the words minimum, viable, and product actually mean.
Minimum
Minimum means small. The need for a minimal scope is pretty straightforward in theory, although very difficult to achieve in practice.
A lot of businesses we talk to before we start working together have big plans for their soon-to-be-built applications. In their minds’ eyes, they don’t envisage a simple or unfinished product, but rather a better version of anything their competition has ever created. And as much as we cheer for our clients to become successful, such visions are far from minimum.
Forcing yourself to prioritize and focus on the features that give your users the biggest value is probably one of the most difficult things you’ll face while working on an MVP. What helps to cut out a minimal scope?
- Limited budget. A challenge for most early-stage startups that makes them think outside the box and look for lean ways of testing a business hypothesis.
- Deadlines. When you know upfront that there’s a limited time you’ll be able to devote to the product, you’ll have more drive to set priorities to particular features or modules of your application.
- Detailed cost estimation. Nothing works as sobering as a breakdown of features with a price tag on each.
- Cost vs. business value. The first features in your limited scope should be one of the biggest business value and relatively low cost.
Viable
Viable stands for the ability to test a business hypothesis. When building an MVP, you’ll look for the smallest possible thing you’re able to make in order to test whether your hypothesis is true or false. Let’s take Zappos’ story as an example.
Zappos is an American e-commerce selling apparel and shoes. They went into business twenty years ago when no one else was doing it. Everybody was buying their shoes in brick and mortar stores. To find out whether people are ready to buy shoes online, Nick Swinmurn, the founder of Zappos, built a dummy website with pictures of different pairs of shoes from a local mall.
The original Zappos MVP website
Whenever someone placed an order, Swinmurn would buy the shoes in a mall and send them to the customer. This way, he proved people would buy shoes online long before he spent hundreds of thousands of dollars on building the inventory and the e-commerce platform.
Product
In the lean sense, the letter P in MVP does not necessarily have to be a product. It’s much closer to a prototype than a running version of a real application. At least in theory.
According to Eric Ries’ definition, the product is nothing more than just an iteration that aims to collect market feedback regarding our idea. It doesn’t even have to be software. Clickable mockups or an explainer video can also play the role of a “product”. In the Zappos example, it’s the dummy website wrapped in a concierge-type of service that’s totally transparent to the end-user.
Contemporary MVPs go beyond Eric Ries’ concept and move towards its roots - a software we can test on a market.
Different approaches to building an MVP
Over the years, various authors have used the term Minimum Viable Product differently. What’s more, the discussion about what MVP actually has led to coining a couple of new, closely related concepts, which makes it easy to get lost in the definitions. To prevent that from happening, let’s take a look at the terms you can run into when working on your product.
Minimal marketable product (MMP)
Minimal Marketable Product (MMP) is a version of a product with a minimal set of features yet still ready for launch. In this sense, it represents the idea of less is more. It’s a reasonable approach that on one hand allows for a faster time-to-market (because we don’t build more than we need) and, on the other, prevents businesses from spending money on features with questionable business value.
An MMP is often presented to early adopters who can provide enough valuable information to decide whether (and how) to scale the product further. That’s also the common understanding of an MVP - a product you can launch relatively fast with a limited budget, and still become successful.
Minimal marketable release (MMR)
Minimal Marketable Release (MMR) is an iteration of an MMP containing the smallest possible set of features that address the users’ needs. Similar to the MMP, the goal of a minimal marketable release is to reduce the time between releases and collect feedback from the market regarding the value it provides.
Minimal marketable feature (MMF)
You probably already guessed that a Minimal Marketable Feature (MMF) is the smallest piece of functionality that gives value to the end-users and to the organization.
To give you an example, Spotify uses an MMF approach to test new functionalities for their application. Because the digital music service operates on various markets, releasing a new feature everywhere would cost the company a significant amount of money. Instead, Spotify develops a feature and tests it first on a pioneer market. If the results are satisfactory, the company invests in developing the same feature for other markets as well.
Relations between MVP, MMF, MMP, and MMR
What is not an MVP?
With all those concepts, it might be easier to say what an MVP is not. In short, we’re not dealing with an MVP in four cases:
- When the scope is too big. If we’re building a full-bodied product with fancy features, for different types of users, different markets etc. we can’t say we’re building a minimum viable product.
- When we don’t know what to measure. This point refers to the “viable” part of the MVP. If we’re not able to say how we’ll assess the product’s success, we can’t talk about an MVP.
- When there’s no hypothesis, meaning there’s no goal for the MVP. It’s really difficult to come up with the right ideas for the product if we don’t know what to test.
- When it doesn’t sell. There has to be enough value for the end-user to pay for, or at least sign up for our product.
Why is MVP building important for a startup?
By now, you should have already observed the major benefits of making a Minimum Viable Product a part of the software development process. Let’s wrap them up now:
- The more you delay entering the market, the more time and money you risk. The information collected via an MVP makes it easier to assess the potential return on investment.
- Shorter release loops mean lower development cost.
- By focusing on early adopters, you’re able to deliver value to the end-users much quicker than with a full product.
- An MVP gives you the advantage to plan ahead based on the feedback from the market.
- It minimizes the risk of building a product no one would use. Enough to mention that no product-market fit is the top reason why startups fail.
- Finally, with a working model of your business idea, it should be easier for you to convince investors to support your product.
How to pick the features for a Minimum Viable Product easily?
When you’re building a digital product for the first time, assessing on your own what can be risky or bloated is more than difficult. Applications, as we know and use them, are often quite big systems with complex business logic. How to pick the right features for your MVP? Here’s a step-by-step formula we recommend:
- Prepare user flow and name all possible actions your user can make in your application. These will be your features.
- Assign business value to each feature.
- Estimate the time and budget you need to build every functionality.
- Compare business value with resources you need. If you have to put a lot of money and time to build a feature of little business value, take them out of your list or leave it for later.
- List the key features for the walking skeleton.
The fiercest discussions we had with our clients burst around the concept of “minimum”. In the case of an application, achieving the minimal scope usually means compromising on things such as:
- Platforms. Many successful projects out there have both their web and mobile versions. Take Uber, Facebook, or Airbnb. All of them launched MVPs first and none of them covered more than one platform. Think of it this way: if you were building a new tool for office workers, would they absolutely need a mobile version of the tool to use it efficiently? Probably not. Why would you then want to make them happy with something they don’t find essential?
- Language versions. Even if you’re 100% sure that your product will be global, start smaller. Translation of your content and localization is the effort you don’t want to make before you know that the product is successful on a smaller scale. However, planning for language versions from the start will allow you to adjust the architecture and save on rebuilding it later on.
- Design. Unless it’s the design that gives your users unique value, hold your horses (and budget) before you end up paying for a custom UI designer. Focus on the experience and usability instead.
- User roles. Many applications have different user roles and permissions. Administrator and User are only two basic types. When you’re launching a product to test it on the market, try to pick only the necessary ones.
- Scale. We bet that when thinking of your early-stage product, you can already imagine it attracting thousands of users. You want to get ready for potential usage peaks, for Black Fridays, for scaling up and out. Think twice before you dive into meticulous knitting of the perfect architecture for the future. Instead, focus on your business goal and the most important features, but keep in mind the bigger picture.
How to build an MVP: a proven process
There’s a quote by Antoine de Saint-Exupery that a lot of people use when they discuss usability, user experience, and the minimum viable set of features:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Of course, when talking about an MVP, we’re not on the lookout for perfection. What we need is just good enough but valuable. The key is to choose such a minimal scope that would address the needs of our potential buyers. It sounds easy in theory, but in practice, if you haven’t done it before, it can get overwhelming.
To benefit from the minimum viable product and save yourself from investing a lot of money into a totally unnecessary thing, you need to prepare. The more thorough the preparation, the better (and less painful) the development.
Research, research, research.
The beginning of MVP development is far from exciting unless gathering tons of information and insights is what excites you most. Before you hire (or outsource) developers to build your solution, there’s a lot of homework waiting for you. Sloppy research will backfire during the product design workshop or the scoping session. What’s more, it will probably hurt the project by making you spend more money and time than you need and, what’s even worse, build a product no one would want to use.
What to research for a minimum viable product?
- First, you need to know your goal.
In order to build a successful product (or a successful MVP) you need to have a clear business goal. In other words, you need to know what your business is going to gain by releasing the product. It may be entering a new market or presenting the offer to a new group of users. Your goal will be a lighthouse for all business decisions you’ll make along the way, especially when it comes to the product scope.
Our role as software designers and developers is to help you discover this goal and choose appropriate tools that make it achievable.
- Then, get to know your users.
Sounds a bit like a marketing cliché, but in fact, you need to possess some basic knowledge about your target audience. As a customer, which applications do you use? The ones that you find comfortable and useful or the ones imposed from outside? I bet the former. The same refers to your potential users. First, they need to find your solution valuable. That’s why you’ll need to know your customers inside out. It’s the only way to guarantee that your users would find your features indispensable and useful instead of needless and redundant.
- Interview your potential users.
Make sure you ask them about the tools they use now. What they like, what they’re missing, how do they interact with the solution or software? These are questions that would help you understand the bottlenecks as well as opportunities and threats of designing a different product. Client interviews are also one of the most efficient ways to verify business ideas and examine whether there’s an initial demand for our product on the market.
We often use back-selling techniques and Google Forms to help our clients verify their business ideas.
- Research your competition. Thoroughly.
Far too many companies, especially startups, are so proud of figuring out their business idea, that they forget to check if similar solutions already exist. Careful examination of potential competitors whose solutions get the same job done is an amazing source of inspiration and a valuable factor in risk assessment. After all, there’s nothing shameful in having the same idea as someone else. You can still differentiate yourself and your product from the competition.
Scoping Session
Once you decide that you need software in order to deliver demanded features, we hold a scoping session to fully focus on the minimal set of features that would not only define your product but also support you in achieving business goals.
To stay focused on the objective, we use a technique called user story mapping. It helps us group particular features under the business goals they serve and then prioritize them in order to extract the first and the following product releases.
It’s important to mention at this point that for new products, you’ll need to build a backbone of your application. It means that before we’ll be able to sprinkle magic on your app, we’ll need to build a so-called walking skeleton. If your product is simple, an existing box solution may be just enough. More disruptive ideas, however, tend to have unusual and complex business logic. Such skeletons could even take more than three months to build.
Your MVP scope would comprise the backbone features and the first release. Everything else would create a roadmap showing how the product could develop beyond the MVP level.
A scoping session is also an excellent tool to check whether your business knowledge is enough to build a product. An experienced product design team would ask you tens of difficult questions to find potential loopholes and flaws in your product and help you fill them with validated information.
Iterative product development
After the scoping session, we start turning your plans into reality. In order to keep the focus on the business goals, we divide your MVP scope into smaller chunks, called sprints. What’s important is that to each sprint we assign features that carry a certain business value. Agile approach makes it easier to plan, prioritize, and then test particular product releases.
Read our story of cooperation with Humanitrack, which involved building both an MVP and a polished beta version of the non-profit community platform.
Should you outsource your MVP?
There are a lot of theories saying that you should fear to outsource your MVP. The reality, however, shows that when you have an idea, even a validated one, you’ll still need a team to build it for you.
In the practical sense, since a minimum viable product is actually a limited version of a product that you’re able to ship and monetize, you have two options.
The first is to build a team on your own. This option can be cheap and you won’t have to take into account the risk of someone else not understanding your vision completely. It also makes sense if you have previous hands-on experience of both working on a software product and managing people.
The second option is to hire a software development company – a team of people who ship software on a daily basis and have worked on similar projects before. This experience will allow them to ask you the right questions and help you ship your product to the market. At Merixstudio, we support our clients not only in validating their business ideas and building MVPs but also afterwards, when they are running tests with their target audience. We design testing scenarios and guide young businesses on how to properly collect feedback and test an MVP hypothesis.
Whichever model you choose, the key is to compose a team in such a way that everyone understands your idea and is able not only to see the user perspective but also to guard your business goal. The insights and the vision, however, have to be yours.
Building MVP with a software development company: Autium case study
It’s all very well, but how does such outsourcing work in practice? Glad you asked because we’ve built a number of MVPs for businesses of different sizes operating in various industries – and now, we want to share this experience with you using Autium as an example.
Let’s start with a few words of introduction. Autium is the brainchild of a UK-based tech startup whose founders had the first-hand experience of fleet management and assurances. Knowing how cumbersome insurance claim processing can get, they wished to take the weight off the shoulders of both fleet managers and drivers. As a result, they came up with an idea for a platform enabling automated incident management.
Presented with this vision, we drafted the first version of estimation and pointed to the need for clarifying it further before launching the development process. Since the Autium founders were aware of what it takes to build a successful MVP, they were eager to discuss their ideas during the product design workshop. At that point, our goal was to define the client’s objectives, confront them with the end-users’ expectations, and select core functionalities accordingly. We also drafted the project roadmap for the next iterations and refined the budget estimate. Once we agreed on the scope of work at all stages of the MVP’s growth, we got down to UX and development proper.
As part of the first iteration, we build a mobile and a web application, both comprising the essential features only. The former, being targeted at drivers, facilitates reporting all necessary details of the accident, including pictures and an exact location based on GPS device location. The latter allows fleet managers to store and modify information about drivers and vehicles grouped into depots, as well as incidents or claims. It also offers real-time analytics and the quick generation of claim documents.
At this point, it’s worth mentioning that Autium decided on starting with an MVP for a reason. Their goal was to build a functional product that would truly benefit its users – and they knew this can happen only with the help of their target audience. With an MVP at hand, they approached the prospective customers and started gathering feedback which we used to improve the following versions of the platform.
As a result, version 2.0 is not only fixed but also enriched with some meaningful functionalities. From now on, the mobile app offers daily inspections that facilitate the process of checking and documenting the condition of the vehicle, carried out twice a day. We also introduced reports on the most common issues and damage to the car and added notifications informing on the approaching technical inspection date.
It wasn’t only the iterative approach to development that made the MVP successful. Based on our previous experience, we also went for the solutions which we consider reliable and relatively fast to implement – especially that both the budget and deadline were tight in this case. As the mobile app was to cover both Android and iOS, we decided on a cross-platform solution that ensures faster and cheaper deployment: React Native. For backend, we chose Django – and thanks to Django admin, we didn’t need to reinvent the wheel. In the end, the MVP development spanned around 1900 manhours.
Autium is still collecting user feedback and together, we’re working on version 3.0 of their product. As you can see, validating your business idea against user expectations and using feedback to improve the product is much more than just a theoretical best practice. Matched with the software development expertise, it can truly work to your advantage.
Minimum Viable Product: key takeaways
When we talk to our customers, most of them have a goal to build a product, not an MVP. They know that the reality of the startup scene is very different from what it used to be in the times of Zappos. Users want products. Startups want small products that would sell. Building MVPs is therefore much more about looking for a way to maximize ROI and minimize business risk in uncertain circumstances. The definition has made a full circle.
Now you know that building an MVP is not as easy as it seems. There are different nuances and misconceptions around the term. The process looks short and sweet, although it’s quite difficult to implement in practice.
- Identify the need or the problem.
- Figure out how to address the problem or the need.
- Think of what could be the smallest thing you can do to check whether your idea makes sense.
- Build it, test it with your users and learn from their feedback.
The good news is that you don’t have to do it on your own.
If you’re struggling with preparing an MVP or choosing the best way to verify your hypothesis, reach out to our product design team. We’ll help you out.