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

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

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

记得浙大管理课X分享过一个故事:

爱因斯坦在普林斯顿任教时,周四下午刚结束大三期末X,他拿起卷子匆忙离开,助教小跑着穿过cāo场追上他,善意地提醒道:教授,您是不是nòng错了,今年题目和去年是一样的。爱因斯坦说:我知道题目和去年一样,但是X不同。

“题目相同,但是过了一年后正确X不同”。

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

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

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

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

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

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

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

To B产品大而全有必然性的:SaaS厂商的会员客户达到一定量后,都会主推支持低代码、低成本开发的PaaS(如北森)平台。即搭建开放平台,支持客户们个性化的功能需qiú。每个客户都是X的,客户拥有个性化配置一切的X;我们要尽全力去实现每一个客户的X和个性化,而不是限定他们一定要怎么样。

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

二、问题根源:产业X的特殊性

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

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

1. 宏观视角:消费X和产业X差异

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

在消费X的市场里,这句话是X的。

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

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

但产业X它本身就已经有了一个产业(现有的Xliú程),它不是去创新,而是在这个产业当中做一些X,只是这个X过程中有不确定因素。它鼓励探索不同的边界;相比消费X,产业X更多的是强调由合作带来对分工,这里的分工和合作关系很难被设计出来,基本上都要一次次地mō索和实践。

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

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

另一个层面是:消费X对产品经理的能力要qiú是理解场景与用户的行为路径,更关注单个用户的cāo作体验,往往对于某一类客户的抽象归纳能力很突出。但是对于产业X,做企业X类产品的PM而言,要理解并发的多角sè功能逻辑,在同一套系统里要能够宏观地看待跨部门协作的效率。

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

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

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

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

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

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

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

2. X情商:管理(需qiú提出者)预期

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

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

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

除了X和逃避,高情商的产品经理反应是哪一种呢?

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

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

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

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

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

一些产品常识,希望大家避雷:

  • 没有人会看公告/通知。
  • 没有人会看系统消息和X短信。
  • 没有人会改默认设置。
  • 没人会沉浸式地看产品cāo作教学。

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

需qiú和需要的差异,我们X用户调研访谈,循着用户表达的“需要”去挖掘隐性的需qiú。

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

#专栏作家#

大井盖先生,X号:八点四十,人人都是产品经理专栏作家。前某厂PM总监,现创业XCEO;关注企业X和金融赛道,爱好广泛,欢迎一起交liú探讨产品或创业相关问题。

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

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

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 “三板斧”剖析To B产品版本管理与需求优先级 https://www.xiongfawang.com/786.html

常见问题

相关文章

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

分享本文封面