# GTM partnership architecture Human Guide

## What This Is For
Build and scale partner ecosystems that drive revenue and platform adoption. It gives the agent a clearer input/output frame for go-to-market work: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the GTM partnership architecture agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for GTM partnership architecture.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the GTM partnership architecture guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- "How do I structure a partner program?"
- "Should we build this or partner for it?"
- "Partner-led vs direct sales motion"
- "How to recruit and tier partners"
- "Co-marketing with partners"
- "When does a partnership actually matter?"
- 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
- Economic commitment (spend, revenue share, co-investment)

## Decision Points And Nuance
The original skill emphasizes: When to Use, Core Frameworks, Real Partnerships Require Skin in the Game, Ecosystem Control = Discovery, Not Gatekeeping, Partnership Tactics > Partnership Theater, Partner Tiering: Three-Tier Model, Crawl-Walk-Run Partnership Deployment, Partnership Value Exchange Clarity, Co-Marketing Execution Checklist, Decision Trees.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- Product leverage (capability you don't build)
- **The insight:** Buried in the cloud provider's partner program requirements: "Must include [our product category] in certified stack."
- **Result:** We became required, not "nice to have." Closed MSP deals 3x faster than generic partnerships.
- Low leverage (co-marketing only) → Don't do it, you'll waste time
- "If we don't do this partnership, what happens to you?"
- "We might lose some customers" → Moderate, test carefully
- Don't over-tier (creates expectations you can't meet)
- Partnership Charter (Required Before Launch):

## Copy-And-Paste Prompt
```text
Use the GTM partnership architecture human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the github/awesome-copilot skill entry for `gtm-partnership-architecture`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# 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:

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:**