组合的收束：卖掉一条线、合并或回到单品

产品线的成熟标志，不是你能同时做几个，而是你敢收回到一个。

一、从五条线回到一条线

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

一位开发者用四年时间做了五个产品：两个有收入、两个半死、一个只剩域名。他每天的时间被切成五份，每个产品都「差一点」。

第五年，他做了一次彻底的收束：卖掉一个有稳定收入但自己不再感兴趣的产品，关掉两个半死的，把一个功能并进主产品，只留下一个。

一年后，主产品的收入超过了原来五个的总和。

他说了一句很朴素的话：

「我以前以为产品线是资产，后来发现它也可能是仓库。」

二、三种收束路径

收束不是失败。 它和扩张一样，是产品线管理的一部分。

三、什么时候该收束

以下评分是用于组织复盘的假设规则，不预测收益。给当前组合打三个分（每项 0–3 分）：

• 7 分以上：组合健康，继续维护。
• 4–6 分：结构性收束，砍掉最弱的一条。
• 3 分以下：整体收束，考虑只保留一个。

3.1 「都差一点」是最危险的信号

如果每个产品都处于「再投入三个月就能起来」的状态，说明资源被平均分配了。平均分配的结果通常是每个都起不来。

收束的本质，是把分散的资源重新集中到一个点上。

四、卖掉一条线：资产与合同的边界

转让一个产品，不是转让一个域名。需要逐项确认：

4.1 共享底座是拆卖的最大障碍

如果两个产品共用一个数据库、一套认证、一个计费账户，拆卖就会变成一次架构手术。

这也是第 3 篇强调「共享要有边界」的原因：共享越深，退出越贵。

拆卖前必须确认：

• 能否在不影响留下产品的情况下，把代码与数据分离。
• 共用的账号能否拆分，或由买方重建。
• 共用域名下的子域能否独立。
• 共用的支付通道能否迁移订阅。

4.2 与合规系列的分工

转让涉及的主体变更、合同签署、税务处理、注销顺序，见年度合规日历与退出 ；账号、数据、凭证的交接顺序，见资产交接与继承 。

本篇只回答「该不该卖、卖哪条、拆得开吗」这三个组合层面的问题。

五、合并：把两个变成一个

合并适合「用户重叠、功能重叠、技术可复用」的产品。

5.1 合并的四个阶段

合并最难的不是技术，是让用户相信「东西没丢」。 迁移工具、校验报告、人工支持，三者缺一不可。

六、回到单品：承认组合是负担

出现下面任意三条，就该认真考虑回到单品：

• 组合有效时薪连续两个季度下降。
• 你在多个产品之间切换，每周超过四次。
• 没有哪个产品在增长。
• 维护负债账本里有三个以上红色项。
• 你已经三个月没有完整做完一件事。

回到单品不是把其他产品直接删掉，而是按第 8 篇的日落流程，把它们冻结或转让。

6.1 保留哪一个

「你最愿意长期做」不应该被低估。 一个人的产品线，最终靠的是持续投入的意愿。

七、收束之后

收束不是终点，而是重新获得选择权。

• 时间集中后是否改善需重新观察留存、贡献和工时；可以设 3–6 个月复核窗口，但不承诺届时收入增长。
• 卖掉或关掉的产品，会释放出域名、账号、账单和注意力。
• 你重新拥有了「再开一条线」的判断力，而不是被旧线拖着走。

八、常见错误

九、行动清单

• 用三个维度给当前组合打分。
• 列出每个产品的「可拆卖性」：代码、数据、账号、域名、合同。
• 对候选合并的产品，算功能重叠率与用户重叠度。
• 选定保留的产品，写下三条理由。
• 对其余产品排优先级：转让 > 合并 > 冻结 > 日落。
• 按日落流程执行，保留说明页至少一年。
• 收束后给自己 3–6 个月，不急着开新线。

使用边界与实操验收

拆卖时代码可分离不代表付款授权、账号、用户数据和合同均可转移。应先拿到平台与合同层面的条件，不能用一次数据库复制冒充资产交割。

拆卖验收样例：共享认证只导出有依据且必要的买方产品用户；买方部署独立 token 校验和计费，旧产品 token 不得获得新系统权限；订单余额与订阅 ID 对账；对拒绝迁移用户保留导出或终止退款路径。双方签署资产清单、未了事项与过渡期访问到期日，交割后撤销临时权限。

关键参考与核验范围

以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。

• Stripe 迁移指南 ：付款数据迁移需要处理商协调；不能等同于直接复制订阅对象。
• 个人信息保护法 ：处理依据、委托/对外提供、出境和个人权利分别判断。
• 公司法 ：责任、治理、出资和股权转让以相应条文为准。

系列导航

• 上一篇：维护负债账本：依赖、证书与平台政策的季度巡检
• 回到目录：一个人的产品线：第二个产品与组合运营
• 相关阅读：年度合规日历与退出 、资产交接与继承 、独立开发者生存指南