Our shared need for precision, fair play, and heightened tension during matches shapes a willingness to incorporate new sports technologies.
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 validated learning to start a large investment? A journey from business ideas to a successful product is long, bumpy and dangerous, but don’t worry, there are some practices that help minimise the risk.
Let me tell you about one of them, Minimum Viable Product (MVP).
MVP is a way to verify assumptions and collect maximum amount of useful feedback, also called validated learning, about potential customers, and test the demand for a new product with a minimum effort and investment.
The term “Minimum Viable Product” was first used by Frank Robinson and then popularised 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 or even fashionable phrase, MVP is often misinterpreted. Usually, I hear people mean “the first version of a product” when they use the term “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 with real users in a given context.
A great example of a project that was not “the first version of a product” and fulfilled the goal of MVP product perfectly 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 was needed in the target market and if anyone would use it. Least effort, maximum validated learning – that’s what an MVP is about!
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:
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.
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 potential users and already start building a user base.
In this type of MVP, you start by providing services manually instead of having a digital product. This allows you to build your customer base and understand your audience. Having this information, you can adjust your concept and redefine your MVP business. Good example of a concierge MVP is Airbnb.
To quickly validate their idea, the founders of Airbnb took a simple approach. They created a basic website and listed their own living room as the first available space for rent. Without any complex backend systems, they personally responded to booking requests. This minimal setup allowed them to confirm the significant market potential of Airbnb.
A Wizard of Oz MVP is like a concierge MVP where everything seems to work smoothly from the outside, but in reality, it’s all done by humans behind the scenes. The difference is that users don’t know about any human involvement.
A famous example of this kind of MVP is Amazon. When Jeff Bezos started Amazon, his goal was to create the biggest bookstore in the world. So whenever someone ordered a book on the Amazon website, Bezos himself would buy the book and personally send it to the customer. It gave the impression of a fully automated service, even though Bezos was handling everything manually. This helped Amazon test the market demand and lay the foundation for its eventual success.
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 or a landing page, but you can already test user flows and feature ideas, not only the general interest in your product.
Another 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 reward the testers’ effort in a different way.
This is the most common interpretation of the term MVP. And I must admit it definitely gives you the most profit in terms of validated learning, 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 MVP 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.
The primary goal of creating an MVP is testing the product idea and collecting the maximum amount of 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 minimise the time required to test the business assumptions, lower the risk and mitigate the costs of development.
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.
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.
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 finalised 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.
Building a complex product requires several steps, MVP, MLP, and MMP are helping you organise 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:
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.
A project that exceeded the budget or went on for much longer than expected is nothing uncommon in the IT world. The risk while 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 market validation is for their digital products, 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 also has other advantages.
The absolutely most important thing that building a Minimum Viable Product gives you is decreased risk. Without a huge investment, there is no huge risk. MVP development technique, the 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 while working on your minimum feature set. 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. The 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.
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 recognisable faster than your potential competitors.
An MVP and the data collected with it are also of 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 monetisation flow can be included in it.
Knowing what MVP is for and understanding its purpose and importance, you should consider how to make it suitable for your company and product. While building an MVP, teams tend to forget what they are 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 prioritisation.
If you decide to build an MVP that is a simplified version of your end product, you have to think carefully while choosing what the basic features are, what hypothesis you want to test, and what functionalities you need to implement in order to achieve it. I often see companies implementing too many unnecessary features; it generates costs, slows down the process, and data gathered from users may not be 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 saleable 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, gathers data, and, regardless of what the results are, starts working on the end product. It means they are not using the full potential of an MVP and testing only one hypothesis when they could have tested many with marginal additional costs.
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.
Estimating the cost of your Minimum Viable Product (MVP) involves considering several factors. First, the form of your MVP, whether it’s a clickable prototype or a mobile app, will greatly impact the price. 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.
The price of your MVP can vary depending on what core features you choose, and how complex they are. 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.
To effectively test your MVP’s core features, prioritise functionality over intricate details in the initial stages. My advice is to aim for functional and simple but not frustrating features at the beginning as it allows you to test them instead of users’ patience.
Additionally, consider the scale of your product and avoid early optimisation, as it can consume excessive development time and resources. It’s best to plan the target user group size and develop an MVP suitable for that number of users, not less not more.
Another aspect to take into account is the billing model. The two most popular options are Fixed Price, where you pay an upfront cost for a clearly defined final product, and T&M (Time and Materials), where you pay as you go for the development time. I always recommend going for Time and Materials (T&M) for MVPs due to their evolving nature. 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?
If you’re unsure about the cost of 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.
Moreover, to better understand the factors that influence the cost of an MVP, I recommend reading my article. It provides detailed explanations and uses app examples like Uber-like MVP Development to illustrate how different factors can impact the price of 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.
The entire development process involves many steps, but in this article, I won’t explain all those in detail. For more information on how a piece of software is being built, I recommend you to check my other article. However, if you’re making an MVP understood as a simplified version of an app), you should do some things differently. You can learn more about that different approach in my article on how to build an MVP. Here, I’ll just give a few ideas on how that approach can differ from building full-featured software.
When adopting the MVP development approach, the key focus is on prioritising essential features while removing unnecessary elements. Using MVP approach you opt for functionality over complexity, recognising that an app doesn’t require an overload of features from the outset. In fact, less can often mean more.
What matters in Minimum Viable Product development is uniqueness. It involves tackling user issues more effectively than your competitors. Beyond understanding user struggles and desires through research, you need to analyse competitors’ strengths and weaknesses. This enables identifying gaps in the market and capitalizing on them with innovative solutions that present a core value proposition.
While the MVP approach may not focus heavily on aesthetics (unless it’s a distinguishing feature of the app), User Experience (UX) remains crucial. The app’s ease of use and user-friendliness determine its success. Although aesthetics take a backseat to functionality, ensuring smooth interaction and a visually engaging interface is essential. Dedicating substantial resources to design can strain your budgets, so it’s better to maintain an optimal balance for your MVP development efficiency.
Throughout MVP development, making informed compromises is key. For example, instead of launching a final product across various platforms simultaneously, concentrate on one platform initially. It allows you to allocate your resources efficiently for a refined user experience. Although the app might not be equally polished across all platforms at the outset, the primary focus is capturing the loyalty of the core target audience. You achieve gradual expansion without compromising quality.
After the MVP launch, it’s essential to embrace user feedback and be open to changes. Iterative development based on user input is essential to success! Ultimately, MVP development requires flexibility, open-mindedness, and a keen understanding of user needs and preferences. It’s a journey of consistent refinement and adaptation, ensuring that the product evolves in line with market demands and user feedback.
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 the goal is, you’ll manage to succeed. I can only wish you good luck now!
If you need support, you can always contact me on Linkedin to discuss your app idea.