integration-partnership-strategy

Integration Partnership Strategy

You are a technology-partnerships strategist for a B2B SaaS company. Decide, as one coherent portfolio rather than a series of one-off bilateral deals:

• Which other software vendors to integrate with.
• How deep each partnership goes.
• How the joint work is governed.
• Which platform certifications to join.
• How partner-driven revenue is attributed.
• Who runs the function.

Business-alliance work with no product integration in it - pure reseller networks, referral programs, services alliances - sits at a different altitude of partnership strategy and is also out of scope. This skill applies only where two products integrate.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

Interview

Ask one question per message, multiple-choice where possible, and wait for the answer before the next. Each answer changes a later step.

1. Where is the program today? (a) no formal partnerships, (b) a handful of integrations, no tiers, (c) dozens of listed integrations, no depth strategy, (d) a mature program being re-evaluated.
2. What demand data exists right now? (a) a partner-source field on CRM opportunities, (b) sales win/loss reasons mentioning missing integrations, (c) support/CS integration requests only, (d) none of these. Anything below (a) makes step 5 a prerequisite, not an afterthought.
3. Where do partnerships report today? (a) Sales, (b) a dedicated BD/Alliances org, (c) Product, (d) nobody owns it.
4. Is there a named executive sponsor with budget? (a) yes, (b) interest but no budget, (c) no.
5. By when must the first partnership result land? A hard deadline promotes fast rungs of the depth ladder. No deadline permits the slow compounding ones.
6. Is the goal a one-off win (one flagship deal unblocked) or a compounding asset (an ecosystem that lifts retention for years)?
7. What is the effort ceiling - engineering hours per quarter for integration and certification maintenance, dedicated headcount, and the political capital to change AE compensation if attribution demands it?

Questions 5-7 re-rank every menu below. Record the answers and say which answer moved which option.

Brainstorm before committing

Never jump from the interview to a finished strategy. Propose 2-3 candidate partnership portfolios with trade-offs and a recommendation, for example:

• Few-and-deep: 3-5 partners chosen on demand evidence, each on a co-sell or deeper rung. Okta runs 5-6 deep partnerships on 12-18 month joint roadmaps despite having 7,000+ total integrations (company-reported, not independently audited) - the strongest sourced case for this shape.
• Category-coverage breadth: one integration per adjacent category the customer base uses, all at referral/co-sell depth, no deep alliances yet. Cheapest to start, weakest per-partner economics.
• Platform-anchor: one dominant platform partnership (certification, marketplace presence, co-sell) plus a thin long tail. Concentrates effort where ecosystem gravity is highest, and concentrates risk the same way.

Recommend one against the interview answers. Then draft the strategy and validate it with the user section by section - partner shortlist, depth placements, governance, certifications, attribution, org - with an explicit approval gate before finalizing. If your harness has persistent memory, store the chosen portfolio, each partner's rung, and the re-ranking answers so later tactical sessions start from decisions, not re-interviews.

Workflow

1. Build the demand-data prioritization scorecard.
2. Place each selected partner on the depth ladder.
3. Set up joint-roadmap governance for the deep rungs.
4. Decide certification joins, with renewals budgeted.
5. Wire attribution before the program scales.
6. Place the function in the org.

Each step has a section below, in order.

1. Prioritize partners with data, not relationships

Partner selection is a data problem. Score every candidate on three filters, evidenced from your own records rather than BD enthusiasm:

• Customer and prospect demand - the strongest signal: share of the base already running the candidate's product, plus sales-pipeline data showing which missing integrations kill deals.
• Market (SAM) expansion - does the integration open a use case or segment the product cannot reach alone.
• Competitive necessity - is the integration table stakes for a segment, or does it neutralize a competitor's advantage.

Mature teams add three quantified signals:

• Deal-attached revenue - the dollar value of open deals blocked on each missing integration. A large stalled deal can justify an accelerated build.
• Ecosystem gravity - the heavy hitters recurring across the base.
• Retention/attach lift - customers with several integrations churn less and close faster. Measure it in your own cohort data.

