13 October, 2020
Even though the term Minimum Viable Product, or MVP app for short, was popularized by Eric Ries in his book ‘The Lean Startup’ almost a decade ago, there’s still confusion regarding what MVP is and what it isn’t. For example, some people confuse MVP with different tools for idea validation, such as prototypes, and others think that something “new and immature” is equivalent to MVP application, which is not always right. In this article, I’ll try to briefly introduce you to the MVP app concept and compare it to some other validation methods.
To understand the MVP definition and the whole concept in-depth, let’s first talk about why we need validation in the first place. Then we try to distinguish some other validation methods such as Proof of Concept and Prototype. After that, we will move into reasons why after almost 10 years, the term MVP is still quite a buzzword. Also, we will discuss a few examples of different MVPs approaches. Eventually, we will take a brief look at a new aspiring upstart – Minimum Lovable Product (MLP).
Ways to validate your assumptions
According to Harvard Business School professor Clayton Christen, 95% of new customer products launched each year will eventually fail. It’s rarely the lack of persistence, skills, or luck that causes the failure (although those are usually desired), but rather the product itself, and to be more specific:
- There was no need for the product in the first place.
- The need disappeared before the product entered the market.
- The cost and time of building the product exceeded initial assumptions.
- Although the market’s need was met, customers’ expectations weren’t.
Assumptions are the main killer of new products, and what’s the worst, all our ideas start with some sort of assumption. We assume what our customers need, how long it will take to build a new product, how costly it would be, what ROI we should expect, and when the assumptions turn out to be wrong, the whole product is at high risk.
For that reason, we need to identify and acknowledge the assumptions we make and verify them constantly, both while starting a new endeavour, as well as in the middle of development. Three common tools for verifying assumptions and gathering feedback are Proof of Concept, Prototype, and aforementioned MVP. Some people confuse them and think that these are just fancy names for the same concept. Let’s take a slightly deeper look to outline the core differences.
Proof of Concept (PoC)
Goal: To validate whether the idea is technically feasible.
The main goal behind PoC is to test whether the idea is technically feasible and worth pursuing. It’s not about discovering what your users need or want, or if there’s the demand for the solution, but rather if it’s possible and worth it to pursue the idea from a technical point of view. After all, you don’t want to take a full swing on an idea that turns out to be 10 times harder (and more expensive) to implement that you initially expected. It might be a quick trial to develop the beta version of the riskiest technological assumption or just a deeper analysis of technical possibilities available. Proof of Concept is usually not shared with end-users and is used as an internal tool.
Main features of PoC:
- Reduces the risk of engaging in unfeasible projects.
- Allows for better prototype/MVP planning.
- For internal use, sometimes shared with investors.
- Low cost.
- Doesn’t test the demand for the idea.
- Helps in estimating the cost of implementation.
Goal: To cheaply gather early feedback.
Prototyping strives to show us how the product will look like after developing. While PoC focuses more on the ‘under the hood’ part, prototyping is more about the UX/UI part. The goal is to cheaply build a simple experimental model of the idea to test and validate the concept before investing in the actual product. Almost anything can be a prototype – wireframes on paper, digital demo, PowerPoint presentation imitating the site, and much more. The ability to get early feedback and find loopholes in the idea early might be a deciding factor in the success of the product.
Main features of a prototype:
- Focused on the general idea and UX/UI parts.
- One can prototype the whole product or just part of the product.
- Enables to gather early feedback.
- Low cost.
- Greatly reduces the risk of building unwanted products.
Minimum Viable Product (MVP apps)
Goal: To launch a product as soon and cheaply as possible, validate assumptions, gather user feedback, and iterate.
MVP is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. — Eric Ries, The Lean Startup
MVP app development is about building a version of the product that will be available on the market and which real users can interact with. The core idea is to include as few features as possible while delivering the value proposition to end-users and to meet as many market needs as possible.
It’s about the continuous loop of building a product, then measuring and testing if your assumptions and hypotheses were correct and gathering users’ feedback, learning from that and improving the product, and repeating, again and again.
Focusing on MVP development rather than on some full-fledged solution reduces the risk of delivering an unwanted product and allows you to cheaply pivot based on the market reaction. Testing the product on the real market is always crucial, even if you’ve already validated your prototype, mainly because people often don’t know what they want, they just think they know what they want.
Main features of an MVP:
- Medium cost (more expensive than a prototype, less expensive than a full product).
- Real product on the market.
- MVP creation allows validating assumptions without building the whole product.
Types of MVP
The idea of an MVP might sound like a “version of the product stripped of most features”. While at its core it’s true, there are multiple approaches to rolling out an MVP, and crossing out most of the features is not the only (if even feasible) way. Let’s take a look at some examples to understand how MVP works.
Wizard of Oz
Sometimes new ideas require a lot of effort to implement. It would be risky to spend half of the budget building the core feature just to realise most of it has to be rebuilt. The solution is to do things manually first, without the user being aware, and based on that to decide whether there’s demand. Imagine, for example, building an app that matches dog owners with dog walkers. You are not sure if there’s demand for that, so instead of investing in developing matching algorithms, payments systems, database, etc, you can just create a simple website and then do all the under the hood magic manually, checking preferred dates, sending SMS confirmations, changing entries in the system, etc. The idea is that an end-user shouldn’t know that they are served by a human rather than a machine.
If you have read the novel, you probably know why the name, and if you haven’t, then spoiler alert – the dreaded wizard is in reality just an old conman who sits behind the scenes all the time and pulls levers, just like in the case of our app for dog walkers. It’s a great way to gather feedback and validate your thesis before investing in expensive software.
This method is very similar to the Wizard of Oz approach, with one crucial difference – the end-user is fully aware that they are being served by a human. In this situation, you become the product, just like a hotel concierge serving its guests. It’s a good approach when you have a general value proposition idea in your head, but you are still unsure about the details of the solution. Having the ability to interact with your customers might give you a lot of inputs. ‘Food on the table’ is an iconic example – Manuel Rosso, the founder of the company, wanted to create a service that gathers your food preferences and sends you recommended grocery lists with discount coupons for the foods you might need. For an MVP, he decided to manually talk to each customer, research shops and coupons, and send it back to customers. Doing it manually allowed him to gather crucial feedback – validate the thesis, realise that the customers visit different shops based on their locations and have specific brand preferences, and include it in his idea before investing in software which then would need rebuilding.
Wizard of Oz vs Concierge – so similar, yet so different.
While it’s a side topic, I feel the need to draw the line between these two methods, as many people treat them interchangeably, which is a big mistake. To put it simply, you use the Wizard of Oz approach to test hypotheses, while Concierge to generate ideas. If you already have an established idea to test, go with Wizard of Oz – if done well, your users shouldn’t feel any difference between your MVP and end-product, apart from the fact that doing things manually rather than letting the computer handle that takes more time. If you need a lot of feedback and fuel for thought first, Concierge is the way to go. Having real interaction with your customers is a great way to learn about them and their needs. However, keep in mind that in the case of Concierge you deliver higher value than your end product would due to that human interaction. Even though people might love the idea of talking with you about their food preferences and getting grocery lists from you, that doesn’t necessarily mean they’ll love interacting with automated software. In the same way, this is why, even though Concierge is great for generating ideas, you shouldn’t use it to test your final hypothesis.
Even though tailor-made software is almost always a better idea, to validate a hypothesis and gather early feedback, it might be wise to decide to use already existing solutions. The most iconic example of Piecemeal MVP is Groupon. The company we know today is a massive ecosystem with integrated payments, mailing systems, coupon generators, etc., but it didn’t start that way. They used already existing solutions and put them together, creating a little Frankenstein. They used WordPress for their site management and WordPress posts served the role of offers, coupons were generated by FileMaker, and automatic mailing was managed by Apple Mail. Even though mixing so many different solutions is not a scalable, long-term solution, it was more than enough to attract early customers and gather invaluable feedback from them.
In this approach, we don’t provide a working product. The idea is to create a simple website, often just with a landing page that describes the value proposition of the product and has a clear Call To Action button, for example, to purchase the service. After clicking the CTA button, a user often receives a message that the product isn’t yet available but it’s possible to sign in for a mailing list / pre-order the service. It’s a great way to gauge the potential interest of customers and confirm/deny the hypothesis that there’s a need for the product on the market.
There are discussions on whether this approach should be treated like an MVP – after all, you don’t have a working product. However, it meets the criteria of “version a new product which allows the team to collect the maximum amount of validated learning about customers with the least effort”.
And many more…
You had your read about four different approaches to validating your hypothesis through an MVP. This is by no means an exhaustive list, on the contrary, there are limitless possibilities to test your products. As long as you can achieve the maximum amount of validated learning with the least effort, you are good to go.
How to define your MVP?
Okay, so you already know what MVP is and how it differs from other validation methods, and you decided to go for it. You have a general theory, but how do you start? You need a more detailed thought process before you just decide to “build something small”, with the wrong approach to MVP, you might rip yourself of all benefits and just waste your money and time.
When planning your product, you often have dozens of assumptions, many of which you probably don’t even recognize. Now, one of the easiest approaches in defining the initial MVP is to ask yourself 2 core questions.
- What is the riskiest assumption? – it’s usually your core value proposition. Your gamechanger. If it works out perfectly, you are destined to succeed on the market, and if it doesn’t, then your whole product is worthless. If you haven’t done that already, it might be a good idea to write it in the form of a thesis that you must verify.
- What is the smallest experiment we can test it in? – now, how can you verify the above thesis without investing months and millions of dollars? Remember, the idea is to validate just the riskiest and most important assumption, and then build on top of that, so if your assumption is, for example, that people would love and pay for the ability to order dog walkers in an Uber-like model, then you don’t need a map, tracking, tipping system or other fancy features, perhaps you don’t even need an app until you validate the idea, but something resembling the experience?
As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek. — Eric Ries, Lean Startup
When you start the process of defining your MVP, you might notice that it’s way harder than you might have initially expected. Building Minimum Viable Product can be considered as one of those things that are easy to understand, but difficult to master, this is why it might be wise to use some help from professionals. In TSH, we offer both long-term cooperations regarding building and evolving an MVP, as well as quicker design workshops just to help you get rolling as soon as possible.
The reasons why MVP is such a buzzword. And why should you build an MVP app?
If you are into product development, you have most probably heard the term MVP more than a dozen times already. Clients, shareholders, designers, product owners… seems like everyone has gone crazy with this term lately. I think it’s fully understandable, once you think about all the benefits when deciding on pursuing a Minimum Viable Product.
Time-to-market is one of the most important factors determining product success or failure. Too long development time is considered the biggest obstacle when it comes to generating an ROI on a new product (Source: BCG Global Innovation Survey, 2015). Just think about, the market is changing dynamically, dozens of new products are launched daily and trends change. Something that seems hot today might be completely outdated in a year, yet sometimes people decide to spend years building an experimental product, just to realise it is not needed anymore.
While building a whole new product might take years, building an MVP platform is usually a matter of months, if not weeks. It allows you to jump on trends or fulfill current customer needs before the trend wave disappears.
Validate-Build Measure-Learn Cycle
User experience is important. Building an MVP enabled you to get real user feedback fast. You’ll see what works and what doesn’t from the very beginning. After all, you are building the product for your end-users, so is there a better way to make sure that the product meets their expectations than engaging them in the creation of the product from the very beginning? What’s more, as mentioned before, people tend not to know what they want, only to believe what they want. Launching an MVP allows you to validate yours and yours’ users’ beliefs fast.
Lower risk and cost
Focusing on the most important value-generators and reducing time-to-market not only greatly increases chances of success, but also reduces overall development costs and project risks. Launching an MVP can cost as little as 5-10% of the cost of the full solution, and it starts generating revenue from day 1. You reduce the risk of misunderstanding your customers, and if you did misinterpret their needs, then you’ll learn that, fast. Being able to launch a product within weeks rather than years reduces the risk of market changing. And in the worst possible scenario, when your product completely doesn’t fit the market and customer needs, you risk losing that 5-10 % of MVP cost, rather than years of development of the full product.
Kill your darlings
One of the most known traps of product development is getting too attached to your product. If you spend years developing your idea, there’s a chance that even if 90% of the feedback is negative, you will still believe that the product needs a little tweaking – you have invested a lot of time, money, energy, and heart into the product after all, how can you now kill the idea? Building an MVP allows you to validate the idea fast before you get attached. If you invest a small number of resources to test your MVP, then if it doesn’t work out, you are more inclined to make the right choice – kill your darlings, lick your wounds, and try again. The longer you work on the product, the more attached you tend to be, and thus make more emotional decisions, which is usually wrong.
Chance to launch a product with a low capital
Software development is not cheap, but it shouldn’t stop innovators from changing the world and challenging the status quo. Since pursuing MVP reduces the general risk of building the product, it makes it more attractive to potential investors. You also need less money to get started, thus the fundraising for MVP is a piece of cake compared to fundraising for a whole big product. Once you launch your MVP, you can start generating revenue, fast. The product is there, and although it doesn’t yet have all planned features and polishing, it already delivers value to customers, value which you can charge for. Now, who’ll have it easier to find new partners and investors? Someone with a business plan on a piece of paper needing full funding, or someone with a working product on the market who just needs to iteratively improve it? MVP allows us to realise big ideas on the budget.
How “MVP” is one of the most misused words in product development.
MVP is a quite popular buzzword, and the problem here is that many people started labeling everything they do as “MVP”, just because it seems trendy. I’ve seen products with a 2-years long development plan, with scope fixed in stone, but still called by their initiators as “MVP”. Nowadays, it seems like MVP is becoming a substitute word for “new”, which only creates additional confusion. If you are building as minimal version of the product as possible to validate your assumptions and then, based on your learnings, decide the next steps, you have an MVP. If you already have a defined product with little room for any pivots or changes in the scope, then it’s just a very early version of the product, but not an MVP.
Minimum Lovable Product (MLP) – an MVP taken to the next level?
While MVP itself was cutting edge in product development a few years ago, nowadays there is less faith that this type of product approach is enough. MVP is great when one is launching an innovative idea with an unconfirmed thesis, but while a decade ago solutions such as Uber, Shopify, Amazon, PayPal, etc. were something brand new and innovative on the market, in 2020, with more than 100,000 new apps released every month on Google Play alone, the competition is high and the chances of discovering something brand new to the market is slim. Companies often choose to improve and tweak an existing idea with some type of competitive advantage, and launching an MVP might not be an option – would you switch from Spotify to a minimal version, stripped of most of the features and UX, just for one different feature? Probably not.
In those situations, a Minimum Lovable Product might come in handy. The goal here isn’t just to validate the thesis, but also to make your customers fall in love with the app. You achieve that by focusing on a set of most important features, and you polish them up nearly to perfection, focusing not only on the functionality itself, but performance, UI, UX, etc. While it’s still not the full version of the product with all the intended features, it has enough to start attracting first customers and compete with other solutions already existing on the market.
Summary (aka – let’s create MVP!)
As you can see, there are multiple ways of validating different types of assumptions, and the ones mentioned in this article are just a subset of various validation methods. The most classic trio is Proof of Concept for validating the feasibility, prototypes to gather very early feedback, and MVPs to gauge market reception and validate the real need. The final goal is always the same – to validate your assumptions as soon as possible while minimising the cost and time needed. Without appropriate validation methods, you are running an extremely high risk of investing time and resources in a solution that just doesn’t have the right to fit well in the market.
MVP development is one of the most recognised methods for mobile apps and web systems delivery. It allows fast time-to-market at low cost and risk, and if done right, an incredible learning experience. While there are multiple approaches to building an MVP, it’s important to recognise that not everything that’s “new and shiny” should be called an MVP. If you are building your MVP, it might be good to revisit Eric’s definition a few times in the process, “MVP is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.