gtm-partnership-architecture by github/awesome-copilot
npx skills add https://github.com/github/awesome-copilot --skill gtm-partnership-architecture构建并扩展合作伙伴生态系统,以推动收入和平台采用。这些并非理论——而是来自构建了八位数年度经常性收入(ARR)的合作伙伴计划,以及观察具有真实经济承诺的合作伙伴关系的模式。
触发场景:
适用场景:
模式:
大多数"合作伙伴关系"只是联合营销的表演。联合网络研讨会、Logo互换、新闻稿。没有经济承诺。没有真正的利益绑定。
真正的合作伙伴关系看起来不同:
如何区分:
问:"如果这个合作失败,双方各自会失去什么?"
如果答案是"什么都不会失去"——那就不是合作伙伴关系。只是一次握手。
我见过的最佳合作伙伴关系,双方都做出了令人不适的承诺。多年的云支出承诺。专门的工程团队。收入保证。这种不适感是关键——它迫使双方努力使合作成功。
框架:三方价值主张
每个成功的合作伙伴关系都为三方创造明确的价值:
贵公司:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
合作伙伴:
共同客户:
决策标准:
在寻求任何合作伙伴关系之前,回答:
如果双方都可以零成本退出,这就不是合作伙伴关系——只是一次握手。
常见错误:
将"合作伙伴关系"视为营销公告。集成发布、联合网络研讨会、联合品牌内容。这些制造了话题,而非业务。真正的合作伙伴关系需要令人不适的承诺。
开发者市场决策:
在高速增长期间,在平台公司运营生态系统。领导层辩论:向任何人开放网络,还是为了质量进行筛选?
质量控制阵营: "我们需要把关。否则我们会收到SEO垃圾信息、低质量API、品牌损害。"
开放网络阵营: "开发者会绕过把关者。网络效应比质量控制更重要。"
决策: 选择开放。质量担忧是真实的,但我们下了一个赌注:控制力来自发现+信任层,而非提交把关。
我们构建了什么来代替把关:
结果: 网络效应胜出。发布了数千个API。质量通过使用情况浮现,而非我们预先决定。
模式:
策展型生态系统(把关者模式):
开放生态系统(发现模式):
何时使用哪种:
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
常见错误:
默认选择策展型,因为"我们需要质量控制"。当你有10个合作伙伴时,这有效。当超过100个时,你就成了瓶颈。应转而构建发现和信任系统。
认证楔子:
在云合作伙伴关系的早期,寻求渠道杠杆。目标是托管服务提供商。
洞察: 在云提供商的合作伙伴计划要求中隐藏着:"必须在认证堆栈中包含[我们的产品类别]"。
策略: 围绕这一句话构建了整个合作伙伴推介。MSPs不仅仅想要我们的产品——他们需要它来维持认证。
结果: 我们变成了必需品,而非"锦上添花"。与通用合作伙伴关系相比,MSP交易达成速度快了3倍。
框架:合作伙伴杠杆类型
1. 需求杠杆(最强)
2. 经济杠杆(强)
3. 竞争杠杆(中等)
4. 客户杠杆(中等)
5. 联合营销杠杆(弱)
如何应用:
在推介合作伙伴关系之前,确定你的杠杆:
高杠杆(需求、经济)→ 全面的合作伙伴投资 中等杠杆(竞争、客户)→ 轻量级合作伙伴,先测试 低杠杆(仅联合营销)→ 不要做,你会浪费时间
资格问题:
"如果我们不进行这个合作,你会怎样?"
常见错误:
基于你的利益而非合作伙伴的利益来推介合作。"我们想接触你的客户"是联合营销表演。"你将维持云提供商认证"才是杠杆。
根据承诺和能力将合作伙伴计划构建为清晰的分级:
第1级:集成合作伙伴(自助服务)
第2级:合作伙伴关系(联合开发)
第3级:战略合作伙伴(共同开发)
决策标准:
常见错误:
平等对待所有合作伙伴。第1级合作伙伴想要自助服务,第3级想要白手套服务。不匹配会造成挫败感。
在全面承诺之前,通过分阶段验证来降低合作伙伴关系的风险。
爬行阶段(4-8周):
行走阶段(8-12周):
奔跑阶段(6-12个月,持续进行):
模式:
大多数合作伙伴关系在爬行阶段失败。这是好事——你可以用最少的投资快速学习。
常见错误:
继续/停止标准:
爬行阶段后:
行走阶段后:
仅在以下情况下进入奔跑阶段:
如果你无法阐明各方获得什么,合作伙伴关系将会失败。
合作伙伴章程(启动前必需):
共同目标:
价值交换:
时间线:
衡量标准:
治理:
签名测试:
双方都应签署章程。如果任何一方不愿书面承诺,就没有真正的合作伙伴关系。
常见错误:
口头协议而无书面记录。当事情变得困难时(它们会的),你需要书面对齐。
启动前(提前4-6周):
启动周:
启动后(第2-8周):
常见错误:
将发布视为终点线。真正的工作在发布后开始——采用、支持、迭代。
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
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)
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
将合作伙伴关系视为销售渠道,而非平台扩展
在没有明确集成路径的情况下启动
期望合作伙伴自我推广
创建过多层级
发布后失联
为虚荣心追求合作伙伴关系
没有明确的退出标准
在开始任何合作伙伴关系之前:
在启动任何合作伙伴关系之前:
合作伙伴杠杆层次结构:
继续/停止标准:
基于在多个平台公司高速增长期间的合作伙伴关系工作,包括运营开发者市场生态系统(开放与策展决策)以及利用云提供商认证要求进行渠道增长。不是理论——是真正推动收入和平台采用的合作伙伴关系模式。
每周安装量
155
仓库
GitHub 星标数
26.7K
首次出现
5 天前
安全审计
已安装于
gemini-cli142
codex142
opencode142
cursor141
warp139
kimi-cli139
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.
Triggers:
Context:
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:
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:
The Partner:
Shared Customers:
Decision Criteria:
Before pursuing any partnership, answer:
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.
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:
Result: Network effects won. Thousands of APIs published. Quality surfaced through usage, not through us deciding upfront.
The Pattern:
Curated ecosystem (Gatekeeper Model):
Open ecosystem (Discovery Model):
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.
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)
2. Economic leverage (Strong)
3. Competitive leverage (Moderate)
4. Customer leverage (Moderate)
5. Co-marketing leverage (Weak)
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?"
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.
Structure partner programs into clear tiers based on commitment and capability:
Tier 1: Integration Partner (Self-Serve)
Tier 2: Partnership Partner (Joint Development)
Tier 3: Strategic Partner (Co-Development)
Decision Criteria:
Common Mistake:
Treating all partners equally. Tier 1 partners want self-serve, Tier 3 want white-glove. Mismatch creates frustration.
De-risk partnerships with phased validation before full commitment.
Crawl (4-8 weeks):
Walk (8-12 weeks):
Run (6-12 months ongoing):
The Pattern:
Most partnerships fail in Crawl phase. That's good — you learn fast with minimal investment.
Common Mistakes:
Go/No-Go Criteria:
After Crawl:
After Walk:
Enter Run Only If:
If you can't articulate what each party gets, the partnership will fail.
Partnership Charter (Required Before Launch):
Mutual Goals:
Value Exchange:
Timeline:
Measurement:
Governance:
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.
Pre-Launch (4-6 weeks before):
Launch Week:
Post-Launch (Weeks 2-8):
Common Mistake:
Treating launch as finish line. Real work starts after launch — adoption, support, iteration.
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
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)
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
Treating partnerships as sales channel, not platform expansion
Launching without clear integration pathways
Expecting partners to self-promote
Creating too many tiers
Ghosting after launch
Pursuing partnerships for vanity
No clear exit criteria
Before starting any partnership:
Before launching any partnership:
Partnership leverage hierarchy:
Go/no-go criteria:
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.
Weekly Installs
155
Repository
GitHub Stars
26.7K
First Seen
5 days ago
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli142
codex142
opencode142
cursor141
warp139
kimi-cli139
AI代理协作核心原则:提升开发效率的6大Agentic开发原则指南
7,600 周安装