Minimum Viable Products and Prototypes

What is an MVP?

According to Wikipedia a Minimum Viable Product is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

Other remarkable features would be:

often less expensive than developing a product with more features
core features sufficient to deploy the product, and no more

Well, this is not being very useful. Just telling us that is basically a functional version of a product but including only the core functionalities.

It is clear that we need to think what is actually an MVP as something useful to us. It should include a limited set of features from the functional point of view. And from the technical perspective we'd need to define how to build one of them and how to provide MVPs in a production line, get feedback from users (no testers), how to analyze this feedback ans start again.

What's the purpose of an MVP? What is it made for? According to Erik Dietrich...

...the purpose of the MVP isn't to build, to create a beta version of the eventual website. Instead, the purpose of this MVP is to see whether people will take advantage of online ordering and whether it will help sales. In other words, the purpose of the MVP is to see whether it's a good investment to build the real thing.

It seems that for Erik an MVP is NOT a prototype or beta version of something but something like a probe, something sent to the deeps of the market to find out what happens if...

Well, it is something to start!

Another opinion comes from Katrine Spirina:

Before investing in a multi-functional software solution, be it an enterprise solution or a medium startup project, it's wise to try to anticipate product’s success in the market and outline the target audience.
MVPs help gauge the level of compliance of an idea with current market trends and tendencies.

I'd like to have a look on the MVP concept from different points of view: Business, Operations and Software Development, always glued to the idea of making possible the consumer engagement.

1-The Business MVP

It is clearly a part of a commercial strategy trying for instance to introduce a new way of doing things in a specific sector. The purposes for MVPs from Business perspective can be heterogeneous but usually focused on testing a new piece of presence in a given market.

The requirements are not usually clear in serious and expensive software projects and in the case of MVPs we possibly we have to play with sets of diffuse requirements that can be understood only partially. The goal here is not an exhaustive list of strict requirements but how to reach the real goals of the MVP. The Software Development team will help us with this and very likey is a good idea to work together (I know, it can be a scaring experience you can believe me when I say they have their little hearts as well).

Time to Market and speed are key factors. To take advantage of a special time period, important events that affect to a specific market and most importantly the time to react to any change from the feedback.

Collection of data and Analysis are specially important. The MVPs are usually very active in collecting all kind of information and data from traffic, requests, usage patterns, devices, prefered time of usage, gender, ranges of age, etc. Many MVPs are created only with the purpose of scanning a place in time and space in the Market to be exploited through Data Analytics operations and eventually support the decision of going beyond in the future in a specific niche of the Market or not.

So, from the Business point of view what can be our conclusions?

We know what we want to do only until a certain level. The effort to get a level of specificity is a challenge for the Business Analysis department that will make a fast creation and availability of the MVP that possibly never will reach a stable status.

The MVP is NOT necessarily the final product and many changes can come.

Time is critical. We cannot get our MVP in weeks or months. We are talking about days once the basic requirements have been agreed and, we can say, described.

Data are very important because we need some feedback, and soon as possible! Collect data and exploit the results to help your decision making process. We need to extract patterns and trends from data that helps us to make the right decisions.

Our conclusions are that MVP is not a full-scale product and it had to survive in the market and attract early adopters. The MVP will allow turning an idea into a product with an limited number of features.

It is time to go to our favorite software development vendor and start talking about our new MVP. But what about to put every new version of the MVP in the Market? What about....Operations?

The Operations MVP

In this case the MVP is a different challenge. We need to be ready to facilitate:

Normalized build processes
Normalized Quality procedures based on standard Quality indicators
A system that supports everything

Because...we cannot start arguing again about what delivery model will be applied this time, who is responsible for the pipeline, what are the execution requirements or where the hell are the infrastructural context description.

No, there is not time for that. we dramatically need a stable and fast as hell Delivery model. A serious company will build a standard, well documented, scalable Delivery Platform able to support normalized procedures by providing specific predefined settings. The parameterization, specific in every case, will make each case different enough.

