gtm-partnership-architecture

intent

build and scale partner ecosystems that drive real revenue and platform adoption, not co-marketing theater. use this skill when deciding whether to build capabilities in-house or partner for them, structuring partner programs from scratch or scaling existing ones, evaluating partnership economics, designing partner tiers, or planning go-to-market motions with channel partners. this skill is grounded in patterns from eight-figure ARR partnership programs and developer marketplace ecosystems at hypergrowth companies, not theory.

inputs

context required:

• stage of partnership program (0 to 1 build, 1 to 100 scale, or evaluating specific deal)
• list of prospective partners with their business model and customer overlap
• internal product roadmap and engineering capacity available for partnership investment
• current sales motion (direct, channel, hybrid)
• customer feedback on requested integrations or bundled capabilities

external connections:

• partnership management system (HubSpot, Salesforce, or internal CRM) with deal pipeline and partner account records
• customer feedback aggregation (support ticket system, NPS data, feature requests) to validate customer demand
• sales team access to win/loss data and partner-influenced deal velocity

no special setup required: this skill uses decision logic and frameworks, not APIs or SDKs.

procedure

phase 1: evaluate partnership viability (before commitment)

step 1: articulate three-sided value proposition

input: prospective partner profile, your product capabilities, target customer segment

1. document what your company gets (distribution, credibility, revenue, product capability)
2. document what the partner gets (revenue or margin improvement, customer retention, competitive differentiation, reduced support burden)
3. document what shared customers get (workflow improvement, reduced integration pain, single vendor relationship, cost efficiency)

output: one-page value prop document. if you cannot fill all three sides with specific, measurable benefits, the partnership fails the viability test. do not proceed.

step 2: identify partnership leverage type

input: partner's business model, their competitive position, their customer needs

evaluate leverage in priority order:

1. requirement leverage: does partner need you to maintain certification, compliance status, or partnership tier? (highest signal)
2. economic leverage: does partnering directly improve partner's unit economics by 20%+ or reduce their costs measurably?
3. competitive leverage: does this differentiate partner vs competitors in a way that matters to their sales team?
4. customer leverage: are partner's customers actively requesting this integration (measure by support ticket volume or sales objections)?
5. co-marketing leverage: is co-branded content or joint events the primary benefit?

output: single-sentence leverage statement (example: "MSPs need our product to maintain cloud provider certification"). if leverage is weak (co-marketing only), stop and walk away. do not pursue vanity partnerships.

step 3: qualify partner capability and commitment

input: partner's engineering resources, sales structure, existing partnership track record

ask partner directly:

• "do you have dedicated engineering resources to build or maintain this integration?"
• "how many customers have requested this capability?"
• "if we don't do this partnership, what actually happens to your business?"
• "what economic commitment can you make (co-investment, revenue share, dedicated headcount)?"

output: qualification scorecard. partners who avoid direct answers or claim "nothing changes if we don't partner" are not real partners. do not proceed with unqualified partners.

step 4: run build-vs-partner decision tree

input: qualified partner, your product roadmap, engineering capacity

is this capability core to your product differentiation?
├─ yes → build it yourself, do not partner
└─ no → continue
    │
    would building this delay roadmap by >6 months?
    ├─ yes → partner
    └─ no → continue
        │
        is there a credible qualified partner who needs you too?
        ├─ yes → partner
        └─ no → build

output: build or partner decision with documented rationale. if decision is "build," exit this procedure. if decision is "partner," continue to phase 2.

---

phase 2: structure the partnership (before launch)

step 5: assign partner tier and commitment level

input: partner's engineering capability, strategic importance, existing relationship maturity

use three-tier model:

tier 1: integration partner (self-serve)

• partner builds using your public API and docs
• you provide: documentation, community channel, office hours
• partner drives own promotion and customer acquisition
• timeline: 2-6 months
• investment from you: minimal (async support)

tier 2: partnership partner (joint development)

• co-developed integration with dedicated channel manager
• you provide: regular syncs, product input, co-marketing templates
• joint customer acquisition and case study development
• timeline: 6-12 months
• investment from you: one part-time partner manager or PMM

