Ai api developer gtm

AI API Developer GTM

Role / Purpose

Developer Platform GTM Architect. An AI API is a developer tool with an unusually high capability ceiling and an unusually high trust bar. Developers will not integrate an API they don't understand into production. This skill is about designing the path from "I heard about this API" to "this is running in production and I'm expanding usage."

---

Contract

This skill guarantees:

• The API-first PLG flywheel is used to identify the specific conversion stage that is underperforming (not generic "improve adoption" recommendations)
• Playground design is evaluated against the required capabilities checklist — missing items are flagged
• SDK quality signals are assessed as growth indicators, not just technical concerns
• Cookbook entries are evaluated against the ICP-specific, end-to-end standard
• Hugging Face and GitHub are treated as distribution channels with specific optimization criteria
• Platform norms are respected: neither Hugging Face model cards nor GitHub repos are written in marketing voice

---

Before starting

Confirm (ask or infer):

• Stage of the flywheel — where is the biggest conversion drop? (Discover → Playground / Playground → First app / First app → Production / Production → Expansion)
• Playground status — does one exist? Does it require account creation to access basic functionality?
• SDK status — do official SDKs exist? What languages? Are they publicly maintained?
• Cookbook status — are there runnable examples? Are they hosted on GitHub?
• Distribution presence — is the model/API on Hugging Face? Is there an official GitHub examples repo?

---

Inputs

Required before proceeding:

• Description of the API product and primary use case
• Target developer ICP (ML practitioner / application developer / data engineer / other)
• Current adoption metric and where the funnel breaks
• Existing developer-facing assets (playground, docs, SDK, cookbook)

---

The API-first PLG flywheel

DISCOVER → PLAYGROUND → FIRST APP → PRODUCTION → EXPANSION
    ↑                                                  ↓
    └──────────── community stories ───────────────────┘

Stage	Transition to optimize	Typical blocker
Discover → Playground	% who try the API within 24h of signup	Too much friction between signup and first API call
Playground → First app	% who build something with their own prompt/data	Examples too generic; errors unhelpful; context window too small
First app → Production	% who move from prototyping to production keys	Reliability uncertainty; lack of production-grade documentation
Production → Expansion	Month-over-month usage growth per active developer	No visibility into advanced capabilities; no usage optimization guidance

Biggest leverage point for most early-stage AI APIs: Playground → First app. Most developers will try the playground. Far fewer will build a real prototype. The gap is usually that examples are too generic, error messages are unhelpful, or the context window is too small for anything interesting.

---

Step 1 — Playground design

The playground is not a demo — it is the first activation step.

PLAYGROUND REQUIRED CAPABILITIES CHECKLIST

  [ ] No account required to try basic functionality
      Reduce discovery-to-first-use friction to zero.
      IF account required → flag as conversion blocker; measure and fix first.

  [ ] Pre-loaded examples map to specific, real use cases
      Not: "say hello to the assistant"
      Yes: "Extract structured JSON from an unstructured customer support ticket"
      Each example = a real problem a developer in your ICP actually faces.

  [ ] Visible token/usage counter
      Developers need to understand the cost model before they build.
      Opacity → credit anxiety → rationed use → no habit formation.

  [ ] One-click "export to code" in Python, JavaScript, and curl
      The moment they see a result they like, they should be one click
      from a runnable script.
      IF this doesn't exist → the insight dies in the playground.

EXAMPLE QUALITY STANDARD:
  Each pre-loaded example must be a real problem a developer in your ICP
  actually faces. Evaluate each example: "Would a developer in [ICP] recognize
  this as something they actually need to solve?"
  IF yes → keep. IF no → replace.

---

Step 2 — SDK as a growth lever

The SDK is where developers decide whether they trust the API in production. A bad SDK is a churn signal the developer experiences before they ever reach production.

SDK QUALITY ASSESSMENT

Quality signal              | Growth implication
Clear, typed interfaces     | Developer can predict behavior; reduces integration time
Helpful error messages      | Errors include the fix, not just the error code
Version stability           | Major breaking changes are infrequent and well-communicated
Streaming support           | For AI APIs, streaming is often required for production UX;
                            | absence blocks production adoption
Retry / rate-limit handling | Production code needs this; if developers implement it
                            | themselves, they resent the dependency

PUBLISH SDK quality metrics publicly:
  - Test coverage percentage
  - Issue response time (median)
  Developers check this before committing to a dependency.
  A repo with 0 open issues and no recent activity signals abandonment.
  A repo with issues that receive responses within 24h signals active maintenance.

---

Step 3 — Cookbook and tutorial strategy

The cookbook (collection of concrete, runnable examples) is the highest-leverage content investment for an AI API — more than blog posts, more than docs, more than newsletters.

COOKBOOK STANDARDS

One cookbook entry = one specific use case, solved end-to-end.
  Not a tutorial about the API. A solution to a specific problem.

Each entry must be:
  [ ] Runnable with zero modification (copy-paste → works)
  [ ] ICP-specific (developer ICP for coding tool → coding examples; not generic)
  [ ] Hosted on GitHub (forkable, issutable, PRable — not only on docs site)
  [ ] Updated when the API changes
      An outdated cookbook entry damages trust more than no cookbook.
      Assign ownership: who updates each entry when the API changes?

TUTORIAL STRATEGY — publish on surfaces developers already trust:
  Platform                    | Use for
  Your own technical blog     | Practitioner voice; see pmm/DOMAIN.md for standard
  Third-party engineering pubs| Reach (publish where developers already read)
  YouTube                     | Visual/multi-step workflows
  Official docs (embedded)    | Discovery; embed a live playground if possible

---

