开发者采用高但收入不跟随、纠结 bottom-up…

为面向开发者的产品设计可执行的 go-to-market motion：先固定约束，跑摩擦门，选且只选一个主运动，并写出自助入口、开发者到买家的交接规则与扩展路径。

适用场景

解决思路

1. 先做访谈：一次问一个问题，尽量用多选题；一旦能说清产品表面、当前采用证据和谁签字就停止，其余边做边确认。需要问：1) 开发者安装、调用或运行什么——library、CLI、self-hosted server、hosted API、IDE/agent extension、platform？2) 他们首次获得价值前必须发生什么：account、credit card、API key、infrastructure、security review、同事？3) 价值只对单个开发者可见，还是只有团队/组织使用后才可见？4) 商业模式和今天的付费边界是什么（free vs paid、self-hosted vs hosted、individual vs organization features）？5) 当前证据：signups、active accounts、paying accounts、expansion，以及这些数字置信度？6) 今天能否判断免费用户属于哪家公司，并把 usage 汇总到 account？7) 谁曾为此产品签过合同，触发因素是什么——他们联系你，还是你联系他们？8) 你这边谁能对信号采取行动：没人、founder、一个 rep、一个团队？响应多快？9) 哪些开发者受众重要——个人和小团队、公司内工程团队，还是 platform/infrastructure groups？10) 什么不可做：没有 sales team、没有 gated docs、没有 cold outbound、对 free tier 有公开承诺、partner exclusivity？11) 必须在什么时候显示收入变化——board meeting、runway date、renewal，还是不固定？12) 想要本季度一次性成功，还是持续复利的资产：自增长免费表面、partner channel、可重复的 qualification machine？13) 你的 effort ceiling 是什么：产品工作小时数、本季度实际可招 headcount、能从 security 和 legal 获得的协调、选择必须多可逆？
2. 最后三个问题决定 step 3 排序，先问再讨论 motion：硬性近期日期在已有免费基础时提升 developer-influenced sales，压低任何需要招聘的 motion；复利 mandate 提升 bottom-up self-serve，因为其他 motion 之后都从中取用基础；无新增 headcount 上限直接删除 top-down with developer proof；拒绝让出 margin 直接删除 ecosystem-mediated。
3. 记录答案；若 harness 有 persistent memory，存储所选 motion、qualification rule 和被拒绝的选项；之后每个 content、community 和 pricing 决策都复用它们。
4. Step 1 在任何探索前固定约束：业务模型已经决定谁能进入 loop——deal size 决定一个人类是否值得碰 deal，付费边界决定人类何时变得必要；若模型未定，先停下并解决，参考 samber/developer-relations-skills@devtools-business-model。
5. 把产品摩擦当属性而非偏好：如果首次价值需要 infrastructure、approval 或第二个人，无论 funnel 怎么优化都无法让 motion 成为 bottom-up。
6. 响应能力是真实的：无人能在数天内行动的 qualification signal 只是 telemetry，不是 motion；按团队本季度实际可配备的人力设计 motion。
7. 在争论 motion 前先做销售算术：加入 self-serve motion 的 salesperson 应带来约 4 倍其 fully loaded cost 的增量收入（Lenny's Newsletter, _The Transition_）；如果 qualified-account volume 乘以现实 deal size 达不到该门槛，任何含人的 motion 暂时都不可用。
8. 同时看反向风险：Pete Kazanjy（Founding Sales, Atrium）说永远不要把 lead gen 误当成 business——$19-29/月 self-serve 是 lead generation，业务是 $50K-$250K contract，连 Datadog 和 New Relic 都运营 sales organizations；问题不是人类是否进入，而是何时进入。
9. 在提出任何建议前，把三个约束（business model、product friction、response capacity）说出来。
10. Step 2 用证据跑三个 friction gates，冷启动跑自己的 onboarding 算证据，信念不算：1) Entry gate——开发者能否无 account、无 approval、无 card、无 call 达到首次真实价值？列出每个强制步骤并标出可移除的；用 Hila Qu（Reforge，前 GitLab）在 Lenny's Podcast 的用户原话测试：“You can use it today.” 2) Value gate——价值是单个开发者就有，还是只有团队规模才有？协作价值意味着 bottom-up 是 entry，不是 motion。3) Spread gate——正常使用是否会产生理由让第二个开发者看到它（shared artifact、repo 中的 config、link、PR）？没有 spread，self-serve 只产生永不扩展的单座 accounts。
11. 根据 friction gates 决策：failing gate 1 直接排除 bottom-up；failing gate 2 或 3 意味着需要 hybrid——developer entry，human-assisted 或 platform-level conversion。
12. Step 3 明确进入 brainstorming mode 并说出来；先拓宽：走 references/motion-archetypes.md 中的四种 motion——bottom-up self-serve、developer-influenced sales、top-down with developer proof、ecosystem-mediated。删除每个被 step 1 约束、失败 gate 或访谈答案排除的 motion，并在 Rejected motions 下记录杀死它的约束；一个被留在菜单底部的 motion 下季度会变成 scope；只是暂时被阻塞的 motion 放到 memo 的 revisit triggers，而不是放回菜单。
13. 按事实呈现 taxonomy：这四种 motion 是本 skill 的综合，不是 published framework；底层 published vocabulary 是两个独立轴——product-led vs sales-led，top-down vs bottom-up，加上 sales assist（Lenny's Newsletter, _GTM motions of 30 B2B SaaS companies_）。同一来源命名 bottom-up lead gen：sales-led 公司的 free product 用于喂 leads 而非收入；使用这个术语——一个跑 bottom-up lead gen 却称其为 product-led growth 的团队会多年争论 funnel，直到有人正确命名 motion。
14. 对幸存 motion 排序并说出排序。Effort 是公司必须构建或招聘的东西、需要从 security 和 legal 获得的协调、选择多可逆——绝不是预算数字。三条默认排序：effort: top-down with developer proof > ecosystem-mediated > developer-influenced sales > bottom-up self-serve；value: top-down with developer proof > developer-influenced sales > ecosystem-mediated > bottom-up self-serve；efficiency: developer-influenced sales > bottom-up self-serve > ecosystem-mediated > top-down with developer proof。
15. 把排序读成数量级：bottom-up self-serve 是一个季度产品工作且无新增 headcount，每个 landed account 是卡大小；developer-influenced sales 是一个季度构建 rollup 和 rule，之后是回答信号的常驻工作，它在效率领先但在两个输入都不领先，因为转换的是已付费获取的 accounts；ecosystem-mediated 是一个季度 partner 工作加永久 margin，listing 很难撤回；top-down with developer proof 是常驻 sales 工作加 compliance evidence，并在第一份合同前就投入 product、security 和 legal。efficiency 排序会饿死 top-down with developer proof：最高价值、最高 effort，所以在每轮排序中都输；但在以下情况仍提升它：buyer 今天已资助该 category；市场是已知 accounts 的集中列表；决定购买的是 compliance mandate 而不是 developer。同样在 buyers 的 committed cloud spend 是进入他们的唯一 procurement path 时提升 ecosystem-mediated，因为任何 direct motion 无论如何都触达不到该预算。
16. 把这些排序当作默认而非法律；随上下文和执行者重新排序：已有 free accounts base 且 rollup 就位，把 developer-influenced sales 推得更前；还没有 free surface 但 entry gate 通过，把 bottom-up self-serve 放第一，因为 motion 2 没有可转换对象；有 in-house partner team 或 marketplace listing 已上线，把 ecosystem-mediated 提升到两者之前。
17. 然后按效率顺序呈现 2 到 3 个候选 motion，绝不是一个，并由你的推荐领头。每个候选覆盖：money path；必须为真的 prerequisite；公司必须 build 或 hire 什么；放弃什么；最早有效证据；在三条排序线上的位置。在进一步细节前让用户选择。
18. 承诺一个 primary motion，至多一个堆叠其上的 secondary。两个 primary 意味着决策未做，团队会为每个 account 属于哪个 funnel 争论。候选数量和 one-primary 规则是本 skill 自己的基线，不是 published rules。
19. Step 4 设计所选 motion 需要的 entry：从 first value 倒推，数开发者必须存活的步骤。具体命名 first-value moment（例如 “a passing test run against their own repo”、“a trace visible in their own dashboard”），不要叫 activation；移除或推迟每个非必需步骤；signup、card、quota approval 和 team creation 每个都是可测量流失，能推迟到价值后就推迟；决定什么永远保持 open：documentation、pricing detail、limits 和 error/troubleshooting content 在任何人联系你之前就被阅读，gate 它们会静默丢失 technical evaluations；对 top-down 和 ecosystem motions entry 仍重要——被交给工具的开发者也会用同样方式评估，糟糕 entry 会把它们变成内部反对者。此表面的执行细节属于战术 skills：samber/developer-relations-skills@developer-quickstart-guide 处理路径本身，samber/developer-relations-skills@readme-optimization 处理首屏。
20. Step 5 写 developer-to-buyer handoff rule。Adoption 按 developer 衡量，收入按 account 记账；1) 把 usage 汇总到 account——email domain、workspace/organization object、license 或 API key、self-reported company；不完美胜过缺失；如果没有，就是 build item 而不是脚注。2) 选 signals，按 intent 递增：depth（production use、sustained volume、CI integration）、spread（第二和第三个 active developer、invites、shared workspace）、boundary contact（有人碰了 SSO、audit、limits、security questionnaire、billing）；boundary contact 最强，因为它直接映射到付费边界。3) 把 threshold 写成一句团队无需解释即可执行的话，数字取自自己的 conversion data，而不是 published benchmark。4) 说明高于阈值会怎样：谁在多少小时内联系，带 technical offer（architecture review、limits conversation、migration help、security pack）——绝不是 “15 minutes to learn about your needs”；Jeanne DeWitt Grosser（Vercel，前 Stripe 和 Google）在 Lenny's Podcast 设定谁有资格发送：“if you are an account executive in my org and I put you in front of 10 engineers at our company, it should take them 10 minutes to figure out you aren't a product manager.” 5) 说明低于阈值会怎样：刻意不做任何人类动作；写下 do-not-contact line，否则 outreach 会漂移到每个 signup，并在最不能容忍它的受众中烧掉 free surface 的声誉。6) 按角色路由：signer 很少是 signup；给 champion enablement pack，给 approver 无需询问的风险答案，给 buyer 用他们词汇写的 cost comparison。一句话形式和 hours-not-days 响应窗口是本 skill 自己的基线，无研究支持——references/sourced-benchmarks.md § “Numbers this skill sets itself” 列出全部；当自己的数据反对时可移动。signal families、threshold template、routing 和 champion pack 内容在 references/handoff-and-expansion-playbook.md。
21. Step 6 按 vector 设计 expansion，不靠希望。Land-and-expand 只有路径被命名时才是战略。对已有 accounts，识别每个处于哪个 vector，然后给触发器和 owner：同一团队更多 developers；同一公司更多 teams；每用户更多 workload；更多 product surface。两件事决定大 account 是否持续增长：达到 standardization decision——platform 或 architecture group 把工具设为默认；multi-threading——第二个 technical advocate 加一个 manager-level contact（本 skill 自己的门槛，设定为使单个 champion 离开不能拖住 account）。预判 procurement re-entry：第二次更大采购可能触发第一次 credit-card 购买跳过的 security review、legal pass 和 vendor onboarding。
22. Step 7 写 GTM memo，逐节验证。产出团队无需你也能执行的决策，模板： # Developer-first GTM - <product> ## Constraints model and paid boundary, product friction, response capacity ## Friction gates entry / value / spread, with the evidence for each ## Rejected motions each one, and the constraint that ruled it out ## Primary motion money path, prerequisite, what must be built or hired ## Entry design first-value moment, steps removed, what stays open forever ## Handoff rule account rollup, signals, threshold sentence, who acts, who is never contacted ## Expansion path vector per account segment, trigger, owner, multi-threading rule ## Leading indicators the numbers that move before revenue, with targets and dates ## Refused what this motion will not do, so nobody re-proposes it monthly ## Revisit triggers the events that reopen the decision。呈现每节并在写下一节前获得同意；motion 错误会传播到下面每一行，在第四个标题抓住远比第十个便宜。完整 worked memo、弱版和强版同节在 references/gtm-plan-example.md。
23. 区分 individual developers 和 company buyers，不要平均两者。Individual adoption（indie developers、hobbyists、small teams——consumer buying 的开发者类比）：user 和 payer 是同一个人，或根本无购买；成功表现为 usage 先于 revenue，购买小、快、刷卡，churn 容易；motion 是纯 self-serve，人类进入 loop 的成本高于合同。Company adoption：user 不是 signer；成功表现为通过 security、architecture 和 procurement review 的 evaluations；motion 需要 account rollup、champion pack 和 paperwork。两者相同：first value 必须单个开发者可独自达到，documentation、limits 和 pricing detail 必须保持 open。之后不同：联系谁、提供什么、expansion 甚至意味着什么，因为第一个 paid moment 之后一切都变。明确排序两条路径而不是同时服务两者；为 hobbyist 和 enterprise platform team 同时设计的 entry 两者都服务不好。
24. Measurement：开发者聚焦公司 free-to-paid conversion 中位数 5%，约为非开发者聚焦公司中位数的一半（Lenny's Newsletter, _What is good free-to-paid conversion_，描述为 1,000+ 产品 survey）。Devtool 用 blended B2B benchmark 衡量会看起来坏掉但实际正常。Net revenue retention bands 也按 motion 不同：bottom-up 产品 12 个月 “good” 接近 100%，不是 enterprise 的 110%（_What is good retention?_）。引用时带来源；用自己的上季度设定目标。完整 sourced bands 和 measurement definitions 见 references/sourced-benchmarks.md。按 published bands 的方式衡量 conversion，否则比较无意义：在窗口内创建 accounts 中，前六个月内开始付费的 accounts，按 cohort，在 account level。Lifetime ratio 会美化任何 signups 增长的产品。跟踪小指标集，五个或更少（自设上限），都在 revenue 前移动：time from first touch to first value；share of accounts reaching depth signal；share of qualified accounts contacted within promised window；free-to-paid conversion at account level；有 paid base 后：net revenue retention 和 share of revenue from expansion。给 memo 中每个数字标注 sourced——带来源和 measurement definition——或 self-set。未带定义的 benchmark 和伪装成 industry standard 的 self-set threshold 都会通过 review，然后误导其上每个决策。两个列表并排在 references/sourced-benchmarks.md。
25. Memo 定稿前把计划按阈值检查，迭代直到通过：三个 friction gates 都用证据回答，任何失败 gate 都反映在所选 motion；恰好一个 primary motion，至多一个 secondary，每个 rejected motion 带 blocking reason；first-value moment 是具体可观察事件，并数出之前强制步骤数；usage 今天能 roll up 到 account，或使其可能的排期；qualification threshold 是一句话，使用自己数据推导的数字，命名 owner 和 response time；do-not-contact line 写下；每个进行中的 expansion vector 有 trigger 和 owner；每个 leading indicator 在本季度内可 instrument 或 schedule，并带日期 target；memo 中每个数字标注 sourced——带来源和 measurement definition——或 self-set。这些数字背后的 framework definitions 属于 samber/developer-relations-skills@devrel-metrics，instrumentation 属于 samber/developer-relations-skills@devrel-analytics；本 skill 只选能证明 motion 有效的少数指标。
26. 检查 common failure modes 并避免：assumed bottom-up（motion 因听起来便宜而被选，gate 1 未测；症状高 signups、无 depth、无 expansion）；qualifying users 而不是 accounts（同一公司 40 个 signup 被当成 40 leads 并收到 40 封邮件）；contacting on signup（教会开发者受众 free tier 是诱饵）；gated documentation、limits 或 pricing（开发者先评估再交谈，book a demo 墙把评估变成静默退出）；demo-only enterprise path 无 self-serve floor（每个小 account 不可服务，长尾离开）；没有回 self-serve 的路（sales 决定不追的 accounts）；enterprise tier 卖给 one-developer account（land 从未真实，renewal 会说明）；expansion 当成 sales-only 而 vector 是 product-driven（spread 和 workload growth 是产品问题）；计算 provisioned seats 而不是 active ones（休眠 seats 预测 renewal contraction）；惩罚增长的 pricing shape（开发者悄悄限制自己的 usage 以避免吓人账单，account 因无人报告的原因扁平化）；每季度切换 motion（每次切换重置学习；按书面 revisit trigger 改变，不按坏月份）；对错误行 benchmark（devtool 用 blended B2B conversion band，或 bottom-up 产品用 enterprise retention，会得出失败但实际正常）；导入 sales-led 响应时间 folklore（“contact within 5 minutes” 统计来自 inbound form fills，不是 developer product usage；导入这里意味着 contacting on signup）。

适用边界 · 注意事项

• 不用于定价点或价格结构设计——使用 samber/developer-relations-skills@devtools-pricing-strategy。
• 不用于输出 pricing page、campaign calendar 或 launch plan；本 skill 只产出 motion 决策、handoff rules、expansion path 和 leading indicators。
• 若业务模型未定，先停下并解决（见 samber/developer-relations-skills@devtools-business-model）；否则 deal size 和 paid boundary 会使后续全部失效。