作为产品经理,你做完一件事,别人问你怎么做的,你能说好吗?如何在说的过程中,体现出你的逻辑思考能力、需求分析能力、优先级排序能力和解决问题的能力?如何让你的经历变成经验,变成可迁移的能力,变成别人可复制的技术? 今天给大家介绍一个案例,主人公叫Ver。他是我的学员,Ver曾给我讲了一个故事,听完他的故事之后,我觉得这就是产品经理的工作典范,能成为复制到需求分析阶段的蓝本,照着这个做,不会有问题。 一、故事背景 Ver之前在一家在线教育公司,做面对学校的基于SaaS平台的在线排课系统。这一看就是TO B的产品岗位,B端客户,那都是客户爸爸呀。可李悦就是把B端金主爸爸的需求优先级排在了后面,为什么他敢这么干? 大家都知道,从事B端的产品经理可能经常会遇到这样一种情况:当你已经完成最近的需求排期后,新功能开发也在有条不紊地进行,这时候,BD和销售却跑过来跟你反馈说,有一个重要客户急需某个功能,需要我们尽快开发出来,这时你应该怎么做,是赶紧去重做需求排期吗? 其实,不止是B端,还是C端,总会有一些临时突发的需求出现,发生这种情况的时候,很可能就打破我们之前的产品节奏了。更何况,作为产品经理,你是接受需求的前线,你接到需求后,和研发去提,研发不同意咋办?这是一个天雷,劈在了你的身上,到底怎么办呢? 别急,身为产品经理的我们需要有一套清晰的逻辑思维去甄别、去分析,这时我们可以使用产品经理最常用的"三板斧"——用户、场景、需求。 万变不离其宗,"用户——场景——需求"这个公式,一定要变成下意识的判断。 二、确定用户 首先我们要知道提需求的人是谁,可能有人说,当然是用户了。但我们了解真的了解我们的用户吗? 我们知道,B端产品服务的对象通常是企业、商户、政府部门、事业单位等。 通常情况下,决定是否使用产品的决策人和真正的产品使用者并不是同一类人,很可能是上下级的关系,而产品面向的使用者通常是对应某类职业的人群。 这时请注意,这类人在使用产品时的身份标签是他所做的职业,产品面对的用户是剥离个体兴趣,更多是带有集体属性的人群。 这也意味着用户更关注产品能否满足我所做的业务场景需要,至于页面美不美观,图标好不好看,并非核心重点。 三、场景需求分析 面对需求,我们应该有什么样的处理方式呢? 首先,任何需求都是基于场景的,我们需要弄清楚:用户提到的需求中的场景是什么? 一天销售跟我说:"学校老师希望在"教师无课查询"模块里面,增加"文件导出功能",并说是老师特别提出来的,是个刚需。" 这时,我跟销售说:"需要跟老师进一步沟通下这个需求的具体场景。" 之后老师表示需要根据无课的时间情况做调课,但因为有时出差在外不方便,所以需要导出文件用手机看。 这时就可以发现:老师提出的需求场景是实际存在的,但他提出的需求并不是真正能完成他任务的需求,而给出一个问题的解决方案。 请注意这里,老师是直接提出了一个解决方案。这是什么意思呢? 一个问题,往往包括了两部分:一部分是问题空间的,只有问题;另一部分是解决方案空间的,是这个问题的解决方案。 很多时候,用户或者产品经理,其实都会把问题空间的事情,直接变成解决方案空间的。就问题而言,这里老师遇到的问题是什么呢? 老师的问题是:如何在无课的时候进行调课? 所以,通过进一步询问,就会发现:其实老师真实需求是需要在移动场景下去完成工作上的调课,真正需要做的是做移动端的调课功能,而不是导出课表文件。 导出课表文件,能让老师收获一个什么呢? 老师能收获一个课表文件,然后老师就在课表文件上,找哪里没有课程?找到之后呢?老师就会想着把课程调到这里呀。但是,之后怎么办?老师肯定还会和销售说,我想把这个课程调过来,完成了这个需求,才出来真需求。产品能接受,研发能接受吗? 所以,要分析老师真实的使用场景,以及场景下的需求分析。 四、优先级排序 接下来才是需要思考的是我们真的需要做这个需求吗?或者说这需求是真的有必要马上去实现吗? 这时,我们可以套用产品的价值公式来分析需求价值: 需求价值=用户广度*需求强度*需求频率 还是以上面的案例为例,排课系统的实际使用用户是学校的教务老师,大多数学校老师的工作场景主要是围绕在学校内的,也就是说有经常出差的老师占比并不高。 那做移动端的调课功能是需要经常出差的老师的痛点吗? 在实际调研中发现平均每周学校的调课记录有十几条,说明调课在学校使用中是一个较高频的场景,作为经常出差在外的老师来说,有这个移动端调课功能的确是能方便不少。 但在当时我们还没有开发移动端的APP,即使要实现周期也很长,所以这个需求并没有被采纳。 五、服务 = 产品 + 人 这时可能有人会问,B端的一个客户可能就养活了大半个公司的人,就因为分析后需求优先级不高就不满足客户提的要求了吗? 通常来说若客户对公司足够重要,公司也会尽量满足客户的需求,这时产品经理要各种资源更容易一点,即使再小众的需求也能被提到很高的优先级。 但出现需求不能马上实现的情况又该怎么办呢? 首先,要明确我们提供的是服务,产品只是个外在形式。虽然现在许多B端的产品主推SaaS(产品即服务),这个叫法实际并不准确,我认为对B端的服务=产品+人。 正所谓"产品不行人来补",当产品不能马上很好满足用户需求时,就需要通过运营人员的工作代替产品的不足。 如上面的案例,给出的解决方案是若老师在外有调课需要,可以告知公司的排课人员代为调课,并将调课后结果告知给老师。 别忘了我们之前分析的B端用户特征,他们核心关注的是业务能否顺利完成,至于形式如何是次要的。 六、总结 总结一下,当有突如其来的需求时,我们考虑的思路: 首先,是看我们需求来源——他们是谁?是否为产品的直接使用者?并且B端用户特点是是更关注业务实现效率,他们的行为特征往往更取决于所处职业的集体特征。 其次,需求对应的场景是什么?是否为用户真实要解决的问题场景?解决方案是否仅为一种,是否还有其他方案? 最后,通过分析需求价值公式(需求价值=用户广度*需求强度*需求频率)决定需求的优先级。 最后,B端的服务效果往往取决于产品与人(运营人员)共同努力,当无法通过产品及时解决用户需求时,可以考虑通过人工的方式为用户解决问题。