编者按:本文来自微信公众号“产品汪的青草牧场”,作者 cc,36氪经授权发布。
对于B端产品来说,需求方一般是企业员工或组织成员,和C端产品经理眼中的“用户需求”不同,作为为需求买单的一方,需求方提出的需求往往不容拒绝,甚至经常存在反复。
B端产品经理的现状,往往是面对需求方 “天马行空”的畅想和不断变更的“需求”,就像一个夹在中间的“小媳妇”一样,在不被满足的客户和熬夜加班的研发同事之间疲于奔命。
面对大量不能拒绝的“需求”,如果产品经理不能分辨出其中的要求和需求,就会在无形中给产品的设计和实现带来很多“坑”,只能投入更多的代价进行补救。
那什么是要求,什么是需求,为什么要分辨他们呢?
通俗来讲,要求就是我想要一匹更快的马,需求则是我想要更快的抵达我的目的地;我想要同事帮我买瓶水,这是我向同事提出的一个要求,我背后的需求其实是口渴(基本需求)和懒得动(人性弱点)。
区分两者的意义在于,如果能找到要求背后的需求,就可以获得更大的解决域—假如同事帮我带回来一瓶饮料,是同样可以满足我口渴和懒得动的需求的)。
对于B端产品来说,我认为“需求”的本质其实是需求方的痛苦之处。而“要求”是客户对这个痛苦之处的解决方案。
举例来说,老板说,“我想要实现企业信息数据化,所以希望你能帮我开发一套系统。”
对于产品经理来说,信息化系统就是老板的要求,而老板背后的需求可能是因为缺乏经营数据,使老板的决策没有依据,可能每次拍脑袋决策使他心慌;
也可能是因为经营信息传递到老板的过程中全靠下属定期汇报,效率低下,
为了搞清楚经营现状而每天听下属进行汇报,就已经消耗了老板的绝大部分精力,老板因为缺乏充足的时间去规划全局而感到焦虑。
这个信息化的诉求的背后,其实是老板的心慌和焦虑,是这种情绪迫使老板决定付出相当的成本通过落地信息化系统来解决这种心慌和焦虑。
这里思考一个问题,如果不落地信息化系统,老板就不能解决这个问题吗?
老板完全可以招聘人手组建经营管理部门,专门做业务信息的采集和汇总工作,信息化的系统能实现的,用微信和excel同样能实现!
一个需求往往有多个可行解,要求却只有一个可行解。
对于B端产品经理来说,如何挖掘出要求背后的需求呢?
我的思路是预设客户提出的都是要求,并通过问“为什么你想要实现xx?”来向真实需求逐步逼近,并通过需求的两个重要特性来对结果进行确认。
▋ 1.建立预设:客户直接提出的百分之九十九是要求。
通常来讲,作为更懂行业知识却不具备产品分析能力的客户来说,他是没有能力抽象并表达出需求的,
客户会说,我想要一瓶水,但是并不会对我们说,我渴了,这个过程其实就损失了很多的信息,是谁,因为什么原因,需要这瓶水?我们小技巧的第一步,就是默认客户提出的是要求而非需求。
▋ 2.需求具有“不可执行性”,要求往往是可执行的。
要求作为需求具象化的解决方案,是可以被执行的方法,而需求是不可执行的。比如我困了是需求,而想睡觉,则是可执行的方法。
比如客户提出“要在某个页面加一个搜索框,针对列表中全部字段信息进行检索”,产品经理心中就要明白,需求方提出了一个要求,我要探求他背后的真实需求,为什么客户需要一个搜索框呢?在具体业务中通常是通过哪些信息对数据进行定位呢?因为什么原因要对数据进行定位呢?
▋ 3.需求身旁,常常有情绪伴生。
对需求产生的来源进行深究,底层一定都是趋与“利”、逃避“害”的人性,需求分析的关键在于明确“利”与“害”的关键点到底在哪里。
我们不是客户,可能无法第一时间带入客户去体会需求的成因。但是我们可以通过体会场景中客户描述问题时情绪的变化来判定要求背后的“利”与“害”,进而分析出客户未说出口的真实需求。
比如客户提出希望将某个业务做到线上以实现线上化,线上化这个词并没有情绪在其中。
我们应该继续提问,为什么要实现线上化?可能客户就会说,“现在因为整个业务在线上没有记录,全部走线下流程,我作为领导,不能实时了解到部门的业务现状,收到的信息都是滞后的,问题出了很久,我可能都不知道。”
当我们体会到,客户的语句中表达出了对部门内部业务运转失去控制的焦虑时,我们就知道,我们找到了信息化背后的需求所在。
我们可以利用刚才的小技巧,在日常生活中来进行一下验证。
举个例子,张三和李四是大学同学,都在帝都从事产品工作。
这天,张三微信李四,“周末有事吗?一起吃个饭吧。”
于是李四使用这个技巧展开了分析:
李四约我周末一起吃饭,我先默认这是个要求而非需求。
另外,吃饭是可执行的操作,而且并没有察觉到情绪的存在,李四向我提出了一个要求!
那他背后的需求是什么呢?
张三试探问道:“为什么想起要一起吃饭呀?”
李四回答道:“我刚和女朋友大吵了一架,想找你喝酒。”
张三想,那其实找我吃饭是个要求,背后的需求其实是李四的倾诉欲。
倾诉欲本身不可执行,而且带有情绪,很有可能,这就是李四的真正需求!
我们默认客户提出的都是要求,而非需求。
通过问询要求背后的原因来逐步逼近需求。
通过要求具有可执行性来进行验证,如果可执行则继续通过刨根问底继续逼近需求。
当挖掘出的原因不可执行后,判断这其中有没有情绪夹杂其中,如果有明显有情绪夹杂其中的话,那么很有可能这就是客户要求背后的真实需求了。