You cannot walk into a functioning system and announce you're going to change it. The system will reject you. This is true for organisms, organizations, software infrastructure, and sales territories. Systems have immune responses. The louder you announce the change, the stronger the immune response.

The Trojan Horse strategy is the alternative. You don't announce the revolution. You become indispensable first. Then the revolution happens quietly, from the inside, and by the time anyone asks "wait, how did we get here?" — the answer is: you were already here.

Where I Learned This

I spent several years selling enterprise software into accounts with entrenched incumbents. ServiceNow. Salesforce. SAP. The accounts where the incumbent had been there for 10 years, had 200 integrations, and had champions three layers deep. The conventional wisdom was: you needed a sponsor at the C-level, a major pain point the incumbent wasn't addressing, and a compelling migration story.

That playbook worked occasionally. It was exhausting, cycle times were 18 months, and the win rate was miserable. The accounts that actually moved — the ones that flipped from competitor to us cleanly and quickly — all had one thing in common. Nobody announced they were switching. The switch was a conclusion that emerged from a series of small, unremarkable, useful things that happened over time.

How It Works in Enterprise Sales

The classic Trojan Horse in enterprise software looks like this: you get into an account not as a replacement but as an addition. You're not replacing the ticketing system — you're adding an AI layer on top of it that makes the existing system better. You're not replacing the CRM — you're adding an outreach tool that integrates with it.

The key word is "assist." An AI that assists the existing workflow is not a threat. An AI that replaces it is. Same product, different frame, completely different organizational immune response. One gets past security. One gets rejected at the gate.

The language shift — same product, different immune response

"Replace your ticketing system" Rejected
"Assist your agents on top of what you have" Pilot approved
6 months later: AI handling 70% of tickets Expansion
Incumbent displacement Never announced
Chess strategy and positioning
Position first. Announce nothing. Let the evidence accumulate.

The Anatomy of a Good Trojan Horse

Three components make a Trojan Horse work:

A genuine value add, not a foot-in-the-door gimmick. The assist has to be real. If your AI layer genuinely makes the existing system better, the organization adopts it without friction. If it's thin value designed only to get you inside, people notice and you get evicted. The Trojan Horse that works is the one that actually helps — the transformation happens as a side effect of genuine value delivery, not as a bait-and-switch.

Depth over breadth in the initial deployment. Don't try to touch everything. Pick the one workflow where the assist is most obviously valuable, and own it completely. An AI that handles 95% of one category of tickets perfectly is far more powerful than an AI that handles 30% of all tickets adequately. Depth creates the proof point. Proof points create the expansion conversation.

Metrics that accumulate quietly. The Trojan Horse doesn't announce itself. But it keeps a scoreboard. Time saved per week. Tickets deflected. Escalations reduced. These numbers compound. At the six-month mark, when someone asks "what is this AI assistant actually doing," you have an answer that's hard to argue with. The numbers make the case you were never allowed to make in the boardroom.

Where This Goes Wrong

The Trojan Horse strategy fails in two ways:

First: you move too fast. The assist becomes a replacement before the organization has had time to build trust and dependence. The champion who let you in gets blindsided and becomes an enemy. You get evicted faster than you got in. The cadence matters. Let the trust build at the organization's pace, not yours.

Second: you forget to close the loop. The Trojan Horse gets you in. It doesn't close the deal. At some point — usually around month nine to twelve — you need to have the expansion conversation, translate the metrics into a business case, and formally capture the territory you've occupied. The window doesn't stay open forever. At some point procurement starts asking what this thing is and why it's renewing automatically.

"The systems that get disrupted aren't the ones that were attacked. They're the ones that let something useful in."

Business meeting and strategy discussion
The expansion conversation happens after indispensability — never before

The Deeper Principle

The Trojan Horse strategy is not deceptive. That's the important distinction. You're not hiding what the product does. You're sequencing how it's introduced so the organization has time to experience the value before it has to make a decision about the change.

Most enterprise AI deployments fail not because the product is bad but because the change is announced before the value is felt. The announcement activates the immune response. The ROI data comes later. By then the rejection is already in motion.

The Trojan Horse inverts this. Value first. Announcement never — or at least, not until the value is self-evident and the organization has already made the de facto choice. The formal decision becomes a confirmation of something that already happened, not a leap of faith into something unknown.

Systems resist change. Systems don't resist indispensability. The distinction is the entire strategy.

Don't announce the revolution. Become indispensable first.