MVP strategy in insurance system transformation: Expert insights for a customer-first future
About the author, Gatis Vuguls, Principal Architect–Insurance: I have dedicated the majority of my professional career to working on complex insurance core system transformation projects, typically replacing outdated systems with modern solutions like Guidewire InsuranceSuite. Along the way, I have gained extensive experience working with insurance carriers across four continents. These carriers vary in size, from small ones offering straightforward policies and simple claims processes to some of the largest global insurance providers specializing in complex commercial insurance.
Launching a Minimum Viable Product (MVP) is all about practicing what you preach when it comes to agility using a lean startup methodology. It’s like putting out a trial version of your product with just enough features to learn a ton about what your end users want. This MVP is your way of saying, “Hey, we’ve got something cool, but we’re ready to make it even cooler based on your feedback.”
In recent years, the insurance industry has been all about embracing the MVP strategy. Why? Because technology is evolving fast, and customers’ needs are changing quicker than ever. By using the MVP approach, insurance companies can not only get their products to market faster but also stay nimble in a rapidly shifting insurance landscape.
Now, the MVP approach isn’t just about speed; it’s also about getting early feedback. When you launch that initial version of your product, you’re essentially opening the door for your customers to tell you what they love and what they’d like to see improved. This feedback is like gold, helping you fine-tune your product to make it even more awesome.
But here’s the challenge: in the world of insurance, where complex systems are the norm, integrating the MVP concept can be a bit like solving a tricky puzzle. It requires careful planning and execution because these systems are deeply woven into the core processes of insurance companies. So, while the MVP approach is a game-changer, it’s not always a walk in the park when it comes to insurance systems.
💡According to McKinsey, a team proves the value of the new business by piloting two or three minimum viable products (MVPs). Carriers should take an iterative, test-and-learn approach to pilots, with each lasting no more than 8 to 10 weeks. It is important to keep the scale of these pilots manageable and not attempt to perfect final offerings.
From my experience, the success of an MVP-driven initiative, especially in the context of core system transformation projects, requires a well-thought-out strategy and commitment from all stakeholders. While I’ve seen some projects that used the MVP concept exceptionally well, more often, there’s a lot of room for improvement in how it’s executed. To truly harness the potential of the MVP approach for complex enterprise systems, it’s essential to merge the agility and quick turnaround of MVP with the robustness and reliability that enterprise-grade applications demand.
Benefits of using the MVP approach
The primary purpose of an MVP approach isn’t to manage the overall scope of the product. Unfortunately, MVP is often misconstrued as a tool for ensuring product conformance and a reason to stick closely to out-of-the-box (OOTB) functionality. MVP is, in fact, an excellent approach for prioritizing and managing the scope of product releases, rather than the overall product scope itself. Its primary goal is to minimize the feedback loop between the development team and the end users of the system.
There are several benefits to using an MVP but a couple of these I believe are especially significant:
Meeting diverse needs with early user feedback
In insurance core system transformation projects, business representatives actively participate throughout the build phase. These representatives, including Product Owners, subject matter experts (SMEs), or end users during the user acceptance testing (UAT) phase, ideally offer feedback as the system is being constructed. This iterative feedback loop serves as a unified customer view which ensures that features are customized to meet target user needs effectively throughout the entire build phase.
However, there are often gaps between the system being built and the end user requirements. Three common gaps I’ve observed are:
- Some user profiles aren’t represented within the project team. For instance, specific users—who are not regular users of the system—might rely on another business profile to convey their requirements to the development team.
- The Subject Matter Experts (SMEs) designated for the project often struggle with allocating sufficient time to clearly articulate the business requirements. These SMEs typically hold critical roles in the day-to-day operations of the business. Even when they are fully committed to the transformation project, they must continue providing their expertise for ongoing operations. Consequently, SMEs find it difficult to dedicate the necessary time to fully grasp the broader operational context of the new system, leading to the submission of requirements that are heavily influenced by the legacy system rather than the new one. In essence, the project team often ends up receiving system-specific requirements instead of holistic business requirements.
- A notable complexity gap often exists between production and lower-tier environments. While attempts are made to mirror production-like behavior in these environments, many core system replacement projects struggle to achieve this parity. These disparities can stem from various factors, such as the absence of precise test data in external systems, policies and claims that deviate from real-world scenarios, or unusual system loads.
Building trust among stakeholders with early releases
While large-scale core system replacement projects demand several months of commitment before the inaugural release to production. This extended timeline often raises concerns among decision-makers. Though it’s possible to showcase progress without a live production application, demonstrating a cohesive MVP — with all its components functioning seamlessly — can significantly bolster confidence among senior stakeholders. Furthermore, these early releases enable key stakeholders to assess whether the project is on track to achieve its initial objectives and start early analysis to see if the investment will yield the anticipated return.
Challenges with MVP in core insurance systems
Although utilizing an MVP approach for insurance system innovation has clear advantages, insurance leaders encounter various implementation obstacles. Let’s delve into the primary challenges within insurance ecosystems that require attention for successful adoption of the MVP approach.
Legacy systems’ impact on cost and flexibility
Operating multiple core insurance systems simultaneously impacts costs from both IT and operational perspectives. Consequently, migrating policies or claims from legacy systems often becomes the default approach when implementing a new system. However, this can limit the flexibility of insurance carriers when implementing the new system as this new system needs to support legacy policies and claims.
Cultural resistance
Insurers—often established decades ago with rich histories—have likely experienced at least one core system replacement project that wasn’t as successful as initially planned which led to increased workloads. Employees often wish for a system with all-encompassing features right from the start, especially after experiencing such transitions. End users may find it challenging to adopt a new system that lacks certain features from the legacy system, even though those features in the legacy system were originally introduced to work around some of its shortcomings.
Regulation and compliance concerns
Many insurance products are subject to regulations which add complexity to the MVP approach. Features related to product definitions, system security, data privacy, financial reporting, and others must be implemented before the system’s launch. Insurers cannot simply ‘use a landing page’ to gauge end-user or customer reactions before building their products, as regulatory requirements must be met or carriers risk fines.
Interdependencies
Core insurance system transformation projects rarely affect only the core system. It’s common for other areas such as infrastructure, legacy applications, or other non-core third-party systems to be impacted.
Development teams working on these other systems should be able to continue their work even after their MVP is completed, rather than halting progress and waiting for the core system’s features to catch up. This may require resources from the core insurance teams to develop features that would not have otherwise been included in the MVP.
Recommended action plan when using the MVP approach
The application of the MVP approach in insurance core systems transformation can have a measurable impact when industry leads follow a clear action plan that directly aims to solve the pressing challenges posed by core systems. This action plan helps align stakeholders on the MVP’s scope and plan pilot releases while also keeping an eye on the bigger picture that helps evolve the action plan to achieve bigger goals. Finally, the action plan must include a roadmap from MVP to a fully-fledged product.
Define the MVP’s scope
In my view, nailing down this aspect is paramount. Several factors contribute to increased complexity when building a new product, including:
- Lines of business
- States or countries
- Partners/brands
- Products/Offerings
Choosing to not implement any of these dimensions fully introduces complexity to operations such as:
- Brokers or internal customer service representatives (CSRs) have to use both legacy systems and the new system.
- Inability to offer innovative products to all potential customers.
- Cumbersome processes for seemingly straightforward tasks (For example, a customer wants to upgrade their offering but it isn’t available yet in the new system).
All of these considerations should be taken into account when establishing the overall scope of the MVP. I wish I could give a straightforward recommendation regarding which aspect to prioritize, but minor details matter greatly. For instance, some insurance carriers permit policies to be transferred from one state to another, while others do not. For a carrier that allows such transfers, a new system that doesn’t support this scenario would require the introduction of new business processes involving policy cancellation in the new system and rekeying it in the legacy system. Conversely, carriers without inherent support for this process present a clear area where the MVP can focus on a single state.
Think of the bigger picture
Due to the complexities of core system transformation projects, it’s not uncommon for insurers to deviate from the original plan. To effectively navigate these challenges, one must strategize and plan carefully. Always take a moment to reflect on the broader implications before making decisions, especially when considering reducing the scope.
Any alterations to the project’s scope should stay in harmony with the initial goals set by the business users, taking into account the broader effects on the organization. Prioritize thorough functional and non-functional testing, avoiding the temptation to release prematurely just to meet deadlines. Remember, while the MVP allows for an initial product that isn’t perfect, this should be a deliberate decision, not an unplanned outcome. A misaligned MVP that doesn’t serve its intended purpose can result in a lack of confidence from end users and erode trust among senior stakeholders.
Plan a pilot release
Selecting eager end users who are willing to tolerate some hiccups can be highly beneficial, rather than rolling out the system to a broader user group. These users should receive training on how to provide constructive feedback about the system. This ensures that the support team does not have to contend with false positives or poorly written reports.
Here is why a pilot release should be conducted in conjunction with the MVP approach:
- It serves as a way of validating that the defined product is acceptable.
- If major flaws are discovered, the insurance carrier has an opportunity to reschedule the full release.
- A pilot release provides an opportunity not only to witness the product in action but also to verify other dependencies such as infrastructure, monitoring, and business-as-usual (BAU) operations.
Engage stakeholders
Before commencing development, insurance carriers should establish a clear communication strategy. This strategy should include a concise explanation of how the MVP benefits various stakeholders within the organization. The program team should maintain transparency and also address the stakeholders for whom the MVP may cause short-term challenges or difficulties.
Another crucial element of the communication strategy should include a roadmap from MVP to a fully-fledged product. While this may sound somewhat like a waterfall approach, it should not be. The roadmap doesn’t have to entail detailed requirements; it should merely consist of high-level features and a plan for when these will be implemented. If the project needs to make significant changes to the overall plan, whether due to user feedback or other factors, this roadmap should also be updated to ensure that users are aware of the long-term plan. When such a roadmap is absent, end users may begin to believe that they will be left with the MVP indefinitely, leading them to prioritize features that in reality aren’t required for day one.
Final thoughts
Embracing the MVP approach is generally a prudent move when dealing with complex core insurance systems. It allows for efficient development by breaking down the complexity into manageable segments. However, it’s crucial to acknowledge that there are limitations to this approach.
When a core insurance system is already live, it demands resources for continuous monitoring and maintenance, potentially diverting focus from the delivery team. Implementing changes in a live system requires careful consideration due to potential impacts on existing policies and claims, sometimes necessitating different logic for new policies versus existing ones. These factors can influence the team’s velocity, extending the overall project timeline.
For comprehensive insights into navigating these intricacies and optimizing your MVP approach, let our seasoned insurance experts at Grid Dynamics help you. Explore how to navigate complexities, ensuring efficiency and success from discovery to launch. Your roadmap to a successful insurance system transformation awaits.
