Wunderlist：为什么一款用户上千万的待办应用，被收购之后一定会被关掉？
大厂收购你的目的常常是拿到团队和能力，而不是让你继续独立生长
Wunderlist：巅峰期设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购；终局是收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中。
设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购
收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中
3,815 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
与收购方自有产品线直接重叠
两条产品线互斥，整合即意味着其中一条必须消失
收购目的偏向团队与能力而非产品
产品独立发展不在收购方规划中，投入与迭代随之停止
创始人提前离开
产品缺少持续的内部推动者，进一步加速了整合
用户数据与生态绑定在买家体系内
用户无法反对整合，只能接受迁移或自行离开
Timeline: peak to collapse
产品发布
以待办与任务管理应用进入市场
用户增长
用户规模超过千万，成为同品类口碑最好的产品之一
被收购
被大型软件公司收购，创始团队与产品进入该体系
服务关闭
功能被整合进收购方的自有任务应用，原产品正式关闭
Four-Dimensional Retrospective Breakdown
Background & Golden Era
产品以清爽的界面与跨平台同步在任务管理工具中获得口碑，用户增长稳定，因此进入大厂的收购名单，创始团队与产品一起被纳入对方体系巅峰期的成绩单是：设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
收购方本身已有同类产品线，收购的目的是获得团队与能力，独立产品与自有产品线重叠，最终只能被整合关停公司的流量、分发或支付长期依赖单一平台，当平台把同一功能内置为免费能力时，原有的用户价值在一夜之间被抽走。
Internal Culture & Bureaucratic Hubris
组织习惯了「跟着平台节奏走」，产品规划始终滞后于平台政策变化，没有人负责建立真正属于自己的护城河。
The Collapse & Aftermath
收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中。Wunderlist的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
被大厂收购时，先问自己的产品是否与对方重叠
重叠的产品很少能独立存活。
- •在收购协议中约定产品的存续期限与迁移方案
- •把品牌与用户关系作为谈判筹码而不是附属品
- •不要把收购当作产品成功的终点
- •不要在收购后停止与用户的直接沟通
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
在收购谈判中把产品存续与用户迁移写进条款
Critical intervention point：2015 年被大型软件公司收购的谈判阶段
- •不接受没有产品存续约定的收购条件
- •不在整合期内停止原产品的迭代
- •不对用户隐瞒整合与迁移安排
- •在协议中约定原产品的独立运营期限与功能承诺
- •明确数据导出与迁移的时间表并提前告知用户
- •把品牌与用户沟通渠道保留在自有域名下
整合后的资源投入按协议执行，产品团队的考核与用户留存指标挂钩。
产品在整合期内继续获得用户信任，即使最终合并，用户也能完整带走自己的数据，品牌不必以「被关停」收场。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
这款应用的体验和口碑都很好，所以被大厂看上了。但对方已经有一个同类的任务产品，收购的主要目的是把优秀的团队和能力拿进来。这种情况下，两条产品线只能活一条，而活下来的必然是主品牌。用户在这个过程中没有任何发言权，只能在通知里看到服务关闭与迁移指引。
卖公司的时候，要一并争取产品的存续条款和用户的迁移知情权。
Business Post-Mortem Memo · Wunderlist
为什么一款用户上千万的待办应用，被收购之后一定会被关掉？
# Business Post-Mortem Memo：Wunderlist > 为什么一款用户上千万的待办应用，被收购之后一定会被关掉？ > Period: 2011 - 2020 | Industry: Tools & Internet > Peak: 设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购 > Final: 收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中 ## Overview 大厂收购你的目的常常是拿到团队和能力，而不是让你继续独立生长。巅峰期设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购；终局是收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中。 ## Top-voted root causes 1. [Strategy] 与收购方自有产品线直接重叠 (1,255 votes) 2. [Org & Culture] 收购目的偏向团队与能力而非产品 (1,054 votes) 3. [Org & Culture] 创始人提前离开 (853 votes) ## Actionable lessons ### 被大厂收购时，先问自己的产品是否与对方重叠 > 重叠的产品很少能独立存活。 - ✅ DOs: - 在收购协议中约定产品的存续期限与迁移方案 - 把品牌与用户关系作为谈判筹码而不是附属品 - ❌ DON'Ts: - 不要把收购当作产品成功的终点 - 不要在收购后停止与用户的直接沟通 ## Revival plans ### 在收购谈判中把产品存续与用户迁移写进条款 — 良略编辑部 Intervention: 2015 年被大型软件公司收购的谈判阶段 - Must cut: - 不接受没有产品存续约定的收购条件 - 不在整合期内停止原产品的迭代 - 不对用户隐瞒整合与迁移安排 - Breakthrough moves: - 在协议中约定原产品的独立运营期限与功能承诺 - 明确数据导出与迁移的时间表并提前告知用户 - 把品牌与用户沟通渠道保留在自有域名下 - Expected outcome: 产品在整合期内继续获得用户信任，即使最终合并，用户也能完整带走自己的数据，品牌不必以「被关停」收场。 ## Community insights ### 被收购时的真正问题从来不是价格，而是「你的产品在大厂的产品地图上占哪一格」。 — 良略编辑部 (产品经理) 这款应用的体验和口碑都很好，所以被大厂看上了。但对方已经有一个同类的任务产品，收购的主要目的是把优秀的团队和能力拿进来。这种情况下，两条产品线只能活一条，而活下来的必然是主品牌。用户在这个过程中没有任何发言权，只能在通知里看到服务关闭与迁移指引。 - Alternative Move if Replayed 卖公司的时候，要一并争取产品的存续条款和用户的迁移知情权。 --- Source: 良略 · https://www.lianglue.com/c/wunderlist