toB 研发和销售两种不同的节奏经常会使得产品经理左右为难，那么我们到底是应该选择效率高呢还是响应快呢？

如果你处于toB企业产品行业当中当产品/项目经理，一方面，可能经常会有销售/实施部门的人向你或者老板吐槽研发的效率不高，客户也经常认为研发的响应太慢，想办法施压推动；另一方面，开发团队已经觉得自己已经在满负荷工作了，客户需求还是源源不断的来，原定的开发计划都没法按时交付。

作为产品经理，会发现自己左右为难，忙于一面“挡需求”，一面“增效”（嗯，其实就是让研发加班）。其实这其中的一个原因，是toB研发和销售两种不同的节奏和思考方式所导致的，只有解开这个根因，才能真正对症下药。

产品研发团队想要效率高

研发团队最关注的点是提升整体的研发效率，特别是敏捷式的开发，非常注重开发中的精力集中，才能够在计划的时间内交付承诺的功能。

一个高效的敏捷开发团队日常所关心的是：

• 我们上几个迭代完成了多少故事点（Story points）？
• 我们能不能按规划完成未来两个产品路线上的需求？
• 我们对需求点的评估是否准确？
• 开发团队的负荷如何？
• 我们怎么偿还我们的技术债务？减少紧急情况的出现？
• 我们的技术架构应该是如何的，才能符合当下和未来的业务需求？

对于研发团队来说，高效就像是跑马拉松一样，保持着稳定的高节奏（每一周或两周一次迭代发布），沿着产品路线持续推进，哪怕有高优先级的需求插入，也应该是可以安排到下一个迭代再去考虑。

这种高效有一个重要的前提条件：在进入开发前，已经提前给需求点定义好优先级，然后开发人员可以按照定好的优先级逐个需求进行开发。这个优先级应该来源于一个中长期的产品愿景，然后研发团队一同来分解，逐步来实现和验证商业价值，而这个价值并不是着眼与某个或某几个客户，而是从公司和市场的长期价值。

销售团队想要响应快

从销售团队的角度来说，可能是完全不一样的思维模式。销售人员的激励模式决定了他们的收入不是与公司整体的盈利挂钩，而是和自己手上特定的客户是否能够签单、收款成功相关。而这些客户很可能是现有的标准产品所不能完全满足，拥有一些自己特定痛点的。

这些痛点会体现在整个销售和实施周期上，客户部门，无论是领导还是员工，都不断会提出他们的一些需求，这些需求有真实的，也有拍脑门YY的，也不管三七二十一先提出来，然后这些需求就会变成与签单和收款相关的工作项。

这些需求很可能会在售前实施售后过程中的任何时间点提出来，不管这些需求点是否在我们原定的产品路线里面，销售团队都需要产品和开发团队尽快进行需求可行性和工作量的评估，也需要我们尽快安排进行开发，这样才能尽快答复客户和推进报价、签单和收款。

所以，跟研发团队关注自己的效率不同，销售团队更看重的是研发团队的响应速度：能够快速理解客户需求、做出和确认产品方案、进行开发工作量的评估、排期和开发出自己的客户所关注的需求点（不管这些需求点是不是我们原来的产品路线上），总之能够越快响应客户越好，恨不得在客户看来，研发团队就是专门为他们服务的。

不同的视角，不同的节奏

总结一下研发和销售两者视角的差异：

• 产品研发部门更多考虑能够满足大量客户的通用需求，更希望实现前后一致、经过慎重思考、意外情况少的需求和管理过程，只有这样他们才能够根据这些明确的需求去进行评估、进行软件的架构的统筹设计。对于他们来说，规划之外的打扰越少，团队的效率才能越高，也越能减少开发过程中的失误；
• 销售团队是一个客户一个客户地来打单，从这个角度来看，他们向公司汇报时不断强调客户的需求点是十分合理的做法，因为这样才能让产品研发团队尽快安排资源来实现功能，进而签单。如果不能够对大客户的额外需求进行快速响应，对销售是非常不利的。

这种视角上的差异导致两个团队的步调的差异，而步调的差异就会导致两个团队之间的磨合和沟通出现问题：

