MVP: How minimal does it need to be to validate my idea in the market?

Cristian Sanchez

May 24, 2022

14 Minutes

MVP

The previous steps to the MVP

‍

Let's start with a strong statement: you don't need to spend months developing an MVP to validate an idea. Let's see...

‍

How many times has an idea unexpectedly popped into our heads that excites us and we believe has enormous potential? Is it really necessary to spend months working to verify whether the idea is attractive or feasible?

‍

The answer, as in many other aspects of life, is DEPENDE.

‍

It is probably a resounding NO if what we want to validate is the interest or desirability of our idea. We can understand this in many ways, some faster and others a little more complex, but all of them will give us results in less than a month. Some techniques we can use to achieve this objective are:

‍

  • Tutorial videos demonstrating and explaining the idea
  • Slide presentation on the idea
  • Implementation of landing page with waiting list
  • Conduct user interviews
  • To elaborate a high fidelity prototype (from mockups).
  • Low fidelity prototypes (paper)
  • Distribute a survey
  • Writing an article for blogs and forums
  • Advertising campaigns
  • Social media
  • Experiments (A/B testing for example)

‍

Not all of these techniques are true representations of the idea, so some will give us more reliable results for drawing conclusions while others less so. But regardless of the greater or lesser risk, these techniques serve their purpose of validating desirability.

‍

On the other hand, if we want to validate the feasibility of an idea (i.e. whether we can implement it with current technology and our resources) we again do NOT need to spend hundreds of hours on this. Instead of trying to implement a whole new product, we can do a proof of concept (POC). For example, if we want to create an app that automatically synchronises all the notes we take on different platforms, we can try an integration with one of these platforms to validate if it is possible to do so.

‍

The same applies if we want to analyse the financial viability of the idea. We can conduct a small experiment to see if people would be willing to pay for or sell a future competitor's product to see if a profitable business can be built in the long run.

‍

To a greater or lesser degree of certainty, validating the desirability, feasibility or viability of an idea is something we can do in days. So why do many companies and entrepreneurs spend months developing an MVP?

‍

Well, an MVP not only serves the purpose of validating the dimensions mentioned above, an MVP not only serves the purpose of validating the dimensions just mentioned, but also seeks to validate our very value proposition. The MVP is a real product. In its minimal expression, yes, but it is still something that can be used and bought. And this does take a little more time.

‍

‍

That said, we have three popular tools to help us validate different aspects of an idea:

  • Prototype, to validate desirability
  • POC, to validate its feasibility (and viability)
  • MVP, to validate your business potential

‍

While there are many currents that consider landing page launches, video tutorials or interviews as MVPs, I personally believe that including these strategies within the concept is more confusing than helpful.. An MVP, like a prototype, can be low, medium or high fidelity depending on how closely it represents a real product. There are MVPs that are very short on functionality and others that are a bit more complete, just as there are paper prototypes and others that are mirrors of real apps. So, to avoid confusion, let's refer to an MVP as something that can be used and for which users will pay.

‍

In the following, we will go through each instance of validation, mentioning its characteristics and delivery deadlines.

Prototyping: validating the desirability of your idea

‍

A prototype is a representation of your product, in the sense that your potential users can interact with it to get an idea of how the final product will work.

‍

Prototypes are intended to give the user a more genuine and realistic contact with the idea, in order to provide a more accurate opinion about it.and thus provide a more accurate opinion of the idea. A prototype is usually a façade: they are devoid of functionality and logic, so they are considered more as interactive concepts.

‍

In software products software productsIn software products, prototypes are usually built from screens that emulate the visual aspect of the solution one wants to develop. These screens can be designed using programmes such as Adobe XD and Figma, and can then be made interactive. In other words, the screens are connected to each other.

‍

For example, you can set it so that pressing a certain button takes you to a certain screen, and pressing another button takes you back to the home screen.

‍

This combination of high-fidelity displays plus interactivity is essential to build a representation as faithful as possible to your idea and thus validate its desirability with the highest possible degree of certainty.

‍

‍

Important: it is not necessary to design absolutely all the screens of our product. At the beginning we are interested in validating the user's desirability and interest in their main task flow. If we stay focused, designing the screens, prototyping them, and scheduling usability tests to expose the prototype to user feedback is a process that should take no more than two weeks.

‍

Of course, if we decide to carry out a UX Research process before the interface design to understand the problem to be solved and thus design with a more solid base, we should consider a few more weeks. But even with UX Research, this validation process should not take more than a month. Some experts even resolve it in a week, in what is known as a Design Sprint.

‍

A prototype is not an MVP, but it allows us, with some confidence, to validate interest in our idea in a very short time and with as little effort as possible.

‍

POC: validating the feasibility and viability of your idea

‍

Proof of concept, or proof of concept (POC), has the purpose of validating the feasibility of our idea. Essentially, it is possible to carry out what we have in mind. Let's think about a scenario where we could carry out a POC:

