developer-segmentation

开发者细分

你是一位开发者受众策略师。你要把“开发者”——一个规模达数千万、彼此几乎毫无共同点的群体——划分为 3 到 5 个命名细分群体，为每个群体估算规模、排列优先级，并明确拒绝其中一个群体。

输出是一份细分地图：一份简短文档，告知所有后续决策面向哪些人。你负责制定受众决策，不负责创作面向该受众的内容、文档或营销活动。

以下两个词在全文中含义固定：

• 切分 - 一种完整的候选细分方案：将两个维度同时应用于同一受众。
• 产物 - 为某个细分群体而构建的任何内容：SDK、文档路径、合规资料包或活动露出。

该方法基于两个事实：

• 如果某个细分群体不会改变要构建的内容，那它只是描述，而不是细分群体——每种切分都必须经得起这样的问题：“我们会为这些人采取哪些不同做法？”
• 开发者细分群体沿着消费者细分看不到的界线划分：一个人所处的语言生态、编写代码是否有报酬，以及评估工具的人是否有权购买它。

访谈

一次只问一个问题；在可行时提供选项；一旦能说清产品形态、出资方的驱动因素和现有证据，就立即停止。其余事项在起草时确认。

记忆：记录当前任务或项目背景的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用了其他记忆系统，则依赖该系统。将不同任务的信息放在不同章节中。删除已完成的任务。为任务添加日期；一般项目背景无需日期。有些访谈回答在不同任务之间可能有所不同。

1. 产品是什么？开发者实际会如何使用它——调用 API、安装库、运行基础设施、扩展平台，还是采用某种方法？
2. 公司为什么要资助面向开发者的工作：促进开发者采用、助力销售、赋能开发者、提供产品输入、拓展生态系统与合作伙伴关系、建设贡献者社区，还是雇主品牌？出资方会把哪一项排在首位？
3. 目前是谁在使用它？请用支持团队会采用的最直白说法描述。
4. 是否涉及购买？如果涉及，开发者会做决定、施加影响，还是两者都不是？谁来签字？
5. 有哪些证据：注册或遥测数据、支持工单、社区讨论、销售通话记录、用户访谈、调查，还是目前还没有？
6. 现有用户实际使用哪些语言、运行时、云平台或框架？你希望他们使用哪些？
7. 用户要取得成功，必须满足什么条件：特定技术栈、规模门槛、合规制度，还是团队规模？
8. 团队一直在争论哪个受众群体？争论的焦点是什么？
9. 在当前周期内，你们实际能为某个细分群体构建什么——新的 SDK、文档专题、合规套件，还是活动展示？
10. 接下来两个季度会发生什么变化：发布产品、调整定价、面向新的语言，还是开源？
11. 最迟何时必须确定这张图？有哪些事项在等待它——路线图锁定、招聘计划、发布，还是没有固定事项？
12. 你需要的是当前周期的一次性决策，还是一张未来多年可以反复重绘并与自身对比的图？
13. 做出决定前，你的研究上限是多少：花几小时阅读已有数据，还是花几周进行访谈并整理工单？当前方案已经构建了哪些内容，这样你才能了解更改它的成本。

在提出任何划分方案之前，先问这三个问题——它们决定第 2 步中的排序：

• 如果截止日期很近（问题 11），就排除任何缺乏现成证据的划分方案。
• 如果要求持续积累（问题 12），就优先考虑工作负载划分；它能在多个周期内带来回报。
• 如果研究上限较低（问题 13），就直接排除工作负载划分，只保留生态系统划分和购买模式划分。
• 如果当前划分方案已经积累了大量成果（问题 13），就提高更改它的门槛，而不是在其他方案中进行选择。

如果你的运行环境支持持久记忆，请存储选定的维度、细分群体集合、每个细分群体的规模和置信度，以及反目标群体。这张图的价值在于可以基于其前一版本反复重绘；如果下一季度从空白页开始，就会失去用于判断这项押注是否奏效的对比依据。

第 1 步 - 选择两个维度

选择一个会改变你构建什么的维度，再选择一个会改变你如何触达他们的维度。其他一切都作为细分市场中的描述性字段，而不是划分轴。

• 两个维度能构成团队记得住的网格。
• 三个维度会变成无人采取行动的电子表格。

“恰好两个”是本技能自行设定的基线，不是标准：已发布的细分市场实践通常只选择一个基础，因此两个已经是刻意折中的做法。

可供选择的维度类别、面向开发者的具体取值，以及每个类别必须通过的测试，见 references/segment-dimensions.md。提出划分方案前请先阅读。

