不少公司的产品经理都有考核指标，有的是和产品数据关联，有的是和需求关联，比如新需求数量等等。那么，优化需求算不算新指标？怎么去做？这篇文章，给我们答案。

有位小伙伴提了个问题：

项目已经进入试运行阶段了，但客户方一直在提新的需求。项目经理和产品经理一致说，项目已经上线，现在提的需求应该属于新需求，要重新评估工作量。

但客户却说：这不算是新需求，是因为你们没做到我们之前想要的功能。

所以，这一类没有做到预期的功能优化，到底算不算新需求呢？

我觉得这是一个非常复杂的问题，我将从以下七个层面来分析：

一、产品的盈利模式

《麦肯锡结构化战略思维》中始终强调“明确定义”的重要性。所以在讨论这个问题时，我们同样要明确一个定义。

即产品的合作模式是什么？是订阅制？项目制？还是人月制？

大多数遇到类似问题的情况，都是项目制的合作，即定制化合同。

因为订阅制基本是以产品自有迭代周期为基础，客户的需求需要经过产品团队的过滤筛选，最终形成产品迭代的自有需求，产品研发团队的需求自主权相对较高。

人月制则是打多少卡结算多少费用，只要人在这里，你说怎么改咱就怎么改。

所以，只有在定制化合作的商业模式下，项目金额是固定的，甲方肯定想功能越多、越好用，乙方肯定想工作量尽量少，利润空间尽量大。

于是，虽然看起来目标都是做好项目履约，但在很多细节上，因为出发点不同，导致预期不同。

而需求，是项目的源头，自然经常产生争执。

况且，项目制的合作，还需要考虑持续合作的空间。因为不是一锤子买卖，导致很多问题都要考虑后果。

我说这些，一方面是为了强化“问题定义”的意识，另一方面也是表达这类问题很常见，产品经理遇到之后，大可不必劳心动气，因为这些问题，就是需要我们去解决。

二、售前和交付之间的差异

“实物与宣传不符”，是造成这类问题的重要原因。因为售前阶段对用户预期的培养过高，导致用户看到实际交付物之后存在心理偏差。

当然，从不同的角色角度来看，售前阶段为了拿标，基本都会提高用户预期，但中标之后，一定要和交付团队做好交接，把已经挖的坑亮出来，别藏着。

关于这个话题，可以看一下之前写的售前到交付工作交接的历史文章（8000字干货：从售前到交付，一场以交接为主的修行）

因此，有些售前承诺但并未体现在合同里的，或者合同里写的比较模糊，但售前时确实说过的，从隐性契约精神来看，还是要尽量满足。否则可能影响乙方公司的口碑，进而影响到其他项目、其他客户。

当然，同样的需求有不同的解决方案，至于工作量的多与少，可以参见下文第五条。

三、甲乙双方的信任关系

很多问题，说到底是信任度的问题。虽然不同的人，脾气秉性不同，但如果你前期与客户建立了良好的信任关系，这些问题都有很多可操作空间。

所以，当出现问题的时候，已经有点晚了。但也没有很晚，毕竟事情还没有上升到无法挽回的境地。

就像我们生病一样，生病一定是之前自己对某些方面的关注度不足，但生病本身也是在提醒自己多多关注某些方面。

甲乙双方的信任关系和项目进展情况也是相互影响，相互促进的。我经历过依靠产品经理扭转客户态度的实际案例，也经历过把一手好牌打得稀巴烂的情况。

所以，回到今天的主题，关于新增需求和优化需求的界定，本应该有很大的协商空间才对。

如果没有，那一定是之前就已经出了问题，而且这个问题一定不仅仅表现在需求层面，可能后续的验收、收款都会举步维艰。

当你所处的团队与客户方关系出现问题时，采用私下缓和关系的方式，逐个击破或旁敲侧击，通过自己的专业能力，或者你退一大步，他退一小步这样的条件置换，才是更要紧的事情。

切不可过于纠结于细节，除非领导授权。

四、客户需求洞察

今年我经常在不同的渠道需求洞察，因为我真的觉得它特别重要，是一种非常关键的产品思维，是做好产品经理所必备的能力和习惯。

