一个产品的结束方式，会决定你下一个产品的开始方式。
一、突然消失的那个工具
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
一位开发者运营着一个笔记同步工具，用户不多但很忠诚。某天他觉得「不赚钱」，直接关掉了服务器，没有通知，没有导出，没有退款。
三天后，他开始做新产品。发布当天，旧产品的用户在社区里发帖：「这个人上一个产品说关就关，数据都没了，别用他的东西。」
新产品上线一个月，几乎没有转化。他后来才意识到：关停不是一次技术操作，是一次公开的信用事件。
二、三种处置，而不是「要么继续要么关」
| 处置 | 定义 | 适用 | 成本 |
|---|---|---|---|
| 继续 | 正常投入资源迭代 | 有增长、或有明确战略价值 | 高 |
| 冻结 | 只做安全与故障修复，不加新功能 | 稳定但不再增长，仍有收入 | 低 |
| 日落 | 停止服务，迁移或退款 | 长期亏损、无战略价值、维护风险高 | 一次性高 |
大多数人只有「继续」和「关掉」两个选项，于是要么硬撑，要么突然消失。冻结是中间态，也是最被忽略的一档。
三、判断标准
下面是未经统计验证的初始观察规则，不能取代合同和用户承诺。给每个产品打四个分（每项 0–3 分）：
| 维度 | 0 分 | 3 分 |
|---|---|---|
| 收入贡献 | 净贡献为负 | 净贡献占组合 30% 以上 |
| 增长趋势 | 连续 6 个月下滑 | 持续增长或稳定 |
| 维护负担 | 工时占组合 40% 以上 | 工时占比低于收入占比 |
| 战略价值 | 无明显价值 | 为其他产品导流、占住关键平台 |
- 10 分以上：继续。
- 6–9 分：冻结，设定 6 个月观察期。
- 5 分以下：进入日落流程。
3.1 战略价值必须可验证
「这个产品对我有战略意义」是最常见的拖延理由。把它写成一个可验证的命题：
- 它为旗舰产品带来了多少注册？
- 它占住了哪个平台或关键词？
- 它维护了哪个用户群的关系？
如果三个月后这些数字仍然为零，战略价值就不成立。
四、日落前的三个替代方案
在关停之前，先考虑这三条路，它们通常比直接关停更划算：
| 方案 | 做法 | 适合 |
|---|---|---|
| 转让 | 卖给同行、用户或小型收购方 | 有用户、有收入、但你没精力 |
| 开源 | 代码开源，社区自托管 | 技术型产品、用户有自建能力 |
| 托管转移 | 交给合作伙伴继续运营 | 有渠道依赖的产品 |
转让涉及资产、合同与税务，处理顺序见年度合规日历与退出 ；交接细节见资产交接与继承 。
五、30/60/90 天日落清单
日落不是「关服务器」，而是一串有顺序的动作。以下是一个 90 天管理排程示例；合同、法律或用户迁移需要更长时间时应调整，重大安全事件也不能被迫继续不安全运行：
5.1 第 0–30 天：通知与准备
- 决定最终关停日期，写进公告。
- 公告发到产品内、邮件列表、官网、社交媒体。
- 说明关停原因（简短、诚实、不甩锅）。
- 提供数据导出方式与截止日期。
- 说明付费用户的退款或迁移方案。
- 关闭新用户注册与新增付费。
- 停止自动续费，避免关停后继续扣款。
5.2 第 31–60 天：迁移与支持
- 逐个联系付费用户，确认迁移或退款。
- 提供导出文件的格式说明与校验方式。
- 处理退款，保留凭证。
- 把常见问题写成一份迁移指南。
- 评估是否有用户愿意接手（转让或开源）。
5.3 第 61–90 天：归档与关闭
- 导出并归档用户数据（按隐私政策与法定期限保留）。
- 删除不再需要的个人数据，保留删除记录。
- 归档代码仓库，打上最终标签。
- 保留域名至少一年，设置跳转页。
- 关闭服务器、数据库、第三方服务。
- 取消相关订阅，避免继续扣费。
- 从应用商店、目录站、集成市场下架。
- 在官网保留一页说明，解释发生了什么。
5.4 一个容易漏掉的清单
| 项目 | 为什么容易漏 |
|---|---|
| 定时任务与 Webhook | 服务器关了，任务还在跑 |
| 第三方集成 | OAuth 应用、Webhook 订阅仍然有效 |
| 域名自动续费 | 关停后仍在扣钱 |
| 邮件列表 | 还在接收新订阅 |
| 搜索引擎收录 | 需要提交移除或保留跳转页 |
| 商标与账号 | 需要决定保留还是放弃 |
六、对用户的责任边界
| 用户类型 | 你应该做的 | 你不必做的 |
|---|---|---|
| 免费用户 | 提前通知、提供导出 | 无限期保留数据 |
| 付费用户 | 按剩余期限退款或提供替代方案 | 终身免费迁移 |
| 年付用户 | 按适用法律、承诺与实际未履行服务确定退款 | 不作“一定免赔间接损失”的通用结论，免责效力需核对 |
| 企业客户 | 按合同条款执行，提前书面通知 | 超出合同承诺的支持 |
边界要写进服务条款，而不是在关停时才解释。 即使有终止条款，也要核对有效性、既有承诺与消费者权益；没有约定不自动产生无限期服务，但不能据此任意关停。
七、常见错误
| 错误 | 后果 | 更好的做法 |
|---|---|---|
| 突然关停 | 口碑崩塌，影响后续产品 | 提前 30–90 天通知 |
| 不提供数据导出 | 用户数据丢失，投诉与差评 | 提供导出与校验 |
| 不退款 | 支付通道投诉、拒付 | 按剩余期限退款 |
| 关停后仍在扣费 | 风控与信誉损失 | 先停自动续费 |
| 域名直接放弃 | 被抢注，品牌受损 | 保留一年并跳转 |
| 不留说明页 | 用户以为你跑路 | 官网保留一页解释 |
| 不归档代码 | 未来无法复用或证明 | 打标签归档 |
八、把日落变成组合能力
一条健康的产品线，应该每年至少认真评估一次每个产品的去留，而不是等到撑不住了才想。
| 频率 | 动作 |
|---|---|
| 每月 | 看一遍分产品 P&L 与工单量 |
| 每季度 | 给每个产品打四维分 |
| 每年 | 决定是否进入冻结或日落 |
敢于日落，才敢开始。 一个从不关产品的人，最终会被旧产品拖住，无法投入新产品。
九、行动清单
- 给每个产品打四维分，标记 5 分以下的产品。
- 对每个低分产品，先评估转让、开源、托管转移三条路。
- 选定日落产品后，定一个 90 天日期。
- 按 30/60/90 清单逐项执行。
- 检查定时任务、Webhook、自动续费、域名四类隐性依赖。
- 在服务条款里补上关停与退款条款。
- 把日落说明页保留至少一年。
使用边界与实操验收
30/60/90 天、域名保留一年与评分门槛都是排程示例，不是法定安全港。永久/LTD 承诺与普通订阅需分别处理。
日落台账示例：某年付用户已付 120、合同期 12 个月，假设关停时尚有 5 个月未履行且适用按月比例退款，则应退 50；若合同或法律更有利于用户，依其处理。记录停止续费、导出校验、退款回执和删除范围；支付通道关闭前仍要安排未结争议。
关键参考与核验范围
以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。
- Stripe 争议时间说明 ：常见窗口和起算日存在支付方式、服务日期等例外。
- 个人信息保护法 ：处理依据、委托/对外提供、出境和个人权利分别判断。
- 公司法 ：责任、治理、出资和股权转让以相应条文为准。
系列导航
- 上一篇：定价协同：避免产品之间自相残杀
- 下一篇：维护负债账本：依赖、证书与平台政策的季度巡检
- 回到目录：一个人的产品线：第二个产品与组合运营
- 相关阅读：年度合规日历与退出 、资产交接与继承
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。