一个产品技术很好、有人喜欢、背后还有大公司，为什么还是会消失？
有个网站专门记录这些事：Killed by Google。它收录 Google 结束或计划结束的服务、应用与硬件，是一个很好的产品研究入口。
不过，墓碑只告诉我们一个名字消失了，不一定告诉我们它为什么消失。业务出售、功能合并、停止独立开发、服务关停，背后的判断完全不同。
对想做产品的人来说，最有价值的问题是：这个产品验证了什么，又有哪些条件一直没有成立？如果换成一个小团队，结论会不会不同？
本文选择 8 个代表案例深入分析，并用 Jamboard 补充生态合作视角。它不是全部关停产品的目录，也不是 Google 内部决策的还原。事实优先引用官方公告；“分析”与“验证问题”是基于公开信息的推论。资料核对日期为 2026 年 10 月 18 日。
先分清：什么叫“死了”？
| 产品 | 本文关注的节点 | 实际发生了什么 | 最值得研究的问题 |
|---|---|---|---|
| Google Reader | 2013 年 7 月 | RSS 服务关闭 | 有忠实用户，为什么仍不值得继续做？ |
| Google Wave | 2010 年 8 月 | 宣布停止作为独立产品继续开发；不是当天关服 | 技术演示如何变成稳定使用习惯？ |
| Google+ 消费者版 | 2018 年宣布退出，2019 年关闭 | 消费者社交服务退场 | 大量入口能否换来真实互动？ |
| Google Allo | 2019 年 3 月 | 应用停止服务，部分功能进入 Messages | AI 功能能否推动关系链迁移？ |
| Inbox by Gmail | 2019 年 | 独立应用退场，部分体验进入 Gmail | 好功能是否必须拥有独立产品？ |
| Google Stadia | 2023 年 1 月 | 消费者云游戏平台关闭 | 技术可行与商业成立之间差了什么？ |
| Google Podcasts | 2024 年 | 独立服务退出，推动用户迁往 YouTube Music | 用户要的简单，与平台要的整合是否一致？ |
| Google Domains | 2023 年完成资产出售，随后迁移 | 业务交给 Squarespace | Google 不做，是否意味着市场不值得做？ |
表中日期对应不同生命周期事件，不能直接拿来计算统一口径的产品寿命。Google+ 的讨论仅限消费者版；Podcasts 各地区的退出节奏也并不完全相同。
用六个角度看一个产品
研究关停案例时，我更关心以下六件事：
| 角度 | 要问的问题 |
|---|---|
| 用户价值 | 哪类人在什么时刻，非用它不可？ |
| 使用与迁移 | 用户为什么会回来？需要搬数据、改习惯，还是拉别人一起换？ |
| 商业模式 | 谁付钱？收入能否覆盖服务、获客、支持与维护？ |
| 生态依赖 | 它是否需要开发者、内容商、合作伙伴同时参与？ |
| 组织战略 | 对用户有价值的东西，是否也值得所属公司继续投入？ |
| 信任与退出 | 如果停止服务，用户会损失什么？能否带着数据离开？ |
下面的案例，都沿着这些问题展开。没有公开收入或成本数据的地方，不把“可能不划算”写成“已经证明亏损”。
1. Google Reader：忠实用户不等于公司的优先级
事实。 Reader 是 RSS 阅读服务。Google 在关停公告中明确给出两个理由：使用量下降，以及公司希望集中资源做更少的产品。服务于 2013 年 7 月 1 日关闭，并提供订阅等数据的导出安排。官方公告
分析。 Reader 的核心价值很清楚：把主动订阅的信息集中起来，让读者自己决定看什么。它同时提醒我们，至少有三件事需要分开判断：
- 有一批人非常需要这个产品。
- 这批人愿意付出足够的钱支持它。
- 这个业务足够重要，值得一家大型公司持续投入。
第一件事成立，后两件事仍可能不成立。官方公告没有证明 RSS 没有市场，也没有提供足以判断独立付费业务可行性的财务数据。
对小团队而言，大公司的退出可以构成研究线索：一个规模有限、需求稳定的市场，也许足以支撑一家小公司。但“用户怀念”与“用户付款”之间，还有一次验证要做。
验证问题。 找到一小群高度依赖信息订阅的人，提供付费试用。看他们是否持续阅读、是否愿意续费，而不只问“你觉得这个想法好吗”。这是对需求强度和可持续收入的同时验证。
2. Google Wave：演示令人兴奋，工作却还要照常完成
事实。 Wave 把实时交流与协作放进浏览器，展示了逐字同步输入、文件拖拽与历史回放。Google 在 2010 年宣布，它没有获得预期的用户采用，因此不再作为独立产品继续开发，并计划复用技术、开放代码和帮助用户导出内容。官方公告
分析。 Wave 最值得思考的是新交互的学习成本。
当一个工具同时改变“在哪里交流”“如何编辑”“怎样回顾历史”，它要求用户学习的可能是一套新的协作方式。团队工具还有额外成本：一个人理解了，其他人也得理解，否则工作仍要回到原来的渠道。
这是一种可能解释，不是已经证实的单一死因。官方确认的是采用未达预期，并没有把全部原因归为“太复杂”。
对今天做 Agent 协作平台的人，这个问题依然具体：用户第一次进入，究竟该创建任务、开会话，还是写文档？如果必须先理解整个系统，首次价值就来得太晚。
验证问题。 选一个已有任务，例如“三个人审完一份方案”。不做完整培训，观察团队能否完成它、是否减少来回沟通，以及下一次是否主动回来。先证明一个工作闭环，再扩展产品边界。
3. Google+：获得曝光，与形成关系网络，是两件事
事实。 Google 在 2018 年的 Project Strobe 公告中表示，消费者版 Google+ 使用和参与度偏低，90% 的用户会话不足五秒。公告同时讨论了 API 维护、用户数据控制与安全问题，并宣布关闭消费者版。官方公告
分析。 一个公司可以给产品很多入口，却不能直接提供“值得互动的人和内容”。
社交产品的价值依赖具体网络：有人发、有人看、有人回应，并且这个循环持续发生。账户存在、页面被打开，甚至短期访问增长，都不等于网络已经成立。
不过，五秒这个数字本身也不能独立解释一切。它是官方描述参与度低的证据，不是一个适用于所有产品的通用失败阈值。
另一个角度是风险成本。即使产品不够活跃，只要保存了个人资料、开放了接口，就仍然需要承担安全、维护和信任责任。低参与度不会让这些责任同步消失。
验证问题。 先服务一个边界清楚的群体，观察有多少人会在没有运营提醒时发起交流、得到回应，并在之后继续参与。早期应证明一个小网络能够自我维持，而不只是积累注册人数。
4. Allo：聪明的聊天功能，能否让朋友一起搬家？
事实。 Allo 尝试把 Google Assistant 等智能能力带入聊天。Google 后来停止支持 Allo，转向 Messages；公告说明，Smart Reply、GIF 等部分能力已经进入 Messages。Allo 于 2019 年 3 月结束服务。产品推出介绍 · 退出公告
分析。 对通信工具而言，功能改进的收益与迁移成本往往不在同一个人身上。
一个人觉得 AI 很好用，但要完成聊天，还得说服别人安装、注册、改变习惯。收益可能属于发起者，成本却由整个群体承担。这里的迁移负担，是产品结构带来的风险；公开公告并不足以证明它就是 Allo 退出的唯一原因。
这对 AI 产品的启发很直接：AI 能力到底需要一个新应用，还是应该进入人们已经使用的渠道？
如果关键价值是总结、建议回复、提取任务，它未必需要重新建立一个通信网络。反过来，如果 AI 改变了协作对象、权限和任务执行方式，独立产品才可能有更充分的理由。
验证问题。 比较两种原型：一个要求团队换到新应用，另一个进入现有工作流。衡量完成同一任务需要邀请多少人、配置多久，以及一周后有多少团队继续使用。
5. Inbox：产品退场，设计思想可以留下
事实。 Google 将 Inbox 描述为尝试邮件新体验的地方，包括稍后处理、智能回复等。退出公告明确表示，部分受欢迎的体验已加入 Gmail，未来将集中投入 Gmail。官方公告
分析。 Inbox 说明，评价一项创新，不能只看它的应用图标是否还在。
从公司的角度，把经过验证的功能送入主产品，可以扩大覆盖、减少重复投入。从用户角度，几个功能被保留，却不保证完整工作方式也被保留：信息组织、交互节奏、默认行为，同样属于产品价值。
对独立开发者，这里有一个边界问题：一个功能很有用，是否足以让用户长期安装并付费使用另一个产品？
如果差异容易被平台吸收，持续竞争可能要靠更完整的工作流、更专门的人群或跨平台能力。不能只靠“平台暂时没有这个按钮”。
验证问题。 假设主平台明天加入你的核心功能，用户还会为什么留下？把答案做成可以实际体验的任务流程。如果找不到答案，先把产品按插件或功能来验证，可能更符合投入规模。
6. Stadia：技术链路跑通，只完成了部分验证
事实。 Google 在退出公告中肯定了 Stadia 的技术基础，同时表示用户增长没有达到预期。消费者服务于 2023 年 1 月 18 日结束；公告包含符合范围的硬件、游戏和附加内容退款安排，也提出在其他业务中使用底层技术的机会。官方公告
分析。 云游戏让用户不必在本地拥有相同等级的计算设备，但一个游戏平台还需要内容供给、玩家习惯、开发者支持与长期信任共同成立。
可以把它拆成三个问题：
- 用户侧： 玩家想玩的内容是否在这里，实际网络体验是否足够稳定？
- 供给侧： 开发者为什么投入适配与维护，投入后是否有足够回报？
- 经营侧： 计算、带宽、内容与支持成本，能否被收入覆盖？
这些是评估同类业务需要检查的条件，不应冒充已公开的 Stadia 内部成本结论。官方“增长不及预期”不能直接推出某一种具体定价或成本结构就是失败原因。
服务退出还揭示了信任的价值：用户购买的是当下的体验，也在赌它未来仍能使用。退款可以处理部分金钱损失，却不能自动恢复时间投入与使用习惯。
验证问题。 在扩展平台前，同时记录真实使用时长、付费留存、每小时交付成本和供给方投入意愿。对 AI 产品也一样：一次优秀演示，只验证了某次输出，尚未证明持续交付值得付费。
7. Google Podcasts：用户希望更简单，平台希望更集中
事实。 YouTube 在 2023 年宣布，Google Podcasts 将于 2024 年退出，投入将集中到 YouTube Music。公告强调发现、社区和音视频切换，并引用当时美国每周播客用户的调查：23% 最常使用 YouTube，4% 最常使用 Google Podcasts。这是特定人群、特定时点的指标，不是全球市场份额。官方公告
分析。 对平台而言，集中入口能让内容发现、创作者工具与消费体验连接起来。对一部分用户而言，理想产品可能只是一个安静的订阅列表和播放按钮。
这两种偏好可以同时存在。一个产品在集团战略上被替换，不意味着原来那种轻量体验没有价值。
但轻量产品也有经营难题：用户可能喜欢它，使用频率却未必能支持高收入；跨设备同步、下载和兼容性仍需长期维护。少做界面功能，不等于没有服务成本。
验证问题。 面向明确的人群，例如通勤听播客的人，比较“丰富推荐”与“直接继续播放”两种体验。检查回访、完成收听与付费意愿，验证简单是否解决了一个足够强的问题。
8. Google Domains：业务换了主人，不能直接判成市场失败
事实。 Squarespace 在 2023 年 9 月 7 日宣布完成 Google Domains 相关资产收购，并安排后续账户迁移。这是业务出售，不是用户域名在当天全部失效。交易完成公告
分析。 同一项业务，在不同公司的产品组合里可能有不同价值。
域名可以连接建站、邮箱与商业服务。对买方而言，它可能是用户进入其他产品的起点；对卖方而言，它可能不再值得独立投入。但仅凭交易公告，无法断言 Google Domains 一定盈利或亏损。
这个案例纠正了一种常见判断：“Google 都不做了，小团队更没机会。”
大公司的选择取决于它的机会成本。小团队的判断，则应建立在自己的获客方式、服务成本、目标收入和客户关系上。规模门槛不同，不代表一定成功，但意味着不能照搬结论。
验证问题。 找到一个具体客户群，估算完整的获客、续费、支持与迁移成本。看能否用有限客户形成可维持的业务，而不只计算潜在市场有多大。
再看 Jamboard：自己退出，也可以把机会交给生态
Google 的 Jamboard 退出公告提供了另一个视角：公司选择依靠 FigJam、Lucidspark、Miro 等合作伙伴提供白板能力，并将精力集中到 Docs、Sheets、Slides 等核心内容协作产品。官方公告
这里值得关注的是“自建还是集成”。用户需要完整的工作流，不代表每个环节都要由同一家公司实现。
对小团队，机会可能来自做好一个专业环节，并能进入已有工作流。不过，集成型业务也会形成平台依赖：接口、权限、分发入口发生变化，都可能影响产品。能接入多个平台、让用户导出数据，会比只依赖一个入口更有回旋空间。
这些案例共同说明了什么？
1. 需求、产品与公司，是三个不同层次
Reader 提醒我们，有需求不保证大公司愿意做；Inbox 提醒我们，有价值的功能不保证独立应用留下；Domains 提醒我们，换一个经营主体，业务可能继续存在。
因此，不能把关停名单直接当成“不要做的方向清单”。也不能反过来把每一个被关停的产品都当成创业机会。
2. 迁移成本会吞掉功能优势
Wave、Allo 与 Google+ 各不相同，但都值得从多人采用的角度研究。
如果收益必须等整个团队或关系网络迁移之后才出现，最早一批用户就要承担很大的启动成本。设计单人可获得的价值、兼容已有渠道、允许渐进迁移，都值得在原型阶段测试。
这是产品设计上的推论，并非对三者关停原因的统一定论。
3. 大公司做实验有道理，用户担心退出也有道理
停止投入可以释放资源。用户却可能已经投入文件、习惯、工作流程与设备。
双方承受的成本不对称。对需要长期托付数据的产品，导出格式、迁移工具、停止服务后的可用范围，应该成为产品设计的一部分。
4. AI 降低实现成本，不会自动解决采用与经营
今天重新做一个更好的 Reader、Wave 或 Inbox，原型可能更容易完成。但用户为什么迁移、为什么回来、为什么付钱，以及开发者为何信任，仍需要单独验证。
“以前技术不够好，现在有 AI”只是一条假设。必须说明 AI 究竟改变了哪个约束：成本、准确率、学习门槛，还是用户完成任务的方式。
做产品前，可以填写这张表
| 问题 | 应该拿出的证据 | 危险信号 |
|---|---|---|
| 谁迫切需要它？ | 一群有相同具体任务的人 | 目标用户是“所有人” |
| 它比现有方法好在哪里？ | 同一个任务的时间、质量或成本比较 | 只能展示功能清单 |
| 用户为什么回来？ | 多次真实使用，且无需反复提醒 | 只有演示后的赞美 |
| 要付出多少迁移成本？ | 导入数据、邀请成员、学习操作的实际过程 | 必须全员迁移才有价值 |
| 谁愿意付钱？ | 真实付款、续费或明确采购进展 | 只有“上线后我会支持” |
| 经营是否可持续？ | 把支持、交付和维护算进去的成本账 | 只计算开发成本 |
| 平台复制功能怎么办？ | 更深的工作流、特定人群或可迁移能力 | 唯一区别是多一个功能 |
| 如果停止服务怎么办？ | 已验证可用的数据导出与退出方案 | 用户所有成果被锁在服务里 |
这不是成功公式。它的作用是把“我觉得这个产品值得做”，转换成可以被用户行为支持或否定的判断。
怎么继续使用这个“产品墓地”
最实用的方式，是挑一个与自己正在做的东西相近的案例：
- 先看原始价值主张，弄清楚它想替谁解决什么。
- 再看退出公告，区分可确认的事实与公关表述。
- 列出仍然缺失的信息：留存、收入、成本、迁移障碍。
- 提出一个今天发生变化的条件，并做一个最小实验。
同时找一个同类、仍在经营的产品做对照。只研究关停者，会产生反向的幸存者偏差：任何特点都可能被事后解释成失败原因。
Killed by Google 最适合作为问题库。它让人看到，产品能不能活下来，取决于用户价值、采用方式、经营条件和组织选择能否一起成立。对想做产品的人，真正值得带走的是这些问题，以及在投入更多之前验证它们的方法。