如何告别:「产品下线」 产品经理该做些什么?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

chnapdsafdsdfa

尘归尘,土归土

所有的产品都有自己的生命周期,高强度的竞争也使得,移动应用的死亡率越来越高。根据艾媒咨询《2015年中国手机App市场研究》的数据:

移动应用的生命周期平均只有10个月的时间

作为一个产品经理,有时「如何告别」是一个不得不面对的问题。

这段时间太动荡,好久没有写东西了,就着这段时间刚好孵化的产品下线了。本文算是自己对移动应用下线的过程的简单总结吧。

不哭,好歹在我手上已经终结了3、4款应用了, _(:3」∠)_

既然无法继续,那就好好道别

国内大多数稍有规模的公司,关于产品上线都是有一系列的流程规范的。相反,产品下线,大多都是草草收尾,甚至有些就和慈禧老佛爷面对八国联军出逃至西安一般,神色慌慌,七零八落。

其实,作为产品经理,在能力范围之内,至少我们还可以,好好向用户道别。

1. 确定下线影响与时间点

产品上线需要有计划,自然下线有应当如此。起目的主要是为了同步各项工作的时间点,保证一些工作的顺利交接,比如计划可以包括以下主要事项:

确定影响范围

产品下线不仅会影响用户,同时很有可能会影响其他如渠道、PR、BD,以及一些其他支援团队。

确定影响程度

影响程度,主要针对的是用户端,相当多的应用不仅存储了用户数据,甚至还有一定的储值或者增值服务。产品在线时,这些都是宝贵的财富,产品下线后,这些就都是「债」了。

确定时间点

当然不同类型的产品,涉及的点会有所不同,但大致会包括:发布通告、应用下架、用户赔偿、服务关停、资源回收等步骤。
大致步骤确认之后,应当跟进之前确认的影响范围和程度,开展工作。

2. 确定弥补方案

产品下线,势必对用户造成影响,一个用户也是用户,尽可能不要造成太大的伤害。伤害的来源,主要是两大块:

用户数据

一般来说在下线产品前,应该尽量保证产品中已经有了数据备份和导出的能力,这样,可以尽可能减少用户数据的损失。

比如如果哪天「简书」倒闭了,就应该保证能够有备份或者导出文章的能力。

当然,UGC产品来说,用户数据的备份和导出能力应该是一个基础能力,再比如很多图片社区,在生成并发布图片的过程中,已经将图片同事保存到了系统相册。

用户财产

对于大厂应用来说,财产弥补一般来说方案还是可以有很多的,很多时候都是自己资源置换(比如给你充个钻),甚至,直接现金赔付都是可能的。这个时候,就必须设计一个较为完整的赔付流程,如果涉及金额较大,最好有安全团队的支持。

对于小厂应用来说,都下线了,很多就意味着破产了,财产弥补的什么,可能是心有余而力不足了。不过可以的话,尽量保持自己的节操。

3. 好好写一则通告

公告的内容不外乎抒发情怀,阐述原因,确定流程,替代方案等内容。

一般通告的渠道包括:应用内的通告渠道、PR公关、社交媒体等。对于很多小产品来说,先在应用内好好写一则通告吧,可以如图所示。

50eb87c7b

一个视频类应用「演技派」的下线通告

什么,你的产品内不能发布通告?好吧,那请忽略吧。不过,目前的移动App,一般一开始就需要设计一套内容分发模块,不然运营起来真的很累

4. 资源结算与回收

外部资源包括:一些应用市场的下架、渠道或者置换资源的结算、外部云服务的结算(比如阿里云、七牛、AWS服务等),能开的发票都开好。

当然如果是一些纯本地工具应用,其实也可以一直放在应用市场上,能服务多少用户就服务多少用户吧。

内部资源包括服务器与域名资源的回收(服务已经停止)、数据与代码的备份、财务结算。

PS:关键的合同一定要交给法务、财务来处理!(如果有的话,233)

5. 收尾

到这个阶段,其实下线工作已经基本完成,从产品经理角度,可能还需要做一些工作:

  • 整理产品文档与设计稿,并归档(产品文档与设计稿,就是这个产品的化石 )。
  • 总结产品失败原因(嗯,失败是成功他妈)。
  • 维护核心用户。

可以将优质用户转移到其他自家产品中。如果有能力也可以保持用户群的运营,把用户当朋友来看时,反而有一种亲切感。甚至,说不定下一个产品的种子用户就来源于此。

不要忘了自己

和团队里的朋友们好好吃一顿,谢谢大家辛苦付出

然后,流着眼泪,带着微笑,向过去道别,向未来进发

 

原文地址:http://www.jianshu.com/p/d3fc4d2b3b80

本文由 @whiteplane 授权发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中