“三板斧”剖析To B产品版本管理与需求优先级

 # 本文为人人都是产品经理《原创激励计划》出品。

伴随着产业互联网的搭建与市场总体环境的变化，产品经理的业务需求相应有所调整。而在To B项目中，其用户目标群体、业务场景等也与To C有所不同。其中，产品经理如何在复合场景下协调团队合作分工、做好版本管理与需求优先级排序？也许，你需要采取如下组合策略。

记得浙大管理课老师分享过一个故事：

爱因斯坦在普林斯顿任教时，周四下午刚结束大三期末考试，他拿起卷子匆忙离开，助教小跑着穿过操场追上他，善意地提醒道：教授，您是不是弄错了，今年题目和去年是一样的。爱因斯坦说：我知道题目和去年一样，但是答案不同。

“题目相同，但是过了一年后正确答案不同”。

讲这个故事是希望告诉产品同学们：产品经理的职责和企业CEO是相似的——需要面对复杂的信息源、需要持续输出正确的决策。

做决策本身就很难，更何况是持续做出高质量的决策。

面对同样的用户，换个场景（地域/空间/时间）后，能满足用户需求的解决方案可能**发生变化，不再是现阶段的最优路径。

一、我们的困惑：怎么做好版本管理与需求优先级

上周和国内头部一家做ERP系统的朋友在闲聊，问到他们产品功能上线流程，发现与To C消费互联网产品开发流程相比，有着非常明显的差异。

ERP系统的作用是串联和呈现，将企业内部所有涉及到跨部门协作的业务流程数字化，整套ERP系统功能庞大，一般按照客户所处的行业特性来划定具体的细分场景，每个细分场景的功能流程不同。

To C的产品，我们都被教育要习惯去关注用户操作的行为数据，根据数据反馈来相应优化功能。但是在ERP系统这一类B端产品里，你明知道有部分功能只有个别用户在使用，也不能随便下线或隐藏功能，功能模块上下游的关联衔接纷繁复杂，牵一发而动全身。

To B产品大而全有必然性的：SaaS厂商的**客户达到一定量后，都**主推支持低代码、低成本开发的PaaS（如北森）平台。即搭建开放平台，支持客户们个性化的功能需求。每个客户都是独立的，客户拥有个性化配置一切的权利；我们要尽全力去实现每一个客户的独立和个性化，而不是限定他们一定要怎么样。

To B产品满足的是公司业务流程数字化的需求，多角色、跨职能的操作，如果只是单一场景下某个（单一）用户角色的需求，导致解决方案变化的的影响因素少，产品经理可以专注在核心的场景里解决问题，决策的难度大大降低。所以，很多做企业服务类产品的PM都**被版本管理与需求优先级排序困扰，这个问题是普遍存在的。

二、问题根源：产业互联网的特殊性

既然版本管理与需求优先级是普遍存在的共性问题，我们就需要去分析问题背后的本质原因，单纯评价是产品经理个人能力差异导致是不准确且**面的。

下面我将分别从宏观和微观两个视角分析，为什么产品人**对B端产品的需求管理与功能开发优先级产生困惑。

1. 宏观视角：消费互联网和产业互联网差异

《冰与火之歌》里有句著名的台词，“In the game of thrones, you win or you die”。

在消费互联网的市场里，这句话是成立的。

比如做熟人社交通讯的微信一家独大，其他产品几乎不存在；但在产业互联网里（如企业服务软件市场），我们在美国看到了百花齐放的春天，大家耳熟能详的比如Salesforce、Slack等等，国内市场也是如此；从市场兼容性可以看出，产业互联网和消费互联网是有差别的。

消费互联网更鼓励高效运作。它的分工关系可以被设计出来，比如有一拨人做产品经理，有一拨人负责把这个产品运营起来，还有一些设计师和工程师等，他们的分工相对来说比较成熟。

但产业互联网它本身就已经有了一个产业（现有的业务流程），它不是去创新，而是在这个产业当中做一些改革，只是这个改革过程中有不确定因素。它鼓励探索不同的边界；相比消费互联网，产业互联网更多的是强调由合作带来对分工，这里的分工和合作关系很难被设计出来，基本上都要一次次地摸索和实践。

2. 微观视角：复合场景下对PM的能力挑战

产业互联网的产品经理起初都是由技术工程师演变而来，比如制造业的ERP，他们懂代码语言和技术框架，转岗后可以良好地与技术团队沟通，协助评估需求开发上线成本，避免了因为不懂技术而无法与技术人员沟通的问题。

另一个层面是：消费互联网对产品经理的能力要求是理解场景与用户的行为路径，更关注单个用户的操作体验，往往对于某一类客户的抽象归纳能力很突出。但是对于产业互联网，做企业服务类产品的PM而言，要理解并发的多角色功能逻辑，在同一套系统里要能够宏观地看待跨部门协作的效率。