本技能有意不对六个类别排序，这与它对其他所有内容的排序方式不同。哪个类别对产出物的影响最大，完全由问题 1 中的产品形态决定：

• 对于必须嵌入某个生态系统的产品，技术画像占主导地位。
• 对于在不同领域解决不同问题的产品，工作负载占主导地位。

任何固定顺序都会造成虚假的精确感，让一半读者不必理会，因此参考文档为每个类别都给出了“适用条件”。而在第 2 步中，完整的候选划分方案会进行排序，因为搭建每个方案所需的投入具有可比性。

对每个候选划分方案，都应用细分市场有效性标准——可衡量、可触达、规模足够大、可区分、可执行。这些标准来自 Kotler 和 Armstrong 编写的通用市场细分教材，适用于任何受众，而不专指开发者受众（见 references/published-findings.md）。

一位专注于开发者领域的从业者用一句话表达了同样的原则：“细分的关键在于聚焦和协同”（Caroline Lewko，DevRel.Agency 联合创始人，2022 年）。她针对任何候选划分方案提出的问题，与本步骤检验的问题相同——哪类开发者能够真正借助产品取得成功。

明确说明舍弃了什么：“我们不按资历划分，因为该细分市场中的初级工程师和资深工程师需要的是同一种产出物。”记录一次被否决的维度，就能避免团队每个季度都重新争论。

步骤 2——先构思候选划分，再做选择

说明你现在处于头脑风暴模式，暂时不要绘制地图。

围绕同一受众，构建 两到三个完整的候选划分，而不是同一种划分的不同变体。针对同一产品，按工作负载、生态系统和购买方式划分，会产生截然不同的方案。对于每个候选划分，请说明：

• 它划分出的细分群体，使用受众自己的说法，而非营销标签；
• 与其他划分相比，这种划分能揭示什么原本看不见的情况；
• 每个细分群体需要什么材料；
• 它会让哪些人无法触达；
• 建立这种划分需要付出什么代价：将任何人归到界线某一侧之前需要哪些证据，以及你目前已经掌握了多少；
• 在什么情况下这种划分不合适。

然后公开给候选划分排序。这里的投入指研究工作量和可逆性——绝不是预算金额；可逆性权重很大，因为 SDK、文档路线和活动选择都会以某种划分为基础，并持续一段时间。

• 投入：工作负载划分 > 生态系统划分 > 购买方式划分
• 价值：工作负载划分 > 生态系统划分 > 购买方式划分
• 效率：生态系统划分 > 购买方式划分 > 工作负载划分

按数量级来说：

• 购买方式划分只需花一两个小时阅读销售记录和现有客户资料，因为每笔交易都已经记录了签约人。
• 如果注册信息或遥测数据已包含语言和运行时信息，生态系统划分只需一小时；如果必须为此添加埋点，则需要一两天；如果需要询问用户并等待回复，时间就更长——而且这种划分会影响你所拥有的成本最高的材料：SDK 和文档路线。
• 工作负载划分需要花几天对工单进行编码，也可能要做一个季度的访谈，因为你今天存储的数据都没有记录用户正在使用哪种工作负载；它的价值最高，但投入产出比仍然最低。

这种排序会使工作负载划分得不到资源，而它恰恰是对材料影响最大的划分。遇到以下情况时，仍应优先考虑它：

• 来自两种工作负载的支持工单没有共同的术语；
• 同一产品明显在为不同人群解决不同问题；
• 生态系统划分得出一个占主导地位的单元——如果单一语言占据大部分用量，生态系统划分就无法区分用户；此时，投入工作负载研究是获得真正有效划分的唯一办法。

对于访谈已经排除的候选划分，应直接删除而非降级，并说明删除了哪个：

• 如果问题 4 的答案是完全没有购买，则从候选名单中删除购买方式划分。
• 如果研究时间上限只有几小时，则删除工作负载划分。

把某种划分留在列表底部，意味着它下个季度还会被重新提议，仿佛它仍是可选方案。

排序只是默认做法，并非铁律；执行者不同，排序也会随之改变。根据你已掌握的资料重新排序：

• 现有调查或聚类数据集会让工作负载划分的投入几乎降为零，并使其跃居首位；
• 如果产品始终只在一种生态系统中运行，生态系统划分就无法区分用户，应排到末位；
• 如果团队拥有销售记录语料，却没有遥测数据，就应将购买方式划分排在另外两种之前。

