被收购后停止开发的邮件客户端 (Sparrow)：一款口碑很好的付费邮件应用，为什么被买下后就不更新了？

# Business Post-Mortem Memo：被收购后停止开发的邮件客户端 (Sparrow)

> 一款口碑很好的付费邮件应用，为什么被买下后就不更新了？
> Period: 2011 - 2015 | Industry: Tools & Internet
> Peak: 法国的第三方邮件客户端开发团队，产品以简洁的界面与良好的交互在用户中获得较高评价，在苹果平台的邮件工具市场上具有稳定的付费用户群
> Final: 被大型互联网公司收购后，产品的主要开发工作停止，团队被调往其它项目，客户端在此后几年逐步停止更新与支持，付费用户被迫迁移到其它客户端

## Overview
当收购的目的是获取团队经验，产品的路线图就会被并入别人的计划。巅峰期法国的第三方邮件客户端开发团队，产品以简洁的界面与良好的交互在用户中获得较高评价，在苹果平台的邮件工具市场上具有稳定的付费用户群；终局是被大型互联网公司收购后，产品的主要开发工作停止，团队被调往其它项目，客户端在此后几年逐步停止更新与支持，付费用户被迫迁移到其它客户端。

## Top-voted root causes
1. [Product & Tech] 市场被系统自带邮件功能挤压 (2,060 votes)
2. [Capital & Finance] 付费规模不足以支撑持续研发 (1,730 votes)
3. [Strategy] 收购目标与产品延续不一致 (1,401 votes)

## Actionable lessons
### 第三方工具要解决平台不做的事
> 把差异化建立在系统覆盖不到的环节。

- ✅ DOs:
  - 聚焦跨平台一致性与团队协作等系统弱项
  - 建立企业客户与团队版付费能力
- ❌ DON'Ts:
  - 不要在系统自带功能高度重叠的领域长期投入
  - 不要把口碑当作付费能力

### 被收购前明确产品的存续安排
> 在交易中争取维护期限与团队承诺。

- ✅ DOs:
  - 在条款中约定产品维护期限
  - 为用户准备数据迁移与过渡方案
- ❌ DON'Ts:
  - 不要假设收购后产品会继续更新
  - 不要让用户的长期使用依赖单一买方意愿

## Revival plans
### 先找到平台不做的部分 — 良略编辑部
Intervention: 2012 年收购完成后产品路线逐步并入母公司时
- Must cut:
  - 停止在系统功能高度重叠的领域投入
  - 停止按个人用户的付费规模规划研发
  - 停止依赖单一平台的生态假设
- Breakthrough moves:
  - 把产品延伸到跨平台与企业协作场景
  - 为企业客户提供安全与合规相关能力
  - 在收购谈判中约定产品维护与用户迁移安排
- Expected outcome: 产品在企业与跨平台场景中保有付费用户，或平稳过渡给用户替代方案。

## Community insights
### 这类产品的困境在于，用户愿意为体验付费，但愿意付的钱不足以支撑一支完整的开发团队。 — 良略编辑部 (工程师)
第三方邮件客户端的使用频率很高，用户对交互体验有明确偏好，因此能形成口碑。但系统自带的邮件应用已经覆盖了大部分需求，独立产品的市场规模有限，订阅与一次性付费都难以支撑持续研发。当收购方看重的是团队经验而不是产品本身时，停止独立开发只是时间问题，用户的解决方案只能是迁移。
- Alternative Move if Replayed 在平台能力不断扩张的领域，第三方产品的生存空间取决于它能否守住平台不愿做的那部分。

---
Source: 良略 · https://www.lianglue.com/c/sparrow-mail