How to get innovation across the line at a warranty company

Last week I was in Chicago for the Warranty Innovations conference, the 17th Annual Extended Warranty & Service Contract Innovations. It is one of the few places where so much of the warranty industry is in one room at the same time: carriers, administrators, OEMs, retailers, lawyers and the people building the technology around them. Everyone there knows more about some corner of this business than I do, and that is exactly why I go.

I spoke alongside Jesse Wilson, Managing Member of Warranty Legal. Our session was focused on navigating the legal, operational and tech challenges of AI implementation, but really it was trying to show folks faster ways to get S%^t done.

We opened with a promise: we were not going to sell anyone anything. Most of the conference was about the “what”. We wanted to spend our time on the “how”: how you actually get an innovation approved and shipped inside your own company.

This article walks you through what we shared during our session.

Everyone is being told to innovate

You have heard it all year. The board is telling the executive team to innovate. The CEO is telling every team to use AI. Every vendor at the conference, us included, has an answer to your pain points. And it does not stop when you leave the office. Every article, podcast and clip promises that some company automated its whole team away with one tool.

So the pressure is real, and so is the desire to change. When we asked the room who had scars from a past innovation project, plenty of hands went up. Mine included. None of the companies in that room are small, and change at that size is always harder than it should be.

Which leads to the question nobody likes to ask out loud: even if you find the right solution, will your organization actually let you get it across the line?

The opportunity is not the problem

Everyone in warranty is working on some version of the same goals: lower severity, lower cost to serve, faster cycle times and growth. Everyone in that room could see the business case for improving them.

What gets in the way is the status quo. And the status quo is not laziness. It is structural. The things that make a warranty company run well are the same things that slow it down when you try to change it. Departments have different KPIs and different roadmaps. Nobody is wrong. Each team is optimizing for something different.

The desire to change is there. What is missing is an innovation playbook.

Every initiative has to cross three bridges

Even with leadership behind it, every innovation initiative has to cross three bridges:

1. Business and operations. Does it move a metric the business already owns, will the people doing the work adopt it, are their plates already overflowing?

2. Legal, security and compliance. What data does it touch, what access does it need, what does the contract have to say, and most importantly, what is the standard turnaround time?

3. IT and technology. What does the roadmap look like, is this already on it, does it connect to the systems you already run, who will support it in the future?

There are two ways to cross them.

Sequentially. Business makes the case, then hands it to legal, then to IT, then to enablement. Each step can take months. A sequence like four months of business review, six months of legal and three months of IT puts you a year to a year and a half out before anyone is using the thing, and a competitor may have shipped twice in the meantime.

In parallel. Legal questions are clarified in the first 30 days instead of surfacing at the end. IT is in the room from day one, helping design the first version. Enablement runs alongside implementation rather than after it. Run this way, the same initiative can ship in a quarter and be measured the next.

Jesse made a point here that stuck with people: legal does not have to be the department that says no at the end. Brought in early, legal can define the terms, scope the data and access, and clear the path, which makes them one of the people who gets the project shipped.

Start with permission to innovate

Before anything else, you need permission to innovate. Sometimes the CEO declares something a priority. Sometimes an internal champion builds the consensus. Either works. What matters is what permission actually requires, and we think cross-functional alignment comes down to three things, locked in before you start:

• Executive alignment. Your leadership team agrees this is a problem worth solving and worth testing. Not one executive, but the CEO and the legal, operations and technology leaders together.

• Cross-functional authority. Someone can work across silos without asking permission every time. That person has to manage execution and build consensus, which is harder than it sounds.

• Graduation criteria. Define what success looks like before you start, not six months into the experiment. Clear criteria, and hitting them, are what let you move from pilot to production quickly. Most pilots that stall do so for exactly this reason; we wrote more about why AI pilots stall before production.

Structure the MVP to clear the blockers early

Once you have permission, the way you structure the first version determines how fast it moves. Four principles:

1. Get buy-in. Design an experiment that produces a win for multiple teams, not just the one sponsoring it.

2. Involve cross-functional teams early. Bring them in from day one, procurement included. Understand their roadmaps during planning for the next quarter, and look for wins that matter to more than one team.

3. Be nimble. Start with an integration, not an infrastructure overhaul. Tie it to a metric operations already owns, and scope the data and access up front so legal and security are never surprised. How you connect to your existing systems is a day one decision; Eui Chung, our CTO, wrote about headed vs. headless integration.

4. Show up with data. Hard evidence ends debates that slides never will. As I like to put it, no one can argue with data, but people can argue with decks all they want.

The point of the proof of concept is not only to prove the idea works. It is to surface early and on a small scale some of the blockers every other part of the business is going to raise, so they are already in consideration by the time you ask to scale.

Build the system, not the hero

The goal of doing this once is to never have to fight this hard again. The companies that innovate consistently do not rely on one heroic project. They build a system:

• cross-functional innovation teams

• quarterly research cycles

• annual hackathons

• clear criteria for graduating an experiment to production

• recognition for the internal champions who push things through

The real innovation is not any single product. It is a team and a process that can ship again and again.

The time is now

There are great companies in the warranty industry, and plenty of partners who can help with any specific problem, whether you decide to build, buy or layer something on top of what you have.

The harder question is whether your organization is ready to ship. With AI, that question gets more urgent every quarter, because the advantage compounds. The companies that ship first build a cost and retention lead that grows for years.

Thank you to Jesse for sharing the stage, and to everyone who stopped us afterward to talk about their own projects. If any of this resonated and you want to talk through a practical way to get something moving inside your organization, I would be glad to hear from you.