Table of content

1. What is a Minimum Viable Product
2. Examples of MVPs
3. Key characteristics of MVP
4. Why you need an MVP
5. What pitfalls to avoid
6. How much does it cost to build an MVP
7. How long does it take to build an MVP
8. MVP development process explained
9. Summary

Let’s imagine you have an idea for a fantastic application… Wait, how do you know it’s actually a good idea? Maybe it seems so outstanding only to you?

A natural step would be to ask one’s family, friends and coworkers for opinions, but is that providing you with enough data to start a large investment? A journey from an idea to a successful product is long, bumpy and dangerous, but don’t worry, there are some practices that help minimize the risk.

Let me tell you about one of them, Minimum Viable Product (MVP).

What is a Minimum Viable Product

MVP is a way to verify assumptions and test the demand for a new product with a minimum investment. The term “minimum viable product” was first used by Frank Robinson and then popularized in the Lean Startup methodology. It’s all about testing the interest in our idea and checking if anyone actually needs it before going all-in.

As a popular, even fashionable, phrase MVP is often misinterpreted. Most often I hear people mean “the first version of a product” when they say “MVP”. This doesn’t have to be wrong, but it is not fully correct either. This definition is not explaining the essential goal of MVP, which is testing the sales potential of a product, and the market demand for it.

A great example of a project that was not “the first version of a product” and perfectly fulfilled the goal of MVP was a video presentation of Dropbox. One of the co-founders of Dropbox, Drew Houston, created a three-minute video demonstration of the idea, and within just a few days he had an answer if the tool is needed and if anyone would use it. Least effort, maximum information – that’s what an MVP is about!

Examples of MVPs

To create an MVP you can use many methods, each of them has a different cost, requires a different amount of time, and allows you to gather a different amount of data. Take a look at the most popular MVP variants:

Demo Video

This might be the cheapest way to create an MVP but it also allows you to gather only a little information. Like the Dropbox founder, you can create a video and see how many people declare interest in your product.

Landing page

With a landing page, you can gather similar feedback as with a video but it’s a little more expensive to create. So why is it worth it? I’d say there is one major advantage, with a landing page you can easily collect contact data of the potential users and already start building a user base.

Clickable prototype

Prototypes created in Figma or similar tools are relatively easy and cheap to build, they give you huge flexibility, so testing many hypotheses is fast and simple. It is of course more expensive than a video, but you can already test user flows and feature ideas, not only the general interest in your product.

One disadvantage of clickable prototypes is the testing group, video, or landing page are very easy to share and promote, on the other hand, a simple application already gives some value to the users. Unfortunately, the prototypes are time-consuming to use, don’t give users any real value, and you will most likely need to reword the testers’ effort in a different way.

Simplified Software Product

This is the most common interpretation of the term MVP. And I must admit it definitely gives you the most profit, but it also comes with the largest cost.

A simplified application can, of course, be more or less simplified. You can go for a really minimum option, like Uber creators, who supported only one city and had only one barely working functionality at the beginning. Or you can decide to create a more advanced version, like Facebook, which started as a quite advanced application for students of one university.

Key characteristics of MVP

The primary goal of creating an MVP is testing the product idea and collecting the data about potential users. Creating a final product is costly and risky, and an MVP approach allows you to verify the product hypothesis, gather useful feedback and observe customers’ behaviour with minimum investment. Its purpose is to minimize the time required to test the business assumptions, lower the risk and mitigate the costs of development.

MVP, MMP, MLP – what is the difference

As software development evolves so is the concept of MVP. Different products require different approaches and the IT world created several techniques to fulfil these requirements.

Minimum Lovable Product

Many companies decide to create MVPs as an extremely simplified and often buggy version of the end product. It is a great approach if your focus group is very forgiving, but bugs and too many simplifications might cause users’ frustrations and, in the end, you don’t get valuable feedback about the features because opinions are too influenced by the bad experience. Minimum Lovable Product (MLP) is about creating enough functionality to satisfy early adopters, not just make them tolerate it.

Minimum Marketable Product

When you know your target users, and understand what features they need most it is time to think of a more advanced product. Minimum Marketable Product (MMP) is the next step after MVP development. It combines the knowledge you gathered with an MVP, with the MLP standard improvements and lets you test the marketing strategies.

At this point, you need to have not only a lovable but also a sellable product. How is it different from the finalized application? I’d say it’s the first version of it. Building a product is all about a feedback loop, constant growth, and new features, so an application can never be called finished.

MVP, MPL, and then MMP

Building a complex product requires several steps, MVP, MLP, and MMP are helping you organize this journey. Each of these development techniques serves a different purpose and the question is not “Which one of them should I build?” but “Which one should I build at this stage of my project?”. A journey from hypothesis to a product might look as follows:

