Gathering feedback on your new idea is very important to shape your product. During the development of your product, you probably encounter problems or have the need to validate a concept. By creating prototypes you can validate this yourself or even by a potential customer. But can these prototypes be used in a minimum viable product (MVP)? In this blog post, I will share the difference between a prototype and an MVP.
Before we start I want to share something about coding conventions. In my experience these are different in every organization and even within teams.
Coding conventions are a set of guidelines for a specific programming language that recommends programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers.
Prototype vs minimum viable product (MVP)
In order to know if a prototype can be used in an MVP, we need to know what it is. I have collected for both prototype and MVP an explanation from the internet.
A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming.
When starting on a new idea there are a lot of unknowns. In order to get a better understanding of certain “problems”, you can create small prototypes. This will help experiment different options to solve the problem and maybe even get some feedback from potential customers. A prototype still follows some of the coding conventions, but to speed up the process shortcuts can be taken. Because of these shortcuts I think a prototype should never be used in the final product. I even think it is best to gather the results, remove the prototype and start from scratch to implement the feature.
Minimum viable product (MVP)
A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.
From my experience, there are always enough ideas for new features. Building every feature and then releasing your product will take a lot of time and is a waste of value. The MVP development technique can help you to define the required features to get your product to the potential customer. It’s all about what is really required in order to use the product. Releasing a product means coding conventions are important to guarantee the quality of your product.
The MVP development technique can also be applied to features. Minimum viable feature (MVF).
A prototype is all about testing a concept or process. An MVP is a technique to ship your product with sufficient features to satisfy early adopters. Both have different goals and come with different coding conventions. A prototype is an experiment to get a better understanding to solve a problem and could be used as a reference for the product feature. Prototypes may never be used in a final product. What are your thoughts about this? Please leave you opinion in the comments below.
Credit featured image: Drew Hays