产品发布一般会等用户使用量最少的时候，国内通常都是晚上发布，发布通常不影响用户使用，服务器那边都会做负载，一个服务一个服务的重启发布，发布后测试还要再做一轮功能验证，确保发布后系统是正常的。
发布之所以放在用户访问较少的时候，是因为如果发布有问题，或者发布后线上有问题短时间无法解决还能回滚版本确保线上的影响是最少的。上线那天通常要搞到很晚，发布小版本还好，大版本发布前后要做的事情还是很多的。一种是在发布的时候研发直接用脚本做数据初始化，这种一般是数据量大、数据与其他数据有关联性、某些必须在系统运行前就处理好的数据，否则系统运行会报错。这些数据通常是研发要负责，产品经理也要跟进。一种是系统上线后，在系统前端通过功能做数据配置，比如一些数据字典、角色权限、业务数据等，这些数据一般由产品经理或者系统管理员去配置，业务数据通常由业务部门或者运营人员配置。
系统发布完，数据初始化配置完成后，测试要在线上做一次需求功能验证，并且要把相关核心功能做一次走查。测试验证会产生数据，如果是C端还好，都是个人账号就正常测试就行，如果是B端业务系统，业务数据是不能随便测试的，在不影响其它功能数据的情况下可以创建后删除，如果有影响需要让业务走正式数据来验证。SaaS平台的验证可以单独开一个租户用来测试。除了测试人员，产品经理也要站在用户的角度去线上环境验证自己的需求，毕竟线上数据更符合实际情况。要写好一个用户培训手册、操作手册也是要点能力的，用户都是小白，要如何把手册和指引写的清晰、通俗易懂也是一个技术活，这个时候产品经理的同理心和体验能力会发挥作用。C端产品一般会有2种模式，一种是新手引导，一种是帮助中心。App类应用一般安装完后或者升级后都会有一次简单的页面操作指引，明确告知用户某个操作在哪个位置是用来做什么的，目的性很强。这个指引也是产品经理在需求阶段就要说明清楚的，并且交互要确定好。工具类的App一般还会有帮助中心，让用户来查某个功能如何使用，遇到操作或者数据问题要如何处理。帮助中心的文章内容或者视频，也都是产品经理需要准备好的。现在B端产品一般都会有一个单独的操作手册模块，是一个树形结构的帮助文档，会根据菜单结构梳理出来。操作手册的入口一般在系统顶部右上角，在具体菜单功能页面上也都会有单独的功能级别入口。客户购买产品后，供应商会给用户做针对性的集中培训，培训次数也需要根据客户实际需求安排，给客户培训的人可能是产品经理，也可能是专门的实施人员。作为产品经理，需要不定期安排自己给客户去实施培训，多接触客户实际的反馈以便更好迭代产品。这样的项目通常会有多轮测试，前面几轮都是内部测试，后面几轮就会直接让用户介入测试，测试前需要对用户做分角色培训。产品经理需要根据角色分别撰写操作手册，在培训的时候除了讲操作手册，还要实操系统。如果公司是集团型企业，有很多子公司，可能还要到处奔波培训，不过现在一般都是线上进行了。项目上线后，用户能正常使用系统，即使过程遇到问题，也能自己在操作手册中找到解决方法，这就是培训和操作手册的目的。项目上线前1周，2周，1个月会收到最多的用户投诉或者问题反馈。这个阶段用户刚开始用产品，可能是不会用、有问题、体验差，各式各样的情况都可能会有。产品经理需要快速跟进这些问题，该反馈给研发改bug的该bug，有紧急问题要修复的也要紧急处理上线，需要优化紧急度没有那么高的就按优先级排序上线即可。为什么会出现这么多用户反馈。
是自己哪里没有考虑到。
遗漏了什么场景。
或者是在体验上哪里没有抓住关键点。
同理心哪里还有不足。
多去看问题多总结思考，对自己的能力提升会有较大帮助。用户产品使用的怎么样，好不好，在数据上能有很好的反馈。根据埋点需求把产品的各个指标和数据情况拉出看板来分析，主要的几个指标有：数据的作用主要是决策分析，产品经理要对数据有一定敏感度，要能从数据中发现问题和方向。即便我们不是数据产品经理也要每天花点时间在数据上，多看多分析，这样可以提高自己对数据的感觉，可以让自己更理解用户，最好是偶尔泡在数据里面，让数据渗透到你的思考之中。产品上线前最怕因问题太多无法准时上线，产品上线后又怕功能有问题，搞得很紧张。产品经理从提出需求开始，到产品需求上线，目的就是为了实现用户价值，从而实现产品价值，再而实现自己的价值。
