Insurance products are complex

Core implementations tend to run into a familiar set of problems: requirements take longer than expected, scope expands, integrations become more complicated, and timelines move.

There are plenty of reasons why that happens. But one issue is consistently understated.

The product itself is rarely defined in one place.

A product may start with rates, rules, forms, underwriting requirements and other source material. From there, different teams interpret what they need and translate it into the systems they own: the rating team configures the rating engine, the policy team configures the policy system, billing gets its version, and the quote experience gets another.

Each team is doing necessary work. But each is also translating the same underlying product into a different technical structure.

That translation takes time, and it happens again and again — at launch, with every change, and most visibly during a core migration.

A carrier may have spent years building and refining a product in one system. Then, when that system is replaced, much of the product has to be understood and rebuilt from the old configuration, documents and the knowledge of the people who have supported it.

We call that migration work.

But a surprising amount of it is re-deriving something the carrier already knew.

The same problem makes product rationalization difficult.

Two products may look different because they live in different systems or were implemented by different teams, even when the underlying product is largely the same.

A clear view of complete requirements is critical 

It also makes relatively simple questions hard to answer. What exactly is this product? Which rules apply in this state? Which forms belong to this coverage? Why does the rating engine behave differently from the quote experience?

The answer is often spread across several systems, documents and the people who have supported the product over time.

The answer is not another core system.

Each system in the stack needs part of the product definition to do its job — the policy system to process transactions, the rating engine to price, billing to collect and account for payments.

But none of them needs to be the only place the product itself is understood.

Oversee is exploring a different model: hold the product definition independently – rates, rules, coverages, forms, payment structures, underwriting requirements and jurisdictional variation and generate the representation each system needs from it.

That does not eliminate the work involved in launching or migrating a product. There will still be integrations, testing, operational decisions and exceptions.

But it can reduce a great deal of repeated interpretation.

And that matters because the industry spends an enormous amount of time rebuilding products it has already built.