Regarding IT, it is already available because our company is using successfully cloud native IT (services and IT) that is scalable, multi tenant and distributed. No more discussions about what message broker or that database we'll use.

Traditional IT (ticketing system, slow provision of IT, restrictions to developers, lack of security, no understanding software delivery processes, etc) has been removed from modern competitive software companies forever. New approaches breaking the old silos (e.g. SRE) have been implemented in these companies with outstanding results and ROI.

An agile production of MVPs needs this new approach.

The Software Development MVP

Regarding software development and according to the above mentioned sections, is quite clear that we need to consider that:

We need small, very small components. Forget macroliths, monoliths and that stuff for junior developers and software factories. Why? Because we'll need to be really, really fast to implement, test and deploy changes.

So, need to use scripts and functions as functional parts of the project instead of big binaries multilayer, because we have only some hours or a few days to deliver our functionalities and only a couple of hours to iterate the MVP. Cloud IT is already working perfectly and every test is atomic, isolated, etc. Small is better!

We need to provide a full automatic test coverage at several levels (Unit, Integration, Security, Functional). Remember that there are normalized quality procedures that will reject any not-covered piece of code.

Telemetry. The key part of any MVP. The design of the MVP contains a good part of components that only get information from users. The MVPs will be used in monitored environments that will provide contextual information while the traceability of the MVP components will send tons of data of all kinds. In this are telemetry is feedback in real time. As Nitin Lahoti asserts : When you go out with the MVP in market, you will receive customers’ feedback. Response or feedback from the target customers can save your product. Getting direct response from your customers is like getting real-time data.

Data Analysis. We need to find patterns from the telemetries to find patterns, trends and meaning. This is the key usage of data in MVP.

API Gateway. To allow this the MVPs must be built considering the usage of modern APIs and Gateways that provide what the MVP needs
1. support to telemetry (MQTT)
2. Server sent events (gRPC)
3. Security flows (OpenID, OAuth2)
4. Data Rate control, Transformation
5. Correlation
6. Multi-protocol, etc.

The iterations from every data analysis and probable changes in the MVP are also critically important. Each iteration should be done in a few hours in order to react to variability of the market conditions and needs for new data.

The idea is to speed up software development in MVPs not following a given type of framework is used (all of us know where is going that approach, don't you Spring-only specialists) but encouraging the focus on functional software and its correlation with tests, supported by a well-tested Cloud IT and normalized procedures. Following these simple rules the software development team can forget IT, delivery and build and focus on the real thing about the MVP.

A possible MVP Flow

Experimental Culture

Well, the MVP practice is based on adopting a more experimental culture based on based methodologies, tooling, architectural models and standard practices. All of these factors are part of the organizational culture that allows the company to be more competitive, helping to Business to be more competitive and innovative as well.

The FTS Software Innovation Engine

FTS is building the Software Innovation Engine including an innovative Build Platform based on AIOps and a Processing Engine to develop software component minimizing dramatically the development time and investment, based on Full Automatic Testing, Predictive Data Analysis, Parallel computing and other cool strategies and techniques.

The design and construction of MVPs using the Software Innovation Engine can reduce the duration of first development (first version of the MVP) to a few days and the duration of each iteration to hours.

Based on the Continuous Delivery Model the Software Innovation Engine offers full test coverage (it does not matter if the target is a prototype or an MVP: everything must be reliable and tested) and auto-scalability features (again, to be reliable we need to be responsive to changing concurrency conditions). Besides, it makes mush easier the transition from the MVP status to a more capable product with all the expected features providing the robustness, availability, automatic response to stress, security conditions and scalability that a professional product needs.

Fully based on Reactive Functional Programming and Low Latency Distributed Data Storage the efficiency and performance of the software components running in the Software Innovation Engine have nothing to do to old framework-based software against plain relational databases, avoiding continuous deadlocks and outages in live environments.

In conclusion, the FTS Software Innovation Engine is the best strategy for the creation, maintenance and exploitation of MVPs as well as the translation of successful candidates to products in scale.

An IT Piece of Advice

Search This Blog