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

“三板斧”剖析ToB产品版本管理与需求优先级记得浙大管理课老师分享过一个故事：爱因斯坦在普林斯顿任教时，周四下午刚结束大三期末考试，他拿起卷子匆忙离开，助教小跑着穿过操场追上他，善意地提醒道：教授，您是不是弄错了，今年题目和去年是一样的。爱因斯坦说：我知道题目和去年一样，但是答案不同。“题目相同，但是过了一年后正确答案不同”。讲这个故事是希望告诉产品同学们：产品经理的职责和企业CEO是相似的——需要面对复杂的信息源、需要持续输出正确的决策。做决策本身就很难，更何况是持续做出高质量的决策。面对同样的用户，换个场景（地域/空间/时间）后，能满足用户需求的解决方案可能会发生变化，不再是现阶段的最优路径。一、我们的困惑：怎么做好版本管理与需求优先级上周和国内头部一家做ERP系统的朋友在闲聊，问到他们产品功能上线流程，发现与ToC消费互联网产品开发流程相比，有着非常明显的差异。ERP系统的作用是串联和呈现，将企业内部所有涉及到跨部门协作的业务流程数字化，整套ERP系统功能庞大，一般按照客户所处的行业特性来划定具体的细分场景，每个细分场景的功能流程不同。ToC的产品，我们都被教育要习惯去关注用户操作的行为数据，根据数据反馈来相应优化功能。但是在ERP系统这一类B端产品里，你明知道有部分功能只有个别用户在使用，也不能随便下线或隐藏功能，功能模块上下游的关联衔接纷繁复杂，牵一发而动全身。ToB产品大而全有必然性的：SaaS厂商的会员客户达到一定量后，都会主推支持低代码、低成本开发的PaaS（如北森）平台。即搭建开放平台，支持客户们个性化的功能需求。每个客户都是独立的，客户拥有个性化配置一切的权利；我们要尽全力去实现每一个客户的独立和个性化，而不是限定他们一定要怎么样。ToB产品满足的是公司业务流程数字化的需求，多角色、跨职能的操作，如果只是单一场景下某个（单一）用户角色的需求，导致解决方案变化的的影响因素少，产品经理可以专注在核心的场景里解决问题，决策的难度大大降低。所以，很多做企业服务类产品的PM都会被版本管理与需求优先级排序困扰，这个问题是普遍存在的。二、问题根源：产业互联网的特殊性既然版本管理与需求优先级是普遍存在的共性问题，我们就需要去分析问题背后的本质原因，单纯评价是产品经理个人能力差异导致是不准确且片面的。下面我将分别从宏观和微观两个视角分析，为什么产品人会对B端产品的需求管理与功能开发优先级产生困惑。1.宏观视角：消费互联网和产业互联网差异《冰与火之歌》里有句著名的台词，“Inthegameofthrones,youwinoryoudie”。在消费互联网的市场里，这句话是成立的。比如做熟人社交通讯的微信一家独大，其他产品几乎不存在；但在产业互联网里（如企业服务软件市场），我们在美国看到了百花齐放的春天，大家耳熟能详的比如Salesforce、Slack等等，国内市场也是如此；从市场兼容性可以看出，产业互联网和消费互联网是有差别的。消费互联网更鼓励高效运作。它的分工关系可以被设计出来，比如有一拨人做产品经理，有一拨人负责把这个产品运营起来，还有一些设计师和工程师等，他们的分工相对来说比较成熟。但产业互联网它本身就已经有了一个产业（现有的业务流程），它不是去创新，而是在这个产业当中做一些改革，只是这个改革过程中有不确定因素。它鼓励探索不同的边界；相比消费互联网，产业互联网更多的是强调由合作带来对分工，这里的分工和合作关系很难被设计出来，基本上都要一次次地摸索和实践。2.微观视角：复合场景下对PM的能力挑战产业互联网的产品经理起初都是由技术工程师演变而来，比如制造业的ERP，他们懂代码语言和技术框架，转岗后可以良好地与技术团队沟通，协助评估需求开发上线成本，避免了因为不懂技术而无法与技术人员沟通的问题。另一个层面是：消费互联网对产品经理的能力要求是理解场景与用户的行为路径，更关注单个用户的操作体验，往往对于某一类客户的抽象归纳能力很突出。但是对于产业互联网，做企业服务类产品的PM而言，要理解并发的多角色功能逻辑，在同一套系统里要能够宏观地看待跨部门协作的效率。换而言之：企业服务类产品（toB）对于产品经理的能力要求更高，需要具备处理复合场景下的并发功能的逻辑思维能力，同时要能够理解客户的业务诉求——产品不单单只是某个用户的工具，而是连接组织内部各线条的系统，客户需要的是整车方案，不是单个轮胎。三、解决方案：可甜可咸的组合策略B端产品需求的来源丰富，有客户反馈、销售团队业务诉求、运营活动策划所需、老板发来的竞品参考。与其说咱们产品同学难在需求处理上，更直接说是难在公信力和话语权上——如何平衡各方的关系，需要处理得很微妙。就像战备时期，所有战力部队向军工厂要武器弹药一样，哪里都不能短缺，得排个优先级，让大家都能接受的结果。1.专业度：建立判断机制，被广泛认可由于之前踩过坑，我们在早期就开始建模型，形成内部产品需求优先级判断标准，产品同学接收到需求后，按照划分的四个维度去归类，根据“一大带四小”的原则去快速启动排期开发。如果功能上线后，用户的使用反馈不达预期，排除其他因素，是需求的源头出了问题，我们会组织内部讨论，修正更新判断标准。举个实战例子，当接到个别客户提出的需求时（判断个性化需求or普遍存在的通用性需求），我们可以从以下五个维度评估：疼痛的深度：个性化需求对于用户而言，是不是刚需；优先做“雪中送炭”的需求，再排期“锦上添花”的需求。影响的广度：是不是牵扯到上游和下游不同业务流程的完整性，如果有紧密关联，不处理则会影响用户的正常操作，就像前面提到的钉钉绩效考勤表。寻找最大公约数：是某个特别用户的唯一需求，还是普遍存在却被忽视的隐藏需求。产品要解决用户普遍存在的问题，就好像数学上解题寻找最大公约数，这一点也会涉及到公司商业模式，有些产品确实解决了用户问题，但撑不起一家有体量的公司活得很滋润。关乎公司发展布局：有些需求必须开发不是单纯为了用户，和公司的战略发展决策有关；比如刚刚提到的我们公司建立判断模型，这个模型是动态的，跟着公司目前的发展节奏和行业所处生态位。技术评估：除了以上四点外，还需要考虑一下技术层面，是否现有技术可以实现，实现成本是否太高。2.修炼情商：管理（需求提出者）预期看到标题你应该挺惊讶的吧？确实产品经理需要具备高情商，毕竟工作内容里有很大一部分是沟通协调职能。最近在看各种销售技巧类的书籍，里面大量提到了顶尖销售人员对于情商的培养。而产品经理和销售的工作职责非常相似——面对用户/客户，把有形的产品或无形的服务推广出去。从神经学的角度解释，人的大脑皮层杏仁核会对周围人或事物表现的敌意，做出抵抗或逃避的反应。我们在讨论需求优先级排序时，如果不能通过控制杏仁核，就会引起对方的反抗意识——想想多少次跨部门讨论需求时，大家争得面红耳赤？除了抵抗和逃避，高情商的产品经理反应是哪一种呢？他们会察觉到负面情绪的触发点，很好地管控自己的情绪，“以退为进”的沟通艺术。3.应急机制：可咸可甜的团队协作SaaS先靠完整的产品来满足大部分通用需求，再靠行业解决方案来满足重点行业的个性化需求，最后靠把SaaS做成PaaS来满足每个客户的个性化需求。客户足够多了之后，围绕着客户继续展开，可以做很多“增值业务”。判断自己在什么阶段，重点做什么事情，是一种基础的战略能力。如果产品经理确定了版本迭代内容与上线时间，在开发过程中，在大的迭代主题之外增加小功能需求的穿插开发，前提是与技术团队做好充分沟通，在不影响原定的开发时间下，帮助需求提出者处理好功能上线（记得和开发小哥们处理好关系，别硬刚）。一些产品常识，希望大家避雷：