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

编辑导读：To B 产品不同于其他产品，它面向的用户是企业，运营时需要注意的事项也有所不同。本文将从四个角度，从运营视角来看 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. 便捷与美观

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

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

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