1. MVP development – define what assumptions you want to test and find the simplest and cheapest way to conduct the market research with potential users, gather customer feedback, and iterate the feedback loop at least a few times to find the features that give the most value to the customers.
2. MLP development – based on the knowledge from MVP create a simple yet functional version of the product that has all the basic features for the customers to love it, gather feedback, understand user journeys and behaviours.
3. MMP development – when the product is well defined, it has a clear mission, vision, and established target users it is time to start testing the sales mechanism.

Creating a product for your company is all about the famous Build Measure Learn process. It helps you keep the low risk and grow the business step by step.

Why you need an MVP

A project that exceeded the budget or went on for much longer than expected is nothing uncommon in the IT world. The risk of building an application is very high, think how much higher it is if you don’t know what to build.

Many startups forget how important is market validation and unfortunately, it has consequences. MVP allows you to validate your app idea and make sure you are building something that people need, want, and will buy. But it has also other advantages.

Lower the risk, save time and money

The absolutely most important thing that building a Minimum Viable Product gives you is the decreased risk. Without a huge investment, there is no huge risk. MVP development technique same as the whole agile development methodology is about taking small steps and learning after each of them.

Thanks to an MVP you can gather immediate user feedback and if you also use agile frameworks like Scrum or Kanban your team can adapt within days. Thanks to that approach you never invest too much in unnecessary features and can quickly review your value proposition.

You are creating an application for users, so it is crucial to ask them for feedback every step of the way. Product’s initial users are the ones who should decide what product you’re building and thanks to MVP you can learn what they have to say, understand them, and discover the market trends.

Be ahead of competition

Mitigating the risk is not the only advantage of minimum viable products. They enable quick launch, so you can start building a user base and become recognizable faster than your potential competitors.

An MVP and data collected with it are also a great value when looking for investors. You’re not having just an idea but already deep knowledge about the market, sales potential, and future customers.

And last, but not least, with even a very simple MVP you can start earning money. It might not be possible for every application type and depends on your customers, but if you plan the minimum viable product carefully, a monetization flow can be included in it.

What pitfalls to avoid

Knowing what MVP is for, and understanding its purpose, and importance you should consider how to make it suitable for your company and product. When building an MVP, teams tend to forget what are they doing it for and focus on the incorrect priorities. It is crucial to remember what the goal is and plan work to reach that goal with the least amount of resources, costs, and time. Creating a good MVP is all about prioritization.

If you decide to build an MVP that is a simplified version of your end product, you have to think carefully when choosing what are the basic features, what hypothesis you want to test, and what functionalities you need to implement to achieve it. I often see companies implementing too many unnecessary features, it generates costs, slows down the process, and data gathered from users are not telling you anything about crucial features you wanted to test.

Teams often forget that an MVP is for gathering information that enables the creation of a useful and highly sellable product. Building a minimum viable product is an iterative process of gathering feedback, learning from it, and updating the product. If you don’t listen to end-users, you’re guessing instead of using the precious data they give you. When you decide to build an MVP, you acknowledge that you’re no longer an expert for the product, but your customers are.

Another common mistake is not updating the MVP. In this scenario, the team creates only one version of MVP, gatherers data, and regardless of what the results were starts working on the end product. It means they are not using the full potential of an MVP and test only one hypothesis when they could have tested many with marginal additional costs.

How much does it cost to build an MVP

Well, that is an important question, isn’t it? Unfortunately, the true answer is: it depends. If you’d ask me for a price range I’d say it’s few thousand to a few hundred thousand Euros. But let’s take a look at what can influence the price.

Form of your MVP – the price will be completely different if you decide on a clickable prototype than if you create a mobile application (even a simple one). There are less costly solutions like low-code and no-code development techniques, but if you want to use the MVP as a base for further development it might be worth considering pricy options like mobile development.

Minimum feature set – the price of your MVP can vary depending on what features you select as most crucial. The number of features is one thing but it’s also important if they are commonly met development problems or require research and POC (Proof of Concept) first.

Desired quality – small details like leaders, tooltips, response time, and app fluency have a major impact on user experience but they have also an enormous influence on application costs. My advice is to aim for functional, simple but not frustrating at the beginning, it allows you to test features instead of users’ patience.

The scale of the product – development technique and architecture decisions strongly depend on the predicted scale of the product. I always advise not to optimize before it’s necessary because optimization is a black hole for development time and your money. It’s best to plan the target user group size and develop an MVP suitable for that number of users, not less not more.