换而言之：企业服务类产品（to B）对于产品经理的能力要求更高，需要具备处理复合场景下的并发功能的逻辑思维能力，同时要能够理解客户的业务诉求——产品不单单只是某个用户的工具，而是连接组织内部各线条的系统，客户需要的是整车方案，不是单个轮胎。

三、解决方案：可甜可咸的组合策略

B端产品需求的来源丰富，有客户反馈、销售团队业务诉求、运营活动策划所需、老板发来的竞品参考。与其说咱们产品同学难在需求处理上，更直接说是难在公信力和话语权上——如何平衡各方的关系，需要处理得很微妙。就像战备时期，所有战力部队向军工厂要武器弹药一样，哪里都不能短缺，得排个优先级，让大家都能接受的结果。

1. 专业度：建立判断机制，被广泛认可

由于之前踩过坑，我们在早期就开始建模型，形成内部产品需求优先级判断标准，产品同学接收到需求后，按照划分的四个维度去归类，根据“一大带四小”的原则去快速启动排期开发。如果功能上线后，用户的使用反馈不达预期，排除其他因素，是需求的源头出了问题，我们**组织内部讨论，修正更新判断标准。

举个实战例子，当接到个别客户提出的需求时（判断个性化需求or普遍存在的通用性需求），我们可以从以下五个维度评估：

1. 疼痛的深度：个性化需求对于用户而言，是不是刚需；优先做“雪中送炭”的需求，再排期“锦上添花”的需求。
2. 影响的广度：是不是牵扯到上游和下游不同业务流程的完整性，如果有紧密关联，不处理则**影响用户的正常操作，就像前面提到的钉钉绩效考勤表。
3. 寻找最大公约数：是某个特别用户的唯一需求，还是普遍存在却被忽视的隐藏需求。产品要解决用户普遍存在的问题，就好像数学上解题寻找最大公约数，这一点也**涉及到公司商业模式，有些产品确实解决了用户问题，但撑不起一家有体量的公司活得很滋润。
4. 关乎公司发展布局：有些需求必须开发不是单纯为了用户，和公司的战略发展决策有关；比如刚刚提到的我们公司建立判断模型，这个模型是动态的，跟着公司目前的发展节奏和行业所处生态位。
5. 技术评估：除了以上四点外，还需要考虑一下技术层面，是否现有技术可以实现，实现成本是否太高。

2. 修炼情商：管理（需求提出者）预期

看到标题你应该挺惊讶的吧？确实产品经理需要具备高情商，毕竟工作内容里有很大一部分是沟通协调职能。

最近在看各种销售技巧类的书籍，里面大量提到了顶尖销售人员对于情商的培养。而产品经理和销售的工作职责非常相似——面对用户/客户，把有形的产品或无形的服务推广出去。

从神经学的角度解释，人的大脑皮层杏仁核**对周围人或事物表现的敌意，做出抵抗或逃避的反应。我们在讨论需求优先级排序时，如果不能通过控制杏仁核，就**引起对方的反抗意识——想想多少次跨部门讨论需求时，大家争得面红耳赤？

除了抵抗和逃避，高情商的产品经理反应是哪一种呢？

他们**察觉到负面情绪的触发点，很好地管控自己的情绪，“以退为进”的沟通艺术。

3. 应急机制：可咸可甜的团队协作

SaaS先靠完整的产品来满足大部分通用需求，再靠行业解决方案来满足重点行业的个性化需求，最后靠把SaaS做成PaaS来满足每个客户的个性化需求。客户足够多了之后，围绕着客户继续展开，可以做很多“增值业务”。

判断自己在什么阶段，重点做什么事情，是一种基础的战略能力。

如果产品经理确定了版本迭代内容与上线时间，在开发过程中，在大的迭代主题之外增加小功能需求的穿插开发，前提是与技术团队做好充分沟通，在不影响原定的开发时间下，帮助需求提出者处理好功能上线（记得和开发小哥们处理好关系，别硬刚）。

一些产品常识，希望大家避雷：

• 没有人**看公告/通知。
• 没有人**看系统消息和群发短信。
• 没有人**改默认设置。
• 没人**沉浸式地看产品操作教学。

“产品是有生命力的流体，在宏观市场环境与微观场景中**发生动态变化。”

需求和需要的差异，我们通过用户调研访谈，循着用户表达的“需要”去挖掘隐性的需求。

“需要”不等于“需求”，需要是浮在表面的渴望，而需求是在具象的情境中发生的情绪感知。

#专栏作家#

大井盖先生，公众号：八点四十，人人都是产品经理专栏作家。前某厂PM总监，现创业公司CEO；关注企业服务和金融赛道，爱好广泛，欢迎一起交流探讨产品或创业相关问题。

本文为人人都是产品经理《原创激励计划》出品，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。