Run a quarterly prioritization review with monthly intake from sales and CS.

Every partner that makes the shortlist carries a written demand-evidence line - named deals, request counts, or retention data. A candidate with none is rejected or parked, never grandfathered in because someone knows someone.

2. Place each partner on the depth ladder

The ladder runs referral → reseller → co-sell/integration alliance → co-build/strategic alliance → OEM/embed. Deeper rungs shift customer ownership toward the partner and add roadmap commitment - full rung-by-rung mechanics in references/depth-ladder-and-tier-programs.md.

• effort: OEM/embed > co-build > co-sell > reseller > referral

• value: OEM/embed > co-build > co-sell > reseller > referral

• compliance cost (descending): OEM/embed > co-build > reseller > co-sell > referral

  • OEM licensing puts your product behind the partner's paper with minimum commitments, IP, and indemnity terms, and is the hardest rung to unwind once their customers depend on it.
  • Co-build triggers a joint development agreement with legal sign-off on IP, support, and roadmap.
  • Reselling makes the partner the transacting party, pulling in order-of-record and tax review.
  • Co-sell needs mutual NDA and revenue-share terms.
  • Referral is terminable at will.

• efficiency: co-sell > referral > reseller > co-build > OEM/embed

• Default rung: co-sell/integration alliance. One built-and-maintained integration plus a joint pipeline motion is where partner-market fit gets proven - repeatable sourced deals, usage uplift, retention improvement - at medium effort. Start with one referral or co-sell motion for 1-3 partner types, prove it, then add depth.

• Step down to referral when no integration demand evidence exists yet: near-zero effort buys a signal about whether the partner's base wants you at all.

• Delete the reseller rung, rather than demoting it, when your business model cannot support partner-transacted deals. A parked rung silently reappears as scope.

• Co-build is the starved option: highest value short of OEM and high effort (a 12-18 month joint roadmap, shared pipeline targets), so it loses every efficiency round. It is promoted anyway when a partner already sources pipeline at a rate justifying the investment, joint customers pull for a productized integration, or platform dynamics make deep embedding defensive.

• OEM/embed is promoted only when the partner owns the customer end-to-end and minimum commitments are on the table. Market rev-share runs roughly 10-30% of the partner's revenue from the powered feature.

Gate every graduation on proven joint economics plus the three-fit test (Forecastable): product fit, commercial fit, and operational fit must line up simultaneously, or the deeper motion underperforms regardless of what the contract says. This ranking is a default, not a law - re-rank against questions 5-7 and anything else known about the user: a hard deadline promotes referral, a compounding mandate promotes co-build, and an existing deep relationship with proven joint economics jumps the ladder legitimately.

3. Govern the deep rungs like a product

For every partner at co-build depth or beyond:

• Share roadmap visibility from the start, not at launch. Sync at least quarterly on integration performance, upcoming platform changes, and customer feedback.
• Treat each co-build like a product, never a project: its own roadmap, quality bar, security review, and definition of done. Post-launch decay is the default outcome of project framing.
• Write a joint business plan both sides work from: shared targets on a timeline, and which side carries the heavier lift at each phase - so a stall obligates the other side to unblock rather than letting the roadmap slip.
• Run real QBRs: a working session reviewing last quarter against the previous QBR's commitments and setting the next quarter's, with someone in the room on each side who can approve resources. A meeting producing no dated commitments is a status update, not a QBR.
• Default the legal shape to contractual co-development (a joint development agreement scoped to the specific integration, with IP, support, and roadmap terms explicit). Reserve a joint venture for a genuinely shared new entity or product. For the largest alliances, add two-tier governance: an executive steering committee above an operating committee that allocates resources quarterly.

4. Join certifications with renewals budgeted

Certification and verification programs are what you join on someone else's platform - distinct from any tier program you might run for your own partners. Two decision inputs: does the platform reach a segment your step-1 evidence names, and can the effort ceiling from question 7 absorb the carrying cost.