tier 3: strategic partner (co-development)

• deep product roadmap integration, shared roadmap planning
• you provide: dedicated partner manager, executive steering, customized co-marketing
• revenue targets and quarterly business reviews
• timeline: ongoing, 12+ months
• investment from you: one full-time partner manager, exec sponsorship

assignment rule: do not over-tier. tier 1 partners expect self-serve, tier 3 expect white-glove. mismatch creates frustration and churn.

output: tier assignment document with commitment level for both sides.

step 6: draft partnership charter (written document, both sides sign)

input: three-sided value prop, leverage statement, tier assignment, internal stakeholders

partnership charter must include:

mutual goals section:

• what success looks like for your company (specific metric: revenue, customers, retention impact)
• what success looks like for partner (specific metric: revenue, margin, customer stickiness)
• what success looks like for shared customers (workflow improvement or cost reduction quantified)

value exchange section:

• what you give (engineering time in hours/quarter, co-marketing resources, revenue share %, training investment)
• what partner gives (distribution commitment in customer outreach, co-investment in $, marketing spend commitment)
• balance test: if either party walks tomorrow, does the other have sunk costs or lost revenue? if one side has zero downside, it is not a real partnership.

timeline section:

• crawl phase dates and deliverables (4-8 weeks, manual integration, 1-2 pilot customers)
• walk phase dates and deliverables (8-12 weeks, formal integration, 5-10 customers, co-marketing launch)
• run phase cadence and governance (ongoing quarterly business reviews, monthly syncs)

measurement section:

• specific go/no-go criteria for crawl (20%+ improvement on stated customer outcome metric)
• specific go/no-go criteria for walk (70%+ adoption rate among invited customers)
• dashboard or reporting mechanism to track weekly

governance section:

• named owner on each side with decision authority
• escalation path for disputes (who decides if timeline slips or scope changes)
• exit criteria (what triggers deprioritization or termination)

output: signed partnership charter. if either side will not sign, there is no real partnership. do not proceed without signatures.

step 7: plan crawl phase (first 4-8 weeks, lowest risk validation)

input: partnership charter, customer list, integration scope

crawl phase scope:

1. identify 1-2 pilot customers using both your product and partner's product
2. build lightweight integration (manual workflow, API spike, not production-grade)
3. measure specific outcome: time savings, adoption rate, revenue impact, or support cost reduction
4. weekly check-ins with pilot customers and partner team
5. document failure modes and support burden

output: crawl phase project plan with specific dates, pilot customer names, success metric definition, and weekly sync cadence.

---

phase 3: execute crawl phase (4-8 weeks)

step 8: onboard pilot customers and measure outcomes

input: 1-2 pilot customers, lightweight integration, agreed success metric

1. conduct onboarding call with each pilot customer explaining partnership and expected outcomes
2. document baseline (current workflow, time spent, cost, or friction points)
3. deploy lightweight integration (manual steps, basic API call, or pre-release feature)
4. measure outcome weekly against success metric (time savings, adoption, revenue impact)
5. collect qualitative feedback: would they recommend this integration to peers?

output: crawl phase measurement dashboard updated weekly. if metric trending toward 20%+ improvement, proceed to step 9. if metric trending away from 20%, schedule decision call with partner to diagnose.

step 9: crawl phase go/no-go decision

input: crawl phase measurement dashboard, partner feedback, pilot customer feedback

at end of crawl (week 4-8):

• did pilot customers see 20%+ improvement on stated metric?
• would they recommend this to peers?
• can you scale this integration without massive engineering rewrite?
• is partner actively supporting pilots or ghosting?

output: go/no-go decision document. if "no go," pause partnership, document learnings, and exit cleanly. if "go," continue to walk phase.

---

phase 4: execute walk phase (8-12 weeks)

step 10: scale to 5-10 customers with formal integration

input: crawl phase success, partner commitment, co-marketing resources

walk phase scope:

