Let’s Get Rolling: Part Two

In part one of this series, we wondered why the seeming infatuation with insurtech continues apace as if software that’s already on the market were inadequate to overcome reliance on legacy technology. And we asked this question: “Since many of those new [insurtech] wheels are unproven (hence, the risk), why wouldn’t we work with the ones that already roll?”

We have no desire to appear defensive. But we’re compelled to say we’ve worked — and continue to work — hard to provide the best of both worlds. Here’s why we say that:

First, we’re not peddling legacy technology. (Why in the world would we do that?) On the contrary, we developed our software and our business model to take the pain out of replacing legacy technology. Second, we developed our software to enable the integration of whatever aspects of insurtech demonstrate productive, business-improving value to our customers.

20/20 Foresight

“Hindsight is 20/20” is a very common expression. We can’t help but wonder why people wouldn’t want their foresight to be a little more acute. Case in point: In part one of this series, we also excerpted some text from an article we’d read. Some of that text said this:

Successful companies often struggle to anticipate and adapt to competition from new entrants … until it’s too late.

We’re not sure what constitutes successful in that sentence. It seems to us companies that struggle to anticipate and adapt to competition from new entrants until it’s too late might be a lot of things — like unsuccessful or gone — but not successful. But setting that aside, it seems to us that if companies choose to work with vendors that keep their eyes open, that take advantage of the investments being made in insurtech, that recognize the winners, and that make their software flexible and configurable enough to integrate and employ those winners, they’d be much more likely to be successful. And they’d significantly mitigate their risks of being too late.

It’s a good thing developers and investors aren’t willing to settle for the status quo. But neither are we. That’s why we work hard to ensure our customers don’t have to settle for anything, especially legacy technology.

Remember: The software you choose may define your legacy.

Let’s Get Rolling

We saw an article in the September edition of Best’s Review. It’s called, “The Billion-Dollar Question: What’s the Allure of Investing in Insurtechs?” The author starts by explaining what he calls VC math:

As a venture-stage investor, the goal is to deliver five times the returns on the money entrusted to me, within 10 years or so. That’s five times overall, not five times on each investment. Success in venture capital hinges on asymmetric risk. When I write a check, I expect one-third of the investments will crater—a total write-off. Another one-third will be mediocre, returning the principal or a bit more. Success of the fund will depend on a handful of winners in the portfolio. The operative question is not how many losers I have; rather, it’s all a function of the magnitude of my winners. If I have a few investments that deliver 50 times, my losing bets will be forgiven and forgotten.

So far. so good. The VC takes calculated risks in hopes of rich rewards. But this part seemed a bit confusing at first:

Many in the venture community do see insurance as an industry full of vulnerable incumbents. Much of that arises from the lack of widespread technology adoption … and an over-reliance on legacy technology. Many see an even bigger opening as the natural result of legacy culture: Successful companies often struggle to anticipate and adapt to competition from new entrants … until it’s too late. Consider the current environment—a huge market plus pent-up technology plus a belief that incumbents will be slow to respond. Taken together, these create the conditions to support the 50 times outcomes required by VC math.

At first we wondered why, analogously speaking, a VC would back a new producer of wheels for an industry reluctant to buy them? To clarify the analogy, the author’s statement might have read like this: