尘归尘，土归土
所有的产品都有自己的生命周期，高强度的竞争也使得，移动应用的死亡率越来越高。根据艾媒咨询《2015年中国手机App市场研究》的数据：
移动应用的生命周期平均只有10个月的时间
作为一个产品经理，有时「如何告别」是一个不得不面对的问题。
这段时间太动荡，好久没有写东西了，就着这段时间刚好孵化的产品下线了。本文算是自己对移动应用下线的过程的简单总结吧。
*不哭，好歹在我手上已经终结了3、4款应用了， _(:3」∠)_ *
既然无法继续，那就好好道别
国内大多数稍有规模的公司，关于产品上线都是有一系列的流程规范的。相反，产品下线，大多都是草草收尾，甚至有些就和慈禧老佛爷面对八国联军出逃至西安一般，神色慌慌，七零八落。
其实，作为产品经理，在能力范围之内，至少我们还可以，好好向用户道别。
1. 确定下线影响与时间点
产品上线需要有计划，自然下线有应当如此。起目的主要是为了同步各项工作的时间点，保证一些工作的顺利交接，比如计划可以包括以下主要事项：
确定影响范围
产品下线不仅会影响用户，同时很有可能会影响其他如渠道、PR、BD，以及一些其他支援团队。确定影响程度
影响程度，主要针对的是用户端，相当多的应用不仅存储了用户数据，甚至还有一定的储值或者增值服务。产品在线时，这些都是宝贵的财富，产品下线后，这些就都是「债」了。确定时间点
当然不同类型的产品，涉及的点会有所不同，但大致会包括：发布通告、应用下架、用户赔偿、服务关停、资源回收等步骤。
大致步骤确认之后，应当跟进之前确认的影响范围和程度，开展工作。
2. 确定弥补方案
产品下线，势必对用户造成影响，一个用户也是用户，尽可能不要造成太大的伤害。伤害的来源，主要是两大块：
-
用户数据
一般来说在下线产品前，应该尽量保证产品中已经有了数据备份和导出的能力，这样，可以尽可能减少用户数据的损失。比如如果哪天「简书」倒闭了，就应该保证能够有备份或者导出文章的能力。
当然，UGC产品来说，用户数据的备份和导出能力应该是一个基础能力，再比如很多图片社区，在生成并发布图片的过程中，已经将图片同事保存到了系统相册。
-
用户财产
对于大厂应用来说，财产弥补一般来说方案还是可以有很多的，很多时候都是自己资源置换（比如给你充个钻），甚至，直接现金赔付都是可能的。这个时候，就必须设计一个较为完整的赔付流程，如果涉及金额较大，最好有安全团队的支持。对于小厂应用来说，都下线了，很多就意味着破产了，财产弥补的什么，可能是心有余而力不足了。不过可以的话，尽量保持自己的节操。
3. 好好写一则通告
公告的内容不外乎抒发情怀，阐述原因，确定流程，替代方案等内容。
一般通告的渠道包括：应用内的通告渠道、PR公关、社交媒体等。对于很多小产品来说，先在应用内好好写一则通告吧，可以如图所示。
什么，你的产品内不能发布通告？好吧，那请忽略吧。不过，目前的移动App，一般一开始就需要设计一套内容分发模块，不然运营起来真的很累
4. 资源结算与回收
外部资源包括：一些应用市场的下架、渠道或者置换资源的结算、外部云服务的结算（比如阿里云、七牛、AWS服务等），能开的发票都开好。
当然如果是一些纯本地工具应用，其实也可以一直放在应用市场上，能服务多少用户就服务多少用户吧。
内部资源包括服务器与域名资源的回收（服务已经停止）、数据与代码的备份、财务结算。
PS：关键的合同一定要交给法务、财务来处理！(如果有的话，233)
5. 收尾
到这个阶段，其实下线工作已经基本完成，从产品经理角度，可能还需要做一些工作：
整理产品文档与设计稿，并归档。
产品文档与设计稿，就是这个产品的化石 。总结产品失败原因。
嗯，失败是成功他妈。维护核心用户。
可以将优质用户转移到其他自家产品中。如果有能力也可以保持用户群的运营，把用户当朋友来看时，反而有一种亲切感。甚至，说不定下一个产品的种子用户就来源于此。
不要忘了自己
和团队里的朋友们好好吃一顿，谢谢大家辛苦付出
然后，流着眼泪，带着微笑，向过去道别，向未来进发
