partnership-architecture

Name: partnership-architecture
Author: beingsmit

39stars7forks

How to install partnership-architecture?

beingsmit/technical-product-gtm/partnership-architecture

$npx -y skills add beingsmit/technical-product-gtm --skill partnership-architecture

Installs into the current project.

Summary

Build and scale partner ecosystems that drive revenue and platform adoption. Use when building partner programs from scratch, tiering partnerships, managing co-marketing, making build-vs-partner decisions, or structuring crawl-walk-run partner deployment.

Files · 1

View on GitHub

SKILL.md

1	# Partnership Architecture
2
3	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.
4
5	## When to Use
6
7	Triggers:
8	- "How do I structure a partner program?"
9	- "Should we build this or partner for it?"
10	- "Partner-led vs direct sales motion"
11	- "Ecosystem strategy"
12	- "How to recruit and tier partners"
13	- "Co-marketing with partners"
14	- "When does a partnership actually matter?"
15
16	Context:
17	- Building partnership program from scratch (0→1)
18	- Scaling existing program (1→100)
19	- Evaluating build vs partner decisions
20	- Structuring partner deals and economics
21	- Planning partner GTM motions
22
23	---
24
25	## Core Frameworks
26
27	### 1. Real Partnerships Require Skin in the Game
28
29	The Pattern:
30
31	Most "partnerships" are co-marketing theater. Joint webinars, logo swaps, press releases. No economic commitment. No real skin in the game.
32
33	Real partnerships look different:
34	- Economic commitment (spend, revenue share, co-investment)
35	- Product roadmap alignment (features built for the partnership)
36	- Executive sponsorship (leadership engaged quarterly)
37	- Mutual risk (both sides can fail if it doesn't work)
38
39	How to Tell the Difference:
40
41	Ask: "If this partnership fails, what does each side lose?"
42
43	If the answer is "nothing" — it's not a partnership. It's a handshake.
44
45	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.
46
47	Framework: Three-Sided Value Proposition
48
49	Every successful partnership creates clear value for three parties:
50
51	Your Company:
52	- Distribution (access to partner's customers)
53	- Credibility (association with known brand)
54	- Revenue (direct or influenced)
55	- Product leverage (capability you don't build)
56
57	The Partner:
58	- Revenue or margin improvement
59	- Customer retention/stickiness
60	- Competitive differentiation
61	- Reduced support burden
62
63	Shared Customers:
64	- Workflow improvement
65	- Reduced integration pain
66	- Single vendor relationship
67	- Cost efficiency
68
69	Decision Criteria:
70
71	Before pursuing any partnership, answer:
72
73	1. What is our economic commitment? (Eng resources, spend, revenue share?)
74	2. What is partner's economic commitment? (Are they investing too?)
75	3. What happens if this fails? (Do we both lose something real?)
76
77	If both sides can walk away with zero cost, it's not a partnership — it's a handshake.
78
79	Common Mistake:
80
81	Treating "partnerships" as marketing announcements. Integration launches, joint webinars, co-branded content. These create buzz, not business. Real partnerships require uncomfortable commitments.
82
83	---
84
85	### 2. Ecosystem Control = Discovery, Not Gatekeeping
86
87	The Developer Marketplace Decision:
88
89	Running ecosystem at a platform company during hypergrowth. Leadership debate: Open the network to anyone, or curate for quality?
90
91	Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality APIs, brand damage."
92
93	Open network camp: "Developers route around gatekeepers. Network effects matter more than quality control."
94
95	The decision: Went open. Quality concerns were real, but we made a bet: Control comes from discovery + trust layers, not submission gatekeeping.
96
97	What We Built Instead of Gatekeeping:
98
99	1. Search and discovery - Surface high-quality APIs through algorithms
100	2. Trust signals - Verified badges, usage stats, health scores
101	3. Community curation - User ratings, collections, recommendations
102	4. Moderation - Remove spam after publication, not block before
103
104	Result: Network effects won. Thousands of APIs published. Quality surfaced through usage, not through us deciding upfront.
105
106	The Pattern:
107
108	Curated ecosystem (Gatekeeper Model):
109	- Pros: High quality, controlled brand
110	- Cons: Slow growth, partner friction, you become the bottleneck
111
112	Open ecosystem (Discovery Model):
113	- Pros: Network effects, rapid growth, self-service
114	- Cons: Quality variance, moderation overhead
115
116	When to Use Which:
117
118	```
119	Is brand damage risk high if low-quality partners join?
120	├─ Yes (regulated, security-critical) → Curated
121	└─ No → Continue...
122	│
123	Can you scale human review?
124	├─ No (thousands of potential partners) → Open
125	└─ Yes (dozens of partners) → Curated
126	```
127
128	Common Mistake:
129
130	Defaulting to curated because "we need quality control." This works whe

People who liked this also viewed

6 picks

Type

partnership-architecture

39stars7forks

View on GitHub

How to install partnership-architecture?

beingsmit/technical-product-gtm/partnership-architecture

$npx -y skills add beingsmit/technical-product-gtm --skill partnership-architecture

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Partnership Architecture
2
3	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.
4
5	## When to Use
6
7	Triggers:
8	- "How do I structure a partner program?"
9	- "Should we build this or partner for it?"
10	- "Partner-led vs direct sales motion"
11	- "Ecosystem strategy"
12	- "How to recruit and tier partners"
13	- "Co-marketing with partners"
14	- "When does a partnership actually matter?"
15
16	Context:
17	- Building partnership program from scratch (0→1)
18	- Scaling existing program (1→100)
19	- Evaluating build vs partner decisions
20	- Structuring partner deals and economics
21	- Planning partner GTM motions
22
23	---
24
25	## Core Frameworks
26
27	### 1. Real Partnerships Require Skin in the Game
28
29	The Pattern:
30
31	Most "partnerships" are co-marketing theater. Joint webinars, logo swaps, press releases. No economic commitment. No real skin in the game.
32
33	Real partnerships look different:
34	- Economic commitment (spend, revenue share, co-investment)
35	- Product roadmap alignment (features built for the partnership)
36	- Executive sponsorship (leadership engaged quarterly)
37	- Mutual risk (both sides can fail if it doesn't work)
38
39	How to Tell the Difference:
40
41	Ask: "If this partnership fails, what does each side lose?"
42
43	If the answer is "nothing" — it's not a partnership. It's a handshake.
44
45	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.
46
47	Framework: Three-Sided Value Proposition
48
49	Every successful partnership creates clear value for three parties:
50
51	Your Company:
52	- Distribution (access to partner's customers)
53	- Credibility (association with known brand)
54	- Revenue (direct or influenced)
55	- Product leverage (capability you don't build)
56
57	The Partner:
58	- Revenue or margin improvement
59	- Customer retention/stickiness
60	- Competitive differentiation
61	- Reduced support burden
62
63	Shared Customers:
64	- Workflow improvement
65	- Reduced integration pain
66	- Single vendor relationship
67	- Cost efficiency
68
69	Decision Criteria:
70
71	Before pursuing any partnership, answer:
72
73	1. What is our economic commitment? (Eng resources, spend, revenue share?)
74	2. What is partner's economic commitment? (Are they investing too?)
75	3. What happens if this fails? (Do we both lose something real?)
76
77	If both sides can walk away with zero cost, it's not a partnership — it's a handshake.
78
79	Common Mistake:
80
81	Treating "partnerships" as marketing announcements. Integration launches, joint webinars, co-branded content. These create buzz, not business. Real partnerships require uncomfortable commitments.
82
83	---
84
85	### 2. Ecosystem Control = Discovery, Not Gatekeeping
86
87	The Developer Marketplace Decision:
88
89	Running ecosystem at a platform company during hypergrowth. Leadership debate: Open the network to anyone, or curate for quality?
90
91	Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality APIs, brand damage."
92
93	Open network camp: "Developers route around gatekeepers. Network effects matter more than quality control."
94
95	The decision: Went open. Quality concerns were real, but we made a bet: Control comes from discovery + trust layers, not submission gatekeeping.
96
97	What We Built Instead of Gatekeeping:
98
99	1. Search and discovery - Surface high-quality APIs through algorithms
100	2. Trust signals - Verified badges, usage stats, health scores
101	3. Community curation - User ratings, collections, recommendations
102	4. Moderation - Remove spam after publication, not block before
103
104	Result: Network effects won. Thousands of APIs published. Quality surfaced through usage, not through us deciding upfront.
105
106	The Pattern:
107
108	Curated ecosystem (Gatekeeper Model):
109	- Pros: High quality, controlled brand
110	- Cons: Slow growth, partner friction, you become the bottleneck
111
112	Open ecosystem (Discovery Model):
113	- Pros: Network effects, rapid growth, self-service
114	- Cons: Quality variance, moderation overhead
115
116	When to Use Which:
117
118	```
119	Is brand damage risk high if low-quality partners join?
120	├─ Yes (regulated, security-critical) → Curated
121	└─ No → Continue...
122	│
123	Can you scale human review?
124	├─ No (thousands of potential partners) → Open
125	└─ Yes (dozens of partners) → Curated
126	```
127
128	Common Mistake:
129
130	Defaulting to curated because "we need quality control." This works whe

People who liked this also viewed

6 picks

Type