• 如果按照销售团队要求的响应快的步调走，研发团队会觉得自己不断地各种的评估和答复工作所干扰，这种干扰还无法预测随时都可能出现，手上的开发任务还得回头加班做，更不用说随时加插的开发任务了；
• 如果按照研发团队要求的效率高、低扰动的步调走，销售团队就觉得一点简单的问题都要让客户等很久，这单子没法做了。

如何处理节奏的矛盾？

方法A：咬定路线不放松

我们可以选择忽略那些紧急的需求，相信我们原定的产品路线规划中的需求才是满足用户真正的通用需求，严格按照产品路线进行研发才是效益最好的投入。所有的额外需求我们都在下一个产品路线规划周期的时候再考虑。

这种规划方式可能在2C产品里面能够走得通，因为在2C产品里面不会有哪一个特定的用户的商业影响力足够达到能够影响到我们的产品路线（当然，这里不是指不去听取用户的建议，而是指不是非得按某个用户的说法去做）。

但在2B里面这种想法没有多少可操作性，特别是面向大客户的企业里面，营收额是块状组成的，单独一个客户的影响力可以十分巨大，一个客户的交易就很可能会打动到管理层为之调整策略。

方法B：销售驱动产品路线

另一个极端，就是产品规划把所有客户要求的需求点都提到更高的优先级，按照投入产出比或者合同金额排个序，然后按优先级从高到低开发，最后再把剩下的时间留给原来的产品规划、架构、偿还技术债、长期的学习和研究。

关于销售驱动的根源和带来的问题在《2B产品的隐藏陷阱：销售驱动》里面有更详细的分析，此处就不再赘述。在产品还没有成型，还在打前两三个灯塔标杆客户的时候，销售驱动是可行的。但面对更多的客户的时候还采用这种方式，公司就会不经意间向项目外包的方向去滑落，但又不是以专业的方式去做项目。结果很可能就是产品规划凌乱，客户也没有能服务好。

方法C：给研发力量划分投资组合

比起上面两种极端的方法，还有一种折中方案。就是划分出一个特定部分的研发力量来专门针对紧急的销售驱动的干扰，例如一个季度中的15~20%的工作量，把大客户的需求点分散到各个迭代中来完成。这样我们才能保证到不受干扰的研发力量，去从事开发通用需求，填补技术债务等等非紧急但很重要的工作。

采用这个方式需要持续管理和落实，不然还是会因为客户需求的“紧急”性，慢慢滑落到“销售驱动”。

还有一种方式是采用专门的项目实施团队，或者通过外包人力，通过项目试试的方式来专门服务所有销售驱动的需求。例如：向SAP一类的大型产品在实施时是通过项目的方式，为每个客户配备专门的开发团队，来处理定制需求和系统集成等工作（当然SAP的实施项目范围远远不止开发，还包括和埃森哲配套进行咨询服务等等，这是由SAP面向的都是超大型客户和非常复杂的需求所决定的）。当然，这个要求产品的核心架构和接口能够对第三方扩展进行支持。

可落实又有灵活性的产品路线

第三种方式，可以有效解决效率高和效应快两者之间的矛盾。我们能够得到一个既能够落实的中长期产品路线，又具有一定的灵活性能够响应客户意料之外的额外需求。保护好既定计划的时间之后，我们可以：

• 比起原来被销售驱动所一拖再拖的产品规划，现在可以更好地承诺按时完成原定计划的工作了，团队也没有理由或者借口把原计划的工作不断地后延；
• 比起简单粗暴地拒绝客户的任何要求，现在团队是可以去快速响应客户的需求的，而且，因为给这些需求划定了配额，也倒逼销售团队将这些销售驱动需求排列优先级，优先去满足利益最大化的需求；
• 当产品完善到一定的程度，知道什么时候把客户的定制需求可以下放到外部或者内部的专门的团队去响应这些需求。

总结

上面讲述了toB大客户产品所特有的一种研发矛盾，这种矛盾缘自与团队中不同角色不同的激励和考核方式：销售团队想要研发团队能够快速响应，来满足特定客户的复杂需求，从而带来收入；研发团队想要的是尽量少的打扰来达到持续的生产力。作为处于中间的产品团队，则要站在整个产品乃至公司的高度来进行规划和调和。

作者：梵天，公众号：梵天Daozen（fantian-daozen）

本文由 @梵天 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议