(The original “rollout”—Apollo 4 on Aug. 26, 1967. Photo credit: NASA.)
An insurance professional probably does not go through a day without digital transformation being part of a conversation, or referenced in an email or an article. While newer members of the industry might believe the importance and impact of technology on the insurance journey is more recent, it’s actually been a critical component all along. Even the Agile concept of Minimum Viable Product—or—MVP isn’t as entirely new as some might think at first glance.
I began my claims adjuster journey in the 1980s using a then recently introduced mainframe system, and it was then several years between its first and second release. Needless to say, the breadth and depth of the process and operational impact was massive with each implementation. But by design, there weren’t activities or avenues for incremental user previews and feedback.
Over the subsequent decades, there were leapfrogs of new coding languages and architectures, each one enabling more opportunities to automate. While carriers were able to achieve monthly or even weekly maintenance releases following the initial implementation of a new core policy, claims, or billing system, major releases could still be two or three years (or more) in the making. And true to our waterfall approach at the time, the scope was based on documented (and aging) requirements versus continuous (and current) user input.
Today the focus is all about customer experience, inclusive of every interaction they have with an employee, along with any and all digital and paper touchpoints that they have with their insurance company. The appeal of agile development practices is obvious—what is not to love about the Principles behind the Agile Manifesto? But for many, achieving rapid and continuous delivery of solutions intently focused on customer value, while keeping pace with massive industry change, is a steep hill to climb.
Key to delivering customer value early and often is the agile concept of MVP. Anyone who has been part of making that initial scope decision can attest to there being about as many interpretations of both what is minimum and viable as there are people participating in the conversation. Why? Because we are more familiar with delivering nothing until being ready to deliver everything.
Having journeyed through my own MVP learning curve, I’ve realized it wasn’t an entirely new concept after all. Long before beginning an agile transformation, I had been part of many proofs of concept as my company strived to learn how to best leverage new technologies and introduce wholly unfamiliar automation scenarios. The concept of a POC emerged in the 1960s with the goal to test the feasibility of an idea that could be small, if not incomplete.
I will date myself by confessing my POC journey includes leading a carrier’s first customer-facing capability using the internet. Our market leaders found us the perfect policyholder to partner with, to design and implement our first run at web-based reporting of worker’s compensation claims. Our developers and business systems analysts often worked at our customer’s office, so they could give us real-time feedback on flows and features through hands-on use in our test environment. Our team was commissioned in September of 1998 and the first claim was successfully reported online, in production, in February of 1999.
I hope that timeline makes a few pause—five months to deliver a brand new, customer-facing capability—more than twenty years ago. And by the way, that included the designing and implementing the technical and operational infrastructure, from security to support.
As we forge ahead, leveraging Agile methodologies to drive digital transformation, some of the terms and concepts may sound new or unfamiliar but don’t let this frustrate your efforts.
Sometimes what was thought to be old can be new again—or at least extendable and reusable. MVP can be realized by resurfacing your “legacy” POC experience.