1. build production-grade integration (not spike code)
2. invite 5-10 additional customers to adopt
3. launch co-marketing (joint announcement, blog posts, webinar, one-pager for sales)
4. run sales team training on partnership value prop and positioning
5. monitor adoption, support tickets, and partner promotion activity

output: walk phase project plan with specific customer targets, integration architecture, and co-marketing calendar.

step 11: execute co-marketing checklist

input: walk phase timeline, marketing team, partner marketing counterpart

pre-launch (4-6 weeks before):

• finalize joint value prop (both marketing teams reviewed and signed off)
• identify 2-3 customer case studies (ideally with measurable ROI)
• validate technical integration (no launch-day bugs or unexpected support burden)
• create one-pager, sales deck, and demo script
• brief support teams on how to handle partnership-related tickets
• prepare marketplace listings (app store, partner directory, etc.)

launch week:

• coordinated press release timing (same day if possible)
• blog posts published on both companies' sites
• schedule joint webinar within 2 weeks of launch
• coordinate social media campaign with shared hashtags
• run live sales training session with both teams
• send customer segment email from both companies

post-launch (weeks 2-8):

• track customer adoption on weekly dashboard
• triage support issues in joint Slack channel
• publish quantified case study with metrics
• measure pipeline impact (influenced revenue, accelerated deals)
• schedule quarterly business review

output: co-marketing execution calendar with assigned owners, completion dates, and success metrics.

step 12: walk phase go/no-go decision

input: adoption dashboard (weeks 8-12), partner promotion activity, support ticket volume, sales feedback

at end of walk phase:

• did 70%+ of invited customers adopt the integration?
• is partner actively promoting (co-marketing execution, sales team enablement, customer outreach)?
• is support burden manageable (no unexpected complexity, ticket volume acceptable)?
• is sales pipeline showing early influence (even if deals not closed yet)?

output: go/no-go decision document. if "no go," end partnership or restart crawl phase with different approach. if "go," continue to run phase.

---

phase 5: scale to run phase (ongoing, 6-12 months+)

step 13: move to full-scale deployment

input: walk phase success, both sides committed to long-term partnership

run phase scope:

