从运营视角来看ToB产品的需求

编辑导读：To B 产品不同于其他产品，它面向的用户是企业，运营时需要注意的事项也有所不同。本文将从四个角度，从运营视角来看 To B 产品的需求，希望对你有帮助。

做产品运营工作，处理产品需求是必不可少的——当然运营不给产品需求做决定，也不合适，这是产品经理的职能，运营行使的是建议权，给出的应该是“基于现实客情和市场动态的合理建议”。

同时，运营在整个业务体系中所处的位置，是承前启后、关联内外。日常工作中，涉及到信息传递、评价决策的时候，运营一定要摆正自己的心态，时刻追溯自己的最终目标，才能保证产品需求的有效传递和价值体现。

所以，做B端业务的运营工作，涉及到产品需求时，首先要明确自己的运营目标、工作心态。

一、目标导向+摆正心态

我所倡导的运营目标是“业绩”，即开单、续费、增购。

除了让公司挣钱，其他花里胡哨的名词，都没什么实际意义。因此，我认为，站在“运营”的角度来判断产品需求，也是以“业绩”为最终导向——这个需求值得让客户掏钱吗？能马上掏钱购买的，就应该加急实现；实现不了人家就断约，或者闹退款，更应该重点考虑。

至于产品研发团队要考虑的技术方案、投入成本，产品运营应该要了解，但不是做判断的第一要素。而且，实际情况中，产品运营再追求“业绩”因素，搞的再极端，很现实的技术框架、成本等问题也会拉着缰绳、踩着刹车。

所以我认为，不用担心你的判断不合时宜，或者追求的目标过于功利，毕竟行使的是建议权，你又不拍板，怕什么？该讲就讲，该理论就理论，和产品经理打嘴仗是常态，“闷嘴葫芦”不可取。

搞清楚自己的位置，如何对产品需求施加影响力？

答：建立统一评价标准后，协调需求的优先级。

二、怎么表现需求的优先级

按我的工作经历，和对接过的产品需求文档来看，很多人习惯性地把需求划分为三个档次（国人爱好？），表现形式有这么几类：

数字“1、2、3”，会让人纠结，到底1是优先级最高，还是3？

文字“高、中、低”只有三个档次，不好拓展。

所以我是倾向于使用字母“A、B、C”。那“A、B、C”代表的含义怎么体现？

我的观点是，可以采用“紧急程度”和“重要程度”互相结合的方法来评价优先级。

其中，优先考虑紧急程度，因为To B业务的客户随时在使用你的产品，出了问题都是需要尽快解决的，毕竟“稳定压倒一切”；而“重要”的需求，要看它的侧重点在哪里，是提效，还是降本，还是竞品打击？或者说仅仅是因为KA客户提的，显得很重要？判断维度过多，就表示不是特别“重要”，所以我认为“紧急”比“重要”优先。

对应地，产品需求的优先级排列原则，可以参考如下方案：

排列好优先级的评价标准后，具体排期时，应该怎么来评估某个需求？

可以参照以下6个维度。

三、判断产品需求的维度

1. 有没有

判断某个产品需求，先看它是不是解决“有没有”的问题，而且还要再加上竞争对手的因素。

客户提出这个需求，肯定是因为现有的产品功能和服务，真解决不了这个问题，必须开发出来才行；还有就是市面上就你一家服务商的话，客户没得选，人家也正用着呢，那就等等吧，没办法。

但实际上能挣钱的生意，肯定不止一家来做（除非你是特殊行业），客户有的选，竞品有这个功能，你没有，你在这个市场就站不住脚。

所以，解决“有没有”的优先级应该是最高，一般排A或者B。

2. 使用效益

这一点是看这个产品需求的实现，对客户使用上的最终效益影响如何。一般有这么几个影响：增加收益、降低成本、提升效率、品牌增值……我一直从业于软件开发领域，能接触的主要是这几个。

优先级排序也是按这个来：

3. 便捷与美观

我提的“便捷”指客户对这个产品的上手程度。

“这个产品功能挺不错，但就是操作不够便捷，我研究了半天才学会。”

客户要是说出这个话，只有两个原因：一是产品设计不合理；二是售后培训不到位。

客户是没错的，可能他理解能力有偏差，可能习惯了别的操作方式，但是只要反馈产品不好用，后面是肯定没什么信心继续用的，买来的东西不去用，怎么会有作用呢？

所以“便捷”的第一要求是“上手快”，排B。

至于“美观”，也就是好不好看，可以稍微牺牲下。

因为To B产品先得让客户用起来，持续使用产生效果，人家才考虑要不要续费（或者付费，毕竟还有“试用”这么一说）。

“好看”是客群使用状况稳定、竞争压力不大的背景下才考虑的问题。

当然，丑肯定是不行的，这类需求一般是排D。

4. 提交时间/次数

很多积压的产品需求，可能是半年、甚至一年以前就已经讲过很多次了，这个情况就需要额外重视。因为很多To B业务按年收费，攒了这么久的问题都没处理掉，到后面不好跟人家再收钱。

这就不是服务方技术能力的问题，而是服务态度和运行机制的问题。所以哪怕不紧急，也得调到B，甚至A。