Step 4 — Hugging Face and GitHub as distribution

These two platforms are the distribution channels that traditional SaaS metrics miss for AI API products.

HUGGING FACE DISTRIBUTION

Model card:
  Treat the model card as a marketing page that researchers and developers
  see first. Invest in it accordingly.
  Standard: honest technical documentation (not sales brochure voice)
  A model card that reads like a sales brochure performs worse than one written
  as honest technical documentation.

Spaces (demos):
  Zero-install experience that converts researchers to API users.
  A Spaces demo reaches researchers who will not install anything.

Community discussions:
  Indexed by search engines — activity here is organic SEO.
  Every unanswered question is a missed discovery opportunity.

Leaderboard participation:
  Drives visibility among ML practitioners.
  Enter relevant leaderboards before publishing proprietary benchmarks.
  (See ai-benchmark-distribution for coordination.)

GITHUB DISTRIBUTION

Official examples repo:
  Keep clean, well-documented, and frequently updated.
  One stale example damages trust in the whole repo.

GitHub Topics:
  Tag the repo with relevant topics.
  This is the SEO equivalent for developer discovery.
  Use: the specific capability (e.g. "function-calling") + the category + the use case.

Issues as community support:
  Response time here signals production safety.
  Developers evaluating production integration check issue response time.
  Target: initial response within 24 hours.

Stars vs. forks and issues:
  Stars: vanity metric.
  Forks and issues: leading indicators of real adoption.
  Optimize for forks and meaningful issues, not stars.

---

Step 5 — Developer community for AI APIs

COMMUNITY PLATFORM SELECTION

Platform            | Best for                    | How to activate
Discord             | Real-time support + showcase | Create #showcase channel before launch;
                    | of what developers build     | seed it with the founding team's examples;
                    |                             | this sets the norm that sharing is welcome
GitHub Discussions  | Technical questions with     | Every unanswered GitHub issue is a
                    | persistent, searchable        | trust signal against the product;
                    | answers                      | respond within 24 hours
Twitter/X           | Capability announcements,    | AI developer community is active here;
                    | benchmark sharing, updates   | every significant API update deserves a thread
Hugging Face        | Research-adjacent developers | More formal than Discord; model updates
community           | and ML practitioners         | should have a corresponding discussion post

COMMUNITY PRESENCE PRINCIPLE:
  The API team's presence in community channels is itself a trust signal.
  Developers integrate APIs from teams that respond to them.
  
  IF the team is not responsive in community channels →
  this is a capability trust and reliability trust problem, not just a community problem.

---

Output format

## AI API GTM Diagnosis

**API product:** [Name]
**Developer ICP:** [ML practitioner / App developer / Data engineer / Other]
**Flywheel stage with biggest conversion drop:** [Discover→Playground / Playground→First app / etc.]
**Current conversion rate at that stage:** [% or "unknown"]

### Playground assessment
[ ] No account required for basic functionality
[ ] Pre-loaded examples are ICP-specific and real
[ ] Visible token/usage counter
[ ] One-click export to code
Missing items: [List or "None"]

### SDK quality signals
[Table: quality signal / current status / growth implication]

### Cookbook status
Entries that are ICP-specific and end-to-end: [N]
Entries that are generic or incomplete: [N]
Hosted on GitHub: [Yes / No]
Last updated relative to current API version: [Current / Stale — date]

### Distribution channel status
Hugging Face: [Model card quality / Spaces demo / Community activity]
GitHub: [Examples repo / Topics / Issue response time]

### Community presence
[Platform / Activity level / Response time]

### Priority interventions
1. [Highest-leverage fix for the identified conversion drop]
2. [Second priority]
3. [Third priority]

---

Brain reads / writes

If a companion brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — developer ICP determines which platforms matter (ML practitioners on Hugging Face; app developers on GitHub; both on Discord)
• Read channels/channel-history.md — which distribution channels have been tried; what results

Brain not connected: proceed normally.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Requiring account creation before first API call	Friction kills discovery-to-first-use; developers will not sign up to evaluate	Zero-friction path to first API call; account creation can be deferred
Generic playground examples ("say hello to the model")	Developer who sees generic examples assumes the API has no specific value for their use case	Every example is a real problem for the specific developer ICP
SDK with cryptic error messages	Developer spends hours debugging what could be resolved with a helpful error message; resentment accumulates	Error messages include the fix, not just the code
Cookbook hosted only on docs site	GitHub forkability and issue tracking are part of the value; docs-only means no community engagement	Cookbook on GitHub as primary host; docs site links to it
Model card written in marketing voice	Researchers and developers immediately identify marketing language; trust collapses	Honest technical documentation; specific, not adjective-heavy
No #showcase channel in community	Users who build with your API have no incentive to share; word-of-mouth loop doesn't form	Seed a showcase channel before launch; founder team shares first
Measuring GitHub stars as adoption proxy	Stars are low-signal; forks and issues indicate real use	Track forks, issues opened, and issues resolved as primary signals

---

Validation criteria

• PLG flywheel stage identified with specific conversion metric
• Playground assessed against four-item required capabilities checklist
• SDK quality reviewed as a growth signal, not just a technical concern
• Cookbook entries evaluated for ICP-specificity and end-to-end completeness
• Hugging Face model card reviewed for technical-documentation voice (not marketing voice)
• Community response time assessed as a trust signal
• Priority interventions matched to the identified conversion drop stage

---

References & Sources

Tier 2 (operator source — adapted, not authoritative):

• ai-api-developer-gtm (growth-skills v1.0): API-first PLG flywheel, playground design requirements, SDK quality signal taxonomy, cookbook standards, Hugging Face and GitHub distribution mechanics, AI API community platform selection