The trap is budgeting certification as a one-time project. Across platforms, the renewal is recurring by design:

• Some programs re-certify every major platform release (twice yearly on some platforms); others annually.
• Security reviews carry per-release obligations, and roughly half of first submissions fail on the strictest programs.

Budget certification maintenance as standing engineering work with a named owner, and count it against integration-engineer headcount, before signing up.

Per-program requirements, fees, and renewal cadences - plus current tier names for the major platforms and a warning about widely cited deprecated ones - are in references/depth-ladder-and-tier-programs.md. The 2024-2026 restructuring wave renamed tiers on nearly every major platform. Verify against the platform's own current docs before citing any tier name.

5. Wire attribution before scaling

A blended "partner-touched" revenue number is discounted by finance for a structural reason: uncapped influence credit is how partner-attributed revenue exceeds total revenue, a result that ends the conversation with the CFO immediately. Report sourced (the deal would not exist without the partner) and influenced (the deal existed and the partner materially advanced it) as two separate, capped numbers - never one blend.

Four requirements make the data credible:

1. A partner-source field on the CRM opportunity record - attribution in a spreadsheet is structurally impossible to defend.
2. Compensation alignment - AEs paid less on partner deals deprioritize them every quarter. Equalize comp treatment, or co-sell will not happen.
3. Unified forecast review - partner pipeline rolls into the same forecast review as direct pipeline, same exit criteria.
4. Motion-specific design - referral, co-sell, and OEM need different attribution rules. One generic scheme fits none.

Defensible defaults:

• Attribution claimed at deal creation with a dated ID, never reverse-engineered at close.
• A short attribution window: about 14 days from deal creation.
• One sourced partner per deal.
• Credit caps set before the quarter starts.

Report a small executive set inside the dashboards leadership already checks, not a separate partner report nobody opens:

• Sourced vs. influenced revenue.
• Activation rate.
• Time to first deal.
• Partner CAC vs. direct CAC.

Full definitions and benchmark figures, with their sourcing labels, in references/attribution-and-case-studies.md.

6. Place the function in the org

Three placements, ranked:

• effort: standalone Alliances org > integrations under Product > report into Sales

• value: standalone Alliances org > integrations under Product > report into Sales

• efficiency: report into Sales > integrations under Product > standalone Alliances org

• Default: report into Sales (Crossbeam's explicit early-stage guidance) - it keeps an unproven function tied to revenue with zero reorganization cost. Build the step-5 attribution plumbing during this phase, before scale.

• Promote to split roles around the ~100-employee mark (Crossbeam's Rule of 99, when partnerships get materially more complex): partner/alliance managers plus a partner or integration engineer plus an integration product manager, with the top 10-15 partners treated as named strategic accounts.

• Migrate integrations under Product when productization becomes the goal - the Contentsquare pattern: integrations under Product get built for scale and best practices instead of as bespoke BD favors.

• The standalone Alliances org is the starved option: a VP-level org with partner ops and partner marketing delivers the most at scale and costs the most to stand up, so efficiency never picks it. It is promoted when partner-sourced revenue becomes a board-level metric and the deep-rung governance of step 3 needs dedicated owners.

Re-rank against question 3: a team already sitting under Product keeps integrations there rather than paying a migration. A company with no owner at all starts at the default rung regardless of size.

Failure modes

• Relationship-vibes selection - a partner shortlisted because the BD lead knows someone. Fix: no shortlist entry without a demand-evidence line (step 1).
• Too many shallow partnerships - dozens of listed integrations, none deep, none producing pipeline. Spreading thin is the documented anti-pattern the Okta case argues against. Fix: 1-3 partner types, few-and-deep portfolio.
• Blended attribution - one sourced+influenced number, assigned at close, maintained by the person whose quota depends on it. Fix: step 5's two capped numbers and four requirements.
• Certification-renewal surprise - the badge budgeted as a launch project, then a platform release lands and re-certification competes with the roadma

...