【推荐】产品经理如何解决冲突性需求(文末有重要信息)


什么是冲突性需求


本田公司的产品经理(本田的产品经理被称为是大型产品领导人,large product leader)在设计第三代雅阁的时候,面临的需求主要集中在三个方面:1、视野要好;2、空间要大;3、发动机要强劲。

每一个需求拿出来都好解决,但是当要同时满足这三个需求的时候,本田的产品经理就面临着进退维谷的情况。

比方说,如果视野要好,那么,那么前挡风玻璃就要设计的大,而发动机舱和引擎盖就要设计的小和短,但是,如果发动机舱和引擎盖小和短的话,那么,就只能塞一台小的发动机进去,而小的发动机则很难提供强劲的动力,并且前挡风玻璃大的话,那么,在夏天的时候,就更容易使车内很热,这就需要一台大功率的空调来降温,但大功率的空调就必须又得要一台大发动机,而大发动机则又无法满足视野好的需求。

也就是说,如果满足需求1,那么,需求3就无法满足,反之亦然。

这种进退维谷的需求,我称之为是“冲突性需求”。

简单做个定义,冲突性需求就是指:

在多个需求中存在关联,且具有互斥影响的需求。

很好理解,因为产品经理在现实的工作中其实经常会遇到这样的需求,随便举几个例子。


冲突性需求的案例


案例1

现在无糖类食品逐渐开始大热,几乎涵盖所有品类,饮料、零食、点心、蜜饯、糖果等等(因为这几样我都买过,就知道这么多,嘿嘿),主要的目标消费者大致就是两类:1、重视健康的消费者;2、患有某种疾病,需要忌糖的消费者,比方说糖尿病患者。

那么,这些人群在消费这类产品的时候,有三个需求其实比较集中,1、无糖但是口感不能太差;2、健康;3、价格不能太高,毕竟食品是存在高频消费的。

但是,这三个需求其实很大程度上就构成了冲突性需求,比方说,如果口感要好,那么,白糖作为这类食品中传统的用料,其实是最好的,因为白糖不但可以作为食品原料,其本身也具有增鲜防腐的功能(这就是为什么炒菜的时候,大厨们都会搁点白糖的原因),但是如果按照传统的量来添加白糖的话,那么,肯定和健康的需求就冲突了,但是,如果减糖的话,那么,口感就又跟不上了,这就是为什么可乐控们视无糖可乐为异端的原因。

当然,肯定有别的办法,比方说用其它甜味剂来代替白糖,但是,如果用各种醇类的话,比方说木糖醇,那么,就又涉及到原料成本的问题,白糖多少钱一吨,木糖醇多少钱一吨,对吧!

那么,还有办法,如果不用木糖醇这类的代糖原料,用各种化学甜味剂,比方说阿斯巴甜,甜蜜素,成本是降了,但是健康又成为了一个问题,毕竟消费者对于化学添加剂搁到食品中还是有所顾忌的。

也就是说,如果满足需求2,那么,需求3就和它形成了冲突(健康的,往往是高成本的,比方说有机食品)。

案例2

在咱们的PMManager刚刚推出的时候,就有很多朋友问我,你这个软件的数据存在哪里?我说存在你的本地电脑上,如果不信的话,你在登录以后,把网断了试试,照样能用,PMM用的不是SAAS的模式。

尽管在软件行业,SAAS模式大行其道,但是细细想的话,其实这种模式在具体软件类型的应用上得区别对待。

对于软件客户,比方说B端客户而言,他们在使用一套企业软件的时候,最关心的需求可能也是三个:1、全周期成本要低;2、数据安全性要高;3、使用要简单。

SAAS能够非常好的满足第一个需求,但是在面对第二个需求的时候,可能就会出现朋友们问PMM的数据放在哪里的问题。

不管SAAS服务商怎么承诺安全性有多好,其实对于很多企业客户而言,心里是多少有点打鼓的,毕竟自己的数据,尤其是如果涉及到大量核心数据的话,放在别人那儿,那就如同把自己的老婆交给别人照顾一样。

