Back to Details

gtm-partnership-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Partnership Architecture

合作伙伴架构

Build and scale partner ecosystems that drive revenue and platform adoption. These aren't theory — they're patterns from building partner programs that drove 8-figure ARR and observing partnerships with real economic commitment.
构建并扩展可驱动收入增长与平台落地推广的合作伙伴生态系统。这些并非理论，而是来自于实际搭建过能创造八位数ARR的合作伙伴计划，以及对具备真实经济投入的合作关系的观察所得的实践模式。

When to Use

适用场景

Triggers:
  • "How do I structure a partner program?"
  • "Should we build this or partner for it?"
  • "Partner-led vs direct sales motion"
  • "Ecosystem strategy"
  • "How to recruit and tier partners"
  • "Co-marketing with partners"
  • "When does a partnership actually matter?"
Context:
  • Building partnership program from scratch (0→1)
  • Scaling existing program (1→100)
  • Evaluating build vs partner decisions
  • Structuring partner deals and economics
  • Planning partner GTM motions
触发场景：
  • "我该如何构建合作伙伴计划？"
  • "我们应该自研还是寻求合作？"
  • "合作伙伴主导 vs 直接销售模式"
  • "生态系统战略"
  • "如何招募并分层管理合作伙伴？"
  • "与合作伙伴开展联合营销"
  • "什么样的合作关系才真正有价值？"
适用背景：
  • 从零搭建合作伙伴计划（0→1）
  • 扩展现有合作伙伴计划（1→100）
  • 评估自研vs合作的决策
  • 构建合作伙伴协议与经济模型
  • 规划合作伙伴GTM推广动作

Core Frameworks

核心框架

1. Real Partnerships Require Skin in the Game

1. 真正的合作关系需要双方投入实际成本

