market-to-devs-sell-to-buyers
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseMarket to devs, sell to buyers
面向开发者做营销，面向采购者做销售
The developer who adopts your tool is almost never the person who pays for it. Win the developer's heart; then hand them the ammunition to win the budget conversation for you.
Use this when: you have stars, signups, and a beloved free tier, and a revenue line of zero.
采用你工具的开发者几乎从来都不是付费的人。先赢得开发者的心，再给他们足够的“弹药”，让他们帮你争取预算。
适用场景： 你的产品拥有大量用户、注册量和广受喜爱的免费版，但营收为零。
The core idea (Czakon)
核心理念（Czakon）
Market to developers, sell to decision-makers. Developers evaluate and adopt; buyers (CTO/VP/procurement) approve money. Your growth engine is the developer champion who sells internally, so your job is to make them look smart to their boss.
面向开发者做营销，面向决策者做销售。 开发者负责评估和采用工具；采购者（CTO/副总裁/采购部门）负责审批资金。你的增长引擎是能在内部帮你推销的开发者拥护者，所以你的工作是让他们在老板面前显得专业靠谱。
Framework: GTM models that work (Czakon)
实用GTM模型框架（Czakon）
Pick the one that fits your product and ICP; don't run all four half-heartedly.
| Model | Fits when | The motion |
|---|---|---|
| Open source | infra/dev-tool, trust & inspectability matter | OSS core → adoption → paid cloud/enterprise |
| PLG / self-serve | fast time-to-value, dev = buyer for small teams | free tier → usage → expand → sales-assist on big accounts |
| Inbound | you can own the problem's content/SEO | educate on the problem → capture → nurture |
| Sales-led / ABM | high ACV, complex enterprise, few big logos | target named accounts, land via a dev champion |
Most dev tools are PLG + a sales-assist overlay for the accounts worth a human.
选择适合你的产品和理想客户画像（ICP）的模型，不要敷衍地同时推进四种模式。
| 模式 | 适用场景 | 运作流程 |
|---|---|---|
| 开源（Open source） | 基础设施/开发者工具，信任与可查性至关重要 | OSS核心功能 → 用户采用 → 付费云服务/企业版 |
| PLG/自助服务（PLG / self-serve） | 价值交付周期短，小团队中开发者就是采购者 | 免费版 → 用户使用 → 功能拓展 → 针对大客户提供销售协助 |
| 获客inbound | 你能主导该问题领域的内容/SEO | 针对问题进行科普教育 → 获取线索 → 培育转化 |
| 销售主导/ABM（Sales-led / ABM） | 客户生命周期价值（ACV）高、复杂企业场景、客户数量少但体量庞大 | 锁定目标客户，通过开发者拥护者达成合作 |
大多数开发者工具采用的是PLG + 针对高价值客户的销售协助模式。
Framework: enable the champion (Czakon + Frankl)
赋能开发者拥护者的框架（Czakon + Frankl）
Give the developer what they need to sell up:
- The Kairos case for their boss (weeks off a release cycle, risk reduced), see .
value-prop-that-converts - A one-pager / ROI snippet they can paste into an internal thread.
- Security/compliance answers the buyer will ask (SOC 2, data handling), the CTO's real fears.
- Proof: attributed results from peers at comparable companies.
Persona → sale map (Frankl): Alpha Dev finds & advocates → VPE/SRE validate feasibility → Empowered CTO approves budget → procurement handles terms (late, enterprise only). A complex sale needs a "what's in it for me" for each. Nail one persona and you get great meetings and no decisions.
为开发者提供向上争取预算所需的资源：
- 面向他们老板的关键价值主张（比如缩短数周发布周期、降低风险），可参考。
value-prop-that-converts - 一份单页文档/ROI片段，方便他们直接粘贴到内部沟通线程中。
- 采购者会问到的安全/合规问题答案（如SOC 2、数据处理方式）——这是CTO真正关心的点。
- 同类公司同行的成果证明。
角色→转化路径（Frankl）： 先锋开发者发现并推广工具 → VPE/SRE验证可行性 → 有决策权的CTO审批预算 → 采购部门处理条款（仅企业级后期流程）。复杂的销售流程需要为每个角色提供“与我相关”的价值点。只搞定一个角色会让你获得很多会议机会，但无法达成决策。
Decision tree: when to introduce paid
引入付费模式的决策树
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.Close your first $1M yourself. Don't hand off sales before you've done it. Teaching a rep is far harder than teaching a founder who's felt the objections firsthand (Frankl).
开发者是否已经获得真实、持续的价值（激活）？
├─ 否 → 为时过早。现在设置付费门槛会扼杀用户采用率，继续交付价值。
└─ 是 → 这是否是小团队（开发者掌控预算）？
├─ 是 → 在产品内提供自助升级服务；保持流程顺畅无摩擦。
└─ 否 → 启动销售协助：帮助拥护者构建内部审批案例。亲自完成你的首个百万营收。 在你自己完成销售之前，不要把销售工作交给他人。教销售代表远比教有亲身应对异议经验的创始人难得多（Frankl）。
Mistakes that look reasonable
看似合理的错误做法
- Expecting developers to have budget: the Alpha Dev loves you and cannot pay you.
- Gating value too early: a paywall before the aha moment converts curiosity into a bounce.
- Cold-selling the VP: bypassing the champion; the buyer trusts their engineer, not your email.
- No champion enablement: the developer wants to buy but has nothing to bring to their boss.
- Four GTM models at 10% each: pick one primary motion and commit.
- 认为开发者有预算：先锋开发者喜欢你的产品，但他们没有付费权限。
- 过早设置付费门槛：在用户体验到“惊喜时刻”之前设置付费墙，会将好奇心转化为用户流失。
- 直接向副总裁冷推销：绕过开发者拥护者；采购者更信任自己的工程师，而非你的邮件。
- 未赋能开发者拥护者：开发者想要购买，但没有可以提交给老板的材料。
- 四种GTM模式各投入10%精力：选择一种核心模式并全力投入。
Your next 30 minutes
接下来30分钟你可以做的事
- Name your model (OSS / PLG / inbound / sales-led) and the one you'll commit to first.
- Identify your happiest free user → that's a champion. Ask what their boss would need to approve budget.
- Build the champion's one-pager: Kairos case + proof + security answers.
- Define the Activation moment that must happen before you ever mention paid.
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.
- 确定你的模式（OSS / PLG / inbound / sales-led），并选定首个全力投入的模式。
- 找出你最满意的免费用户 → 这就是你的拥护者。询问他们老板批准预算需要哪些条件。
- 为拥护者制作单页文档：关键价值主张 + 成果证明 + 安全合规答案。
- 定义激活时刻：在提及付费之前必须达成的用户价值里程碑。
基于真实开发者工具GTM经验构建，整合了Adam Frankl（《面向开发者的创业公司》）和Jakub Czakon（markepear.dev）的框架。
当框架无法做出决策时，就需要专业人士的帮助：The DevTool GTM Company。