最难受的竞争不是来自对手，而是来自你自己上个月刚上线的产品。
一、两个产品，互相吃掉了对方
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
一位开发者先做了一个面向个人的笔记工具，定价 8 美元/月。半年后，他做了面向团队版本，定价 12 美元/月。
结果，个人版的用户开始买团队版——因为只贵 4 美元，还能多拿几个功能。而真正需要团队协作的公司，又觉得 12 美元的团队版「不像企业产品」，转而去看了竞品。
团队版吃掉了个人版的升级收入，又没有接住企业客户。 这就是典型的价格带冲突。
二、三种价格带冲突
| 形态 | 表现 | 后果 |
|---|---|---|
| 价格重叠 | 两个产品价格接近、功能接近 | 用户选便宜的，贵的卖不动 |
| 升级倒挂 | 低阶产品加购后比高阶还贵 | 用户困惑，销售解释成本高 |
| 价值错配 | 价格与目标客户不匹配 | 低端觉得贵，高端觉得不专业 |
2.1 价格重叠的判定
用两个数字判断：
- 价差比 =（高价 − 低价）÷ 低价。可用于描述价差；用户是否视为同档需要访谈或购买行为验证，没有通用 50% 定律。
- 功能重叠率 = 两个产品共有的核心功能数 ÷ 较少一方的核心功能数。只描述功能清单交集，不代表用户价值相同，也不能直接预测价格蚕食。
可先把价差和交集列成待研究组合；是否冲突看用户任务、预算主体、迁移路径和总收入变化，不由两条未经验证的阈值自动判定。
三、功能重叠的判定
不要凭感觉说「这两个产品不一样」。把核心功能列出来，逐项打勾：
| 核心功能 | 产品 A | 产品 B |
|---|---|---|
| 数据导入 | ✓ | ✓ |
| 协作编辑 | — | ✓ |
| 导出格式 | ✓ | ✓ |
| 权限管理 | — | ✓ |
| 自动化规则 | ✓ | ✓ |
| 审计日志 | — | ✓ |
重叠率 = 共有功能数 ÷ 较少一方的功能数。上表 A 有 3 项、B 有 6 项，共有 3 项，按“较少一方的功能数”定义，重叠率为 3÷3=100%。若用交集÷并集则为 3÷6=50%，两者回答不同问题，必须说明分母。
功能清单的计数不等于价值权重：个人记录与团队合规可能共用基础能力，但权限、审计和采购方式不同；是否合并需要用户和运行成本证据。
四、三种处理方式
| 方式 | 做法 | 适用 |
|---|---|---|
| 合并 | 把两个产品合成一个，用套餐区分 | 同一核心任务、用户高度重叠且独立维护无额外价值 |
| 拉开 | 提高高价产品的价格或功能门槛 | 用户群不同，但价格带太近 |
| 分层 | 明确低阶与高阶的边界，低阶不做高阶的事 | 同一用户群的不同阶段 |
4.1 合并的判断
下面三条可以触发合并评估，不自动要求合并：
- 核心任务、用户与付款方高度重叠，且合并有迁移和成本收益。
- 用户群高度重叠。
- 两个产品的获客渠道基本相同。
合并之后，用套餐区分能力，而不是用两个独立产品。是否更好卖需比较定位、迁移成本和真实购买路径，不能由套餐数量推断。
4.2 拉开的判断
如果用户群不同，但价格带太近，就拉开：
- 高价产品提价，或增加只有高价才有的能力。
- 低价产品明确边界，不提供会侵蚀高价的功能。
- 按付费意愿、计价单位、支持成本与价值验证价差，不先设“至少 2 倍”。
价格变为两倍不会自动创造不同品类。按席位、workspace 和个人月费比较时先统一单位；不能把单个企业工作区与单人价格直接相除。
五、升级路径的设计
多产品组合里，用户的迁移路径必须提前设计，否则会发生「降级套利」。
| 路径 | 触发条件 | 设计要点 |
|---|---|---|
| 低阶 → 高阶 | 用量、协作人数、合规要求达到阈值 | 升级时保留数据与配置 |
| 高阶 → 低阶 | 团队缩小、需求下降 | 允许降级，但设数据保留期 |
| A → B | 使用场景迁移 | 提供导入工具，避免用户重录 |
5.1 升级不能靠「功能藏起来」
把功能藏在更高价的产品里，是最常见的做法，也是最容易招致反感的一种。更好的做法是按使用规模或协作复杂度分层：
- 个人用 → 低阶。
- 小团队用 → 高阶。
- 有合规、审计、私有部署要求 → 企业版。
这样用户升级是因为「我长大了」，而不是因为「你把功能锁了」。
六、价差与折扣的协同
| 规则 | 说明 |
|---|---|
| 折扣叠加要先测算 | 检查折后贡献、老用户权益与套餐边界 |
| 年付折扣统一口径 | 不同产品用不同折扣，会让用户觉得定价随意 |
| 迁移价明确期限与承诺 | 永久价格是商业承诺，需测算成本，不等同于会计负债定性 |
| 企业折扣明确授权规则 | 按合同、席位、期限与服务范围解释差价 |
6.1 一个反例
A 产品年付 8 折，B 产品年付 7 折，两者原价接近。用户会发现「买 B 的年付比买 A 的年付还便宜」，于是本来该买 A 的人去买了 B。
折扣策略必须放在组合层面统一看，而不是每个产品单独定。
七、什么时候不该做价格协同
- 两个产品的用户群完全不重叠：各自定价，不需要协同。
- 两个产品处于不同的生命周期：新产品需要渗透定价时，不必向老产品看齐。
- 监管或平台有固定价格：比如应用商店的档位限制。
八、常见错误
| 错误 | 后果 | 更好的做法 |
|---|---|---|
| 两个产品价格只差一点 | 互相侵蚀 | 核对同一用户任务和计价单位，试验不同价格或套餐 |
| 功能重叠却分成两个产品 | 用户困惑，销售成本高 | 合并成一个产品的多个套餐 |
| 升级靠锁功能 | 用户反感 | 按规模与复杂度分层 |
| 折扣各自为政 | 出现降级套利 | 组合层面统一折扣口径 |
| 企业版也打折 | 价格锚点失效 | 企业版单独报价 |
九、行动清单
- 列出所有产品的价格与核心功能。
- 计算每对产品的价差比与功能重叠率。
- 标记可能服务同一任务但边界不清的组合，记录用户和贡献证据。
- 对每组冲突选择合并、拉开或分层。
- 设计低阶到高阶的升级路径与数据保留规则。
- 统一折扣口径，检查是否存在降级套利。
- 把定价决策写成一页文档，新增产品时先对照。
使用边界与实操验收
价差比和功能交集只是描述工具，不是定价或产品合并的科学阈值。不要用改变价格来替代明确产品对象。
反例：个人版 8 美元/月、团队版 12 美元/席位/月，5 席团队实际 60 美元，不能按“只差 4 美元”推断同档。先记录角色、计价单位、协作人数与审计能力，再观察是否发生购买替代；若团队用户稳定付费且个人用户不受损，基础功能重叠不构成必须合并的证据。
关键参考与核验范围
以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。
- 财政部收入确认提示 ：按控制权和交易身份判断总额法或净额法，不能只看到账。
系列导航
- 上一篇：产品间的引流与打包：交叉推广、捆绑与用户池边界
- 下一篇：什么时候砍掉一个产品：继续、冻结与日落
- 回到目录：一个人的产品线：第二个产品与组合运营
- 相关阅读：SaaS 定价与套餐 、SaaS 套餐与权限设计
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。