When your tech partner also competes with you

You are on a discovery call and the overlap is obvious. Their product does a piece of what yours does. Yours does a piece of what theirs does. The partner manager still wants to "explore a partnership." Your sales lead wants to hang up. Both instincts are incomplete.

Plenty of durable technology partnerships sit on complementary overlap: two products that compete on the margin and cooperate in the middle, because the customer runs a workflow neither of you covers alone. That pattern is co-opetition, and it is normal in software. It is also how you leak roadmap, train a competitor, and wake up selling against the company on your partners page. This post is how to draw the line: what overlap is complementary, how to wall off the rest, and when to walk away. It sits next to partner ICP, SaaS partnership agreements, and sunset a partnership.

The 60-second version

If you only read one section, read this one:

• Overlap is not automatically a no. Complementary overlap (different core job, shared workflow) can be a partnership. Same core job, same buyer, same moment of sale is a competitor wearing a partner badge.
• Draw the line in writing: what you will integrate, what you will not discuss, what you will not sell together, and what happens in a contested deal.
• Co-opetition needs walls. Separate the joint SKU from the competitive SKUs. Separate the people. Separate the data.
• Sales conflict is the test. If their reps already displace you in live deals, a logo on a page will not fix it. Either ring-fence those deals or do not partner.
• Do not share roadmap, pricing, or named pipeline across the competitive edge. Integrate products, not strategies.
• Walk away when the overlap is the product, when they need your customers more than the joint workflow, or when they will not accept a written boundary.
• Revisit the line every QBR. Overlap moves as both roadmaps move. A partnership that was complementary last year can be a collision this year.

Complementary overlap vs a competitor in the room

Start with the customer's job, not with feature lists. Two products can share features and still be complementary if the job the customer hires each for is different. A planning tool and an execution tool both "manage work" and still pair. Two execution tools with the same objects, the same buyer, and a rip-and-replace sales motion do not.

A practical split:

Complementary overlap. Each product has a core job the other does not want to own. The overlap is a boundary layer (status, identity, a file, a record) that the customer already stitches by hand. An integration replaces that stitching. You may compete for budget, not for the same line item.

Adjacency that will collide. You are both expanding toward the same module. Today you partner. In 18 months you will both claim that module. This is a time-boxed partnership, not a strategy. Write a shorter term and a sunset review.

Direct competition. Same core job, same partner ICP buyer, sellers already told to displace the other. A strategic alliance language does not change that. You can still have a thin technical integration if customers demand it. You should not have a co-sell motion, shared pipeline, or a joint brand.

Independent software vendors on the same platform live in this mess all the time: they integrate because the platform's customer needs both, and they compete because the platform's next feature could replace either of them. The ones who survive it are specific about the joint workflow and silent about everything else.

Hypothetical: your product does catalog and their product does storefront. Overlap on "product information." That is complementary if each of you stays on your side of the handoff. It is a collision if they just shipped a catalog and their sellers are attaching it to every deal you are in.

Use the partnership prioritization framework to force the question: does this partner create a workflow your customers will use, or does it create access for someone who wants your book of business?

What you can still do together

Complementary overlap does not mean "do everything" or "do nothing." There is a middle set of motions that are usually safe, and a set that are not.

If the only motion that survives the table is a thin integration, that is the partnership. Call it that. Do not staff a co-sell engine on top of it.

How to draw the line (and keep it)

If you proceed, the boundary is the product. A warm sentence in a kickoff call will not survive the first contested opportunity.

Write four lists, short enough to put in the partnership one-pager:

1. In scope. The objects you will sync, the joint workflow, the SKU or listing name. This is what the integration is allowed to be.

2. Out of scope. Modules you will not integrate, data you will not share (pricing, named pipeline, unreleased roadmap, win/loss), motions you will not run (bundling your core against theirs).

3. Contested-deal rule. When both of you are in the same account for overlapping SKUs: no joint pitch, no sharing of notes, each sells their core, the integration is not used as a wedge to replace the other. If you cannot say that sentence, you cannot co-sell.

4. People wall. The humans who see joint roadmap and account lists are not the humans who price the competitive SKU. In a small company this is imperfect. It is still worth naming. One founder seeing everything is normal. Feeding their full sales team your live pipeline is not.

Put the lists in the agreement as an exhibit, next to confidentiality. You already need IP, data, and termination; add "competitive overlap" as a defined topic: what may be used only to operate the integration, and what may not be used to sell against the other party. This is not a substitute for counsel, and it is not a non-compete on your whole company. It is a use restriction on the data the partnership creates.

Operating rules that keep co-opetition from turning into a leak:

• Share product facts needed to build the joint workflow. Do not share future pricing, packaging changes, or named target accounts outside the joint motion.
• Register joint deals as joint. Everything else stays in your CRM.
• Enable their sellers on the joint workflow only, not on "how we win against you."
• At the partner QBR, review overlap as a standing topic: new modules either side shipped, contested deals, whether the line moved.