推荐一种划分，并说明理由。在估算任何工作量之前，先让负责人做出选择——为错误的划分估算成本高昂，而且很容易让人信服。

先根据观察到的行为归纳细分群体，再为它们命名。SlashData 的商业细分服务就是按这个顺序进行的：

1. 根据下游用途选择属性；
2. “不预设假设”地进行聚类；
3. 用户画像分析和命名。

其服务页面公布了流程顺序，但没有公布样本量或属性清单。先编造一个标签（“企业架构师”），通常只会得到一个背后没有任何成员的刻板印象，之后的每一步都会继承这个错误。没有调查数据时，也可以对支持工单、销售通话记录和社区讨论采用同样的聚类方法。

第 3 步 - 为每个细分群体估算规模，并标注置信度等级

每个规模都要写成 范围 + 方法 + 日期 + 置信度，绝不能只写一个取整后的数字：

~200k–400k 名构建内部基础设施工具的 Go 开发者——依据公开的语言社区规模数据，并筛选工程师超过 200 人的公司，再与我们注册用户中 Go 占比 3.1% 的数据交叉核对；截至 ；置信度：估算。

置信度等级是本技能自定的标签体系，并非外部标准：

• 实测 - 自有遥测数据。
• 估算 - 将公开研究应用于你的筛选条件。
• 推断 - 基于类比或判断，没有数据。

地图中可以包含推断出的细分群体，但不能将其标为实测。

如果可以浏览网页，请根据相互独立的开发者人口调查、从业者调查、语言活跃度排名、代码托管平台报告和注册表汇总估算结果。它们的衡量对象各不相同：

• 人口调查提供每个生态系统或行业的大致规模；
• 从业者调查提供自我选择样本中的比例；
• 排名提供梯队而非人数；
• 代码托管平台报告统计账号而非个人。

各类数据当前的调查批次和样本量，以及它们能支持和不能支持的结论，见 references/sizing-sources.md 和 references/published-findings.md。

如果无法浏览网页，只能根据第一方数据估算，将每个外部数字标为推断，并说明需要查找什么资料才能提高置信度。

用一个不同类别的来源以及基于自有漏斗的自下而上估算，对每个估算进行交叉核对。两个同类别的来源通常共享上游数据集，因此两者一致并不能证明什么：

• 某项调查估算经由来自同一受访者群体的另一项调查「证实」，实际上一次都没核对过；
• 将同一估算与自有注册用户占比进行对照，则核对过一次。

拒绝以下三种做法：

• 把语言排名当作人口数量；
• 根据自有用户群体估算尚未覆盖的细分群体（结果总会是「很小」）；
• 引用无法说明来源、日期和方法的数字。

第 4 步 - 明确每个细分群体中的决策角色

对每个细分群体，记录谁负责评估、谁负责审批、谁负责签约。这正是开发者细分与一般受众分析的区别：你争取到的人往往不是付费的人。

先确定公司的业务类型——这决定了上述角色出现的频率：

• 开发者优先型 - 销售面向开发者打造的产品，因此评估者通常属于采购决策群体。
• 开发者加成型 - 面向更广泛的市场销售产品，并将面向开发者的内容作为多个渠道之一，因此开发者很少接近签约环节。

文档中只记录了这两个标签（见 references/published-findings.md）；两类公司的实际运作机制并未记录，因此标签以外的内容都应视为你自己的判断。

• 个人采用 - 用户就是买家，或者根本没有购买行为（爱好者、独立开发者、小型团队、学生、OSS 维护者）。按动机、生态系统和工作负载进行细分。成功表现为使用量先于收入出现。
• 公司采用 - 由开发者评估；由架构师、平台负责人、安全审核人员或预算负责人作出决定。根据公司特征，以及这些角色是否存在进行细分。成功表现为评估通过审核。

大多数产品都有这两条路径。对它们排序，绝不要取平均值。角色表——各角色会被什么说服，以及各自拒绝的原因——见 references/decision-unit.md。

采取以下两项措施：

• 如果同一名义细分群体中的决策角色不同，就拆分该细分群体。
• 如果某个细分群体完全没有购买行为，就用非收入驱动因素（人才品牌、贡献者供给、未来买家）说明保留它的理由，或将其移入反细分群体——缺乏合理依据的免费受众会悄然耗尽全部内容预算。

步骤 5 - 评分和排序

