codel
← Back to the index

INT-10 · SEC. 09 Competitive Intelligence

Incumbent Switching-Cost Teardown

Map documented switching friction and separate it from customer impact that still needs validation.

FORMAT
workflow
DIFFICULTY
intermediate
TIME
12 min
TOOLS
universal
MODELS
any
COPIES
0 so far

When to use this

You're trying to win customers off a specific, named incumbent and keep hearing "switching is too much work" as an objection. Use this to find out precisely what that means so sales and onboarding can address the real cost, not a vague fear of it.

The pattern

Pastes as plain text
This is a teardown of the switching costs around a specific incumbent we're displacing.

Research the incumbent's public data export docs, API docs, integration marketplace, and contract/terms page if available. Then map switching cost across these categories:

1. Data portability: can a customer export their data in a usable format without contacting support? Note any format, size, or plan-tier restrictions on export.
2. Contract lock-in: stated contract length, auto-renewal terms, and any early-termination penalty mentioned publicly.
3. Integration dependency: how many third-party tools commonly connect to this incumbent (check their integration/marketplace page) that a switcher would need to reconnect elsewhere.
4. Retraining cost: how different is the incumbent's core workflow or UI from category norms - is this a tool with unusual terminology or a highly custom workflow that takes real time to unlearn?
5. Migration tooling: does the incumbent, or any third party, offer an import tool or migration service, or is this fully manual today?

For each category, separate DOCUMENTED FRICTION (a public fact such as a
12-month contract, export restriction, or missing migration tool) from
UNVERIFIED BUYER IMPACT (how hard customers experience it in practice).
Do not call a cost "perceived" or low-effort from documentation alone. For
every documented friction, write one sentence on how my product or onboarding
could address it, and name the customer evidence needed to validate the impact.

Before you research anything, ask me in one message and wait: (1) the incumbent's name and URL, (2) my product in one line.

Real example output

1. Data portability: CSV export available self-serve on all tiers, no restrictions found. Documented friction: low. Buyer impact: unverified; ask whether the export contains everything customers need.
2. Contract lock-in: Terms page states a 12-month minimum with auto-renewal and a stated early-termination fee. Documented friction: high. Response: offer to cover or waive the customer's remaining contract cost; validate whether that cost actually blocks the target segment.
3. Integration dependency: Marketplace lists 40+ integrations; no way to tell from public pages how many any given customer actually uses. Documented friction: marketplace breadth. Buyer impact: unverified; flag for sales to ask directly.
4. Retraining cost: Incumbent uses non-standard terminology unlike most tools in this category. Documented friction: terminology difference. Buyer impact: unverified; test a terminology-mapping guide with switchers before sizing the cost.
5. Migration tooling: No official import tool found; several third-party threads mention manual re-mapping as the common path. Documented friction: no official importer found. Response: test an importer for this export format with real migration prospects before calling it the biggest friction.

Why it works

Separating documented friction from buyer impact stops sales from treating public documentation as proof of customer effort. Tying each documented obstacle to a response and a validation question turns a research doc into a testable sales-enablement asset.

Related patterns

Entry INT-10 · by codel · 2026-07-09 · CC-BY-4.0