Channel partners programs have lived with this for a long time: a reseller who also has a competing line card. The healthy version is a line-card rule (when they pitch you, when they pitch the other). The unhealthy version is pretending the other line does not exist.

When to walk away

Walking is a professional move. It is cheaper than a partnership that funds a competitor.

Walk, or refuse to go deeper than a customer-requested integration, when:

• The overlap is the product. If a customer could replace you with them after the integration teaches them the workflow, you are onboarding a successor. Do not teach them.
• Their ask is accounts, not workflow. Discovery that skips the joint job and goes straight to "let us map your customer list" is not a partnership. It is prospecting.
• They will not accept a written boundary. If out-of-scope and contested-deal rules are "too legal," they want optionality on your data. Decline.
• Sales is already at war, and leadership will not issue a stand-down on contested SKUs. A partnerships team cannot paper over a field conflict their own execs will not name.
• The commercial model requires you to share too much. A deep OEM embed or a white-label into a competitor is how you disappear inside someone who sells against you. Thin technical integration is the most you should offer.

You can still be civil. Customers who use both products deserve a working connection. A documented, supportable integration with no co-sell, no MDF, and no lead sharing is a valid answer. Call it what it is: a customer-requested integration, not an alliance.

If you already signed and the line has moved, treat it as a sunset candidate. Use the same honesty you would on a dead integration: notice, what happens to customers, what marks come down. See sunset a partnership. Staying because the logo is on the site is how overlap becomes a permanent leak.

Re-qualify overlap the way you re-qualify any partner: at onboard, at QBR, and when either roadmap ships a module that used to be "theirs" or "yours." Complementary is a snapshot, not a personality trait.

Common mistakes, and the fix

Pretending there is no overlap because you want the logo. The fix: draw the four lists in the first week. If you cannot, you do not have a partnership. You have a hope.

Co-selling the core against each other under a joint banner. The fix: joint pitch only on the in-scope workflow. Contested SKUs are independent. Mixing them trains both sales teams to use the partnership as a weapon.

Sharing named pipeline "so we can map." The fix: map agreed joint accounts, one list, both sides already in the deal. Do not swap books.

No people wall in a small team. The fix: you may not have two teams. You can still refuse to send live pricing and open opps to their field. Founder-to-founder is not the same as CRM-to-CRM.

Staying after they shipped your core. The fix: a QBR decision, then a sunset path. Loyalty to a logo is not a strategy.

FAQ

Can we partner with a competitor at all? Yes, when the joint workflow is real and the core jobs stay different. No, when the partnership would exist mainly to move accounts. Customer-requested integrations sit in between: ship the connection, skip the alliance.

What is co-opetition in this context? Cooperating on one workflow while competing on another. It only works with a written in-scope list, a contested-deal rule, and data walls.

Should we put a non-compete in the partner agreement? A broad non-compete is usually the wrong tool. A use restriction on partnership data and a contested-deal process are the terms that matter. Get counsel. This is not legal advice.

How do we handle a deal where both of us are already in the account? Do not run a joint pitch on overlapping SKUs. Each sells their core. Attach the integration after the stack is chosen, not as a wedge. Tag the deal as contested.

What if customers demand we integrate with a competitor? Build a thin, supportable integration. Do not add co-sell, lead sharing, or a joint brand. Customer demand is a reason to connect products, not a reason to open your pipeline.

Do we tell sales about the overlap? Yes. If you hide it, they will discover it in a deal and conclude partnerships cannot be trusted. Give them the in-scope list and the contested-deal rule.

How often should we revisit the boundary? Every QBR, and whenever either company ships a module that crosses the line.

When is a press-release "alliance" with a competitor actually useful? Almost never, if the only artifact is the release. A named workflow, a working integration, and a support path can be useful.

Further reading

• Strategic alliance: the structure people mean when they say partnership, and why it still needs a boundary when the parties also compete.
• Independent software vendor: the role in which overlap on a shared platform is common and has to be managed, not wished away.
• Channel partners: how indirect channels have long handled a partner who also carries a competing line.

The short version

Overlap does not kill a technology partnership. Unspoken overlap does. Complementary overlap (different core jobs, a shared handoff) can be a real motion. Same core job, same buyer, live displacement is a competitor. Draw in-scope, out-of-scope, contested-deal, and people-wall lists in writing, and keep partnership data on the partnership side of the line.

Walk when they want your accounts, when they will not accept a boundary, or when the integration would teach a successor. A thin, customer-requested connection is always available. An alliance is not mandatory.

If you want help deciding whether a messy overlap is a partnership or a leak, that is exactly what a Partner Audit is for.