market-to-devs-sell-to-buyers

面向开发者营销，向买家销售

采用你的工具的开发者几乎从来不是付费的人。赢得开发者的心，然后给他们弹药，让他们替你赢得预算讨论。

适用场景： 你有星标、注册用户和广受喜爱的免费层级，但营收仍为零。

核心理念（Czakon）

面向开发者营销，向决策者销售。 开发者负责评估和采用；买家（CTO／VP／采购）负责批准预算。你的增长引擎是替你在公司内部推销的开发者 拥护者，因此你的工作是让他们在老板面前显得眼光独到。

框架：行之有效的 GTM 模式（Czakon）

选择适合你的产品和 ICP 的模式；不要四种都浅尝辄止。

模式	适用情况	推进方式
开源	基础设施／开发工具，信任与可检查性很重要	OSS 核心 → 采用 → 付费云版／企业版
PLG／自助服务	快速实现价值，小团队中开发者就是买家	免费层级 → 使用 → 扩展 → 为大客户提供销售辅助
入站营销	你能围绕问题掌握内容／SEO	围绕问题开展教育 → 获取线索 → 培育线索
销售驱动／ABM	ACV 高、企业销售复杂、大客户数量少	锁定指定客户，通过开发者拥护者打入客户

大多数开发工具采用 PLG + 销售辅助 的叠加模式，人工跟进值得投入的客户。

框架：赋能拥护者（Czakon + Frankl）

为开发者提供向上推销所需的材料：

• 能说服老板的 Kairos 案例（缩短数周发布周期、降低风险），参见 value-prop-that-converts。
• 一页纸介绍／ROI 摘要，方便他们粘贴到内部讨论中。
• 买家会问到的安全／合规问题答案（SOC 2、数据处理），以及 CTO 真正担心的问题。
• 证据：来自可比公司的同行所取得、明确归属的成果。

角色 → 销售路径（Frankl）： Alpha Dev 发现并倡导 → VPE／SRE 验证可行性 → 获得授权的 CTO 批准预算 → 采购负责处理条款（较后期，仅限企业）。复杂的销售流程需要为每个角色回答“这对我有什么好处”。搞定一个角色，你就能获得很棒的会议，却无法推动决策。

决策树：何时推出付费方案

Has the developer hit real, repeated value (Activation)?
├─ NO  → too early. Gating now kills adoption. Keep delivering value.
└─ YES → is this a small team (dev controls spend)?
         ├─ YES → self-serve upgrade in-product; keep it frictionless.
         └─ NO  → trigger sales-assist: help the champion build the internal case.

亲自拿下第一个 100 万美元。 在做到之前，不要把销售工作交出去。教会销售代表要比教会亲身经历过客户异议的创始人困难得多（Frankl）。

看似合理的错误做法

• 指望开发者有预算：Alpha Dev 很喜欢你，但没有能力付钱。
• 过早设置价值门槛：还没到惊喜时刻就设置付费墙，会让好奇心变成跳出。
• 冷启动推销给 VP：绕过拥护者；买家信任自己的工程师，而不是你的邮件。
• 不赋能拥护者：开发者想买，却没有任何材料可以拿给老板看。
• 四种 GTM 模式各投入 10%：选定一种主要推进方式，并全力投入。

接下来 30 分钟

• 确定你的模式（OSS／PLG／入站营销／销售驱动），以及你首先要全力投入的唯一一种模式。
• 找出最满意的免费用户 → 这就是拥护者。询问他们的老板需要什么才能批准预算。
• 制作拥护者的一页纸材料：Kairos 案例 + 证据 + 安全问题解答。
• 明确必须在你提及付费方案之前发生的 Activation 时刻。

---

本文基于真实的开发工具 GTM 经验，并采用 Adam Frankl（The Developer-Facing Startup）和 Jakub Czakon（markepear.dev）的框架。 选择 GTM 模式，是一项你要坚持多年的押注。如果你想聊聊，欢迎通过 LinkedIn 联系我。