If you wonder how much it will cost for your product, I suggest you contact a software development company that offers solutions for startups and present them with your idea. I’m sure they will help you make the right choices and will prepare an individual estimate.

Another thing worth considering is the pricing model. The most common ones are Fixed Price, where you pay upfront for a well-specified end product, and T&M (Time and Materials), where you pay as you go for development time. In my opinion, when creating an MVP only T&M is possible, as the whole idea of MVP is that it is supposed to evolve and change, so how can we put a price on it at the beginning?

How long does it take to build an MVP

Unfortunately, I can only give you a wide range of a few days to even more than a year and send you back to the above paragraph about what influences the cost. The very same things have an impact on the timeline.

MVP development process explained

You already understand what MVP is, what purpose is it serving and how much can it cost, let’s now take a tour through the process of building a minimum viable product. I will focus on MVP defined as a simplified software application, as the most commonly build MVP type, but at least half of the below steps apply also for any other MVP type.

Problem identification

The most important role of MVP is research, and what would research be without a hypothesis to check? That is why the very first thing you need to define is a problem you’re trying to solve with your product.

Business objectives

Product is always a part of some business, and it must be aligned with the company’s strategic goals. Well-defined business objectives give you guidance through the whole development process, so don’t neglect this part of defining your product.

Market analysis

This is where the discovery phase of your project begins. The more data you gather before starting the development, the less you will pay for the product because you will be able to avoid a lot of back and forth with the features. You can think of creating a product as building a house. Would you start building without a project? I doubt you would because it’s obvious that moving walls on paper is way cheaper than moving them after building. With an IT project, it is similar, only a little bit harder because you’re not building it only for yourself but for thousands of users.

The first part of your business analysis should be defining the target group. It will help you define the problems to solve, but also the expected scale of your application. Try to define who is your audience, and what type of users you expect. For example, a dating app for vegans has a different target group than a logistics system for large companies.

Think of your users’ needs and how your product will be fulfilling them. Consider also which user group is most important for you and will generate you most profit. Customer research helps you create a better-suited MVP that results in a better selling product, and this is what you are doing it all for.

A great tool to understand your potential users is user personas. It’s a popular way of describing customers that includes demographics, typical problems, and characteristical features.

Another important aspect you should not forget about is competition research. Are there any similar products on the market? What are they doing best and what could be improved? Why should customers use your product instead of theirs? Answering that question will help you define the most important features of your product and also determine marketing strategies in the future.

Additionally, you might consider a go-to-market strategy for your product. It might seem too soon to plan it but is worth defining the customer groups, market goals, and distribution channels. Planning a budget for marketing, how you’ll get to the clients, and what can you use to promote the product are essential for its success.

Product concept

After you’ve gathered information about the market, potential users, and competitors it’s time to create an app concept. At this stage, it should be a high-level overview of what the app will do, what purpose it will serve, and what problems will solve. There is no need to dive into details right now, we’ll get to that in a moment.

Useful might be also defining KPIs (Key Performance Indicators). Try writing down how will you evaluate if the app is successful, it should be aligned with the business goals you’ve defined before and will be a great help to you in future decisions.

Road-map planning

After understanding what you want to build it is time to plan how to build it. The first step should be defining long-term goals for the product. It is important to determine if there are any especially important dates for your product, for example, if you’re creating a trip planning application you don’t want to test it in winter. Try creating a step-by-step plan with orientation dates for all the next steps your product needs in the building process.

A great tool that will help you determine what you want to achieve is a prioritization matrix. It’s a visual representation of your product’s goals and most important features.

A document that you might consider creating at this stage is SRS (Software Requirements Specification). Of course, it won’t be definite and might change as you learn more about your users, but it’s a great way to organize all information about your product. You can read more about SRS in this article.

Once you know the priorities, you need to define MVP functionalities. First, think what is the hypothesis you want to test, then consider what tools will best fit for testing them and what features you need to have implemented. It will give you an overview of the minimum viable product you want to build.

Requirements gathering

At this point, you need to dive into details and specify as many requirements as possible. The best requirement is measurable, concrete, and has an explanation. You can divide requirements by the part of the product they influence. First, consider and document the design and functional requirements. Then focus on non-functional like performance, security, compliance, and integrations.

Don’t rush through this process, the more you think it through the better your app will be. You might use some design thinking methods, organize workshops and brainstorming sessions with your team or even consider the help of a professional business analyst.

Proof of Concept

This is not a required step and many products might not even need it. Proof of Concept is a tool to test if your idea is technically possible to build, so might be crucial if your project is very original and requires some out-of-the-box solutions. On the other hand, if you know the product you create can use well-known tools doing a proof of concept might be a waste of resources.

