What I want to explore today are application programming interfaces, or APIs, but the term is off-putting—technical and perhaps even intimidating. So, let's start with two maxims from Silicon Valley that frame the issue in a friendlier way. Then, we'll look at how a radical approach to APIs has helped Amazon be a mega-success, how they are leading to redesigns for car makers and how they could drive broad innovation in insurance. Lemonade—surprise, surprise—offers an early example of what's possible.
The two maxims:
"Software is eating the world." — Marc Andreessen, a prominent venture capitalist who created the first commercial internet browser more than 20 years ago.
"No matter who you are, not all the smart people work for you." — Bill Joy, a co-founder of Sun Microsystems who wrote the version of the Unix operating system that made it widely popular and who is now a venture capitalist.
Looked at from an insurance perspective, I see Andreessen saying: If you want to be the eater, not the eaten, you need to turn your business into software. Stop thinking about having factories that churn out paper full of legalese and imagine insurance as software. I see Joy saying: Figure out how you can fit into an ecosystem and draw on all those smart people who work for somebody else.
Those two maxims lead to APIs, because they are the technical expression of how you turn your business into software and how you coordinate with all those other smart people. Get the API issue right, and other problems fall away.
APIs are really just definitions of how pieces of software will work with other pieces of software. You're writing an app that needs to include a calculator? You check the API for that calculator object and make sure your app talks to that object in the way it specifies. You don't talk the equivalent of English if the object speaks the equivalent of Spanish. You don't spell "favor" as "favour" if the object speaks the equivalent of American English, not British English.
The magic of APIs is that they're so detailed that all the complexity behind them is hidden. If I want to collaborate with you on something related to software, I don't have to get into long conversations about governance or coordination. I can just say: "Here is my API." You then make sure that you meet the specs, and we're good. You get to draw on all my smart people, and I get to draw on yours.
That's the Joy's Law piece of the puzzle. The Andreessen piece requires specifying APIs for as much of your business as possible. Set up underwriting so that someone with a great bit of software for understanding some type of risk can just plug in once you share your API with the company. (Many APIs are public, but they don't need to be.) Set up claims so that someone with a new way of spotting fraud can just plug in.
Rethinking your business as a software platform or operating system will take some serious effort but will pay huge dividends. Just look at tech giants like Microsoft, Google and Facebook to see the benefits of being able to absorb others' innovations.
Amazon may have taken the most radical approach to APIs. From its early days, Amazon had all parts of its business express themselves as APIs. In other words, they specified, in software, how they would export information and how they would import it, what capabilities they offered and what they needed, etc. All communication had to happen through these interfaces. The specificity simplified coordination both inside Amazon and with outsiders. And the approach seems to have worked out okay....
Car companies, which have always struck me as insurance-like in their determination to do everything in-house, are finding that they can no longer deny the power of APIs. For instance, historically, car makers designed every single detail of the dashboard -- the entertainment system, perhaps mapping, etc. Now, they are finding that people increasingly want an Ox Cord (a term that I assume began as "auxiliary cord," or "aux cord"). Customers want to be able to plug a smartphone into the dashboard to run their own entertainment, mapping, etc. Car companies are responding by designing dashboards that function more as a screen and speakers and by publishing APIs that define how those smartphone connections can happen. The companies will lose some control but wind up with far more robust systems -- and happier customers.
Lemonade is publishing APIs that will let it cross traditional insurance-industry boundaries and easily collaborate with outsiders that might help sell its products. Why just rely on agents or a website when you can have realtors, for instance, seamlessly direct people to you as part of a rental or purchase?
What Lemonade is doing should be just the beginning of more fundamental innovations—at least, if I'm right that lots of the boundaries between traditional product lines will blur or even go away. For instance, life insurance has historically been sold as a separate product to protect a family if the primary breadwinner died but increasingly will, I believe, be incorporated into financial planning. Thinking of life insurance, investment vehicles, benefits programs, etc. as software, not products, and specifying APIs will greatly simplify the sort of combination and innovation that I believe must happen.
If you develop an API-based strategy, you will greatly improve your chances of being the diner, not the dinner.
Cheers,
Paul Carroll,
Editor in Chief
