The idea of a Minimum Viable Product is to develop a product or service offering that has the minimum viable features to bring a product to market so that it can start generating revenue or catch the interest of some investors. If successful, then this product can be further enhanced to include all the bells and whistles it requires. Most of the time you don’t necessarily require a functional product yet and only need to sell the idea to investors to acquire more funding to turn it into an functional MVP.

Depending on your budget and the complexity of your request, there are certain paths/approaches one can take to get to a functional working product or service. It is all going to come down to what you need and want, based on that, one can only determine what processes to include.

There are two possible outcomes one can explore:

The easier approach, the most common: Your idea might already be very possible with a high probability that available ‘tools’ and ‘libraries’ already exist to develop your first product or service offering. This involves combining existing software components and extensions to develop a working solution.

• Interative Mockup (optional).
• Minimal Viable Product.

The more complex approach: If your request is more complex in nature, it will require some exploring via a series of processes to get to a working minimum viable product/solution. Usually these requests are for features or services not yet available in the market and would require some planning, custom development of tools, api’s and features.

The complex route requires more processes to follow, but again not all is required if existing proof of concepts exist, for example.

• POC: Proof of Conceipt.
• Prototype or Interative Mockup(optional).
• Minimal Viable Product.

This process to make sure that all the functionality will be delivered on. It is to guarantee a working and successful product. It is to minimize the risk so that you don’t get a surprise at the end of the project, ‘but that one requested feature is not possible“.

For example, It might involve writing code to test functionality against API’s. Mostly API’s with no or limited documentation. Writing code to build features or functionality that does not exist yet. It is that unknown components that form part of a prototype.

A regular mockup can show you what the UI will look like. It’s a good way to start envisioning what the product will look like. But it’s limited. A step up from a mockup is an interactive mockup. There’s no functionality here, you can’t sign up, you can’t buy a product, you can’t send a form. But what you can do is test the flow of the website or app.

The interactive mockup can be the best way to get the idea out without the production costs of actually making the thing. This is great for showing investors.

For example, with an interactive mockup, you can click buttons and menus to walk through your product. You can click a callout button, that takes you to a submit page that takes you to a success page.

Always consider whether starting with an interactive mockup is right for your business venture.

Where the mockup is about the UX, the prototype is about the functionality. The best thing about the prototype is it allows you to prove the concept from a code angle. It’s like the first draft of a book, you would never publish it, it’s more about getting the idea down.

A prototype doesn’t concern itself with best practices, with security or even bugs because it will never reach the publish. These things push up the price of production. It also only concerns itself with only the vital components, only that which is core and vital to the product. It has this in common with the MPV.

A prototype can be done before or after a mockup, or without one.

The minimal viable product is designed to go public. What differs it from regular development is it’s minimalist in its approach. It picks out only that which is truly necessary for the success of the product and not with the “nice to have”. All those “great ideas” of “wouldn’t it be cool if it did x”. None of those ideas make it into an MVP, only those core features.

A minimal viable product is about proving a concept before investing heavily in it. Unlike the prototype, it’s not about proving from a code perspective, it’s about proving from a customers perspective. Does your product solve the problem as intended? Does it work?

Very often, a business will go all out in the feature set with the belief of “more is always better” but you can spread resources too thin and have lots of features that were expensive to produce that you thought would be important but when taken to market, you find out actually, nobody used.

It reduces risk by reducing the initial investment and making sure that the features you do produce are done right.

It also gives you a base on which to build and experiment. Once you’ve taken your product to market, you can do some research on your users to find out what features they want, not what you think they want. Resources can be directed to things that are actually wanted by your users and not wasted in building a product no one asked for and no one wants.