客户细分

把市场分成需求、预算、行为不同的群组，找到最契合的细分。

为什么

为"所有人"做的产品对谁都不好。客户细分迫使你找出哪个特定群组痛点最急、预算最多、渠道最可达——先为他们做。同一产品对一个细分是必备，对另一个是可选；细分告诉你哪个是哪个。它也防止最常见的创业错误：做通用产品，从所有人得到平庸反馈，永远达不到创造口碑的精准契合。你先选的细分决定定价、文案、功能优先级和渠道——选错会级联影响所有其他决策。

何时使用

在你有假设和一些初步用户对话之后。1-2 天分析。遇到增长瓶颈或重大转型前 revisit。

如何做

1. 收集细分变量
   - 企业属性（B2B）：公司规模、行业、收入、技术栈
   - 人口属性（B2C）：年龄、角色、经验、收入
   - 行为属性：当前工具、问题频率、已花预算
   - 心理属性：目标、价值观、对风险/新工具的态度

2. 聚成 3-7 个细分
   - 把共享变量且需求相似的用户分组
   - 生动命名每个细分："GitHub 单人开发者"、"企业 DevOps 负责人"

3. 按 4 标准给每个细分打分
   - 痛点：问题多急？（1-5）
   - 预算：能/会付吗？（1-5）
   - 触达：能低成本触达吗？（1-5）
   - 契合：你的方案匹配他们确切需求吗？（1-5）
   - 总分 = 之和；你的桥头堡 = 最高总分

4. 选桥头堡细分
   - 你先服务的细分，排除其他
   - 应小到能主导，大到能养活你

5. 精确定义细分
   - 写一段画像：他们是谁、做什么、前 3 痛点
   - 列 3 个你能触达他们的渠道
   - 记下他们不在乎什么（防功能蔓延）

示例

产品：GitHub PR 的代码审查机器人。
初步访谈：30 个不同公司规模的开发者。

识别的细分：
  1. 单人/独立开发者（1 人）    痛 2  预 2  达 5  契 2 = 11
  2. 小团队负责人（2-10）       痛 4  预 3  达 4  契 5 = 16  ← 桥头堡
  3. 中型工程经理（10-50）      痛 4  预 5  达 2  契 4 = 15
  4. 企业 DevOps（50+）         痛 3  预 5  达 1  契 3 = 12

桥头堡：小团队负责人（2-10 开发者）
  - 痛点：他们自己审 PR，这是最大时间黑洞
  - 预算：每队 $20-50/月，有工具预算
  - 触达：活跃于 GitHub、r/ExperiencedDevs、DevOps Discord
  - 契合：他们睡觉时审 PR 的机器人正是他们所需
  - 不在乎：SOC2 合规、SSO、审计日志（企业关注）

决策：先为小团队负责人做；企业是后续扩张。

常见问题

⚠选最大细分而非最高分细分——大细分往往最难触达和服务。
⚠细分定义太宽——"SMB"包括 2 人代理和 200 人公司，需求完全不同。
⚠纯凭直觉打分——用访谈、问卷、渠道研究的数据给每个标准打分。
⚠同时服务 2+ 细分——你分散注意力，做通用产品，两个细分的最尖锐需求都不满足。

最佳实践

✓生动命名每个细分并写一段画像——"GitHub 单人独立开发者"可执行；"小企业"不可。
✓按全部 4 标准打分（痛、预、达、契）——痛 5 但达 1 的细分是研究项目，不是生意。
✓明确列出桥头堡细分不在乎什么——这是你的反路线图，防功能蔓延。
✓规划扩张路径：桥头堡 → 相邻细分 → 下一个——知道顺序防止过早变宽。