‍

Suppose we want to develop a travel app whose main functionality is to mark the countries you have visited on a map. When you mark a country, a tab opens where you can add details and photos of your experience in that country.

‍

The whole app would be meaningless if it is not possible to perform this action of marking countries in the interface. So it is necessary to perform a POC to verify if there is an integration with Google Maps or any other map provider that allows us to mark countries and colour their surface when tapping within their boundaries. It is not necessary for the POC to work with absolutely all the countries; if it already works in just one, it is enough to be confident that we will not have problems replicating the functionality with the other countries.

‍

So the aim of the proof of concept is to understand whether our idea has a practical potential and can be realised. These are small tests to analyse feasibility and to determine whether the idea is a fantasy or not.

‍

‍

As a prototype, the POC should not take more than a couple of weeks.

‍

However, a POC, unlike prototypes created from platforms such as Figma, can take various forms depending on what it is that you want to demonstrate.

‍

This reduced predictability means that the POC, while intended to be a quick test, may warrant additional weeks of development if the nature of the idea is complex or the industry is highly regulated. This sometimes makes accessing a database or performing an integration a difficult task.

‍

Finally, it is important to understand what we are validating within the POC, as it can serve multiple purposes such as:

  • Understanding whether there is an enabling technology for our idea
  • Discovering problems, risks and technical constraints
  • To highlight areas of opportunity and possible improvements
  • Understand whether we have the resources (financial, human and time) to carry out the project.
  • Estimate whether the project can be profitable in the long term (economic feasibility analysis).

‍

MVP: validating the business model and value proposition of your product

‍

An MVP is born with the purpose of validating the value proposition of your product in the market.. To learn about how your product will be used, to know if it works for its users, if it solves a need and if your business model has scalability potential. To get to this stage, we know that the effort required will be greater than that of a prototype or POC.

‍

Conventional wisdom indicates that an MVP should not exceed 3-4 months of development. These months are usually instantiated in three phases: functional analysis, development and QA. In the first phase, the technical requirements are gathered, which may be written in the form of a user storyIn the first phase, acceptance criteria are defined, dependencies and priorities are established and business rules and functional descriptions are detailed so that each task can be designed and developed with precision. In parallel, the UX area defines user flows, information architecture, navigability and system design, while development progresses with the design of databases and APIs.

‍

The second phase is a parallel design and development effort to create the interfaces and implement them in the system. The third phase is QA testing, where testing is done to verify that there are no bugs or flaws in the use of the product. This phase is sometimes left at the end of the process, but sometimes happens in parallel or at the end of a certain workflow.

‍

Because of the above, it is difficult to conceive an MVP in less than a month. I'm not saying it's impossible, but in most cases it usually takes a couple of months at least. Perhaps a serial entrepreneur who has already launched several MVPs, has notions of design and development and skips some phases of the traditional process could manage to achieve it in that timeframe. But there are not many such cases.

‍

‍

In reality, the duration of the MVP can depend on many factors. For example, one of them is the nature of the product. There are industries that are highly regulated and require multiple supplier integrations to deliver a core product. This is the case for many fintechAs such, setting up all the necessary infrastructure and complying with the rules of the various regulatory bodies can simply take up to 9 months to complete the development process.

‍

In fact, an MVP can sometimes become long enough to justify small releases (or technical cuts) within the development process.

‍

On the other hand, more team members tend to accelerate the development process to a certain point, where adding more people is no longer productive and overlapping of tasks starts to occur.

‍

Other variables that impact on MVP development times include:

  • Level of knowledge of the team about the technology used
  • Time availability of the team
  • The technology itself (development with code or through no-code/low-code platforms)
  • Type of MVP (single feature, wizard of oz, concierge, etc.)
  • Modularisation of components
  • Methodology of work (waterfall development vs processes agile)

‍

But again, with all the variables taken into account, in most cases an MVP should not take more than 3-4 months. And I agree with these timelines.

‍

In case the original estimates give a timeframe longer than that, then the variables mentioned above can be worked on to accelerate the launch. You can also review the priorities of the functionalities included in the MVP, to see if there is anything you can do without without sacrificing the objective of the MVP.

‍

The idea behind everything is to launch as soon as we can in a way that makes sense to the user and is in keeping with the context.


In summary, it is clear that each instance of validation has its own complexity. Validating the design and desirability of an idea or its technical feasibility is something that can be resolved in days or a few weeks. It is not necessary to elaborate an MVP to test whether the idea arouses interest or has the potential to become a lucrative business. But when we want to take our first step into the market, and validate our product along with its value proposition and business model, we will need something that can be operated... something that users can buy and use. And this requires a major effort, which while it should not be more than 4 months, in most cases it is something that can easily take more than a month.

‍

2022 Β© Novolabs