5

迭代上线前后 产品经理一定不能忘记的10件事儿

 3 years ago
source link: http://www.chanpin100.com/article/114249
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

迭代上线前后 产品经理一定不能忘记的10件事儿

前几天跟一个产品老哥扯淡,老哥哭诉自己因为迭代上线忘记配置一个参数导致1季度奖金扣没了,我哈哈哈哈怀着悲痛的心情哈哈哈表达了自己深切的哈哈哈哈惋惜。

collect_img16168132484335

前几天跟一个产品老哥扯淡,老哥哭诉自己因为迭代上线忘记配置一个参数导致1季度奖金扣没了,我哈哈哈哈怀着悲痛的心情哈哈哈表达了自己深切的哈哈哈哈惋惜。
笑完之后又想了想,上线前后这个时间段,我也经常忘记一些工作,比如通知客服新的服务、通知用户新的功能、通知老板新的成绩等等…可惜了,要是当年就有一份完整的产品上线事项清单,确保每次上线都完美无遗漏,我可能早就升职加薪,甚至招聘得起生活助理了(划掉)。为了避免更多产品同行的奖金折在这里,我整理一下上线前后产品经理一定要做的10件事儿,大家可以收藏一下。01 验收产品产品迭代测试通过之后,需要提交产品经理和设计师进行验收。一般来说,产品验收只是过一遍新功能的主流程,对于特别重要的功能迭代,或者你特别闲时,可以把各种异常流程也都走一遍,确保无虞。奉劝大家有时间的话,还是要用心验收,不要以为线上出了bug跟你没关系,说不定测试大哥已经准备好甩锅给你了。(社群里的有人吐槽过的真事儿!)一个特别需要注意的点,迭代涉及到的所有页面的文案,都要核对一遍。这种最小的错误,能引发领导对你最大的不信任,连个文案都写不对,你还能干点啥?验收产品这个流程节点基本漏不掉,因为测试会主动提醒你。额外多说一句,如果是一锤子迭代,比如万恶的外包项目,或者是大客户定制项目,发版前,一定一定让客户方负责人邮件确认!再多说一句,验收时顺便跟开发确认一下,埋点别忘了写!02 功能宣讲上线前的功能宣讲会是必须的,参会人至少要包括市场、销售、客服等业务相关人员。讲述的内容是本次迭代的功能,包括其亮点、解决的用户/客户问题,以及常见问题(Q&A)。如果是重磅功能上线,需要市场同学配合PR宣传吹一波;如果是亮点功能,可以加入到销售同学的骗鬼话术中,促进成单。新功能可能会引发的问题,需要让客服知晓,并且提前准备好忽悠用户的说法。

collect_img16168132491498

03 上线邮件上线前夕,产品经理要代表产品开发团队向产品线所有人发一封上线邮件,并且视迭代功能的重要程度以及你想露脸的迫切程度,抄送相关领导。邮件内容基本是本次迭代周期的工作总结,包括功能概要、开发测试概要、以及上线预期等,最好附上相关的需求文档、测试用例等等。上线邮件是一个完整产品迭代流程的重要环节,是整个团队日常工作的阶段性总结。上一段是对外说法,实际上产品经理的小心思是,万一线上出了什么问题,这邮件可以作为甩锅凭据:要么你测试没测出来(还能干点啥?),要么你开发没严格按照我的需求做(还能不能干了?)。04 发布策略迭代直接粗暴的全量发布的话,此条可以忽略。如果需要灰度发布,就要提前约定好新版本推送的灰度用户范围,并唐僧附体一样反复念叨,直到程序猿想拿起那根铁棒子为止。就这,上线前一刻也要再度确认灰度范围,稍不注意,他们就能手滑全量发出去。05 应急预案预估本次迭代可能带来的流量大小,别保守,往高了估,提前跟运维打招呼:服务器加足了,以及做好通宵加班的准备。预估本次迭代可能出现的问题,别保守,往坏了估,提前跟开发打招呼:不要以为上线了就能下班,加班其实刚刚开始。最后,怀着沉痛的心情做好迭代回滚的应急预案,包括技术准备、安抚用户、安抚销售以及领导等,提前更新一下简历也是可以的。06 更新物料提前准备好更新日志、版本号等,如果涉及到移动端APP,还要准备好新版本应用截图、功能介绍等。

collect_img16168132496858

07 数据配置对于需要后台配置参数的功能, 切记要在迭代上线后第一时间配置相关数据。大多数活动类迭代,一般都需要配置参数,比如各种奖项个数、中奖率;一等奖的内定账号等。08 通知用户费时费力为用户做的功能,当然要通知用户了!对于灰度发布的情况,上线后赶紧通知小白鼠们来用,产品公告、用户群、push、短信统统梭了,有问题早发现早解决,解决不了早回滚。如果跳过灰度,直接全量发布,不建议上线后的第一时间通知用户,最好是先让少量用户主动发现并使用,这样即使有问题,也能控制影响范围。(类似灰度发布的效果)一段时间之后,基本确认本次迭代没问题了,再全量通知用户。09 监测数据看数据是迭代上线后的第一要务。一次迭代是否能达到预期目标,一周以内差不多能看得出来,达到目标就总结经验,未达到目标,要及时进行私下里的自我反省和公开的甩锅。10 及时汇报看到数据表现之后,无论结果是否满意,都要及时向领导汇报。数据表现好,汇报邮件比较简单,字里行间暗戳戳的突出自己的英明睿智就行。要是数据表现很烂,那就讲究技巧了,如果邮件里只是写一个结果,那你啥时候被输送到社会上,就在老板的一念之间了。这时候你一方面要自我反省,另一方面甩锅给客观原因,比如大环境不好、疫情影响、川普竞选失败、拜登爬个飞机都摔3回等等…另外,如果有必要,还要附上调整策略,下次迭代一起上,甚至直接做一个小版本上线。-end-关注我们,和产品一起快乐划水~

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK