MVP app. What is it and what are the other validation methods?

To understand the MVP definition and the whole concept in-depth, let’s first talk about why we need validation.

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 – the 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 endeavor and in the middle of development.

Three common tools for verifying assumptions and gathering feedback are Proof of Concept, Prototype, and the 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.

A Proof of Concept is usually not shared with end-users and is used as an internal tool.

Main features of a 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
• Short-lived

Prototype

Goal: To gather early feedback at a minimal cost

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 build a simple, experimental model of the idea on a budget 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 product’s success.

Main features of a prototype

• Short-lived
• 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 pivot at a low cost 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

• Average life cycle
• Medium cost (more expensive than a prototype, less expensive than a full product)
• A real product out in the market
• MVP creation allows validating assumptions without building the whole product

MVP types

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 workable) way.

Let’s look at some examples to understand how MVP works.

The 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 realize 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. An end-user shouldn’t know that a human serve them rather than a machine.

If you have read the novel, you probably know why the name, and if you haven’t, then there’s a spoiler coming.

The dreaded wizard is in reality just an old con man 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.

Concierge

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 talk to each customer in person, research shops and coupons, and send it back to customers.

Doing it manually allowed him to gather crucial feedback – validate the thesis, realize 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 – similar, yet 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 and the Concierge method to generates 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 because of 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 mean they’ll love interacting with automated software.

Although Concierge is great for generating ideas, you shouldn’t use it to test your final hypothesis.

Piecemeal

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 an existing solution. The most iconic example of a 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 pre-existing solutions grouped 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.

Although mixing so many solutions is not a scalable, long-term solution, it was more than enough to attract early customers and gather invaluable feedback from them.

Smoke-test/Landing page

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 learned four different approaches to validating your hypothesis through an MVP. This is not 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 decide to go for it.

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 game-changer. 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 as a thesis that you must verify.

•  What is the smallest experiment we can test it in?

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 that your product will be based on.

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 defining your MVP, you might notice that it’s way harder than you might have initially expected.

Building a Minimum Viable Product can be considered as one of those things that are easy to understand, but difficult to master, so it might be wise to use some help from professionals.

At 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 reason MVP is such a buzzword

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

Time-to-market is one of the most important factors determining the product’s success or failure. Lengthy 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 it. 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 realize it’s 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

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. Is there a better way to meet their expectations than to engage them in the process from the very beginning?

People tend not to know what they want, only to believe what they want. Launching an MVP allows you to validate your and your 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.

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. Now that you have invested a lot of time, money, energy, and heart into the product, how could you kill the idea?

Building an MVP allows you to validate the idea fast before you get attached. If you invest in a few 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 are, and thus make more emotional decisions, which is usually wrong.

Chance to launch a product under low capital

Software development is not cheap, but it shouldn’t stop innovators from challenging the status quo. Since pursuing MVP reduces the general risk of building the product, it makes it more attractive to potential investors.

Here, you also need less money to get started, thus fundraising for MVP is a piece of cake compared to fundraising for a packed 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. The 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 improve it through iteration?

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 a 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 over 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 unique 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 attract first customers and compete with other solutions 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 features Proof of Concept for validating the feasibility, prototypes to gather very early feedback, and MVPs to gauge market reception and validate the genuine need.

The ultimate goal is always the same – to validate your assumptions as soon as possible while minimizing the cost and time needed. Without an appropriate validation method, you are running an extremely high risk of investing time and resources in a solution that just won’t fit well in the market.

MVP development is one of the most recognized 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 recognize 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, “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”.