15 February 2021
The concept of “Minimum Viable Product” (MVP) has been widely popularized in the development world through the Lean Startup model. An MVP is a basic version of a product that can be launched on the market to get validation right from customers during its early stage.
As a kind of “fail fast” approach is cost-saving in that it allows flaws to be identified before time and money are abundantly invested in the development. Early adopters are used to identifying cases when the product wouldn’t succeed or identify how the course of development should be adjusted.
MVP can be structured differently depending on the field and the purpose of a certain product. But one thing is essential in this work: any idea of a product should go through meticulous research of the target audience and the competitors long before customer validation on the market.
The efforts put into this phase bring immense advantages of understanding why the product should exist, what forms, visuals, and essential features can help create an emotional connection with the audience, and what is necessary for successful launching on the market. This preparatory research can drastically shape the process of defining an MVP of the product.
However, even that work can’t completely insulate the process from some surprises when the product falls within Utility tools. The picture between what the product should be and what the product could be can change considerably after beginning work with a development team.
Here are the popular difficulties we are facing when developing this kind of product.
1. The Backend Service Behind a «Simple» Functionality
Some features that might look simple on the surface may have a grand backend service behind them. This service can take months to build and/or turn into a network that serves the simple button on an application or a website.
It is not always obvious what stands behind some technologies we are taking for granted and what data is available to easily get from the system or the Internet network through an application or a website.
It might run counter to what an MVP should be especially when time or budget-limited.
For example, a product that shows in a given moment the actual speed of the Internet should virtually measure the speed of data transfer. That product should know where to pass data and a receiver should accept it and measure the time of transferring. This process repeats in reverse order to calculate both download and upload speeds.
The service that maintains this possibility possesses a lot of quality attributes, located on multiple servers to provide real-time high-fidelity measures for many customers across the world.
The network of these servers itself is a great product on the market and can be evaluated separately.
2. New Technologies Required
Some features may sound like a good idea, but there is no technology yet to bring it to fruition. It could require up to years of kind of scientific work to create this technology. It might be greatly rewarded after all but there is no guarantee of getting a result in a certain timeline.
For example, a new technology of interactions is to be created to get some specific technical information from surrounding devices a user doesn’t have any physical access to.
3. Related Area Involved
Some features go hand in hand with solutions in related areas. What may seem limited to digital products sometimes is involved with other technical fields. So getting a product done consisting of those features requires having subject-matter experts in a developing team who can take care of those solutions. However, there aren’t many outsourcing software development companies staffed with those experts permanently, restricting their ability to make estimates on those types of projects and work on them.
For example, features that involve working with analog signals instead of only digital ones require having specific experts. If a product should obtain data from temperature sensors, photocells, or light sensors, we can say for sure that it won’t be something ordinary from the developing perspective.
4. Apple Limitations
Sometimes some attractive features are forbidden for iOS applications due to Apple policy, so developers can only work with the public APIs provided by Apple. Sometimes there could be workarounds that still solve the customer’s problems but worsen their experience with an application.
Those workarounds might not be so obvious and difficult to discover if no one has ever done it before. After discovering one, the next difficulty is assessing whether or not a customer’s need impels them to use the workaround and pay for it.
An MVP may become a risky undertaking.
To frustrate matters further, Apple’s policy can change, leaving uncertainty in development.
For example, in 2020 Apple didn’t allow access to calls of users for applications, and iOS applications that offer call records provide a recording line that should be merged with a user’s call into a conference.
5. Integration with Third Parties
Fortunately, most listed difficulties can be solved by other ready services which were developed before and maybe even for other needs. So the work of a development team simply boils down to integration with service and implementation of the desirable «button» in a product.
There are only a few cons:
- dependency on the performance of a third party;
- possible limits of service.
Despite that, using a third party instead of doing it on one’s own is fully under the MVP concept.
Speaking of Utility tools, it is important to invest in research and initial grooming of technical features with a development team before handing off something to development. This is to avoid waste and be able to adjust the product concept in the early stages.
In the end, we see the tendency that there is nearly always a way to build an MVP of a Utility tool that earns an approbation on the market.
We at Rocketech create MVPs for different industries, please check our cases here.