Prototyping and MVP
Hi! My name is Mikhail. I am an IT evangelist with 15 years of experience in the IT industry: I started as a C# developer and am now an experienced project manager and product manager. I am writing a book about IT project management, but it is quite difficult to do without feedback. So I decided to publish here some chapters from the book I am working on to receive feedback and constructive criticism. Thank you for reading me – your attention and interest give me the strength to continue.
We have all encountered the concept of a prototype in one way or another. Many IT specialists have also heard of the term MVP, and some have even used it directly. Today we will talk about these concepts, their historical predecessors and the pitfalls that can await those who decide to apply these concepts in their work.
Historical roots
In ancient Rome, the concept of prototyping or minimum necessary solutions was used in military and engineering activities. The Romans often built fortifications first, such as temporary camps (castra), which could be erected quickly to protect an army on the march. These camps were far from perfect, but they were functional enough to provide the minimum necessary conditions for the protection and maintenance of an army. Over time, if the site became permanent, the camp could be rebuilt or improved.
In ancient Greece, MVPs and prototypes were used in the construction of temples and public buildings. Many Greek buildings, such as the Parthenon, were initially built with basic structures to meet basic religious and social needs. If these structures functioned successfully and met the needs of society, they could be expanded or embellished. This process of evolution in architecture from simple to more complex was common for the Greeks, allowing them to adapt to social changes and new opportunities.
Many Russian cities began their history as small settlements, which were often located on hills, along rivers or near trade routes. The main requirement for such settlements was the ability to protect their inhabitants from enemies and provide the minimum necessary conditions for life. Initial fortifications were built of wood, as it was an accessible and easily processed material. Earthen embankments and ditches were often created around wooden walls, which served as additional protection from enemies. This was a simple and effective way to increase the defensive capacity of a settlement. As cities grew and their population increased, and in response to increasing external threats, wooden fortifications were often replaced by stone ones. Stone was a more durable material that provided better protection and increased the service life of the walls, but its use was expensive and required the presence of skilled artisans (they were often invited from other cities). In later stages of development, especially in the face of constant military threats, cities continued to fortify themselves by creating castles and citadels. These structures were the most protected parts of the city and served as the last line of defense in case of attack. They were built in the most strategic places of the city, often on high ground or in the center, and included the most important buildings, such as the residences of the rulers, barracks, warehouses and temples.
Psychological contradictions
The approach of prototyping and creating minimal viable solution options has been used throughout history by all peoples in various fields, from architecture to politics. It seems quite natural and obvious. However, social development was taking place in parallel with the technological development of society. Monotheistic religions were spreading. Religion has had a deep penetration into the consciousness of peoples throughout history and often determined their way of thinking, behavior, and culture. However, monotheistic religions, being largely dogmatic, clearly define the requirements for the believer, the ceremony, and the church, without allowing compromise. Thus, a person found himself in a situation of psychological contradiction: on the one hand, prototyping was approved and supported in many spheres of life, on the other hand, it was rejected in the spiritual sphere. And although people could often consciously share these approaches in different aspects of life, we still feel the consequences of this contradiction subconsciously, having carried through history an ambiguous attitude towards prototypes through education and culture. On the one hand, a prototype is a logical and obvious approach, on the other hand, it is an unworthy half-measure.
Classical definitions
A prototype is an initial, often incomplete version of a product created to visualize, test, and evaluate a concept or idea. Prototypes allow you to test hypotheses about the design and functionality of a product before full development begins.
Main characteristics of the Prototype:
Incomplete functionality: The prototype may not contain all the features and may not be fully functional; its main purpose is to demonstrate the concept.
Focus on design and interface: A prototype is often used to visualize the appearance of a product and test its usability.
Concept testing: Prototypes allow you to test ideas in practice, identify problems and get early feedback.
Rapid creation: Prototypes are created quickly and cost-effectively, allowing you to quickly test different approaches and ideas.
Pre-production: A prototype is a rough version of a product that may differ significantly from the final version after iterations and refinements.
MVP (Minimum Viable Product) is the first version of a product that has the minimum functionality necessary to solve the user's key problem and receive feedback. MVP allows you to test hypotheses about the product with minimal costs and risks before investing in further development.
Main characteristics of MVP:
Minimum required functionality: Contains only the basic functions necessary to solve the main problem of users.
Working Product: The MVP is functional and ready for use by end users.
Fast Launch to Market: Build and launch your MVP in minimal time to get your product in front of users as soon as possible.
Gathering Feedback: The main goal of an MVP is to get feedback from real users to determine the direction in which to develop the product further.
Minimal Cost: MVP is created with minimal investment of time and resources to reduce risks and avoid unnecessary expenses.
The difference between an MVP and a prototype
It is easy to see that MVP is a special case of a prototype. Both concepts are a “test run” in the process of creating a product. However, the MVP concept requires the mandatory launch of the product on the market (to end users) in order to obtain feedback and information about the created user value. This should be a public (available to users, albeit for a limited time) version of the product, containing the full key functionality of the first version. The prototype does not have to be public and can be limited to only one or several functional areas of the future solution.
Let's say we are building a cottage. Then a house with walls and a roof, connected infrastructure, the cheapest stove, toilet, shower and a mattress on the floor is an MVP. A diagram of the future cottage on the website or just a house with walls is a prototype.
Problems with prototypes and MVPs
In addition to the psychological contradiction discussed above, I can highlight two important problems associated with the development of prototypes and MVPs.
The first problem that I increasingly observe in IT development projects is defining the boundaries of an MVP or prototype upon completion of the work. The concepts of MVP and prototype involve planning and defining the boundaries of the product version in advance. The requirements for functionality must be drawn up in advance, and all (!) of these requirements must be implemented. However, at the planning stage, the team or management may have planned a certain version of the product, but during the development process, problems arise (technological, time, resource), the functionality begins to be cut, the profile of the target audience narrows, the number of supported versions of operating systems decreases, and so on. The resulting product is called an MVP and is declared as such in various reports and presentations. As one of my colleagues from a large company included in the TOP-10 companies in Russia says, “We call any resulting crap an MVP.” I urge you to stick to the original concept and not use these terms as an excuse for not completing previously planned work. Deviation from the concept entails significant risks in conducting a quantitative analysis of potential benefits from the product being developed (for example, for A/B testing), loss of the core value of the solution being developed, and misunderstandings between various project participants. The manager's literacy, experience, and wisdom in such cases should allow him to record losses associated with the failure to complete previously planned work and initiate either a revision of the work plan (add time or money resources to the project), or an official stoppage of work with a subsequent revision of the full set of tasks, since the vision and concept of the product itself have changed in the process of work.
The second problem I can formulate as a high level of basic requirements for the product. The IT industry is developing more and more actively, new products and solutions appear. Their quality is constantly improving. If 10 years ago you could afford to release an MVP of a dating application with a simple interface, only a web version and selection filters by three attributes, now launching such an MVP would be simply pointless. The end user has already gotten used to the high quality of similar applications, to ergonomic and feature-rich solutions. Any attempt to offer such a user a “cut” version of the product will not arouse his interest, will reduce interest in development and will negatively affect further marketing – the product will be perceived by the market in advance as inferior to competitors. Of course, if you create a solution in a “Blue Ocean” situation, then these problems can be avoided. But, let's be honest, there are not many such IT projects in the general mass. It is also worth remembering that with the development of the IT industry, the number of regulatory and legislative acts that are mandatory for full implementation is growing. Thus, when developing a public prototype of a solution or MVP, you are required to immediately implement full authorization functionality (if, of course, authorization is provided), observing the requirements of Federal Law 152. You do not have the right to implement these requirements partially. Thus, the complexity, composition and content of MVPs increase every year (which is quite natural). In my opinion, in the future, this may lead to the abandonment of the MVP concept in favor of prototypes launched on the basis of laboratories or within the framework of limited closed beta tests.
Conclusion
The concepts of prototyping and MVP are proven approaches to creating complex solutions, the development of which is advisable to be carried out in several stages. It is important to remember that the boundaries and goals of prototypes should be strictly defined before the start of implementation and remain unchanged during the process. Creating an MVP may not be advisable in some markets or in certain industries, since the prototype will obviously be uncompetitive.
