# GTM developer ecosystem Human Guide

## What This Is For
Build and scale developer-led adoption through ecosystem programs, community, and partnerships. 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 developer ecosystem 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 developer ecosystem.
- 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 developer ecosystem 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 we build a developer ecosystem?"
- "Should we curate quality or go open?"
- "Developer community isn't growing"
- "Nobody's building on our API"
- "How do we compete with larger platforms?"
- API platforms and developer tools
- Products with extensibility (plugins, integrations)
- **Search and discovery** — Surface high-quality integrations through algorithms, not human curation
- **Trust signals** — Verified badges, usage stats, health scores
- **Community curation** — User ratings, collections, recommendations
- **Moderation** — Remove spam after publication, not block before
- **Curated** works when: Brand risk high, dozens of partners, can scale human review

## Decision Points And Nuance
The original skill emphasizes: When to Use, Core Frameworks, Open vs Curated Ecosystem (The Marketplace Decision), The Three-Year Student Program Arc, Developer Journey (Awareness → Integration → Advocacy), Documentation Hierarchy, Community vs Support (When to Use Which), Partner Tiering for Developer Ecosystems, Decision Trees, Open or Curated Ecosystem?.

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
- **Don't over-tier.** 2 tiers is enough. More creates confusion.

## Copy-And-Paste Prompt
```text
Use the GTM developer ecosystem 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-developer-ecosystem`.

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

# Developer Ecosystem

Build and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.

## When to Use

**Triggers:**
- "How do we build a developer ecosystem?"
- "Should we curate quality or go open?"
- "Developer community isn't growing"
- "Nobody's building on our API"
- "How do we compete with larger platforms?"

**Context:**
- API platforms and developer tools
- Products with extensibility (plugins, integrations)
- Developer-first GTM motion
- Platform business models

---

## Core Frameworks

### 1. Open vs Curated Ecosystem (The Marketplace Decision)

**The Pattern:**

Running ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?

**Quality control camp:** "We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage."

**Open 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 and trust layers, not submission gatekeeping.

**What We Built Instead of Gatekeeping:**

1. **Search and discovery** — Surface high-quality integrations through algorithms, not human curation
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 integrations published. Quality surfaced through usage, not through us deciding upfront.

**Decision Framework:**
- **Curated** works when: Brand risk high, dozens of partners, can scale human review
- **Open** works when: Hundreds/thousands of potential partners, network effects matter more than quality control

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

---

### 2. The Three-Year Student Program Arc

**The Pattern:**

Most developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.

**Year 1: University Partnerships**
- Partner with CS departments
- Curriculum integration (hackathons, coursework)
- Student licenses (free or heavily discounted)
- Metrics: # universities, # students activated

**Year 2: Student Community & Certification**
- Student expert certification program
- Student-led workshops and events
- Campus ambassadors
- Metrics: # certified, # student-led events

**Year 3: Career Bridge**
- Job board connecting students → companies
- Enterprise partnerships (hire certified students)
- Alumni network
- Metrics: # hired, company partnerships

**Why This Works:**