做产品运营工作，处理产品需求是必不可少的——当然运营不给产品需求做决定，也不合适，这是产品经理的职能，运营行使的是建议权，给出的应该是“基于现实客情和市场动态的合理建议”。本文将从四个角度，从运营视角来看 To B 产品的需求，希望对你有帮助。
同时，运营在整个业务体系中所处的位置，是承前启后、关联内外。日常工作中，涉及到信息传递、评价决策的时候，运营一定要摆正自己的心态，时刻追溯自己的最终目标，才能保证产品需求的有效传递和价值体现。
所以，做B端业务的运营工作，涉及到产品需求时，首先要明确自己的运营目标、工作心态。
一、目标导向+摆正心态
我所倡导的运营目标是“业绩”，即开单、续费、增购。
除了让公司挣钱，其他花里胡哨的名词，都没什么实际意义。因此，我认为，站在“运营”的角度来判断产品需求，也是以“业绩”为最终导向——这个需求值得让客户掏钱吗？能马上掏钱购买的，就应该加急实现；实现不了人家就断约，或者闹退款，更应该重点考虑。
至于产品研发团队要考虑的技术方案、投入成本，产品运营应该要了解，但不是做判断的第一要素。而且，实际情况中，产品运营再追求“业绩”因素，搞的再极端，很现实的技术框架、成本等问题也会拉着缰绳、踩着刹车。
所以我认为，不用担心你的判断不合时宜，或者追求的目标过于功利，毕竟行使的是建议权，你又不拍板，怕什么？该讲就讲，该理论就理论，和产品经理打嘴仗是常态，“闷嘴葫芦”不可取。
搞清楚自己的位置，如何对产品需求施加影响力？
答：建立统一评价标准后，协调需求的优先级。
二、怎么表现需求的优先级
按我的工作经历，和对接过的产品需求文档来看，很多人习惯性地把需求划分为三个档次（国人爱好？），表现形式有这么几类：
- 数字“1、2、3”；
- 字母“A、B、C”；
- 文字“高、中、低”；
- 其他的形式还有“High、MIddle、Normal”等，形式各异，意图类同。
数字“1、2、3”，会让人纠结，到底1是优先级最高，还是3？
文字“高、中、低”只有三个档次，不好拓展。
所以我是倾向于使用字母“A、B、C”。那“A、B、C”代表的含义怎么体现？
我的观点是，可以采用“紧急程度”和“重要程度”互相结合的方法来评价优先级。
其中，优先考虑紧急程度，因为To B业务的客户随时在使用你的产品，出了问题都是需要尽快解决的，毕竟“稳定压倒一切”；而“重要”的需求，要看它的侧重点在哪里，是提效，还是降本，还是竞品打击？或者说仅仅是因为KA客户提的，显得很重要？判断维度过多，就表示不是特别“重要”，所以我认为“紧急”比“重要”优先。
对应地，产品需求的优先级排列原则，可以参考如下方案：
排列好优先级的评价标准后，具体排期时，应该怎么来评估某个需求？
可以参照以下6个维度。
三、判断产品需求的维度
1. 有没有
判断某个产品需求，先看它是不是解决“有没有”的问题，而且还要再加上竞争对手的因素。
客户提出这个需求，肯定是因为现有的产品功能和服务，真解决不了这个问题，必须开发出来才行；还有就是市面上就你一家服务商的话，客户没得选，人家也正用着呢，那就等等吧，没办法。
但实际上能挣钱的生意，肯定不止一家来做（除非你是特殊行业），客户有的选，竞品有这个功能，你没有，你在这个市场就站不住脚。
所以，解决“有没有”的优先级应该是最高，一般排A或者B。
2. 使用效益
这一点是看这个产品需求的实现，对客户使用上的最终效益影响如何。一般有这么几个影响：增加收益、降低成本、提升效率、品牌增值……我一直从业于软件开发领域，能接触的主要是这几个。
优先级排序也是按这个来：
- 能多赚钱、少花钱的放前面，所以营销类的功能、服务额外重要，排个A或者B；
- 减少工作量的是产品使用者最在意的点，但可以稍微排后些，通过“拖着”来安抚客户，一般排C，除非这个操作体验真的很恶心；
- 品牌增值的话，前提是看服务方的影响力，国内很多企业倾向于使用oracle、SAP，真的是产品很合适吗？不一定。但是用上以后，有那种无形的品牌增值效应——“这钱花的值！”
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的业务，你是不能指望产品设计来教育客户的，除非你是寡头。比如阿里可以这么干，但你不是阿里，可人家阿里的价值观，第一条就是“客户第一”！
五、结尾
综上，即近段时间以来，我对产品需求的重新认识和整理。里面的内容和原则，可能过段时间会变，甚至推到重来。
但是做事情是需要有参考依据的，不然就是瞎搞，至于这些内容，在接下来的工作中，到底还实不实用、合不合理，需要更多实践和讨论来验证。
