Data Products for Analytics Agility - The Challenge and Opportunity

P&C insurance is undergoing unprecedented change, and the rate is accelerating. Flux in climate, economic, regulatory, and technology conditions is challenging every step in the insurance value chain—and the performance of personal and commercial lines businesses of every size. Digital behaviors and expectations of customers, partners, and employees continue to advance rapidly, with AI/ML and GenAI promising revolution versus evolution. 

The monolithic, labyrinthian, enterprise data warehouse (EDW)-centric, operating models and architectures of the past era are simply too narrow and too slow to keep up, let alone drive competitive advantage and innovation in the insurance industry now. The regulated, capital-intensive, legacy systems-dominated industry used to buffer change—laggards in product development, pricing and distribution, flow generation, underwriting and claim adjudication effectiveness, operational productivity and expense, and/or customer experience used to have some time to react. Today, before you know it, industry leaders are taking your best business to grow profitably and leaving you the dregs (both business and data).

To achieve digital business agility and speed, insurance companies are moving away from technology-intensive, tightly-coupled data environments with bolted-on operating models and governance. They are moving to business-driven, product operating models with loosely-coupled solutions and services—and architecture and processes designed to support them. New product operating models enable more business self-service and embedded analytic use cases and contemplate seminal needs for more: “big flat files”; semi-structured data; AI/ML model development, training, and inferences; Retrieval-Augmented Generation (RAG); …and even your own LLM if you are talent-, data-, and budget-rich enough.

What is a product operating model for insurance data analytics?

It’s a change in business and IT behavior and processes beginning with a relentless, leading focus on business purpose and usage—how data analytics products[1] can be used to create lasting if not increasing business value.

For example, deriving insurance loss ratio metrics at coverage, policy, and customer levels is hard, so just displaying such in a tabular report or dashboard might be exciting to some. However, unless loss ratio metrics are used to adroitly influence the behavior of insurance product development and pricing, sales, distribution, and underwriting—there’s little if any return on the data and effort. If we can use relative loss ratios to properly influence renewal actions or predict relative loss ratios to properly influence new business actions—then we’re driving significant business outcomes.

A product operating model demands a product management mentality—with a business product manager responsible for commercial success (not just data sourcing, integration, quality, or visual elegance). I like the breakfast cereal analogy—product managers of successful cereal brands are business leaders relentlessly focused on customers, distribution, and returns. They know their supply chain and manufacturing process but aren’t likely expert grain growers and grinders, plant managers, or food scientists. A product manager also has a long-term, evergreen perspective—improving the product continuously with features that will retain existing customers and attract new ones. If data analytics don’t have responsible, engaged, sustained business leadership and product teams, they’re unlikely to produce meaningful, sustainable business value.

The product operating model needs to be structured and organized to produce business purpose-driven data analytics products that can be: (a) quickly extended and enhanced; and (b) easily accessed and combined with other data analytic products. This should sound familiar to modern software engineers—loosely coupled microservices with common APIs.  In my example above, a loss ratio data analytics product will require the combination of earned premium data and incurred loss data products. Therefore, Product managers are delivering valuable data analytics products (e.g., premium and loss products), and consistent, trusted data supply chains that enable new products and value (e.g., Loss Ratio products).

A data product operating model can be applied on top of an EDW (hey, let’s just build our business purpose-driven data marts from the EDW). However, this approach is restricted to structured data and is dependent upon the EDW as a means—new and enhanced products create a growing backlog of needs from a monolithic, tightly coupled, centrally managed system (sound familiar?). An EDW is incredibly difficult to manage as a business product, and to build with an agile team, let alone decentralized, cross-functional agile teams focused on specific business purposes and value. An EDW product manager would struggle to grasp its myriad sources and customers and focus on driving specific business outcomes.  Instead of hitting everything with the EDW (and DW platform) sledgehammer, the product operating model aims to produce an “EDW” as an end—another compound, structured data product—that needs to be justified and scoped for the specific business purpose and value it would provide (e.g. is it to support a broad, top-level enterprise dashboard for executives, or something else?).

In our next blog post, we'll explore the common pitfalls of implementing a data analytics product operating model and how to avoid them. Stay tuned as we dive deeper into the challenges that can derail even the most promising data initiatives.

[1] I prefer the term "data analytics products" which may include data products (file, table, schema, stream, etc.), data services (query, search, feed, etc), and/or analytic services (report, chart, dashboard, ad hoc user interface, inference, etc.). As the business product manager, I want to provide my customers more than just data!