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

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

笑完之后又想了想，上线前后这个时间段，我也经常忘记一些工作，比如通知客服新的服务、通知用户新的功能、通知老板新的成绩等等…

可惜了，要是当年就有一份完整的产品上线事项清单，确保每次上线都完美无遗漏，我可能早就升职加薪，甚至招聘得起生活助理了（划掉）。

为了避免更多产品同行的奖金折在这里，我整理一下上线前后产品经理一定要做的10件事儿，大家可以收藏一下。

上线前：

01 验收产品

产品迭代测试通过之后，需要提交产品经理和设计师进行验收。

一般来说，产品验收只是过一遍新功能的主流程，对于特别重要的功能迭代，或者你特别闲时，可以把各种异常流程也都走一遍，确保无虞。

奉劝大家有时间的话，还是要用心验收，不要以为线上出了bug跟你没关系，说不定测试大哥已经准备好甩锅给你了。（社群里的有人吐槽过的真事儿！）

一个特别需要注意的点，迭代涉及到的所有页面的文案，都要核对一遍。这种最小的错误，能引发领导对你最大的不信任，连个文案都写不对，你还能干点啥？

验收产品这个流程节点基本漏不掉，因为测试会主动提醒你。

额外多说一句，如果是一锤子迭代，比如万恶的外包项目，或者是大客户定制项目，发版前，一定一定让客户方负责人邮件确认！

再多说一句，验收时顺便跟开发确认一下，埋点别忘了写！

02 功能宣讲

上线前的功能宣讲会是必须的，参会人至少要包括市场、销售、客服等业务相关人员。

讲述的内容是本次迭代的功能，包括其亮点、解决的用户/客户问题，以及常见问题（Q&A）。

如果是重磅功能上线，需要市场同学配合PR宣传吹一波；如果是亮点功能，可以加入到销售同学的骗鬼话术中，促进成单。

新功能可能会引发的问题，需要让客服知晓，并且提前准备好忽悠用户的说法。

03 上线邮件

上线前夕，产品经理要代表产品开发团队向产品线所有人发一封上线邮件，并且视迭代功能的重要程度以及你想露脸的迫切程度，抄送相关领导。

邮件内容基本是本次迭代周期的工作总结，包括功能概要、开发测试概要、以及上线预期等，最好附上相关的需求文档、测试用例等等。

上线邮件是一个完整产品迭代流程的重要环节，是整个团队日常工作的阶段性总结。

上一段是对外说法，实际上产品经理的小心思是，万一线上出了什么问题，这邮件可以作为甩锅凭据：要么你测试没测出来（还能干点啥？），要么你开发没严格按照我的需求做（还能不能干了？）。

04 发布策略

迭代直接粗暴的全量发布的话，此条可以忽略。

如果需要灰度发布，就要提前约定好新版本推送的灰度用户范围，并唐僧附体一样反复念叨，直到程序猿想拿起那根铁棒子为止。

就这，上线前一刻也要再度确认灰度范围，稍不注意，他们就能手滑全量发出去。

05 应急预案

预估本次迭代可能带来的流量大小，别保守，往高了估，提前跟运维打招呼：服务器加足了，以及做好通宵加班的准备。

预估本次迭代可能出现的问题，别保守，往坏了估，提前跟开发打招呼：不要以为上线了就能下班，加班其实刚刚开始。

最后，怀着沉痛的心情做好迭代回滚的应急预案，包括技术准备、安抚用户、安抚销售以及领导等，提前更新一下简历也是可以的。

06 更新物料

提前准备好更新日志、版本号等，如果涉及到移动端APP，还要准备好新版本应用截图、功能介绍等。

上线后：

07 数据配置

对于需要后台配置参数的功能，切记要在迭代上线后第一时间配置相关数据。

大多数活动类迭代，一般都需要配置参数，比如各种奖项个数、中奖率；一等奖的内定账号等。

08 通知用户

费时费力为用户做的功能，当然要通知用户了！

对于灰度发布的情况，上线后赶紧通知小白鼠们来用，产品公告、用户群、push、短信统统梭了，有问题早发现早解决，解决不了早回滚。

如果跳过灰度，直接全量发布，不建议上线后的第一时间通知用户，最好是先让少量用户主动发现并使用，这样即使有问题，也能控制影响范围。（类似灰度发布的效果）

一段时间之后，基本确认本次迭代没问题了，再全量通知用户。

09 监测数据

看数据是迭代上线后的第一要务。

一次迭代是否能达到预期目标，一周以内差不多能看得出来，达到目标就总结经验，未达到目标，要及时进行私下里的自我反省和公开的甩锅。

10 及时汇报

看到数据表现之后，无论结果是否满意，都要及时向领导汇报。

数据表现好，汇报邮件比较简单，字里行间暗戳戳的突出自己的英明睿智就行。

要是数据表现很烂，那就讲究技巧了，如果邮件里只是写一个结果，那你啥时候被输送到社会上，就在老板的一念之间了。

这时候你一方面要自我反省，另一方面甩锅给客观原因，比如大环境不好、疫情影响、川普竞选失败、拜登爬个飞机都摔3回等等…

另外，如果有必要，还要附上调整策略，下次迭代一起上，甚至直接做一个小版本上线。

— end —

◆ ◆ ◆