不出事还好,但是一旦出一次事,那就好比飞机出事一样,像PMM,就存放的是产品经理工作中大量的过程数据,这些数据一旦出点问题,我卖血、卖肾都赔不起啊。

再说了,这几年一直有数据被泄露的新闻,这无疑会对客户对SAAS的安全性产生一定程度负面影响。

那么,如果数据放到客户那里,安全性的顾虑肯定是大大降低了,但是成本那肯定是迅速攀升,对于一般的企业而言,根本负担不起。

也就是说,如果满足需求1,那么,需求2就有可能会和它产生冲突。

案例3

说完了吃的和用的,说点更高端的产品,熟悉军事的朋友肯定知道,坦克这种武器产品,核心的需求指标就是三个:1、机动力;2、防护力;3、火力。

这仨指标也是非常典型的冲突性需求,比方说,如果机动力要增强,那么,在现有车身材料没有质的变化的时候,那么,要么换大发动机,要么减轻整体车重,但是如果换大发动机,那么,车内空间必然减小,空间减小,那么,装弹量就要减少,而装弹量减少,火力的持续性就会受到影响,同样,如果减轻整体车重,那么,防护力就会受到影响。

同样,如果要增强火力,一方面是增加载弹量,另一方面是增加火炮口径,但是增加火炮口径,就势必会增加车重,而车重一旦增加,机动力就又会受到影响。

如果要增加防护力,比方说挂各种主动和被动装甲,那么,车重自然增加,同样,机动力就又要受到影响。

也就是说,自打坦克诞生那天起,设计师们就一直在这三个关键指标中不断权衡,如何才能做到兼顾三者。

这种情况也集中出现在装备制造、汽车制造等传统工业产品中,比方说乘用车的产品经理,就很大程度上会面临开篇讲到的本田LPL遇到的情况。


解决冲突性需求的三个思路


冲突性需求产生的根本原因还是因为用户需求的多样性造成的,对于产品经理而言,理想的状态肯定是“既做这个,又做那个”,但现实的情况正如案例中说到的,很多时候只能是“做了这个,放弃那个”,那么,我们该如何解决冲突性需求呢?三种思路:

1、一刀切

这是最直接,最粗暴的方式,做个比喻,就像是俩人吵架,你去拉架,但是拉的是偏架,好处是你会得到一方的感激,但是也会丢掉另一方的信任。

比方说本田的雅阁,如果只去满足“视野好”的需求,不去管其它的需求,那么,塞一台体积较小的发动机进去就可以了,那么,对于追求动力的用户来说无疑是一种放弃。

因此,一刀切的解决思路最大的风险就在于可能会失去一部分潜在客户。

2、折中

这个方式就得稍微动动脑筋了,如何在冲突性需求中拿出一个折中的方案来满足这些需求,这个看起来简单,其实做起来还是比较难的。

这就好比还是两个人吵架,你既要把架劝了,还不能得罪双方,还是雅阁,如果要满足动力强劲,那么,塞一台现有的大功率发动机进去是肯定的,那么,大空间和视野好怎么办呢,也有方法,比方说把后排座椅缩短个5-10厘米,这样在轴距不变的情况下,乘坐空间自然会加大。

其实很多车企都是这么做的,大家应该有这样的体会,比方说一款轴距2.6米的车,感觉坐着比轴距2.7米的还要宽敞,为什么呢,你去量一下后排座椅的长度就知道答案了。

因此,折中的解决思路最大的风险就是你的产品很难定义出明显的优势,以及会连带到产品价值的设计。

3、创新

这是最好的解决方法,但是也是成本最高,周期最长的,还是吵架,如果用这种思路,不但你能把架劝了,还能让双方形成“不打不相识”的美好结局,当然,如果都能和你再成为朋友那就更好了。

第三代雅阁其实就是采用了这种思路,LPL为了能够高度适配这三个需求,和工程师们一起努力,最终开发出了一台体积小但是功率强劲的发动机完美解决了这仨问题。

