A minimum viable product (MVP) has just enough features to satisfy early customers and can provide feedback for future. It should also show prospective value to keep initial clients – they need to see and believe in the vision of final product.
Before moving on to insurance case, let’s focus on general example how (not) to build a Minimum Viable Product.
2nd scenario: Many publications on MVP present this model as a correct one. However, a process where a user receives a working, relatively cheap product that fulfills essential functions at the very beginning is fine, MVP requires that the previous version should be a base for further development. The solution should be evolving, rather than being replaced – by substitution, we waste time, money and energy that we have spent already on preparing it, setting up processes and teaching users how to use it properly.
3rd scenario: a true MVP – the first step is to create a basic concept, that lacks features, but brings some value and gives the idea on how the final solution will look like. In the following steps, some processes are automated, modules and functionalities are added, changed or even replaced depending on our evolving needs and experience. Yet, they are still based on the same core (or in our example – underbody).
In other words, MVP should:
Companies strive for a perfect IT solution that would support all aspects of their activity, yet almost each and every one of them is somehow limited: InsurTechs – by capital, corporations – by lack of flexibility.
As InsurTech, you do not have to “go big” and implement the whole solution right away, there are many possible scenarios.
Let’s take an example of a company that came up with an idea for a really innovative insurance product. In order to be successful and ahead of competition, you need to start sales as soon as possible. Everything you require at the very beginning is a sales front-end. The best solution would be to implement a module system, which can be expanded as required in the future. Then, after successful launch, a company can decide which direction it wants to thrive. It can even decide to run a fully-fledged insurance business, where back-office or claims modules will be necessary. This issue can easily be solved by White Label, a modular core system (end2end) provided by Altkom Software & Consulting. Thanks to microservice architecture, each of its modules can be implemented separately. It can be expanded with new modules and functionalities or even integrated with foreign systems.
Whether it is a huge insurance organization with an outdated software or a high-tech insurer using a sophisticated system, you may require a tool that would speed up critical processes in your organization and enable quick implementation of new products.
White Label is a lightweight core system, which can exist next to the current core solution and serve as a MVP workbench for innovative, experimental products. There is no need to configure the existing core system. White Label enables to launch pilot sales, and – depending on the pilot’s results – make decision whether to continue the sales and migrate the new product to the core system. One can also decide to withdraw it from sales and handle the existing contracts in the back-office policy module.
Product innovation – possibility to test a new approach to the sales path for existing products ® multicalculation for own brand products from different systems.
Product standardization – ONE product – DIFFERENT sales paths (providing for local specifics) – ONE back-office operation.
High flexibility – ability to customize your sales path to local models, local market characteristics and sales channels (change priorities or steps in your sales path).
Homogeneous offer – one product for all countries with simple adaptation to local conditions, e.g. legal.
Sales configurations implemented by business alone – without IT involvement.
Author: Bartosz Kijewski, Sales Support Specialist at Altkom Software & Consulting