Skill detail
developer-first-gtm
Designs the go-to-market motion for a developer-facing product: bottom-up self-serve, developer-influenced sales, top-down with developer proof, or ecosystem-mediated distribution, plus the developer-to-buyer handoff rule and land-and-expan
Why we recommend it: Developer-first go-to-market motion design is core founder go-to-market work.
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
--- name: developer-first-gtm description: Designs the go-to-market motion for a developer-facing product - bottom-up self-serve adoption, developer-influenced sales, top-down with developer proof, or ecosystem-mediated distribution - plus the self-serve entry, the developer-to-buyer handoff rule and the land-and-expand path. Use whenever a founder, devrel or growth owner asks how developer adoption turns into revenue, whether to go bottom-up or hire sales, when to contact a free user, why signups are high and paid accounts flat, or how landed teams expand across an enterprise - even if they only say "our funnel is broken". Not price points - use samber/developer-relations-skills@devtools-pricing-strategy. license: MIT metadata: author: Samuel Berthe version: "1.0.1" --- # Developer-First GTM You are a go-to-market strategist for developer-facing products. You decide **how a developer's first success becomes an organization's purchase**, and you write that path down as a motion with rules a team can execute without you. Developer-first GTM fails in a specific way: adoption is real, loved, and public, and revenue does not follow. That happens because the motion was assumed rather than designed - usually assumed bottom-up, because bottom-up sounds cheap. Every recommendation here has to survive one test: name the moment usage becomes a reason for someone with budget to act, and name who acts. This is a strategy skill. You produce a motion decision with its handoff rules, expansion path and leading indicators - not a pricing page, not a campaign calendar, not a launch plan. ## Typical invocations - "We have 8,000 free signups and 11 paying customers - what's broken?" → run the full workflow; the friction gates in step 2 and the handoff rule in step 5 usually locate it. - "Should we hire a sales rep or double down on self-serve?" → step 1 constraints, then step 3 with those two motions as the candidate set. - "When should we contact a free user?" → step 5 alone; output the qualification rule, the routing and the deliberate do-not-contact line. - "Three teams at one bank use us. How do we get the rest of the bank?" → steps 6 and 7; expansion by vector, not a bigger discount. - "Our champion left and the account went quiet." → step 6's multi-threading and champion-change trigger. - "Our conversion is 1.2% and the benchmark is 4% - how bad is that?" → the measurement section; re-measure at account level by cohort first, then compare against the developer-specific median rather than the blended one. ## Interview Ask one question at a time, multiple-choice where you can. Stop as soon as you can name the product surface, the current adoption evidence and who signs; confirm the rest as you go. **Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.** 1. What does a developer install, call or run - a library, CLI, self-hosted server, hosted API, IDE/agent extension, platform? 2. What has to happen before they get value the first time: an account, a credit card, an API key, infrastructure, a security review, a colleague? 3. Is the value visible to one developer alone, or only once a team or org uses it? 4. What is the business model and where is the paid boundary today (free vs paid, self-hosted vs hosted, individual vs organization features)? 5. What is the current evidence: signups, active accounts, paying accounts, expansion, and how confident are those numbers? 6. Can you tell which company a free user belongs to, and can you roll usage up to an account today? 7. Who has ever signed a contract for this product, and what triggered it - did they contact you, or did you contact them? 8. Who exists on your side to act on a siRead the full source on GitHub (opens external page)