The insurance CIO said: "Your modern API-based system sounds great. But our core policy admin system is from 1987. It runs on mainframes. The codebase is COBOL. Half the people who built it are retired. How exactly do you integrate with that?"
I'd prepared for API integration questions. I hadn't prepared for "our core system predates the internet."
I fumbled through an answer about integration capabilities and middleware.
He could tell I had no idea: "Let me be direct. We can't replace our core systems. They process billions in premiums. They work. The risk of migration is existential. Every vendor says they'll integrate with legacy systems. Then we discover they've never actually done it. Have you successfully integrated with a 35-year-old mainframe system?"
The honest answer was no.
The deal didn't close.
I learned that insurance tech isn't about replacing old systems with new ones. It's about augmenting ancient infrastructure with modern capabilities while keeping the core systems running.
Why Insurance Tech PMM Is Uniquely Challenging
After three years selling to insurance companies, I learned this industry operates under constraints unlike any other:
Legacy Systems Are Deeply Entrenched
Insurance companies run on technology infrastructure from the 1970s-1990s:
- Policy administration systems (mainframe COBOL)
- Claims management systems (often custom-built decades ago)
- Billing systems (legacy databases)
- Actuarial systems (specialized proprietary software)
These systems:
- Process billions of dollars in premiums
- Contain decades of policy history
- Have business logic embedded in code nobody fully understands anymore
- Are maintained by a shrinking pool of developers who know the technology
Replacing them is nearly impossible:
The risk: Migration could introduce errors in policy calculations, pricing, or claims processing. In insurance, errors mean paying wrong claims amounts or miscalculating policy premiums—both are expensive and potentially regulatory violations.
The cost: Full core system replacement projects take 5-10 years and cost hundreds of millions of dollars. Most fail.
The dependency: Everything connects to the core systems. Replacing them means replacing or reintegrating dozens of downstream systems.
This means buyers aren't looking to replace systems. They're looking to add modern capabilities around legacy cores.
The pitch that failed: "Replace your outdated systems with our modern platform."
The pitch that worked: "Add digital capabilities to your existing systems without touching your core policy admin platform."
Every Product Must Be State-Approved
Insurance is regulated at the state level. Every insurance product must be approved by insurance commissioners in every state where it's sold.
This creates wild complexity:
50 different state regulators with different requirements, different approval processes, different timelines.
A new auto insurance product needs approval in 50 states. Each state reviews:
- Policy language
- Pricing algorithms
- Coverage terms
- Claims handling procedures
This approval process takes 6-18 months per state.
Now imagine you're selling software that changes how insurance products are priced, sold, or administered. Your software changes must be reflected in state filings.
One prospect said: "Your software optimizes pricing using machine learning. That's great. But we can't use a pricing algorithm we can't explain to state regulators. They need to understand and approve our pricing methodology. Can you explain your ML model in terms a non-technical insurance commissioner will approve?"
I couldn't.
We had to rebuild our product to offer:
- Transparent, explainable pricing models
- Audit trails showing how prices were calculated
- Documentation suitable for regulatory filing
- State-by-state configuration for different regulatory requirements
In insurance tech, your software isn't just selling to the insurance company. It's selling to 50 state insurance departments.
Change Must Not Disrupt Policy Administration
Insurance companies can't afford downtime or errors in core operations.
If a policy admin system goes down:
- New policies can't be issued
- Renewals can't be processed
- Claims can't be paid
- Regulatory reports can't be generated
Even minor errors cascade:
A billing system error that undercharges $10/month across 100,000 policies = $1M annual revenue loss.
A claims processing error that overpays 1% of claims by 10% = millions in excess payments.
This makes insurance buyers incredibly risk-averse about software changes:
"Our current system is old and inefficient. But it works. It's been processing policies correctly for 30 years. Why would we risk changing it?"
Every software pitch triggers this calculation:
Potential upside from new software vs. Risk of disrupting working operations
The risk often feels larger than the upside.
We changed our implementation approach:
Old approach: "Full migration to our platform in 6 months." (Too risky—what if migration fails?)
New approach: "Run parallel to your existing system for 12 months. Prove accuracy and reliability. Cutover only after complete validation." (Lower risk—can fall back to old system if anything goes wrong)
The Buyers Are Insurance People, Not Tech People
Insurance executives come from insurance careers:
- Underwriters who became VPs
- Claims adjusters who became executives
- Actuaries who became CIOs
They think in insurance terms:
- Loss ratios
- Combined ratios
- Claims frequency
- Policy retention
- Premium growth
Software is just a tool enabling better insurance operations.
I made this mistake early, pitching "digital transformation" and "modern cloud architecture."
The SVP of Operations interrupted: "I don't care about cloud architecture. Will this improve our combined ratio? That's what I'm measured on."
I didn't know what a combined ratio was. The demo ended.
(Combined ratio = claims + expenses / premiums. Under 100% = profitable. Over 100% = unprofitable.)
I rebuilt our messaging around insurance metrics:
Tech-focused: "Our cloud-native platform leverages AI for automated processing."
Insurance-focused: "Our platform reduces claims processing costs by 18% and improves claims accuracy, directly improving your combined ratio."
Speak their language. Measure what they measure.
Long Product Lifecycles Mean Slow Decision Cycles
Insurance products have multi-decade lifecycles:
A homeowner's policy sold today might not pay out a claim for 20 years (think: slow-moving foundation damage).
An annuity product sold today might pay out in 40 years (retirement).
This creates conservative decision-making:
"We need software that will still work in 20 years. Will your startup be around in 20 years?"
Fair question. Most startups aren't.
We had to prove longevity and stability:
- Financial backing from established investors
- Customer base including large carriers
- Escrow arrangements for source code (if we shut down, customers get code)
- Data export capabilities (customers can leave any time)
We also built partnership relationships with established insurance technology vendors who'd been in the market for 30+ years. Their implicit endorsement helped prove we weren't a risky flash-in-the-pan startup.
What Actually Works in Insurance Tech Marketing
After three years of failed pitches and legacy integration nightmares, here's what works:
Position as "Augmentation" Not "Replacement"
Don't pitch replacing core systems. Pitch augmenting them.
Bad positioning: "Replace your outdated policy admin system with our modern platform." (Impossible and terrifying to buyers)
Better positioning: "Add digital distribution, automated underwriting, and customer portals to your existing systems without touching your core policy admin platform." (Feasible and lower risk)
Insurance companies want modern digital experiences. They don't want to replace working core systems.
Build Proof Through Carrier-Specific Case Studies
Insurance buyers trust other insurance companies more than vendor claims.
We created carrier-type-specific case studies:
For P&C insurers: "How a regional auto insurer reduced claims processing time by 40% while maintaining existing policy admin systems."
For life insurers: "How a life insurance carrier added digital distribution without replacing their 30-year-old policy admin platform."
For health insurers: "How a health plan improved member experience with modern portals integrated to legacy claims systems."
Each carrier type has different systems, different regulations, different challenges.
Demonstrate Regulatory Understanding
Insurance buyers need to know you understand their regulatory environment.
We created regulatory documentation:
- State-by-state requirement summaries
- Regulatory approval process guidance
- Example state filing language
- Compliance checklists
This demonstrated we understood insurance wasn't just technology—it was regulated financial services.
Prove Legacy Integration Capability
Don't just claim you can integrate with legacy systems. Prove it.
We built reference architectures for common legacy platforms:
- Guidewire integration examples
- Duck Creek integration examples
- Custom mainframe integration case studies
- Batch file processing (for systems without APIs)
We hired engineers with insurance technology backgrounds who actually understood COBOL, mainframe systems, and batch processing.
This credibility mattered enormously. Insurance IT teams could have technical conversations with our engineers who'd actually done legacy integration.
Create Long-Term Relationship Programs
Insurance decisions happen slowly. Sales cycles are 12-18 months.
We built long-term relationship programs:
- Industry conference sponsorships
- Insurance association memberships
- Educational content about digital transformation
- Executive roundtables
These relationships built trust over time. When buyers were ready to make decisions 18 months later, we'd been adding value the entire time.
Use Insurance Industry Language
Insurance has specific terminology. Use it correctly.
Bad: "Reduce customer churn" (Insurance people don't say "churn")
Good: "Improve policy retention and persistency" (Correct insurance terminology)
Bad: "Improve customer lifetime value" (Too vague)
Good: "Reduce lapse rates and increase policy renewals" (Specific insurance metrics)
Speaking the language correctly signals you understand the industry.
Managing carrier-type-specific messaging, state-by-state regulatory requirements, and legacy integration details across P&C, life, and health insurance segments created content complexity. I used tools like Segment8 to organize messaging frameworks and competitive intelligence by insurance type—being able to quickly access the right battle cards for auto insurance carriers vs. life insurance carriers saved time in competitive situations.
The Unexpected Advantages of Insurance Tech
Despite the legacy systems and slow decision cycles, insurance tech has advantages:
Contract values are large. Insurance carriers are big companies with big budgets. Average deal size: $250K-$500K annually.
Retention is extremely high. Once integrated with core systems, switching is nearly impossible. Our retention rate: 98%.
Expansion revenue is strong. Start with one product line (auto insurance), expand to others (home, commercial). Our net revenue retention: 140%.
Professional relationships matter. Insurance is relationship-driven. One successful implementation leads to referrals within insurance networks.
Eighteen months after the CIO asked about COBOL mainframe integration, we closed the deal.
Not because we could replace his legacy systems. Because we proved we could integrate with them.
We built a mainframe integration connector. We demonstrated it working with similar legacy systems. We provided references from other carriers who'd successfully integrated.
His team implemented our digital portal and automated underwriting while keeping the 35-year-old policy admin system untouched.
Six months post-implementation:
- 40% of new policies came through digital channels
- Underwriting automation reduced processing time by 60%
- The legacy system was still running perfectly
He introduced us to three other insurance carriers.
Insurance tech marketing isn't about flashy innovation or disruption. It's about respecting legacy systems and regulatory complexity while adding modern capabilities.
The playbook:
- Position as augmentation, not replacement
- Build carrier-type-specific proof and case studies
- Demonstrate regulatory understanding
- Prove legacy integration capability
- Create long-term relationship programs
- Use correct insurance terminology
Insurance moves slowly for good reasons. The companies that win respect those reasons and work within the constraints.
That's how you win in insurance tech.