如何告别产品下线产品经理该做些什么

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