This is a companion post to my January 16, 2020 post titled “Re-perceiving Kotler’s product framework for insurers.” I wrote:
Insurance products currently do a lot of heavy lifting for insurance carriers. Insurers should expect products to do much more to strengthen competitive success.
Insurance products are meant to simultaneously attract customers and generate profitable premium flows throughout the product’s existence on the carrier’s books. Insurance products, taken as a complete portfolio, also represent a significant part of the carrier’s competitive face to the marketplace. Moreover, as importantly as the competitive presence, insurance products represent the risk appetite of an insurance carrier.
Insurers demonstrate changes in their risk appetite through elimination of existing products, alterations to existing products, and introduction of new products. Concomitant with new products and alterations to existing products, insurers also make their shifting risk appetite profile evident with changes to their pricing and underwriting practices.
But insurers should consider their set of products not just as an outcome of the company’s strategy to reflect a specific competitive presence and risk appetite but also as a dynamic vehicle that continually shapes the tactical initiatives and operational processes that attract, service, and keep customers and producers.
The insurance product is the foundation of the insurance industry
Insurance analysts and others have justifiably discussed that ‘customers’ are, or should be the center of an insurance firm’s strategy. We, counting myself among these industry pundits and writers, also have discussed the criticality and nature of customer service and the importance of an insurer’s distribution channels.
But it is far too easy to overlook the essential factor that weaves itself through all of those discussions: the insurance product. As I stated in my January 16, 2020 post and explained: insurance products do a lot of heavy lifting. To be more specific: No product, no customer. No product, nothing for a producer to market and sell. No product, nothing for an insurance carrier to service. No product, no insurance carrier. Risk management / mitigation is an insurance carriers sine qua non but no product, no sine qua non!
A key question almost asks itself: where do insurance products come from?
Answering that question in broad strokes is the reason for this post.
Broad-brush strokes of insurance product development
The genesis of an insurance product is a concept. (See visual.) The concept is an objective or set of objectives to satisfy the risk mitigation needs of an insurer’s current customers or target customers. The target customers could be either in an insurer’s current markets or new markets identified for expansion.
The end-point of an insurance product is a client. The insurance client could be one or more of several types: an individual life insurance or annuity client, or a personal property and casualty insurance client. The client might be a commercial property and casualty insurance client or an employees benefits client. The first types of enumerated clients obviously represent ‘retail’ insurance clients. The latter types obviously represent corporate or enterprise clients: the client themselves are purchasing insurance for their company (including the actions of its management and the liabilities attached to its products and services) or for the employees of their company.
The other point I am making – and illustrating in the visual – is that the insurance product development process is, or should be, a continual, never-ending cycle that moves to concept to client and back again. (With my apologies to J.R.R. Tolkien for using that phrasing.)
Producers are not clients
Please note: One characteristic of any of these retail or corporate clients is that none are producers. Insurance agents, brokers, or MGAs are extremely important for the insurance industry to function but they are not insurance clients. (I can hear the gnashing of teeth and the wailing cascading through the air.)
I define a client as someone who pays premiums and fees to the insurance carrier. The only time in my multi-decade insurance career I remember a broker sending money back to the carrier I was working for was when we ‘clawed back’ commission after conducting a retroactive profitability analysis. And truth be told, we didn’t actually get the money sent back but instead deducted the monetary amount from what we paid the broker firm the following year.
‘Finer’ brush-strokes of insurance product development
Let’s dive into the never-ending product development cycle a little further by applying some ‘finer’ brush strokes to our visual.
I’ve added new elements to the ‘never-ending product development cycle’ visual below: ‘product’, ‘producer’, ‘customer service’ , ‘claim service’, and ‘information flows.’ Each of these elements are essential to an insurance product development cycle. Each of these six elements contribute, or should contribute, to the information flows that insurers should be managing to create and enhance products.
Let’s tackle six of the elements in the visual, excluding ‘information flows’ which I discuss in the next section:
- Concept: The concept for an insurance product comes from:
- a standing product development committee
- an appointed product development committee to create one or more products and then disband
- competitive information from producers
- competitive information from the insurer’s market research / marketing department
- customer surveys
- customer service interactions
- claim service interactions
- social media
- analysis of customer service calls / emails / IMs / letters / faxes generated from clients who purchased the product through their outreach to the insurer or insurance agency / brokers.
- Product: The product is:
- the original concept transformed into a legally approved, actuarial priced entity (hopefully actuarially priced to generate profitable premium on its own and/or to maximize the client’s lifetime value for the insurance carrier)
- filed with regulators in the applicable jurisdictions that insurer wants to sell and service the product
- supported by:
- rating /quoting and underwriting systems (I distinguish these types of business systems from core administration systems)
- core administration systems (billing, policy administration, claims)
- training documents for agencies, broker firms, and producers as well as for customer service representatives
- shaped for specific types of clients (because one size does not fit all)
- fitted into the insurer’s customer relationship management (CRM) system
- an integral component of the insurer’s marketing tactics
- part-and-parcel of the insurer’s risk appetite philosophy.
- Producer: The producer is the certified, trained, licensed salesperson (career agent, independent insurance agent, broker, MGA) who is authorized to contact prospective clients to sell the product in the client’s jurisdiction.
- Client: The person whom the insurer believes is the best ‘fit’ for the product; in the phrasing of the L&A insurance industry, the product is ‘suitable’ for the person who might purchase the product.
- Customer Service: The customer service personnel in the insurance carrier, the insurance agencies / broker firms, and applicable claim firms have been trained in the product attributes and expectations concerning client requests, questions, and concerns generated after purchasing the product.
- Claim Service: Claim service can be provided to the client who purchased the product by the insurer’s own claim department, by third-party claim firms the insurer uses when additional resources (or more expert resources) are needed to supplement the insurer’s own claim staff, or some combination of the two.
In the next section, I discuss the two major domains housing the insurance product development participants.
Insurance product development participant domains and information flows
Participants within: insurance value chain & ecosystem
I mentioned some of the functional departments that are involved, or could be involved, with the insurance product development process. The participants could be members of the insurance carrier’s value chain or ecosystem. (See visual below.)
For the purposes of this post, I define the members of the insurance carrier’s value chain as the people who are considered employees of the insurance carrier. They work for functional / departmental areas within the insurance carrier (although they very well could be geographically dispersed).
My definition of an insurance carrier’s ecosystem encompasses the people who are employed by third-party contractors who the insurer reaches out to, such as the people who:
- sell and distribute the carrier’s products (i.e. insurance broker firms, insurance independent agencies)
- adjudicate claims (i.e. third-party claim firms)
- provide legal services (i.e. external law firms)
- remediate property losses (i.e. building contractors)
- rehabilitate physical injury (i.e. healthcare providers)
Strong ties (value chain members), weak ties (ecosystem members).
I put the insurer’s clients – regardless of the insurance major line of business – in the insurer’s ecosystem rather than in the insurer’s value chain.
The domain the product development participants reside is important for reasons beyond ‘strong ties, weak ties.’ One reason that the insurance carrier needs to know the domain of the participants is to create, manage, and audit the security and privacy attributes of the data elements being (potentially) shared in the information flows that move from concept to client and back again.
There are at least five different major information flows that insurers need to manage from concept to client and back again (Refer to the visual above in this section and the visual in the preceding section):
- the information flow from the insurer to the market (i.e. to the client)
- the information flow from the market to the insurer
- The information flow within the insurance value chain
- the information flow within the insurance ecosystem
- the information flow between the insurance value chain and ecosystem
Insurers also need to know what information flow systems each domain is using. The probability that each domain, or sub-domains within each domain, are using different information flow systems is very high. It is almost a certainty that the information flow systems used within the insurance ecosystem third-party contractors are extremely varied (and some third-party contractors may not have digital information flow systems at all).
BTW I realize that I haven’t defined or described information flow systems: for me, these systems include communication and collaboration systems as well as the ‘information’ from interactional content (distinguished from operation transactions) from Systems of Record, Systems of Engagement, and Systems of Decision-Making. Beyond this short paragraph, I will diary a discussion of information flow systems, including the nature of the content in the information flow systems, to future blog posts.
Historic bottlenecks to insurance product development
The insurance product development process should be a coherent and well-orchestrated process. The process requires efficiency and effectiveness. The process demands the generation, accessibility, sharing, storage, and interaction of ‘rough’ and ‘refined’ information that flows to and from the various participants in and throughout each domain.
Historically there have been three significant bottlenecks in the insurance product development process: the actuarial department and IT department in the insurer’s value chain and State insurance regulators in the insurer’s ecosystem.
I’d be curious if these three bottlenecks (actuarial, IT, State insurance regulators) have kept their reputation for significantly slowing down the process of getting a product from concept to client.
There are many future blog posts that call out to be written about insurance product development. One future post in particular that demands to be written is a discussion of the set of technologies and technology applications, including communications and collaboration systems, that insurers should use:
- to create and refine the concept into a product ready for market
- during the process to develop and deploy products into the market
- to capture market information about the product once clients begin to purchase it
- weave the market information with other sources (i.e. internal product development committees, agent/broker discussions, customer service requests about the product) to enhance or create new products.
What other areas of product development cry out for a discussion of technologies and technology applications? Let me know what you think?