产品经理改需求“该死”么?

来来来，今天聊聊产品经理的原罪之一：改需求。

在项目开发群中，产品经理时不时的调整逻辑后，开发会扔过来类似的一张图：

互联网圈茶余饭后，只要一提到产品经理，不论是群嘲还是自黑，都离不开“改需求”这仨字。和朋友聊完后，他说之前遇到一个求职者，被问到“曾经做过的哪个项目最满意的时候”，求职者说出某个项目既没有亮点，也没有贡献值。深挖后，竟然说出——在该项目迭代版本中，没有改过一次需求。

那我不禁想问：“不改需求就是好产品经理么？”首先咱得梳理改动的是什么需求，分为三类：

一、因为外部业务环境变化所导致的。该业务因为市场大环境、国家政策的监管等不可逆的因素而导致该业务的可预见性。为了及时止损，产品经理需要调整业务方向和策略，这有没有问题？——这是完全没有问题的。总不能看见了坑，果断跳下去，还鼓劲喊：“好路好路，可以走”。所以这种场景下，可能意味着产品规划和策略要回炉重造了。

那产品经理“该死”吗？如果明知故犯，那是肯定不可饶恕的。如果是行业政策大环境因素有制定调整策略，依然是好的产品经理。

二、产品经理没能梳理清楚业务所导致的。这是产品经理没和业务方梳理清楚，而导致产品经理对业务的预判出现了错误。首先主背锅者肯定是产品经理，副背锅者是整个团队。有几层产品经理要梳理清晰：

• 产品经理要非常了解业务流程；（熟悉业务最重要！！！）

• 产品经理要多次和业务方确定沟通——包括：“业务目标”、“业务规划”、“产品方案沟通”和“目标用户调研”；（找准目标用户和清楚业务策略）

• 评审阶段中交代清楚产品规划、背景和目标，让团队提出质疑和想法。（让团队提出质疑）

业务方向理解错了，意味着业务目标和业务策略的理解也错了，同时产品规划和产品策略也错了。要改么？指定是要改的，而且要大改。

那产品经理“该死”吗？一定的、绝对的、毫无理由的“该死”。这将让团队的心血付之一炬，所以在思考核心模块时，前期的准备工作一定要做好。

三、功能流程设计和逻辑导致的。如果纯粹是功能设计的问题导致的需求变更说明产品经理没有理清楚细节和逻辑，导致开发过程中需要重复调整流程和逻辑。这完全是产品经理基本功不过关。这种调整需要去甄别几种情况：

• 如果不调整对业务会造成重大影响，对用户体验会造成影响的，果断需要调整；

• 如果不调整对公司能造成损失的，果断需要调整；

• 如果调整了，工期暂不会有delay且能有正向的反馈，果断需要调整。

如果是其他的，建议放在下期迭代。对于这种情况，每个项目或多或少都会遇到，最好的方式当然是产品经理前期描述清楚，项目团队群策群力，达到不改需求，这是最好的状态。但是，有多少团队是这样的状态呢？

每个产品的设计都是有其背景的，功能的变化有可能也是随时产生的。重点是这个变化对不对？这个变化会引起其他模块的什么变化，会有什么后果？正确的需求微调改上100次都无所谓，错误的需求改一次只会更错。

主要方向是正确的，适当的微调完全是可以的。因为永远不希望看到——产品经理评审产品方案后，就停止思考了。

当然，如果在产品方案之前完整地梳理清晰了，那就更好了。。。如何去梳理清楚呢？去看看《产品经理工作流》吧。