A Minimum Viable Product (MVP) can be best described as a minimal, viable (or workable) product: the most basic, standard and stripped-down version of your product or solution. The term comes from The Lean Startup method and is all about getting an answer to the only question that matters as a founder, entrepreneur or corporate: is there (a sufficient) need for my solution, product, app or service?
Eric Ries wrote the book The Lean Startup and as the term suggests it is all about a lean and mean version of a company. Through a lot of experimenting and working from a position of extreme uncertainty, conclusions can be drawn faster and thereby gain knowledge about markets, customers and users. Testing crucial questions such as “is there a need for my product” is also called “validating”.
Validating sounds more difficult than it is. To validate an idea, an MVP – the minimum, workable version of your idea – is needed. You must then talk to your target group. Ask them what their needs are and whether or not they would need your idea. Note that it is important not to ask overly guiding questions, but to continue to use open questions as much as possible. You should, for example, ask your target group: “Do you consider solution X?”. An example of a question that is not beneficial would be: “Since you realize that you cannot solve this problem yourself, I wondered: what would you like to pay for solution X?”
We develop an MVP in collaboration with the customer. This requires that sufficient information is available so that a product can be developed for a low price that meets the requirements for proper validation. At the same time there is room for flexibility: certain specifications, such as how the design looks, do not have to be written in stone. There is a reason why it is called an MVP: functionalities must be clear to the user, workable and ensure that validation is possible.
Thanks to quick iterations (repeated experiments) it is possible to discover after delivery of an MVP which things should or could be optimized. Once this knowledge is available, we are flexible and we optimize what could be improved. We naturally take the roadmap into account. That is the strategic plan behind the idea, which is often caught in a software system (such as Jira, the most used variant, or Teamweek and Trello).
PoC and MVP
Note that we use the term MVP in this article, but that this information also applies to a Proof of Concept (PoC) – another form of the MVP. The PoC is the first version of the intended technology that acts as proof that the solution actually works. A PoC is often used to validate a technological solution and often uses third parties (such as Firebase, Google Maps, and other SDKs (software development kits) and API) to arrive at a workable solution quickly. Although the PoC can also be presented to the target group, it is often used as a showcase, a demonstrable example for first investors and customers.
A PoC differs from an MVP in that the MVP is a marketable product, for which you like to put marketing and sales efforts. With a MVP, safety, user cases and the roadmap of technology are taken into account more often. A MVP is also generally further developed than a PoC.
The development of a MVP (or PoC) takes place in the following phases:
During intake, we discuss what needs to be developed. Whether it is an app, website or other (technical) solution: we want to know what problem is being solved with this innovation, what purpose it serves and what considerations have been made. Perhaps there has already been a(n) (exploratory) survey among (potential) users. This too is input that can be of value during the development of an app, platform or site.
The intake is about sharing the right information so that the development team can get to work with the wishes that are on the table. We also share feedback, since we have been developing technological products for years. This means that we ask you if this solution really fits the problem you are trying to solve. This is an educational process for both parties, through which we strengthen each other.
From the intake, it is possible to prepare a definition. This is where the Epics and Stories are compiled. This means that the process is made concrete through smaller definitions: what should this app be able to do? And what issues are needed to make this work?
The definition is an essential part of the process. From the design stage, it is possible to have an overview of what will be designed. This overview can only be honored by making agreements. Story Mapping is an extremely suitable tool for this.
The development of an app or site can be organized in various ways. On the one hand, it is possible to hire a dedicated team that works remotely. For example, by adding a Product Manager or Owner, work can sometimes go more smoothly. On the other hand, it is possible to bring IT talent to the Netherlands and assign them to a team.
In this earlier post, you can read more about the ways in which you can approach a development team. In any case, it is clear that outsourcing development pays off. Experience also shows that putting together a development team yourself is challenging and should better be left for experts to handle.
Worth to mention that modern technologies allow starting building an MVP without tech crew and coding. You can read more about it in our articles about How to start a tech startup without a CTO and How to start building an MVP without coding.
The launch of an MVP is a great milestone: you went from concept to the first workable version of your solution. Along with that, you have something in your hands to start a conversation with users. Although the launch can feel somewhat ‘basic’, that is also the starting point: it is a solution that offers sufficient insight into the wishes and expectations of potential customers or users.
The delivery of the MVP, the so-called launch, is done according to Sprint Demos, where the completed tasks are demonstrated and the progress measured. This, of course, also applies to the following steps.
Different development possibilities of an MVP
There are different ways to develop an MVP. Of course, we work as agile as possible, but, depending on the use case, certain shortcuts can easily be taken, such as:
- A modern agile technique: back-endless. This is a method that revolves around the use of the cloud. There is no physical back-end in which the application, platform or site is built. However, this is continuously available online – and therefore more agile. For example, the use of online real-time databases from Amazon, Azure or Google.
- Serverless is another modern Agile technology. As a user, you do not pay for unused server space, since no deployment, lifecycle management or other DevOps tasks are required. Examples include the use of Amazon Lambda.
- We use many libraries and frameworks. There are many things available that make development easier. For example, we could make an MVP app work faster with a hybrid framework.
- We look at which open-source items are already available on the internet. There are many small partial solutions available on the internet. Why reinvent the wheel?
- Finally, there is a hybrid form. This is ultimately also a scalable solution, but it is a slightly more robust and secure method. This makes it very suitable for enterprise and FinTech solutions (which deals with more strict banking legislation).
MVP development costs
Naturally, the various technical products also entail different cost items. An MVP can be developed from as little as 5000 euros – which makes the development of an idea into a startup a lot more accessible. When developing an app, an amount starting from 10,000 euros must be considered. We covered our approach to an app costs estimation in this article. With a platform or interactive web app, a sum of 15,000 – 25,000 euros is a good estimate. Moqod can also help with financing the MVP.
We have many years of experience in developing MVPs. We develop a (so-called) beta product lean & mean. This quickly shows whether a product market is fit and you already get that insight for limited budgets.