The Pattern:
Most "partnerships" are co-marketing theater. Joint webinars, logo swaps, press releases. No economic commitment. No real skin in the game.
Real partnerships look different:
  • Economic commitment (spend, revenue share, co-investment)
  • Product roadmap alignment (features built for the partnership)
  • Executive sponsorship (leadership engaged quarterly)
  • Mutual risk (both sides can fail if it doesn't work)
How to Tell the Difference:
Ask: "If this partnership fails, what does each side lose?"
If the answer is "nothing" — it's not a partnership. It's a handshake.
The best partnerships I've seen involved uncomfortable commitments on both sides. Multi-year cloud spend commitments. Dedicated engineering teams. Revenue guarantees. The discomfort is the point — it forces both sides to make the partnership work.
Framework: Three-Sided Value Proposition
Every successful partnership creates clear value for three parties:
Your Company:
  • Distribution (access to partner's customers)
  • Credibility (association with known brand)
  • Revenue (direct or influenced)
  • Product leverage (capability you don't build)
The Partner:
  • Revenue or margin improvement
  • Customer retention/stickiness
  • Competitive differentiation
  • Reduced support burden
Shared Customers:
  • Workflow improvement
  • Reduced integration pain
  • Single vendor relationship
  • Cost efficiency
Decision Criteria:
Before pursuing any partnership, answer:
  1. What is our economic commitment? (Eng resources, spend, revenue share?)
  2. What is partner's economic commitment? (Are they investing too?)
  3. What happens if this fails? (Do we both lose something real?)
If both sides can walk away with zero cost, it's not a partnership — it's a handshake.
Common Mistake:
Treating "partnerships" as marketing announcements. Integration launches, joint webinars, co-branded content. These create buzz, not business. Real partnerships require uncomfortable commitments.
实践模式：
大多数“合作关系”只是联合营销的表面功夫。比如联合线上研讨会、Logo互换、新闻稿发布，没有实际的经济投入，也没有真正的风险绑定。
真正的合作关系完全不同：
  • 经济投入（资金支出、收入分成、联合投资）
  • 产品路线图对齐（为合作定制功能）
  • 高管层面支持（领导层每季度参与）
  • 共同承担风险（如果合作失败，双方都会受损）
如何区分真假合作：
问自己：“如果这个合作失败，双方会失去什么？”
如果答案是“什么都不会失去”——那这不是合作关系，只是口头约定。
我见过的最佳合作关系都包含双方都不太情愿的投入：多年的云服务支出承诺、专属的工程团队、收入担保。这种“不情愿”恰恰是关键——它迫使双方必须让合作成功。
框架：三方价值主张
每一个成功的合作关系都会为三方创造明确的价值：
你的公司：
  • 渠道拓展（触达合作伙伴的客户）
  • 品牌可信度（与知名品牌关联）
  • 收入增长（直接或间接带来的收入）
  • 产品能力延伸（无需自研的功能）
合作伙伴：
  • 收入或利润率提升
  • 客户留存/粘性增强
  • 竞争差异化
  • 支持负担降低
共同客户：
  • 工作流程优化
  • 集成成本降低
  • 单一供应商对接
  • 成本效率提升
决策标准：
在推进任何合作之前，先回答以下问题：
  1. 我们的经济投入是什么？（人力、资金、收入分成？）
  2. 合作伙伴的经济投入是什么？（他们是否也在投入？）
  3. 如果合作失败会怎样？（双方都会失去实际的东西吗？）
如果双方都能毫无成本地抽身，这不是合作关系——只是口头约定。
常见误区：
将“合作关系”当作营销宣传手段。比如集成上线、联合线上研讨会、联合品牌内容，这些只能制造热度，无法带来实际业务增长。真正的合作需要双方投入实际成本。

2. Ecosystem Control = Discovery, Not Gatekeeping

2. 生态系统控制：源于发现机制，而非守门模式

The Developer Marketplace Decision:
Running ecosystem at a platform company during hypergrowth. Leadership debate: Open the network to anyone, or curate for quality?
Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality APIs, brand damage."
Open network camp: "Developers route around gatekeepers. Network effects matter more than quality control."
The decision: Went open. Quality concerns were real, but we made a bet: Control comes from discovery + trust layers, not submission gatekeeping.
What We Built Instead of Gatekeeping:
  1. Search and discovery - Surface high-quality APIs through algorithms
  2. Trust signals - Verified badges, usage stats, health scores
  3. Community curation - User ratings, collections, recommendations
  4. Moderation - Remove spam after publication, not block before
Result: Network effects won. Thousands of APIs published. Quality surfaced through usage, not through us deciding upfront.
The Pattern:
Curated ecosystem (Gatekeeper Model):
  • Pros: High quality, controlled brand
  • Cons: Slow growth, partner friction, you become the bottleneck
Open ecosystem (Discovery Model):
  • Pros: Network effects, rapid growth, self-service
  • Cons: Quality variance, moderation overhead
When to Use Which:
Is brand damage risk high if low-quality partners join?
├─ Yes (regulated, security-critical) → Curated
└─ No → Continue...
    │
    Can you scale human review?
    ├─ No (thousands of potential partners) → Open
    └─ Yes (dozens of partners) → Curated
Common Mistake:
Defaulting to curated because "we need quality control." This works when you have 10 partners. At 100+, you become the bottleneck. Build discovery and trust systems instead.
开发者市场决策案例：
在一家平台公司高速增长期间负责生态系统运营。领导层争论：是向所有人开放网络，还是为了质量进行筛选？
质量控制派：“我们需要守门机制。否则会出现SEO垃圾内容、低质量API，损害品牌。”
开放网络派：“开发者会绕过守门人。网络效应比质量控制更重要。”
**最终决策：**选择开放。质量问题确实存在，但我们赌了一把：控制源于发现+信任机制，而非提交审核的守门模式。
我们构建的替代守门机制的方案：
  1. 搜索与发现 - 通过算法筛选出高质量API
  2. 信任标识 - 认证徽章、使用数据、健康评分
  3. 社区筛选 - 用户评分、收藏集、推荐
  4. 内容审核 - 发布后移除垃圾内容，而非事前阻止
**结果：**网络效应获胜。数千个API被发布，高质量的内容通过使用数据自然浮现，而非我们事前筛选。
实践模式：
Curated Ecosystem（守门人模式）：
  • 优点：高质量、品牌可控
  • 缺点：增长缓慢、合作伙伴摩擦大、你成为瓶颈
Open Ecosystem（发现模式）：
  • 优点：网络效应、快速增长、自助服务
  • 缺点：质量参差不齐、审核成本高
何时选择哪种模式：
低质量合作伙伴加入是否会带来高品牌风险？
├─ 是（受监管、安全敏感领域）→ 采用守门人模式
└─ 否 → 继续...
    │
    人工审核是否可规模化？
    ├─ 否（潜在合作伙伴达数千家）→ 采用发现模式
    └─ 是（潜在合作伙伴仅几十家）→ 采用守门人模式
常见误区：
默认选择守门人模式，因为“我们需要质量控制”。当你只有10个合作伙伴时这可行，但当合作伙伴达到100+时，你会成为瓶颈。取而代之，构建发现与信任机制。

3. Partnership Tactics > Partnership Theater

3. 合作策略：聚焦实际杠杆，而非表面功夫

The Certification Wedge:
Early in a cloud partnership, looking for channel leverage. Targeting managed service providers (MSPs).
The insight: Buried in the cloud provider's partner program requirements: "Must include [our product category] in certified stack."
The play: Built entire partnership pitch around that one line. MSPs didn't just want our product — they needed it to maintain certification.
Result: We became required, not "nice to have." Closed MSP deals 3x faster than generic partnerships.
Framework: Partnership Leverage Types
1. Requirement leverage (Strongest)
  • Partner needs you for certification/compliance/partnership status
  • Example: Cloud provider certification requiring your category of product
  • How to find: Read partner program requirements, marketplace rules
2. Economic leverage (Strong)
  • Helps partner make or save money directly
  • Example: Reduce partner's support costs by 30%
  • How to measure: Calculate partner's ROI in their P&L terms
3. Competitive leverage (Moderate)
  • Gives partner differentiation vs competitors
  • Example: Exclusive integration for 6 months
  • How to validate: Ask "would competitors want this?"
4. Customer leverage (Moderate)
  • Partner's customers demand the integration
  • Example: 50+ support tickets requesting integration
  • How to measure: Partner support ticket volume
5. Co-marketing leverage (Weak)
  • Joint content, events, logo swaps
  • Example: Co-branded webinar
  • Reality: Nice to have, rarely closes deals
How to Apply:
Before pitching partnership, identify your leverage:
High leverage (requirements, economics) → Full partnership investment Moderate leverage (competitive, customer) → Light partnership, test first Low leverage (co-marketing only) → Don't do it, you'll waste time
The Qualification Question:
"If we don't do this partnership, what happens to you?"
  • "We lose cloud provider certification" → High leverage, pursue
  • "We might lose some customers" → Moderate, test carefully
  • "Nothing really changes" → No leverage, walk away
Common Mistake:
Pitching partnerships based on your benefit, not theirs. "We want access to your customers" is co-marketing theater. "You'll maintain cloud provider certification" is leverage.
认证杠杆案例：
在早期云合作中，寻求渠道杠杆。目标客户是托管服务提供商（MSP）。
**洞察：**在云服务商的合作伙伴计划要求中，有一条被忽略的条款：“认证堆栈中必须包含[我们的产品类别]。”
行动：将整个合作提案围绕这一条款展开。MSP不仅想要我们的产品——他们需要它来维持认证资格。
**结果：**我们的产品成为必备项，而非“锦上添花”。MSP合作的成交速度是普通合作的3倍。
框架：合作杠杆类型
1. 要求型杠杆（最强）
  • 合作伙伴需要你才能获得认证/合规/合作资格
  • 示例：云服务商认证要求必须包含你的产品类别
  • 如何找到：研读合作伙伴计划要求、市场规则
2. 经济型杠杆（强）
  • 直接帮助合作伙伴赚钱或省钱
  • 示例：帮助合作伙伴降低30%的支持成本
  • 如何衡量：用合作伙伴的损益表计算ROI
3. 竞争型杠杆（中等）
  • 帮助合作伙伴获得竞争优势
  • 示例：6个月的独家集成权限
  • 如何验证：问“竞争对手是否想要这个？”
4. 客户型杠杆（中等）
  • 合作伙伴的客户要求集成你的产品
  • 示例：50+支持工单请求集成
  • 如何衡量：合作伙伴的支持工单数量
5. 联合营销型杠杆（弱）
  • 联合内容、活动、Logo互换
  • 示例：联合品牌线上研讨会
  • 现实：锦上添花，但很少能促成交易
如何应用：
在提案合作前，先确定你的杠杆类型：
高杠杆（要求型、经济型）→ 全力投入合作 中等杠杆（竞争型、客户型）→ 轻量级合作，先测试 低杠杆（仅联合营销）→ 不要做，会浪费时间
资格审核问题：
“如果我们不开展这个合作，你会怎样？”
  • “我们会失去云服务商认证”→ 高杠杆，推进
  • “我们可能会失去一些客户”→ 中等杠杆，谨慎测试
  • “其实没什么变化”→ 无杠杆，放弃
常见误区：
基于自身利益提案合作。“我们想要触达你的客户”是表面功夫。“你将维持云服务商认证资格”才是杠杆。

4. Partner Tiering: Three-Tier Model

4. 合作伙伴分层：三层模型

Structure partner programs into clear tiers based on commitment and capability:
Tier 1: Integration Partner (Self-Serve)
  • Partner builds with your public API/docs
  • You provide: documentation, Slack channel, office hours
  • Partner drives their own promotion
  • Timeline: 2-6 months
  • Best for: Ambitious partners with engineering resources
Tier 2: Partnership Partner (Joint Development)
  • Co-developed integration
  • You provide: dedicated channel, regular syncs, product input
  • Platform provides co-marketing support
  • Timeline: 6-12 months
  • Best for: Strategic fit partners, accelerating integration quality
Tier 3: Strategic Partner (Co-Development)
  • Deep product roadmap integration
  • You provide: dedicated partner manager, executive relationship
  • Customized co-marketing, revenue objectives
  • Timeline: Ongoing
  • Best for: Marquee partnerships that shift positioning
Decision Criteria:
  • Tier based on strategic fit AND partner capability
  • Don't over-tier (creates expectations you can't meet)
  • Create clear graduation path between tiers
Common Mistake:
Treating all partners equally. Tier 1 partners want self-serve, Tier 3 want white-glove. Mismatch creates frustration.
根据合作伙伴的投入和能力，将合作伙伴计划划分为清晰的层级：
Tier 1：集成合作伙伴（自助服务）
  • 合作伙伴使用你的公开API/文档自行构建
  • 你提供：文档、Slack频道、办公时间支持
  • 合作伙伴自行负责推广
  • 周期：2-6个月
  • 最佳适用：具备工程资源的积极合作伙伴
Tier 2：合作型合作伙伴（联合开发）
  • 联合开发集成
  • 你提供：专属沟通渠道、定期同步、产品输入
  • 平台提供联合营销支持
  • 周期：6-12个月
  • 最佳适用：战略契合的合作伙伴，加速集成质量提升
Tier 3：战略合作伙伴（深度联合开发）
  • 深度产品路线图集成
  • 你提供：专属合作伙伴经理、高管对接
  • 定制化联合营销、收入目标
  • 周期：持续进行
  • 最佳适用：能改变平台定位的顶级合作伙伴
决策标准：
  • 根据战略契合度和合作伙伴能力划分层级
  • 不要设置过多层级（会超出你的交付能力）
  • 为层级间的晋升设置清晰路径
常见误区：
对所有合作伙伴一视同仁。Tier 1合作伙伴想要自助服务，Tier 3想要专属服务。错配会导致不满。

5. Crawl-Walk-Run Partnership Deployment

5. 合作伙伴部署：爬行-行走-奔跑模型

De-risk partnerships with phased validation before full commitment.
Crawl (4-8 weeks):
  • 1-2 pilot customers using both solutions
  • Manual or lightweight integration (not production-grade)
  • Measure specific outcomes: time savings, adoption, revenue impact
  • Go/no-go: 20%+ improvement on stated metric
Walk (8-12 weeks):
  • 5-10 additional customers
  • Build formal integration
  • Co-marketing: joint announcements, webinars
  • Sales enablement: training, playbooks
  • Go/no-go: 70%+ adoption rate of invited customers
Run (6-12 months ongoing):
  • Full-scale deployment
  • Joint enterprise sales, integrated customer success
  • APIs/native integrations, marketplace listing
  • Quarterly business reviews, executive steering
The Pattern:
Most partnerships fail in Crawl phase. That's good — you learn fast with minimal investment.
Common Mistakes:
  • Skipping Crawl phase (jumping straight to full commitment)
  • Running phases in parallel (creates confusion, can't isolate signal)
  • Continuing partnerships not delivering value (sunk cost fallacy)
  • Moving to next phase without clear go/no-go criteria
Go/No-Go Criteria:
After Crawl:
  • Did pilot customers see 20%+ improvement?
  • Would they recommend to peers?
  • Can we scale this integration?
After Walk:
  • Did 70%+ of invited customers adopt?
  • Is partner actively promoting?
  • Is support burden manageable?
Enter Run Only If:
  • Both Crawl and Walk passed criteria
  • Both sides committed to next phase
  • ROI model validates at scale
通过分阶段验证降低合作风险，再进行全面投入。
爬行阶段（4-8周）：
  • 1-2个试点客户同时使用双方解决方案
  • 手动或轻量级集成（非生产级）
  • 衡量具体成果：时间节省、用户Adoption、收入影响
  • 进入/终止标准：目标指标提升20%+
行走阶段（8-12周）：
  • 新增5-10个客户
  • 构建正式集成
  • 联合营销：联合公告、线上研讨会
  • 销售赋能：培训、操作手册
  • 进入/终止标准：受邀客户的Adoption率达70%+
奔跑阶段（6-12个月，持续进行）：
  • 全面部署
  • 联合企业销售、集成化客户成功
  • API/原生集成、市场上架
  • 季度业务回顾、高管指导
实践模式：
大多数合作在爬行阶段失败。这是好事——你用最小的投入快速学习。
常见误区：
  • 跳过爬行阶段（直接全面投入）
  • 并行推进多个阶段（造成混乱，无法明确效果）
  • 继续没有价值的合作（沉没成本谬误）
  • 没有明确的进入/终止标准就进入下一阶段
进入/终止标准：
爬行阶段后：
  • 试点客户是否看到20%+的提升？
  • 他们是否会推荐给同行？
  • 我们能否规模化这个集成？
行走阶段后：
  • 受邀客户的Adoption率是否达70%+？
  • 合作伙伴是否在积极推广？
  • 支持负担是否可控？
仅在以下情况进入奔跑阶段：
  • 爬行和行走阶段均通过标准
  • 双方都承诺进入下一阶段
  • 规模化ROI模型已验证

6. Partnership Value Exchange Clarity

6. 合作价值交换：清晰明确

If you can't articulate what each party gets, the partnership will fail.
Partnership Charter (Required Before Launch):
Mutual Goals:
  • What does success look like for us?
  • What does success look like for partner?
  • What does success look like for customers?
Value Exchange:
  • What we give (engineering time, co-marketing, revenue share)
  • What partner gives (distribution, credibility, co-investment)
  • Is this balanced? (Would both sides still do this if other walked?)
Timeline:
  • Crawl phase (dates, deliverables, metrics)
  • Walk phase (dates, deliverables, metrics)
  • Run phase (ongoing cadence, QBRs)
Measurement:
  • Specific metrics for success (revenue, customers, retention)
  • How we'll track (dashboard, reports, reviews)
  • Review cadence (monthly? quarterly?)
Governance:
  • Who owns decisions on each side?
  • Escalation path for disputes
  • Exit criteria (what triggers ending partnership?)
The Signature Test:
Both sides should sign the charter. If either side won't commit to paper, there's no real partnership.
Common Mistake:
Verbal agreements without documentation. When things get hard (and they will), you need written alignment.
如果你无法清晰阐述双方的所得，合作注定失败。
合作章程（启动前必备）：
共同目标：
  • 我们的成功标准是什么？
  • 合作伙伴的成功标准是什么？
  • 客户的成功标准是什么？
价值交换：
  • 我们提供什么（工程时间、联合营销、收入分成）
  • 合作伙伴提供什么（渠道、可信度、联合投资）
  • 是否平衡？（如果一方退出，另一方是否仍愿意继续？）
时间线：
  • 爬行阶段（日期、交付物、指标）
  • 行走阶段（日期、交付物、指标）
  • 奔跑阶段（持续节奏、季度业务回顾）
衡量标准：
  • 具体的成功指标（收入、客户、留存）
  • 如何跟踪（仪表盘、报告、回顾）
  • 回顾频率（每月？每季度？）
治理机制：
  • 双方的决策负责人是谁？
  • 争议升级路径
  • 退出标准（什么情况会终止合作？）
签署测试：
双方都应签署章程。如果任何一方不愿书面承诺，那这不是真正的合作。
常见误区：
仅达成口头协议，无书面记录。当遇到困难时（一定会遇到），你需要书面的共识。

7. Co-Marketing Execution Checklist

7. 联合营销执行清单

Pre-Launch (4-6 weeks before):
  • Joint value prop finalized (reviewed by both marketing teams)
  • Customer case study identified (ideally 2-3 options)
  • Technical integration validated (no launch-day bugs)
  • Sales enablement ready (one-pager, deck, demo)
  • Support trained (both teams know how to handle tickets)
  • Marketplace listings prepared (if applicable)
Launch Week:
  • Press release (coordinated timing)
  • Blog posts (both companies)
  • Joint webinar scheduled (within 2 weeks of launch)
  • Social media campaign (coordinated hashtags)
  • Sales teams briefed (live training session)
  • Customer comms sent (email to relevant segments)
Post-Launch (Weeks 2-8):
  • Customer adoption tracked (weekly dashboard)
  • Support issues triaged (joint Slack channel)
  • Case study published (quantified results)
  • Pipeline impact measured (influenced deals)
  • Quarterly business review scheduled
Common Mistake:
Treating launch as finish line. Real work starts after launch — adoption, support, iteration.
启动前（启动前4-6周）：
  • 联合价值主张最终确定（经双方市场团队审核）
  • 确定客户案例（理想情况2-3个选项）
  • 技术集成验证（无启动日bug）
  • 销售赋能准备就绪（单页文档、演示文稿、Demo）
  • 支持团队培训完成（双方团队都知道如何处理工单）
  • 市场上架准备完成（如适用）
启动周：
  • 新闻稿（协调发布时间）
  • 博客文章（双方公司）
  • 联合线上研讨会安排（启动后2周内）
  • 社交媒体活动（协调话题标签）
  • 销售团队Briefing（现场培训）
  • 客户沟通（向相关用户群发送邮件）
启动后（第2-8周）：
  • 跟踪客户Adoption（每周仪表盘）
  • 支持问题分流（联合Slack频道）
  • 发布客户案例（量化成果）
  • 衡量Pipeline影响（受影响的交易）
  • 安排季度业务回顾
常见误区：
将启动当作终点。真正的工作在启动后才开始——用户Adoption、支持、迭代。

Decision Trees

决策树

Should We Build or Partner?

我们应该自研还是合作？

Is this capability core to our product differentiation?
├─ Yes → Build it yourself
└─ No → Continue...
    │
    Would building this delay our roadmap by >6 months?
    ├─ Yes → Partner
    └─ No → Continue...
        │
        Is there a credible partner who needs us too?
        ├─ Yes → Partner
        └─ No → Build
该能力是否是我们产品差异化的核心？
├─ 是 → 自行研发
└─ 否 → 继续...
    │
    自研是否会导致Roadmap延迟超过6个月？
    ├─ 是 → 寻求合作
    └─ 否 → 继续...
        │
        是否有可信的合作伙伴也需要我们？
        ├─ 是 → 寻求合作
        └─ 否 → 自行研发

Which Partner Tier?

选择哪个合作伙伴层级？

Does partner have engineering resources to self-serve?
├─ Yes → Start at Tier 1, evaluate for Tier 2 after 6 months
└─ No → Continue...
    │
    Is this a marquee logo that shifts our positioning?
    ├─ Yes → Tier 3 (Strategic)
    └─ No → Tier 2 (Joint Development)
合作伙伴是否具备自助服务的工程资源？
├─ 是 → 从Tier 1开始，6个月后评估是否升级到Tier 2
└─ 否 → 继续...
    │
    这是否是能改变我们定位的顶级品牌？
    ├─ 是 → Tier 3（战略级）
    └─ 否 → Tier 2（联合开发）

Should We Continue This Partnership?

我们是否应该继续这个合作？

Did Crawl phase meet success criteria?
├─ No → End partnership, learn from failure
└─ Yes → Continue...
    │
    Did Walk phase meet success criteria?
    ├─ No → End partnership or restart Crawl with changes
    └─ Yes → Move to Run phase
爬行阶段是否达到成功标准？
├─ 否 → 终止合作，从失败中学习
└─ 是 → 继续...
    │
    行走阶段是否达到成功标准？
    ├─ 否 → 终止合作或调整后重启爬行阶段
    └─ 是 → 进入奔跑阶段

Common Mistakes

常见误区

  1. Treating partnerships as sales channel, not platform expansion
    • Partnerships should expand what your product can do, not just who buys it
  2. Launching without clear integration pathways
    • Partners will struggle and fail without step-by-step guides
  3. Expecting partners to self-promote
    • You must provide co-marketing templates, resources, support
  4. Creating too many tiers
    • 2-3 is optimal; more causes confusion and expectation mismatch
  5. Ghosting after launch
    • Relationships need ongoing cultivation; schedule recurring touchpoints
  6. Pursuing partnerships for vanity
    • Brand name or funding connections don't equal customer value
  7. No clear exit criteria
    • Define upfront what failure looks like and when to deprioritize
  1. 将合作当作销售渠道，而非平台扩展手段
    • 合作应扩展产品能力，而非仅触达更多客户
  2. 启动时未提供清晰的集成路径
    • 没有分步指南，合作伙伴会遇到困难并失败
  3. 期望合作伙伴自行推广
    • 你必须提供联合营销模板、资源和支持
  4. 设置过多层级
    • 2-3个层级最佳；过多会造成混乱和期望错配
  5. 启动后失联
    • 关系需要持续维护；安排定期沟通
  6. 为了虚荣追求合作
    • 品牌知名度或融资关系不等于客户价值
  7. 没有明确的退出标准
    • 提前定义失败的情况和优先级降低的时机

Quick Reference

快速参考

Before starting any partnership:
  • Three-sided value prop articulated
  • Partner tier identified
  • Crawl phase scope defined
  • Success metrics agreed
  • Partnership charter drafted
Before launching any partnership:
  • Customer ready criteria met
  • Co-marketing checklist complete
  • Sales team briefed
  • Health management cadence scheduled
Partnership leverage hierarchy:
  1. Requirement (they need you for cert/compliance)
  2. Economic (saves/makes them money)
  3. Competitive (differentiates them)
  4. Customer (their customers want it)
  5. Co-marketing (nice to have, rarely decisive)
Go/no-go criteria:
  • Crawl: 20%+ customer outcome improvement
  • Walk: 70%+ adoption rate
  • Run: Both phases passed + ROI validated
在启动任何合作之前：
  • 明确三方价值主张
  • 确定合作伙伴层级
  • 定义爬行阶段范围
  • 达成成功指标共识
  • 起草合作章程
在启动任何合作之前：
  • 满足客户就绪标准
  • 完成联合营销清单
  • 完成销售团队Briefing
  • 安排健康管理节奏
合作杠杆优先级：
  1. 要求型（他们需要你获得认证/合规）
  2. 经济型（帮他们赚钱/省钱）
  3. 竞争型（帮他们差异化）
  4. 客户型（他们的客户需要）
  5. 联合营销型（锦上添花，很少起决定性作用）
进入/终止标准：
  • 爬行阶段：客户成果提升20%+
  • 行走阶段：用户Adoption率70%+
  • 奔跑阶段：通过前两个阶段 + 验证规模化ROI

Related Skills

相关技能

  • developer-ecosystem: Developer-specific ecosystem programs
  • enterprise-account-planning: Managing enterprise deals with partners
  • technical-product-pricing: Pricing partnership deals
Based on partnerships work across multiple platform companies during hypergrowth, including running a developer marketplace ecosystem (open vs curated decision) and leveraging cloud provider certification requirements for channel growth. Not theory — patterns from partnerships that actually drove revenue and platform adoption.
  • developer-ecosystem: 开发者专属生态系统计划
  • enterprise-account-planning: 管理与合作伙伴相关的企业交易
  • technical-product-pricing: 合作交易的定价策略
基于在多家高速增长的平台公司的合作实践，包括运营开发者市场生态系统（开放vs守门决策）和利用云服务商认证要求实现渠道增长。这些并非理论——而是来自真正驱动收入和平台Adoption的合作模式。