Data Products for Analytics Agility - Avoiding Common Pitfalls

In our previous post, we introduced the concept of a product operating model for insurance data analytics and how it can create lasting business value. Now, let's examine the common challenges that can prevent organizations from realizing the full benefits of this approach.

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).

In our final post of this series, we'll explore what insurance data analytics products look like in practice and how they create value across the insurance value chain. We'll map out the various data domains and show how they work together to drive business outcomes.