每个产品的上线，对于产品经理来说都意味着一个里程碑

上周在准备新的产品版本上线，本来原计划是在周天版本发布。结果不出意外，果然又顺利的拖到了今天周一，而且还没有发。

截止到现在，我还在和团队一起完成新版本的测试和最后的需求验收工作。

所以趁着这个时间点，分享下我做产品上线前的经验。

因为，每个产品的上线，对于产品经理来说都意味着一个里程碑

C端的产品上线，会马上面临用户的使用和运营的推广，可以第一时间感知到用户的变化甚至是吐槽。

对于很多老用户来说，重大的产品改动，会引起他们的吐槽。因为用户使用习惯了，就不愿意在花时间重新学习了。

所以C端产品的上线和改定，几乎都要适应原有的布局、框架等等，除非技术瓶颈限制，否则就不会大调整，就像许多企业的logo一样，花了非常多的金钱投入到重新设计logo，结果和以前几乎一模一样。

比如小米的

比如金蝶的

这也是因为保证了品牌的价值，保证大众对品牌的认知没有变化。

而B端的产品上线，则要求关注是功能稳定与否。最具有代表的就是医院的HIS系统了，要是上线就可能导致开处方、开药、收费等无法进行，那么为了避免这个情况，大规模的上线都会要求配合线下人工处理环节，虽然这看起来非常臃肿，但是也是一种最有效的方式。

毕竟一套新系统的上线，如果出现问题，那么就就直接影响患者的就医流程、体验、以及医院的营收了。

产品上线前，许多时候是玄学

一个产品上线前，即使测试人员投入100%的精力和专注度，也无法保证100%的产品完善度，仍然存在部分需求遗漏、或者问题是存在卡壳。

这是无论在哪一家公司、企业都会有的。

而产品经理切记，唯一要保证的自己KPI功能要上线。

比如我们做的蓝泡插件工具，里面允许用户对自己的公众号文章封面图保存，但调用的外部图库速度过慢，导致封面图设置点击后，始终是不成功。

实际上是速度影响的，但用户的感受就是这个插入按钮没有用。

还有举个例子，还有就是我们提供的图片保存模板功能，因为安装了插件总会有样式冲突，换了几个版本仍然存在类似的问题，这类问题不是说产品经理、测试人员发现了，提出来就可以改正了，而是要真的反复研究几遍才有结果。

作为产品经理，在上线前倒计时时间。你只能淘汰掉不完善的需求，保证主流程通畅就行，做出妥协。否则就是开发、设计、测试、产品经理的无休止内耗了，因为有一些问题你并不知道是技术问题还是操作问题，难以定位。

所以，最佳策略是保证老板以及用户需求的功能完善了，而基于此做的产品创新或者功能设计，就要学会接受适当延后或停止。

每天使用自己的产品1个小时，减少延期

在做这款新的工具产品期间，我仍然每天都会使用1个小时以上，因为本身自己就是产品的目标用户。

所以，我可能非常懂自己的产品。

相比之前创立的PMTalk产品经理社区，以前只是因为我是他的founder，而被迫使用，因为产品的属性不同，导致论坛产品依靠的是内容而不是产品；现在因为，我是用户，我需要这样的工具，才会继续使用。

天天使用产品的背后，自然就是更好的产品体验打造。我们花了相当多的时间不是在做新需求，而是做以往需求的补全。

比如我们提供给用户的样式管理、模板管理，通过分页的形式提高了用户的信息流访问速度，让他们不用在缓慢的时间加载。

因为天天使用产品，自然就清楚了那些功能是用户的核心功能，那些只是产品经理的YY，优先级会跟随核心功能的变化而变化。

还有比如我们做的图库，是希望用户来管理自己的公众号素材图片，但上线后，作为创作者每天都使用。实际上一个创作者主要的精力还是在文章内容的创作上，图片只会占据20%甚至是更低的精力。

简单来说：图库的使用频率没有文字类的相关管理更高。

所以这也让我们原本对图库相关需求降低了，而围绕其他的问题进行优化。不用那么着急开发新功能，优化用户最常使用的功能，一直打磨到精致为止。

产品上线延期了，再牛逼的产品经理都躲不掉总之。因为以上的问题，我们这个产品版本就上线延期了，运气好点看看明天时间能不能推出来。

到现在为止，我自己使用自己家的工具已经超过7个月，从刚开始以替换原有工具，到现在习惯使用新工具，我认为整个的周期也是一个产品经理、和团队互相磨合的过程。

在BUG描述、产品设计原型方案、沟通上都会有磨合点，大家的沟通成本会越来越低。

对应的，后续对于上线的时间点将会给的更准。后续所造成的需求变动影响也会更低。

所以，每个产品经理都离不开上线延期，因此想要那些熬个夜、通宵几天赶出来的版本，那么就要关注核心点，最终才能有合适的版本。

今天的分享就在这里。