“三板斧”解析To B产品需求优先级管理

管理课老师分享过一个故事:爱因斯坦在普林斯顿任教时,周四下午刚结束大三期末考试,他拿起卷子匆忙离开,助教小跑着穿过操场追上他,善意地提醒道:教授,您是不是弄错了,今年题目和去年是一样的。爱因斯坦说:我知道题目和去年一样,但是答案不同。
“题目相同,但是过了一年后正确答案不同”。

“三板斧”解析To B产品需求优先级管理

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

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

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

01 产品经理的困惑:版本排期与需求优先级

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

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

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

To B产品大而全有必然性的:SaaS厂商的会员客户达到一定量后,都会主推支持低代码、低成本开发的PaaS(如北森)平台。即搭建开放平台,支持客户们个性化的功能需求。

每个客户都是独立的,客户拥有个性化配置一切的权利;我们要尽全力去实现每一个客户的独立和个性化,而不是限定他们一定要怎么样。

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

02 问题源头:产业互联网的特殊属性

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

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

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

《冰与火之歌》里有句著名的台词,“In the game of thrones, you win or you die”。在消费互联网的市场里,这句话是成立的。

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

消费互联网更鼓励高效运作。它的分工关系可以被设计出来,比如有一拨人做产品经理,有一拨人负责把这个产品运营起来,还有一些设计师和工程师等,他们的分工相对来说比较成熟。产业互联网它本身就已经有了一个产业(现有的业务流程),它不是去创新,而是在这个产业当中做一些改革,只是这个改革过程中有不确定因素。

它鼓励探索不同的边界;相比消费互联网,产业互联网更多的是强调由合作带来对分工,这里的分工和合作关系很难被设计出来,基本上都要一次次地摸索和实践。

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

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

另一个层面是:消费互联网对产品经理的能力要求是理解场景与用户的行为路径,更关注单个用户的操作体验,往往对于某一类客户的抽象归纳能力很突出。

但是对于产业互联网,做企业服务类产品的PM而言,要理解并发的多角色功能逻辑,在同一套系统里要能够宏观地看待跨部门协作的效率。

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

03 解决方案:可咸可甜的组合策略

B端产品需求的来源丰富,有客户反馈、销售团队业务诉求、运营活动策划所需、老板发来的竞品参考。与其说咱们产品同学难在需求处理上,更直接说是难在公信力和话语权上——如何平衡各方的关系,需要处理得很微妙。

就像战备时期,所有战力部队向军工厂要武器弹药一样,哪里都不能短缺,得排个优先级,让大家都能接受的结果。

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

由于之前踩过坑,我们在早期就开始建模型,形成内部产品需求优先级判断标准,产品同学接收到需求后,按照划分的四个维度去归类,根据“一大带四小”的原则去快速启动排期开发。

如果功能上线后,用户的使用反馈不达预期,排除其他因素,是需求的源头出了问题,我们会组织内部讨论,修正更新判断标准。

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

疼痛的深度:个性化需求对于用户而言,是不是刚需;优先做“雪中送炭”的需求,再排期“锦上添花”的需求。

影响的广度:是不是牵扯到上游和下游不同业务流程的完整性,如果有紧密关联,不处理则会影响用户的正常操作,就像前面提到的钉钉绩效考勤表。

寻找最大公约数:是某个特别用户的唯一需求,还是普遍存在却被忽视的隐藏需求。产品要解决用户普遍存在的问题,就好像数学上解题寻找最大公约数,这一点也会涉及到公司商业模式,有些产品确实解决了用户问题,但撑不起一家有体量的公司活得很滋润。

关乎公司发展布局:有些需求必须开发不是单纯为了用户,和公司的战略发展决策有关;比如刚刚提到的我们公司建立判断模型,这个模型是动态的,跟着公司目前的发展节奏和行业所处生态位。

技术评估:除了以上四点外,还需要考虑一下技术层面,是否现有技术可以实现,实现成本是否太高。

2. 修炼情商:管理(需求提出者)预期

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

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

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

除了抵抗和逃避,高情商的产品经理反应是哪一种呢?他们会察觉到负面情绪的触发点,很好地管控自己的情绪,“以退为进”的沟通艺术。

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

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

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

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

业界动态

互联网广告极为重要的进化:广告商品化

2021-6-10 10:09:25

业界动态

淘宝联盟是什么意思?

2021-6-10 10:21:47

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索