MVP project planning

In some cases, a simple landing page will be enough to test your hypothesis while in others you will need to build quite a complex application. Depending on your needs next steps can go very differently.

If you decide to create only a landing page, maybe a low-code solution like WordPress will be the best choice. It is fast and relatively cheap, so you should be able to create an MVP within a few days.

Another fast and not expensive solution is to create a clickable prototype. It is probably the best option for testing users’ flows and behaviours but requires you to have a focus group ready to test your idea on a prototype.

A more complicated solution, that also costs more and takes longer is to build a simplified application. It comes with a cost but gives you much flexibility, allows testing different hypotheses with one tool, and is closest to the actual product.

Regardless of what you choose, a key part of planning an MVP is defining its scope. Having in mind the goal of your minimum viable product and knowing what data you want to collect, you have to precisely define what should be created.

It is also important to plan the deliverables and timeline for building an MVP. You should consult with the contractor that will do the job and they have a better understanding of the paste of work and the complexity of specific features.

Same as when planning any other investment, you must not forget about defining the budget. If you know the budget it is possible how to wisely use it. When you hire an experienced contractor they will help you plan the scope of the project to achieve the MVP goal and not extend the budget. Remember that in most situations it is easier to change the scope than find additional finances.

The last two things to figure out before starting the implementation are project management and risk management methodologies.

MVP development

At least, the time has come, to create a product! I would recommend starting with wireframes and a customer journey map. In the next step, you can add colours to it and create a full UX/UI design. Once you have that ready and you’re satisfied with how everything looks, make it a clickable prototype. It will help you test if everything is well thought-through if there are no gaps in the flow, missing screens, or buttons. You can also release it to the first testing groups and start gathering feedback already at this stage.

For the actual application building, the developers step in. There are few models of cooperation with developers and I’m sure a project manager can help you choose the best-suited option for your product, but let me explain shortly the most popular solutions.

The waterfall is the most popular product-building model for non-IT products. If you would be creating a new chair model after having a design you would build the whole chair and give it a test, not a leg first. Unfortunately for most IT projects, it isn’t the best choice because building an application has a bit different rules than building a chair. First of all, it is a lot more expensive. Second, it can be tested in parts, you don’t need the whole product to check it.

Agile is a methodology created for IT projects. It is all about adapting to the changing requirements and market situation. In my opinion, it is a much better choice for most IT projects. If your developers’ team decided to use Agile they will deliver work in short iterations (every week or a couple of weeks) and you can start testing it right away. It is a great opportunity to go back to the product requirements and start validating them. You can invite a small testing group of your company employees, maybe family or friends, and already start modifying your product based on the gathered feedback.

From the technical point of view, there are a few things you need to understand about building an application (web, mobile, or desktop). There are two main parts of your project frontend and backend. The front-end is what your users will see, the UI of your application. There is only some simple logic in it, for example, if I click this button I will be redirected to that page. The backend contains the more complicated logic elements, it makes operations on your database, and all integrations with external systems are coded on the backend. The main reason we need to divide the code is the security. Frontend code is available for all users as it runs on their devices, backend is much more secure as it runs on the servers and users can’t access it.

As you see, your development team requires to have knowledge in both front-end and backend, but there are a few more areas of expertise you need to think about. Code is only letters and numbers, so you will need some tool to run the code and actually create an application, that is what Dev-Ops engineers take care of. Another thing is tests, before releasing the application to a broad audience you need to be sure it won’t crash if someone clicks the wrong button. QA engineer is a person that can perform manual tests on the application but also write automated tests to make sure it always works as expected.

Launch

As said before, the development can take weeks, months, or even years, but at some point, your MVP is ready to launch. It is always an exciting moment that everyone waits for, but it is not the end of the journey. Now the full focus should be on data gathering, and evaluation of the ideas, user flows, and functionalities.

The most important outcome of the MVP launch is the direction of changes. Depending on how much data you gathered and what was the feedback there are a few possible scenarios. If the feedback was very negative, you can throw the idea away and start over with a new one, it is the pessimistic scenario. If there is a lot to fix but you see a light of hope, that someone will your product, it’s best to modify the MVP and do another iteration of tests. And finally the optimistic scenario, your MVP was a great success, so you can rebuild it into a full-fledged product.

Further development

Even if the feedback was very positive there is always some place for improvements. Validate the ideas, redefine user stories and then proceed with the development.

Summary

To build a useful MVP you will face a ton of hard choices, but I’m sure with the right attitude, knowing what mistakes to avoid, and understanding what is the goal you’ll manage to succeed. I can only wish you good luck now!

If you need support, you can always contact me to discuss your app idea.