Driving Maximum Business Value With Minimum Viable Products

Driving Maximum Business Value With Minimum Viable Products

(Image source: Shutterstock.)

In the Agile world, the minimum viable product (MVP) approach is a key tenet to delivering solutions more quickly and nimbly. The MVP represents a departure from legacy approaches of defining all functions and features up front regardless of business value. The “viable” in “minimum viable product” is that MVPs must deliver business value. The scale of business value may evolve from a small number of users and features to a wider set, but business value must be delivered from the start.

Correctly embracing the concept can be difficult for insurance carriers. Many insurers have long memories of “day one” and “day two” deliverables where “day two” never happened. MVP approaches are intended to build value incrementally with each additional release. They are unlike traditional project approaches, wherein business value is achieved only at the end of a large, onerous, and time-consuming release.

Doing the Most Valuable Minimum

The MVP approach has narrow scope, short cycles, and continuous feedback to improve subsequent releases. The business value will not be as great in each release for an MVP approach, but incremental value will be obtained sooner, accelerating the realization of full business value.

The MVP is an investment in something. The anticipated business value should be defined to guide the product roadmap, measure success, and provide guardrails for feature development. The optimization of business value is a critical outcome of any product that starts with an MVP. If the MVP makes existing processes too complex or too manual, the MVP approach should be reassessed.

A Tale of Two MVPs

A carrier recently launched an MVP to roll out a new product portfolio on a new suite of core systems. The insurer decided to implement one state and one product for the initial MVP release. Subsequent releases focused on automation of business processes to handle volume increases. Before new states or new products were added, the workflows were streamlined. Both internal and external users were getting more value with each release.

As the insurer began to migrate existing business onto the new platform, the business processes were already automated, integrations were in place, and portal capability was robust. The existing business migration focused on product and jurisdictional requirements, not the core processing capability which was already implemented. The MVP approach of building out capability and users over time enabled the delivery team to achieve the minimal viable objectives. Both business and IT thought that the MVP worked well.

Another insurer approached a new core system MVP in a similar fashion. The initial MVP delivered one new product, in all states, with limited automation. Subsequent releases added new products to the platform without additional business workflow improvements or integrations. As the sales of new products increased, manual business processes were unable to scale to meet the increased volume. Tactical fixes on the new platform were implemented to alleviate some of the manual burden, but only as new products were launched.

The operations areas faced a huge challenge. Processes were different depending on product, and it was difficult to support the increasing volume. Although the business leaders were pleased with product sales, agents and customers grew frustrated with service gaps. In this situation, subsequent releases to the initial MVP focused on maximizing product sales rather than expanding capability to create product viability.

Internal views on the success of the MVP were mixed. IT thought they did a great job of execution, keeping automation and integration minimal to deliver products on the platform quickly. Internal stakeholders weren’t sure anymore about the MVP. Sales were great, but the Underwriting, Billing, and Claims organizations thought the legacy platform was much better.

Navigating the Roadmap to a Unanimous Destination

Ensuring that product sponsors are aligned on the goal and objectives of the MVP is key to implementing a successful MVP. Too often, product sponsors have high hopes that the MVP will meet the bulk of their requirements. Product sponsors should be fully engaged on the approach to the MVP and understand the evolution of the product over time. Sponsors should be at a high-enough level in the organization to support the direction and remove roadblocks.

Setting product direction is a critical step to getting the MVP off to the right start. A long-term roadmap that defines functions and features as well as user groups is important to determine how to launch the MVP. Effective product roadmaps evolve functions and features in each release based on user (customer) input. Prioritizing the features and feedback that are aligned to business value is key in determining what goes into the next release.

Engaging a user group throughout the process helps deliver business capabilities that meet the needs and expectations of the group the software is intended for. Listening to the voice of the customer is a powerful approach to prioritizing features and delivering a product that is readily adopted. Incorporating user feedback into the prioritization process encourages maximum business value.

Quality Over Quantity

Since releases in an MVP approach are so fast paced, a common mistake is only to engage users (customers) when the MVP is finished. Doing so means the product team has missed out on valuable feedback that could have been incorporated throughout the release and sprint process. Additionally, unengaged users may potentially hamper full adoption and acceptance of the solution. The cost and impact of not engaging users throughout the life cycle of the MVP is far greater than the cost of involving them from the start.

Traditional projects often rely on fixed scope, dates, and budgets. When these concepts are attached to an MVP, success is far less likely. MVPs are meant to evolve and be nimble. When everything about an MVP is fixed, there is little room to learn and adapt the product based on user feedback. This approach also constrains the valuable discussion about business value and feature prioritization. When scope, dates, and budget are fixed, quality is often sacrificed to be “on target.”

A viable product requires quality, which includes elements of performance, reliability, and scalability depending on user personas. Successful MVP-based deliveries build quality in from the outset and continue to build on quality through automation, ensuring that it is never put on the back burner. When quality is deprioritized or left to the end, the MVP usually becomes a disappointment to stakeholders. It is also much more expensive to re-engineer a product for quality than to engineer it in from the beginning.

Taking It to the Max

The MVP is a powerful construct to increase business value realization and minimize the risks associated with a large release approach. When done well, business and technology teams optimize the approach to delivering software that has positive business benefits.

Challenges arise when some of the concepts of an MVP are only selectively used. Most often, these challenges result from a lack of understanding of the theory behind MVP-based delivery, leading teams to fall back on the use of legacy methods.

For insurers, implementing an effective MVP model can help get products to market more quickly, increase adoption of digital engagement, and limit the investment in “nice-to-have” features that don’t yield business value. Learning from previous MVP attempts and aligning the future approach to best practices is an important step in becoming nimbler and more flexible in a dynamic environment.

To Stay Competitive, Embrace the Data Science Team of the Future