不过这一点放在产品bug的处理上，应该反着来。几个月前提交的bug，一直没方案去处理的话，那就优先解决新提交的bug。给客户的印象应该是“一直在解决问题”，而不是“一直解决不了问题”。这一点，主要是方便前线的同事来做售后服务。

当然，某个产品需求/bug已经存在很久，而且是大面积问题，就可以调到A，要求产品研发团队成立专项组来解决。

5. 覆盖的客户范围

覆盖范围，可以按这么几个维度来区分：数量、行业（类目）、地区。

同一个产品需求，10家提过到100家提过，说明这是需求越来越刚需；只有这10家提过，那优先级就得靠后，一般会排个C。

有些需求，只有特定行业会用到，比如我现在做AI聊天机器人的产品需求分析，服饰类客户对尺码推荐的要求就很高，尺码推错了买家就得退换货，增加店铺的运营成本，所以版型类的需求或bug，一般会放在B、A，因为尺码推荐这个功能是一直在运行的，要不就得关了这个功能。

To B产品的客群，一般会有扎堆的情况，或者同行的企业老板、负责人，都有一个圈子，甚至可能是一家子。产品功能的好坏，不用自己来宣传，人家私底下一讨论就能达成共识。

还有一个情况就是，某个地区、某个领域，都存在着标杆客户，这家用什么产品，这一片客户也会跟着用这个。所以在确认产品需求的时候，一定要搞清楚：这需求谁提的？影响力怎么样？

6. 竞品动作

涉及到竞品因素，在分析产品需求时，可以参考两个大的原则：

1）对方有的，我必须有。能让客户付费的功能，一定要搞出来，哪怕实际用处不是很大。To B的运营要看业绩，市场被人抢了还怎么搞，一定要守住阵地。

2）差异化避免不了，就一定要保持领先。大家都服务同一类客户，或许会打差异化策略，但遇到抢单的时候，核心功能肯定会被用来作比较，这时候就看哪家的功能更落地、效益更明显了。所以，自家产品的核心功能和卖点，在涉及竞品影响的时候，一定是排A。

当作为“运营”这个角色，能够理清所掌握的需求排期后，就需要同产品经理来协调优先级，在具体的沟通、传递过程中，需要掌握以下5个原则，避免扯皮、提高沟通效率。

四、产品需求的传递原则

1. 说人话

尤其是对前线、对客户的沟通，不要人为地设置门槛。

各种专业术语、名词，实在翻译不成大白话的，也得加个注释，举个例子。

你的产品使用人群可能就是高中毕业，但非要用英文来命名某个功能，这不找事吗？

2. 不要拦截

“客户提出来的需求，不一定是合理的需求”，这话谁都会讲，所以很多运营喜欢自己先判断一下，自认为不合理的需求，就直接过滤了，导致产品经理和研发团队一直收不到，客户那里可能急得直跳脚。

正确的做法应该是记录客户原话，一直保留在工单或需求汇总表里。这个需求可能提的不合理，或者短时间内真实现不了，但是人家提过，起码得留个记录，万一有别的方案可以实现呢？

所以实际上，在对接产品研发团队的时候，添加”暂不支持“的备注即可。产品经理有余力，可以再拿出来聊一聊。

3. 表达一致

每一块功能、服务的用词表述，都需要是一致，不搞多样化，不要增加理解难度。

账户就是账户，从头到尾都是账户。在 A 产品是这样，在 B 产品也是这样。这个地方叫“设置”，那个地方叫“配置”，肯定不行。

不仅仅是产品设计上，在需求描述、对外的产品包装上也是如此。一以贯之，才能形成整体调性。

4. 跟进到底

这个需求之前对接过一次，可能被产品经理毙掉了，或者排期靠后，但不代表可以不管它。

因为需求的来源是客户，你没记着，人家可记着呢！很多产品经理容易忘事，积攒的不少需求没空排期，结果是最后不了了之。

站在运营的角度，这种现象肯定是不合理的，一定要定期回顾需求的提交时间，跟进到底。

反过来也一样，产品研发团队辛辛苦苦开发了一段时间，最后也上线了，运营一定要跟进它的落地效果和客户反馈，这也是对后端团队工作结果的重视和认可。

5. 站在客户立场

哪怕公司的企业价值观再怎么强调“客户第一”，很多产品经理还是有不食人间烟火的习惯。

最典型的一个例子就是：客户说“我需要怎样怎样”，产品经理给你来一句“我们的设计是怎样怎样，你应该怎样怎样……”

谁规定的？客户为什么一定要按你的来？

这个时候，运营的屁股一定要坐在客户那边，因为To B的业务，你是不能指望产品设计来教育客户的，除非你是寡头。比如阿里可以这么干，但你不是阿里，可人家阿里的价值观，第一条就是“客户第一”！

五、结尾

综上，即近段时间以来，我对产品需求的重新认识和整理。里面的内容和原则，可能过段时间会变，甚至推到重来。

但是做事情是需要有参考依据的，不然就是瞎搞，至于这些内容，在接下来的工作中，到底还实不实用、合不合理，需要更多实践和讨论来验证。