分享我最近做产品的哭与泪：上线就是一个玄学

最近带着团队做vision PRO的产品上线，不出意外，产品上线后各种BUG，甚至是让用户苦苦的在系统注册登录上等了2个小时也没有结果。

运气比较好的时候，用户主流程没有问题，但是一旦真的用户实操就有问题了。

因为安装环境的系统版本、用户账户不一样，都会导致测试过程中出现各种问题。

所以产品经理一定要考虑到上线的各种突发场景，最差的是做好的产品的回滚准备，而我们经常说产品上线失败，就是这个意思。

在有限时间里面，没有解决产品的核心功能性BUG，产品最终上线失败，所以在临近上线，公司会要求团队通宵，就是因为上线截止才发现各种问题，紧密发现前端、后端、客户端等问题要修改。

需求评审不等于执行就没问题

产品经理会通过需求评审，提前和技术团队做产品设计方案讲解，但实际真在产品研发落地执行过程中，就会发现各种想不到的问题，比如选择的某些项目是开源的，结果自己拿过来部署不了，要么是网络问题要么是开源项目没有人维护了。

比如我们遇到的开发过程中，发现对方给的SDK无法调通等，需要厂家给予协助优化，才能够完成集成。

中间执行过程中所需要的问题，就要产品经理来带头协调，甚至有的会涉及到利益原则的问题，比如对方给提供更多的设备权限，这件事就可能超出原本的商务协议了，最终导致之前的产品设计方案失败了。

上线有BUG，可以有其他解决方案

当然有BUG是非常正常的，我们可以在上线的时候，用其他他解决方案来替代，比如网页打不开，就给出公告文案进行引流。

比如最近的Manus就采取了网页端允许用户访问，但是一到点击注册、登录需要调用接口的时候，就无法加载了。但这就保留了用户的核心体验。

而不是直接整个网站全部无法访问

这也是我们系统高并发的常见解决方式，如果没有这类产品研发经验，你就会流失大量的用户

需求池的优先级

做产品要关注需求的优先级，我认为判断一个产品经理是否负责，就是看他对需求池的了解程度如何，要是他连产品现在有哪些优先紧急的问题都不清楚，那就是失责的。

因为需求池涉及到了产品核心问题，如果连需求池都没有建立与管理起来，那么产品出问题也不意外。

需求池随着产品不同阶段周期，也会发现若干个产品设计的问题，这个时候就要判断是阉割还是放在下个版本集体处理了。

但切记别轻易决定推到重新做，因为这是浪费了前期工作资源投入，还有宝贵的时间。

在公司里，我们看到一个产品经理入职总是喜欢把之前的功能模块推翻，但作为一个公司CEO来说，这种事情尽可能避免，哪怕对以前的功能做一些隐藏，都比推翻好。

所以如果是一个科技型公司，企业CEO一定要深入这些产品的需求上，把握核心产品的功能走向，避免浪费资源。

曾经百度的CEO李彦宏就在内部公开说：“自己都不知道公司内部在孵化上面项目，突然今天就冒出来一个APP，结果和其他部门是重复的。”

这就导致公司浪费了大量的资源。

因此上线是一个产品经理终要面对的坎，要么选择长久的熬夜加入，要么就前提详细做项目管理，减少延期的可能。

让团队每个成员都清楚当前的核心目标是什么，因为我们现在过于划分详细的研发阶段，导致开发与实际上线接触过于分散，而少了集中目标。

你可以看到那些上线已经几年的产品，在没有大的功能变化下，其上线更新的频次就不会那么高，因为用户的习惯养成了，而产品经理要做的就是在细分人群下做一些小而美的需求，很多人会把这个称之为维护性需求。

今天的分享就在这里。

分享我最近做产品的哭与泪：上线就是一个玄学

浅谈AI时代下架构设计：为什么说在AI时代下，中台会再次回归到企业数字化核心位置？

Manus是个好概念，但并不神奇

从奔驰裁员赔付N+9的瓜，聊一聊全球供应链对普通人的影响

Manus后，50W的产品经理一定去建立开源“代码库”