Wunderlist：为什么一款用户上千万的待办应用，被收购之后一定会被关掉？
大厂收购你的目的常常是拿到团队和能力，而不是让你继续独立生长
Wunderlist：巅峰期设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，2015 年被大型软件公司收购；终局是收购后功能被整合进收购方的自有任务应用，原产品于 2020 年正式关闭，用户被迁移到新的产品线中。
About this link：网站已无法访问：域名无法解析或连接超时。
公开报道整理 待核查 Figures as of 2020 1 sources What do these mean?
How to read this bar
This bar states plainly what we know and what we have checked, so you can judge it yourself.
· Review status: “pending” means no editor has checked it against the sources yet; “checked” means key facts match the sources.
· Figures as of: the year the numbers are current to; later changes are out of scope.
· Sources: listed one by one at the bottom of the page. “Primary” means official filings, annual reports or regulator documents.
· Corrections: every change and its basis is published — nothing is edited silently.
Editorial policy → Editorial policy: the full inclusion rules, verification process, AI disclosure and correction promise.
设计精良的待办事项与任务管理应用，用户规模超过千万，被视为同品类中体验最好的产品之一，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.
这款应用的体验和口碑都很好，所以被大厂看上了。但对方已经有一个同类的任务产品，收购的主要目的是把优秀的团队和能力拿进来。这种情况下，两条产品线只能活一条，而活下来的必然是主品牌。用户在这个过程中没有任何发言权，只能在通知里看到服务关闭与迁移指引。
卖公司的时候，要一并争取产品的存续条款和用户的迁移知情权。
Sources
1 sourcesThese are the references used to compile this case; the numbers match the [1][2] marks in the timeline. Primary sources come first, and archive links are kept where possible.
1 of these are overseas sites (Wikipedia, the Internet Archive, etc.) that may be unreachable from mainland China, so domestic sources (Baidu Baike, mainstream financial media, exchange filings) have been added wherever possible.
-
[1]
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