gtm-partnership-architecture▌
github/awesome-copilot · updated Apr 8, 2026
MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.
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.
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.
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
Core Frameworks
1. Real Partnerships Require Skin in the Game
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:
- What is our economic commitment? (Eng resources, spend, revenue share?)
- What is partner's economic commitment? (Are they investing too?)
- 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.
2. Ecosystem Control = Discovery, Not Gatekeeping
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:
- Search and discovery - Surface high-quality APIs through algorithms
- Trust signals - Verified badges, usage stats, health scores
- Community curation - User ratings, collections, recommendations
- 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.
3. Partnership Tactics > Partnership Theater
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.
4. Partner Tiering: Three-Tier Model
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.
5. Crawl-Walk-Run Partnership Deployment
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
6. Partnership Value Exchange Clarity
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
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.
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
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)
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
-
Treating partnerships as sales channel, not platform expansion
- Partnerships should expand what your product can do, not just who buys it
-
Launching without clear integration pathways
- Partners will struggle and fail without step-by-step guides
-
Expecting partners to self-promote
- You must provide co-marketing templates, resources, support
-
Creating too many tiers
- 2-3 is optimal; more causes confusion and expectation mismatch
-
Ghosting after launch
- Relationships need ongoing cultivation; schedule recurring touchpoints
-
Pursuing partnerships for vanity
- Brand name or funding connections don't equal customer value
-
No clear exit criteria
- Define upfront what failure looks like and when to deprioritize
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:
- Requirement (they need you for cert/compliance)
- Economic (saves/makes them money)
- Competitive (differentiates them)
- Customer (their customers want it)
- 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
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.
How to use gtm-partnership-architecture on Cursor
AI-first code editor with Composer
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
- ›Cursor installed and configured on your development machine
- ›Node.js version 16.0+ with npm package manager (verify with
node --version) - ›Active project directory or workspace where you want to add gtm-partnership-architecture
Execute installation command
Execute the skills CLI command in your project's root directory to begin installation:
The skills CLI fetches gtm-partnership-architecture from GitHub repository github/awesome-copilot and configures it for Cursor.
Select Cursor when prompted
The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:
Verify installation
Confirm successful installation by checking the skill directory location:
Reload or restart Cursor to activate gtm-partnership-architecture. Access the skill through slash commands (e.g., /gtm-partnership-architecture) or your agent's skill management interface.
Security & Verification Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.
List & Monetize Your Skill
Submit your Claude Code skill and start earning
Use Cases▌
User Story & Requirements Generation
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Competitive Analysis
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Roadmap Prioritization
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Implementation Guide▌
Prerequisites
- ›Claude Desktop or compatible AI client
- ›Access to product documentation and roadmap tools (Jira, Notion, etc.)
- ›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
- ›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Installation Steps
- 1.Install product management skill
- 2.Start with user story generation for known feature
- 3.Progress to competitive analysis: research 2-3 competitors
- 4.Use for roadmap prioritization: apply RICE/ICE scoring
- 5.Draft stakeholder communications and refine based on feedback
- 6.Build template library for recurring PM tasks
- 7.Share effective prompts with product team
Common Pitfalls
- ⚠Not validating competitive research—verify facts before sharing
- ⚠Accepting user stories without involving engineering team
- ⚠Over-relying on frameworks without qualitative judgment
- ⚠Not customizing outputs to company culture and communication style
- ⚠Skipping stakeholder validation of generated requirements
Best Practices▌
✓ Do
- +Validate research and competitive analysis with real data
- +Collaborate with engineering when generating technical requirements
- +Customize frameworks and templates to your company context
- +Use skill for first drafts, refine with stakeholder input
- +Document successful prompt patterns for PM tasks
- +Combine AI efficiency with human judgment and intuition
✗ Don't
- −Don't publish competitive analysis without fact-checking
- −Don't finalize user stories without engineering review
- −Don't make prioritization decisions solely on AI scoring
- −Don't skip customer validation of generated requirements
- −Don't ignore company-specific context and culture
💡 Pro Tips
- ★Provide context: company goals, constraints, customer feedback
- ★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
- ★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
- ★Use skill for 70% generation + 30% customization to company needs
When to Use This▌
✓ Use When
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid When
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path▌
- 1Basic: user stories, feature specs, status updates
- 2Intermediate: competitive analysis, prioritization frameworks, PRDs
- 3Advanced: product strategy, go-to-market planning, OKR setting
- 4Expert: product vision, market positioning, business model innovation
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.8★★★★★30 reviews- ★★★★★Chaitanya Patil· Dec 28, 2024
gtm-partnership-architecture reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Xiao Brown· Dec 20, 2024
gtm-partnership-architecture reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Hana Gonzalez· Dec 16, 2024
gtm-partnership-architecture has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Piyush G· Nov 19, 2024
I recommend gtm-partnership-architecture for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Xiao Shah· Nov 11, 2024
I recommend gtm-partnership-architecture for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Kwame Shah· Nov 7, 2024
gtm-partnership-architecture fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Hana Reddy· Oct 26, 2024
We added gtm-partnership-architecture from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Shikha Mishra· Oct 10, 2024
Useful defaults in gtm-partnership-architecture — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Aarav Gill· Oct 2, 2024
Useful defaults in gtm-partnership-architecture — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Michael Khan· Jul 23, 2024
gtm-partnership-architecture is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
showing 1-10 of 30