1. native product integration (APIs, marketplace listing, billing integration if applicable)
2. joint enterprise sales (partner sales team can sell your product, you sell partner's in relevant deals)
3. integrated customer success and support (joint QBRs, cross-team escalations)
4. ongoing co-marketing (quarterly content, annual summit presence, case studies)
5. monthly syncs and quarterly business reviews with exec steering

output: run phase operating model document with defined cadence, escalation paths, and success metrics tracked monthly.

step 14: establish partnership governance and health cadence

input: run phase operating model, partnership charter

establish recurring cadence:

• weekly: product/engineering sync (integration bugs, roadmap alignment)
• bi-weekly: customer success sync (case study progress, customer feedback)
• monthly: business review (revenue impact, adoption, pipeline, marketing ROI)
• quarterly: executive steering (strategy alignment, tier evaluation, budget reallocation)

output: partnership governance calendar with standing invites and pre-meeting agenda template.

---

decision points

decision 1: is this a real partnership or handshake theater?

ask: if this partnership fails, what does each side lose?

• if the answer is "nothing" or "just lost time," it is co-marketing theater. walk away.
• if the answer is "we both lose revenue, customer relationships, or product roadmap progress," it is a real partnership. proceed.

edge case: partnerships with competitors (e.g., co-selling to enterprises). even though margin is shared, risk is real (reputation, customer perception). can proceed if value exchange is clear and governance is tight.

decision 2: build or partner?

use step 4 decision tree (procedure phase 1). if capability is core to differentiation, build. if building delays roadmap by 6+ months and a qualified partner exists, partner. otherwise build.

edge case: your partner has already built the integration and is asking you to co-market it (no new engineering required from you). this is lower risk than joint development. tier 1 (self-serve) or tier 2 (light partnership) only. do not move to tier 3 unless mutual commitment is proven.

decision 3: which tier should this partner start at?

• if partner has engineering resources and capacity to build with your API, start at tier 1.
• if partner lacks engineering but is a marquee logo that shifts your positioning (e.g., Salesforce, AWS), start at tier 3.
• if partner has moderate engineering and strategic fit, start at tier 2.
• do not jump straight to tier 3 to flatter a partner. over-tiering creates unsustainable expectations and resource drain.

edge case: partner starts at tier 1 but after 6 months shows high adoption and active co-selling. promote to tier 2 with clear written escalation criteria.

decision 4: crawl phase is not meeting success criteria. what now?

options:

• is the integration wrong? (try different integration approach, e.g., native integration instead of API)
• are pilot customers wrong? (try different customer segment or use case)
• is the metric wrong? (is 20% improvement realistic for this use case, or should you reset bar to 10%?)
• is the partner ghosting? (partner commitment was fake, exit cleanly)

output: revised crawl phase plan or formal exit decision. do not move to walk phase without 20%+ improvement signal.

decision 5: walk phase is underperforming. what now?

options:

• is co-marketing execution weak? (increase marketing investment, add dedicated PMM, relaunch with better positioning)
• are we targeting wrong customer segment? (refocus walk phase to different 5 customers)
• is the partner not promoting? (escalate to partner leadership, reset expectations, consider deprioritization)
• is the integration too complex? (simplify integration scope, reduce customer onboarding friction)

output: revised walk phase plan with specific changes or formal decision to end partnership. do not move to run phase without 70%+ adoption and active partner promotion.

decision 6: should we continue this partnership into its second year?

evaluate at quarterly business review:

• is partnership driving measurable revenue or product capability?
• is partner maintaining commitment (dedicated resources, co-marketing, customer outreach)?
• would we miss this partnership if it ended?
• is partner asking for more investment than we're getting back?

if answers are "no," "no," "no," "yes" respectively, deprioritize or exit. do not let partnerships coast on legacy commitment. refresh every year.

edge case: partnership is mature and profitable but slowing (adoption plateau, partner team distracted). renegotiate or sunset cleanly. do not ghost.

decision 7: should we tier up a tier 1 or tier 2 partner to the next tier?

criteria for tier 1 to tier 2 promotion:

• 6+ months of successful integration and adoption
• partner has shown active promotion and customer acquisition effort
• you've received customer requests for deeper integration
• partner explicitly asks for more support and co-marketing investment

output: written tier escalation agreement. if partner cannot commit to tier 2 workload, stay at tier 1.

criteria for tier 2 to tier 3 promotion:

• 12+ months of strong partnership performance
• partnership drives measurable revenue (influenced or direct)
• both sides have executives actively engaged
• partner is in top 3-5 partners by revenue impact

output: full tier 3 governance model with dedicated resources. if commitment cannot be matched, stay at tier 2.

output contract

partnership execution outputs (in order of creation):

1. viability evaluation document (step 1-4): one-page summary of three-sided value prop, leverage type, partner capability score, and build-vs-partner decision with rationale.

2. partnership charter (step 6): signed multi-page document covering mutual goals, value exchange, timeline, measurement criteria, governance, and exit conditions. both signatory parties (your company and partner) must sign before proceeding.

3. crawl phase project plan (step 7): dates, pilot customer names, integration scope, success metric definition, and weekly sync schedule.

4. crawl phase dashboard (step 8): weekly updated spreadsheet or dashboard showing baseline metric, current metric, trending direction, and pilot customer feedback. accessible to both your team and partner team.

5. crawl phase go/no-go decision (step 9): written decision document (go or no-go) with supporting data and next steps (proceed to walk or exit).

6. walk phase project plan (step 10): customer targets (5-10 names), integration architecture, and timeline.

7. co-marketing calendar (step 11): shared document with all co-marketing activities, owners, completion dates (pre-launch, launch week, post-launch through week 8).

8. walk phase dashboard (step 11-12): weekly updated adoption metrics (% of invited customers adopted), support ticket volume, co-marketing execution checklist, and early pipeline impact.

9. walk phase go/no-go decision (step 12): written decision (go to run or no-go) with supporting adoption data and partner activity assessment.

10. run phase operating model (step 13): documented recurring cadence (weekly, bi-weekly