菜单
Define a real ICP and the developer personas in the sale. Use when the founder says the product is "for developers," can't name who would say no, or is marketing to whoever holds the budget instead of who actually adopts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Interview the founder once and write a docs/gtm-cofounder/founder-brief.md that every other skill reads first, so the advice is about their real business, not a textbook. Use this before anything else, or whenever the agent lacks context on the founder's product, ICP, market, or stage, or is giving generic GTM advice.
After the founder brief, turn it into an honest diagnosis and a prioritized, stage-aware GTM roadmap saved as docs/gtm-cofounder/gtm-roadmap.md. This is the hub the founder returns to every session to see where they are and the single next move. Use right after start-here, whenever the founder doesn't know what to work on next, wants a plan instead of a one-off task, or is drowning in disconnected tactics.
Refresh the founder's competitive and market context. Re-scan named rivals and the category for what changed since the brief was written (rebrands, repositioning, new entrants, pricing shifts, renamed categories) and update docs/gtm-cofounder/founder-brief.md and the roadmap with anything that moves positioning. Use on a cadence, or whenever a competitor rebrands, a new tool appears, or the founder senses the market has shifted under them.
Get the first 50 real users through channels the founder's ICP already uses. Use when the product shipped and nobody came, the founder is "posting more" with no result, or is reaching for paid ads before product-market fit.
Build authority by teaching the problem space, not announcing features. Use when the founder finds "marketing" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect.
Measure GTM with the metrics that matter (net developer retention, DREAM funnel) instead of vanity numbers. Use when the founder has dashboards full of stars and pageviews but can't tell if go-to-market is working, or is optimizing acquisition over a leaky bucket.
| name | who-is-this-for |
| description | Define a real ICP and the developer personas in the sale. Use when the founder says the product is "for developers," can't name who would say no, or is marketing to whoever holds the budget instead of who actually adopts. |
"Developers" is not a market. It's a medium. If your ICP doesn't exclude anyone, it isn't one.
Use this when: you describe your user as "developers" or "engineering teams," you can't name a person who is clearly not a fit, or you're aiming your messaging at the VP of Engineering because they have the budget.
A usable ICP is specific enough that some people are obviously out. "Every developer" gives you nothing to say, because a message that speaks to everyone speaks to no one. Sharpen until exclusion is possible.
And in almost every AI/dev-tool sale there is more than one person: the developer who adopts is rarely the person who pays. Market to the adopter; sell to the buyer. Confuse the two and you get great meetings and no decisions.
Map who plays each role. You need all of them for a complex sale; skip one and the deal stalls.
| Persona | Cares about | Role in the sale |
|---|---|---|
| Alpha Dev | "What's possible?" Lives in the future. No budget. | Finds you, experiments, advocates internally, creates social proof |
| Empowered CTO | Kairos, weeks off a release cycle, competitive edge. Has budget. | Approves spend and strategic fit |
| VP Engineering | Team velocity, DX, quality at scale. Fears downtime/security | Evaluates feasibility, tests in staging |
| SRE / Platform Eng | Reliability, less toil. Reads your code before your copy. | Gatekeeps operational risk |
The Alpha Dev is not your long-term customer. They chase the next shiny thing. You need them anyway: they carry new tech to the people who pay.
A job title is not actionable; a job is. Write it as:
When [situation], I want to [motivation], so I can [expected outcome].
Example: "When I inherit a service with no tests, I want to generate a safety net fast, so I can refactor without fear." That sentence tells you the trigger, the pain, and the win. A demographic never does.
Does the developer who adopts also control the budget?
├─ YES → single-player / PLG motion.
│ ICP centers on the adopter. Optimize time-to-value, self-serve, transparent pricing.
└─ NO → complex sale.
ICP centers on the adopter FOR ADOPTION, and the buyer FOR REVENUE.
You need a "what's in it for me" for every persona above.
Fill every line with something a stranger couldn't guess:
talk-to-users)❌ "For developers who want to ship faster." ✅ "For platform engineers at 50-500-eng companies who just standardized on Kubernetes and are drowning in hand-written YAML, the ones who'd say 'I spend a day a week on manifests I shouldn't have to touch.' Not for solo devs on Heroku."
When… I want… so I can…).talk-to-users before anything else.Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). When a framework can't make the call, that's what a human is for: The DevTool GTM Company.