当客户说想要优化某个需求的时候，到底是因为什么？

可能是为了和合同保持一致。尤其是很多体制内的老员工，非常认真，同时也担心担责，不管合同或需求说明书中写的对不对，都要按照这个内容做。

可能是产品的功能确实不好用。有很多甲方比乙方的产品经理在业务专业性上要强很多，所以他们能够发现产品中的问题。这种情况，只能怪自己技不如人。

另一方面来看，这是一个快速提升的机会，要紧紧抓住。

可能是客户在自嗨。提需求的人，无论是谁，都可能陷入盲目自嗨中，提出一些伪需求。这就需要产品经理通过有效的需求洞察辨别这个需求背后的“场景”、“痛点”、“目标”是什么。

之后来分析现在这个需求是否能够实现背后的目标？

就像你的需求是让张飞买剃须刀，如果他真的买了，那我们真是产品界的奇才。但张飞真的有必要买吗？

（当然，这个问题和经典面试题：如何把剃须刀卖给张飞，并不冲突，只是两者的出发点不同）

也有可能你没有get到客户所提需求真正的原因。就像去年的文章中提到，客户让你去买水，并不一定是口渴了，可能还有其他原因，最终的表现形式是：买一瓶水（从收到需求到明确需求——需求洞察）。

因此，需求洞察是在与客户“争执”是否为新增需求的前提。只有搞明白对方到底想要什么，才知道哪个方式更有效。

五、产品经理解决方案能力

如果客户始终坚持这是优化需求，我们也可以通过自身的专业能力，让优化需求改动量要么更小、要么更合理。

这一步有几个前提：

1. 产品经理对现有业务和系统现状很熟悉，知道改动过程中可能存在什么风险，或者能够通过底层设计逻辑寻找更简单的改造方式；
2. 产品经理在团队内部有话语权，否则优化过程中一定会四处碰壁，相互推诿；
3. 有一定的技术思维，能够初步评估不同解决方案所需的改造工作量。

这三点其实可以汇集为一点：这个产品经理经验丰富，能力强。

当然，实际工作中，类似的问题很多人都会直接上升到领导层或商务层，通过公司的力量来解决。这种方式本身没有问题，只是对于我们产品经理个人而言，缺少了一些可以尝试、可以锻炼的机会。

通过困难收获的成长，速率还是很快的。

六、优化的边界在哪？

即便是功能优化，同样的坑也不要掉两次。原需求范围没有框定清楚，优化需求的范围一定要协商一致。

另外，这些优化功能同样需要进行工作量评估，即便客户现在没有结算，我们视其为沉默成本，后续迭代新合同时，如果客户信任感又重新建立起来了，再把工作量补回来也未尝可知。

七、关键问题是什么？

我觉得出现这个问题的本质是团队内的需求管理流程出了问题。

需求分析阶段无论客户是否参与，需求评审时双方一定没有达成一致（5千字拆解【需求评审】,让评审效果最大化）。

或者后续需求变更的流程不规范，无迹可寻，无证可依。

也可能因为双方人员变动、工作交接没做好，导致大家认知不一致（工作交接中的“交”与“接”）。

等等这些问题，其实都是产品经理的问题。

八、写在最后

很多朋友会提到“契约精神”这个词，我觉得要从两个方面来看：

1. 产品经理不要主动、多次和客户方提合同范围，提合同边界。因为如果真要较真起来，那一纸合同中没有约定的功能可太多了，客户随便提一些问题，就够产品经理和项目团队喝一壶的。
2. 大部分客户也是讲究契约精神的，即便偶尔会较真，会为难，但他也需要为自己的企业负责，也需要为自己的项目结果负责。毕竟，大家都是为公司做事。

所以，优化需求到底算不算新需求，这个问题我说了不算，你说了也不算，但我们可以通过很多行为，让说了算的人，按我们的设想计算。

我最终的观点可以概括为一句话：

先退一步表态，再通过专业性缓和关系，以需求洞察为基准，寻找双方都满意的方案，最终促使客户退一小步。

不过要记得，下一个周期，从售前便开始抓起，共建信任关系。