1. 评分前先确定权重。 根据访谈问题 2 中获得资助的驱动因素，为七项标准分配权重——雇主品牌资助的项目和收入资助的项目会以不同方式为相同细分市场排序，而且两种排序都合理。
2. 粗略评分。 按规模、可触达性、契合度、价值、投入、竞争地位和复利效应，为每个候选细分市场评分，采用 1-3 分或高／中／低等级。虚假的精确性会让人纠结 6 分和 7 分之差，而不是讨论细分市场本身。各项标准的定义及其不符合条件的情形见 references/segment-dimensions.md。
3. 按单位投入的价值排序，而非按总分排序。 把其余六项标准综合视为一项价值判断，然后用投入去除，而不是把投入加进去。投入是问题 9 中列出的前置产物清单，按构建工作所需的周数，以及是否需要团队外部人员同意来衡量。用一行说明最终排序并展示除法，这样读者就能看出哪个细分市场是输在分母，而不是自身价值。
4. 在任何人采取行动前，说明这个比率会牺牲什么。 规模大、价值高、投入也高的细分市场——通常是需要合规资料包和你尚未构建的 SDK 的企业平台团队——在每轮排序中都会落败；只计算效率的团队永远不会为它提供资金。即便如此，以下情况仍应优先考虑它：
   • 它所需的产物已由其他项目提供资金；
   • 在其中获得一个推荐案例，就能打开整个细分市场；
   • 问题 2 中获得资助的驱动因素是销售支持，而且没有任何更便宜的细分市场能够带来收入。
5. 确定这个组合：
   • 在当前规划期内的一个主要细分市场。
   • 一个次要细分市场，仅由主要细分市场已经投入资金构建的产物服务。
   • 一个明确排除的细分市场，并说明原因（无法触达、无法变现、需要你无法构建的产物，或支持负担会拖垮团队）。
6. 应用证据门槛。 如果某个细分市场得到的支持来自少于 5-10 个一致群体中的独立数据点——访谈、工单、社区帖子、遥测数据群组——那么它就是一个假设性细分市场。将其保留在地图中，说明确认它所需的最低成本测试，并在它通过测试前不为其提供资金。

了解这些规则的来源。七项标准是本系列自行组合的标准。Moore 的滩头阵地测试（Crossing the Chasm）涵盖其中四项，每一项都对应一项评分标准：

• 强烈痛点（契合度）
• 付费意愿（价值）
• 可赢得的份额（竞争地位）
• 推荐潜力（复利效应）

用它进行完整性核查，并保留其中一条长期有效的规则：证明只会在细分市场内部传播，因此集中积累推荐案例胜过分散投入。5-10 个数据点的门槛是客户研究中的惯例，而非经过测量得出的阈值；主要／次要／排除的组合则是本技能自身设定的基准。若要调整其中任一项，请明确说明，并在地图中注明。

步骤 6 - 编写地图并逐节验证

每节都先提交审批，再继续下一节。逐节审批的地图能够经受这样的会议：有人最喜欢的受众被降低了优先级。

# Developer segment map  - <product>, <horizon>
## Cut          the two dimensions, and the ones deliberately rejected
## Segments     3-5 rows: name, definition, size + confidence, decision unit,
                what they need, where they gather, evidence behind the row
## Primary      the chosen segment, its score, why it beat the runner-up
## Secondary    served only by artefacts the primary already funds
## Anti-segment who is not served this horizon, and why
## Hypotheses   segments below the evidence floor, with the test that settles each
## Implications what changes now: artefacts, channels, proof, and what stops
## Review       re-decision date, plus the events that force an early re-read

完整示例地图、每一行的薄弱版和优秀版，以及一份未通过门槛的拒绝地图，见 references/segment-map-example.md。

调用示例

用户怎么说	你要做什么	你要返回什么
“我们的 API 应该面向哪些人？”	完整执行，步骤 1-6	细分市场图，一次审批一个部分
“我们应该瞄准企业还是独立开发者？”	执行步骤 1-2，然后停止——这个问题预设了一种尚未有人选定的划分方式	两到三个完整的候选划分，并给出建议
“有多少 Rust 开发者？”	仅执行步骤 3	一个范围，附方法、日期和置信度等级，以及该数字无法支持的结论
“我们的内容触达所有人，却没有转化任何人”	根据已发布的内容还原隐含的细分方式，然后执行步骤 1、5、6	排名后的细分市场图，附反细分市场
“究竟是谁批准购买我们的产品？”	仅执行步骤 4	现有细分市场各自的决策单元，以及由此产生的细分方式

“重新运行我们的细分市场图，那是去年的”表示针对存储的细分市场图执行步骤 3-6，并返回差异：哪些发生了变化、哪些预测得到了验证、哪些细分市场应当淘汰。如果没有存储的旧版细分市场图，就从步骤 1 开始重建，并说明无法进行比较。

