top of page
Wavy Abstract Background
  • Writer's pictureMark Hodson

Data Products for Analytics Agility

 

The level P&C insurance business 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?).

 

What are some pitfalls of pursuing a data analytics product operating model?


I see three big reasons that the wheels fall off early, or that distract from achieving expected insurance business outcomes.  Succumbing to (or ignoring) these risks is easy, and confronting them early and often is hard but essential.

 

1.    Lack of business leadership, engagement, and change management:

  • Success with the product operating model requires senior business executive sponsorship of enterprise data analytics—it may be the responsibility of a Chief Actuarial and Analytics Officer, a Chief Data Officer, or the simply an explicit responsibility of another C-level businessperson (CFO, Chief Underwriting Officer, CMO, etc.).

  • Business will assign data analytics product management (leadership) roles and the take the responsibility for achieving expected business outcomes from data analytics.

  • Business will allocate subject matter experts and users to serve on cross-functional, agile, evergreen product delivery teams.

  • Business is committed to changing the way data analytics are defined, prioritized, delivered, and used—collaborating with governors, architects and engineers to deliver business outcomes not just capabilities—and insisting on the use of unified, certified data analytics supply chains.

  • Coherence if not integration with digital, core business system, and/or other enterprise transformation initiatives—there must be operating model synergy not competition.

 

2.    Conflation of data analytics producer and consumer responsibilities:

  • Producers (and product managers) must serve enterprise use cases, not just individual business areas or factions. Multiple producers within a data domain (e.g., the supply chain of derived premium metrics, or a channel, customer, product, or other broadly used dimension) lead to silos and competing versions of the truth—redundant efforts and productivity-sucking cycles of conflict, explanation, reconciliation, and repair.

  • Valuable business self-service (BSS) is enabled and governed, not just allowed—unified, certified, understandable data analytics supply chains spur responsible, consistent, scalable business self-service uses. Business areas manufacturing their own versions of metrics and dimensions are flying BS not BSS flags.

  • The fatal flaws above easily stem from generalized headlines such as “decentralization”, “democratization”, and “hub and spoke”.  Take the time to define how you will drive business value with data analytics—e.g., some level of centralized governance, architecture, technology, and operations (the “hub”) supports data domain product managers and product delivery (the “spokes”) which serve business users/uses across the enterprise (the “wheel).

  • And finally, practice “inside-out” data governance—i.e., engage governance in the charter, design, built, deployment, and use of products. Attempts to bolt governance onto products in later stages are futile.

 

3.    Technology-led vs business-led insurance data analytics products (and operating model).

  • Technology is necessary but not sufficient for data analytics products success (delivering expected business outcomes)—see above.  Don’t burden your start-up with heavy technology investments or changes out of the gate.

  • Understanding data warehouse, data lake house, data fabric, data mesh and other technology concepts, capabilities, and tradeoffs is helpful in making technology and architecture choices when you know what you need to produce and how it’s going to be used—they are not definitive business purpose-driven solutions.

  • If pressed, I would say that a level of maturity with a modern cloud data platform is the primary technology prerequisite in pursuing a data analytics product operating model—it enables choices among many data platforms and data/analytics services, speed (at least infrastructure-as-code), and economics (minimizing capital investments).

 

What exactly are insurance data analytics products?

 

In a mature state, there are very likely hundreds of data analytics products in an insurance business.  Start by thinking about the insurance value chain and the data domains associated with the underlying core business processes.  Each data domain is a family of data analytics products, and each data analytics product may include several features (data asset(s), data feed(s), tabular report(s), dashboard(s), inference(s), ad hoc user query interface, etc.).

 

  • Marketing – product development and marketing measures such as product development and marketing acquisition costs; campaign attribution; etc.

  • Distribution – producer (agent/sales reps) counts, locations, and hierarchies; appointments and licensing; commissions; etc.

  • Flow – submissions; quotes; conversion ratios and cycle times; etc.

  • Policy Financial – premium-bearing financial transactions (i.e., issue, renew, endorse, cancel, reinstate); written and in force premium; earned premium, retention and price change; exposure; etc.

  • Claim Financial – claim financial transactions (open, reported, paid, and reserve adjustments); frequency; severity; loss reserve and development; cycle time; IBNR; etc.

  • Billing Financial – disbursements; receivables; aging/DSO; cash flow; etc.

  • Policy Operational – time, effort, and cost of underwriting, customer service, and other policy operations

  • Claim Operational – time, effort, and cost of claim adjudication, customer service, and other claim operations

  • Customer Experience – wait time; resolution cycle time; satisfaction; etc.

 

As summarized above, we need to derive many insurance business process measurements (facts) in our data analytics products, but the list is not complete.  We also need to produce rich “dimension” products that can be combined and used to filter, aggregate, and relate measurements—enterprise dimensions such as market segment, branch, LOB, product, producer, geography, date, time, etc.  These products (and producer responsibilities) may be bundled into the core data domain product families; however, they need special product management considerations—enterprise dimensions must be defined and used consistently within and across data domain-oriented measurement products. Dimension data sources often transcend data domains, and include 3rd-party data.  For these reasons, dedicated product management role(s) for enterprise dimension products should be strongly considered.

 

There’s one more thing to wrap up our description of insurance data analytics products—data analytics products can be combined to create new data analytics products.  I alluded to a prime example in the product operating model section above—Earned Premium and Reported Loss data products can be combined to create a Loss Ratio data product.

 

Conclusion

 

Since the dawn of the insurance industry many centuries ago and the founding of many leading P&C insurance companies over a century ago, we have used data analytics to select, price and manage risk—data analytics, particularly predictive insights, are the business.  Our data analytics products are more important, complex, and regulated than in other industries, so we can’t count on generalized approaches or expect to copy the successes in or across many other industries. We must do the work of adoption and adaptation for insurance business success, which requires a fundamental alignment of business leadership, product management, and information technology practices.

 


[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!

Recent Posts

See All

Spreading Snowflake Excellence

For many insurers, Snowflake – the cloud-based data platform – is central to their data modernization journey.  Snowflake is more than a traditional database; it’s a data platform.  It houses data pip

Modernizing Data Goverance

Data Governance Modernization If the first generation of data governance was about awareness, and the second generation introduced tools and operating models, data governance modernization today is ab

Comments


bottom of page