这种思路的最大好处就是不但能创新性的解决用户的问题,满足需求,并且创新的结果会成为企业的优质资产,比方说本田现在装机最多的1.5T的地球梦发动机,通过刷ECU,把马力干到了240匹,扭矩243,而奥迪的2.0T高功率版本的动力也才252匹,宝马的2.0T高功率版本的动力也才252匹。

这也就是为什么本田被誉为是日系车里发动机技术最强的,也才有了本田是“买发动机送车”。

特别说明:

以上关于本田1.5T发动机的介绍只仅仅是案例需要,不存在任何广告动机啊!

当然,这种创新的思路最大的风险就是可能会让产品在前期的研发成本陡增,还有半途夭折的可能。


4、针对冲突性需求,我真正想说什么


这个小节的标题是不是很有意思,讲了这么多,难道不是介绍冲突性需求?

还真不完全是,我真正想说的还是把产品上的冲突性需求延伸到产品管理中。

其实在企业日常的产品管理中,同样存在类似的情况,也就是说,产品管理体系其实也是在不断的解决冲突性的需求。

怎么回事呢?

我们假定你有一个产品从有想法到发布,公司的要求是六个月,这六个月的工作目标就是“如期上市”。

那么,什么因素会影响到这个目标的实现呢?三个:

1、需求的适配性;2、产品发布的速度;3、成本

如果我们用一个数学公式来表示的话,就是:

当目标确定(如期发布)的时候,那么,整个产品管理体系运转的效果就会直接影响目标的实现,而体系运转的效果则会受到这三个因素(变量)的影响。

比方说,如果想要如期或者提前发布(变量S值确定),且成本确定的情况下(变量C值确定),那么,要让T的值正常或更高,就必须确保或提升变量F的值。

涉及到产品经理的具体工作,比方说问题管理,就要求我们如何才能更准确的捕捉、分析、验证这些问题的真实性以及导出相应的需求。

但是,一种可能也会出现,就是我们为了更好的确定需求适配性,而化了更多的时间,也就是F值增加,同时呢,又要确保T值不变,那么,就必须要降低S值和C值,但是呢,一旦要缩减S值,就势必又涉及到其它业务体系对入市速度的影响,比方说研发周期。

我这只是举了一个很小的例子,大家想想,现实中是不是就是这样,真正的产品管理体系的运作,这个公式就完全能够表达出来,而我们所做的所有具体的工作,其实根本上说都是在不断调整F、S、C这三个具有冲突性的值。

解决的思想其实也脱离不了第三小节讲到的三种思路,要么只关注其中的一个值,要么在三个值中做折中,要么就是在产品管理体系的实施上进行模型创新,包括但不仅仅限于PMS,比方说研发体系为了更快的开发出产品,就在瀑布的模式上创新出了敏捷。

这才是我在本文中真正想表达的,其实我只想让大家记住这个公式就可以了,好好揣摩这个一下我们的工作都是如何在这个公式中体现出来的。

具体如何基于对这个产品管理公式的思考做好产品管理工作,请继续往下看。


做个预告


弹指一挥间,我在产品管理这个领域中已经折腾了20年了,尽管没做出过什么牛逼的产品,但是经验还是有一些的,我在想,如何能够为我这20年的产品管理职业生涯做个值得纪念的注解呢?

想来想去,我打算在今年,把内容分享的重点放到产品管理上,大概会占到70%的比例,因此,准备开一个大的免费系列,名字暂定为《PMKSG-产品管理知识体系框架导读》,初步计划知识点不会少于150个,估计一年内做完。

当然,产品经理个人的知识技能这块,我还会继续去做,主要以《构建产品经理个人知识体系》这个学习包为主要形式。

除此之外呢,一些小的系列和文章也会穿插在今年的知识分享中,这个嘛,我就想起什么写什么了。

总之一句话,感谢这么多年来大家对老汤的支持和信任,我也结识了很多朋友,学到了很多东西,今天是腊八,老话说,过了腊八就是年,在2021年,还希望朋友们继续支持老汤和联盟,我们会用更多更好的内容来答谢大家的!

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址