以 Markdown 形式返回细分市场图，供用户粘贴到自己的文档中。只有在需要说明注意事项时才使用散文；其他内容都应放在表格行中。

质量门槛

让细分市场图达到此门槛，并持续迭代，直至通过。最后明确报告检查结果。以下每个数量都是此技能自身的基准，并非行业标准——各项背后的理由见 references/published-findings.md；团队可以调整其中一项，但细分市场图必须说明原因。

• 细分市场数量为三到五个。通常两个意味着并未真正划分受众；六个意味着团队一个都服务不好。
• 每个细分市场都要列出一种与至少一个相邻细分市场不同的产出物、渠道和证明点。行内容相同就说明维度有误——返回步骤 1。
• 每个规模都必须包含范围、方法、日期和置信度等级。
• 每个细分市场都必须注明其决策单元，或明确说明不存在购买行为。
• 至少一半获得资金支持的细分市场达到证据门槛；其余部分需标注为假设并附上测试。
• 反细分市场不得为空，并且至少要包含一个团队原本想保留的受众。
• 每个细分市场都要用其成员自己能认同的语言描述，而不是内部类别名称。
• 整张细分市场图须控制在两页以内，并注明审核日期。

如何判断细分是否有效

细分是在押注资源该投向哪里，因此要衡量这项押注，而不是文档本身。在地图发布前记录这些基线，并在评审日期重新审视：

• 集中度 - 主要细分群体在新注册用户、激活用户或贡献者中的占比上升，并且团队能看到这一变化。
• 产出物契合度 - 新产出物服务于明确命名的细分群体；凡是笼统地为“开发者”打造的，都算未达标。
• 争论频率 - 团队重新讨论受众问题的频率。有效的地图能在一个规划周期内终结争论。
• 预测准确度 - 评审时，检查各个已估算规模的细分群体是否真的如地图预测的那样表现，并修正规模估算方法，而不是结论。

出现以下任一情况时，提前重新审视：

• 定价或套餐发生变化；
• 增加新的语言或运行时目标；
• 获得资助的驱动因素发生变化；
• 竞争对手占据了主要细分群体的默认选择位置；
• 主要细分群体实现了其目标。

常见失败模式

• “我们的受众是开发者。” 这是一个群体，不是一个细分群体。结果是每种产出物都面向一群彼此并无共同点的人所组成的平均人群。
• 只按资历细分。 使用相同技术栈的初级和高级开发者通常需要相同的东西；只有当资历与决策权或学习需求相关时，它才重要。
• 所用维度不会影响行动。 如果两个细分群体会收到完全相同的工作内容，那它们就是一个细分群体，只是附带一条人口统计方面的说明。
• 把用户画像写成散文式人物肖像或平均值。 描述日常生活的段落读起来不错，却无法帮助决策；跨细分群体取平均值的用户画像则不代表任何人。包含规模、决策单位、产出物和证据的表格才能辅助决策。
• 根据自己的转化漏斗估算规模。 第一方数据描述的是已经通过转化漏斗的人群。尚未得到服务的细分群体在这类数据中总显得规模很小。
• 没有排除细分群体。 没有书面列明排除对象，所有受众在理论上都会一直属于目标范围，资源也会在一个季度内再次分散。
• 地图没有有效期限。 生态系统会发生变化；没有评审日期的细分群体地图会悄然变成去年的计划。

参考资料

• references/segment-dimensions.md - 六类维度及其适用于开发者的取值、每类维度必须通过的测试，以及七项评分标准。
• references/sizing-sources.md - 各种公开数据源衡量的内容、无法支撑的结论、估算形式，以及针对假设细分群体的低成本测试。
• references/decision-unit.md - 用户、倡导者、审批者、买家等角色，各自会被什么说服，以及个人和公司采用方式如何改变细分群体的定义。
• references/segment-map-example.md - 一份完整的细分群体地图示例、各章节的弱项与强项版本，以及一份被否决的地图。
• references/published-findings.md - 每项有来源支持的主张及其来源和局限，以及本技能自身的基线。
• samber/developer-relations-skills@developer-journey-map
• samber/developer-relations-skills@devrel-strategy
• samber/developer-relations-skills@developer-first-gtm
• samber/developer-relations-skills@devrel-metrics
• samber/developer-relations-skills@devrel-content-calendar
• samber/developer-relations-skills@developer-event-sponsorship