打包还是拆分：产品团队的案例研究方法

先确定组合服务于哪个任务

组合应该对客户有明确意义。列出各部分支持的任务，以及同一位购买者是否会在相近时间需要它们。仅仅因为产品属于同一家公司，并不足以说明应该一起销售。

考虑拆分时，要确认客户能独立从某一部分获得价值，还是仍然必须购买其他部分才能完成任务。拆分价格不应该掩盖真正完成目标所需的成本。

观察哪些客户已经购买多个部分，哪些只使用一个，以及原因是什么。把实际行为与“所有人都想账单更简单”的假设区分开；不同人群可能需要不同结构。

交付层面要检查共同的配置、客服、基础设施和集成依赖。单独定价的功能仍可能承担共享成本，分摊方法也应透明，不能把任意分配当成客观事实。

同时研究组合提升便利性与组合增加复杂性的案例，记录产品成熟度、客户类型和迁移成本。客户已经拥有替代品时，同一个套餐结构可能产生完全不同的结果。

不能只看收入标题，还要了解优惠、老套餐迁移和服务范围变化。若来源没有交代这些条件，就应把商业效果标为尚不确定。

例如软件团队可以向明确的适用人群测试一个清楚的组合方案，请客户复述他们会得到什么，以及是否会替代其他购买。理解困难本身就是重要证据。

在合适周期内观察购买、各部分使用、客服负担和取消原因。事先安排老客户待遇与测试结束方式，避免让客户被困在不清楚的服务关系里。

复制到自己的笔记里填写。空白代表尚待验证，不需要用猜测把它填满。

客户任务：
组成部分与依赖：
需求重叠的人群：
各部分独立价值：
共享成本：
可比案例与差异：
方案理解测试：
使用与支持指标：
迁移和退出安排：

选一个支持案例，再找一个结果不同的反例。阅读正文及其来源，检查与你的情境是否可比。

可用于练习的英文案例（请自行核查原始来源）：

在 App 中搜索公司和主题，阅读案例，再用追问比较不同做法。