不知道作为 SaaS 产品经理,你有没有遇到过这些问题?比如客户在使用系统的过程中,会提出各种需求,但实际上只是在向你传输解决方案。
再比如内部沟通时,如何向对方解释,你的思路虽然逻辑上成立,但实际业务场景下,客户并不是这样去做的。
前者是因为提炼对方表达后的关键信息,整合还原成真实的业务场景。而后者是因为在表达过程中,没有结合业务场景去描述需求。
而为了解决这类问题,SaaS 产品经理需要能用场景描述的方式,给予对方强烈的代入感,便于双方基于业务去沟通。
接下来,我会结合工作中的一些思考与感悟,分享一个“讲故事”的方式,希望彼此能得心应手地聊需求。
1、回归业务场景,是做 SaaS 产品的起点
在说讲故事之前,我们先来聊聊回归业务场景的重要性。
01、对外的沟通协调
由于每个人的存在不同的知识背景和思考模式,而我们的目的是基于实际问题做沟通。
因此将业务场景构建成故事,可以保证我们是在解决问题,而非交流彼此的感觉。
这就好比梁宁老师说的,在腾讯内部如果想办成一件事,得不停地像念咒一样念用户体验。
本质是希望我们不要被个人的理解和视角所遮蔽,能站在对方的角度上提出解决方案。
02、对内的思考与分析
我们常说产品经理在做事前,需要明确问题、定义问题,而问题实际是基于业务场景存在的。
任何脱离场景的问题,都是产品经理自己臆想,而非对方提出来的。
而在梳理业务场景的过程,实际上就是在做梳理。
写出来自己多读几遍,或者直接找客户确认,其实目的是保证我们在一开始的方向是对的。
要知道如果理解存在歧义,那么之后梳理的业务流程和产出的原型原型,都需要重新返工,真的费时费力。
03、回归到 SaaS 产品本身
业务脱离场景,即使逻辑上能成立,但终究不能称作产品,因为他不能解决问题。
原来我在设计功能时,直接就是凭借自己的想象画流程图,然后自信慢慢地拿给产品经理看。
结果肯定是不通过,但对方又不会直接告诉你,「你应该先搞清业务场景,再实际动手」。
就这样我一错再错,但又不不知道自己错在哪。
现在想想,对方说一切靠自己动脑筋想,这个固然没错。但是否,你提供一个方向给我会更好呢?
再到后来我通过学习意识到,SaaS 产品的本质是解决企业的业务问题,而业务本身就已经存在。
所以说 SaaS 产品在做的是企业运作流程的还原,而非要去改变。
到这里,你是否理解了业务场景的重要性,尤其是对 SaaS 产品来说,业务场景可以说是命脉。
接下来进入文章的主题,如何像讲故事一样描述场景。
2、产品经理如何讲故事
这里介绍一种通用的场景描述方式,一是为了不遗漏关键信息,二是为了描述地更加丰满、立体,像故事一样。
这里借助 5W1H 的分析法,看看这个场景故事都应该包含哪些元素。
01、场景的 5W1H
(1)角色(Who)
之所以用「角色」代替「人员」,是因为在企业中我们更多地以角色来完成任务,这个也比较好理解。
同时对于 SaaS 产品来说,想要完成一项工作,一定会涉及到对接,也就是工作流中存在多角色。
(2)场所(Where)
可以说场所是场景中最明显的单元,也是很容易混淆的概念。
比如你可以在食堂吃饭,也可以在食堂玩电脑。
食堂这个场景是固定的,但受其他因素的影响,你会做出不同的动作。
(3)时间(When)
客观存在的属性,这也比较好理解。
到点上下班,天黑了要回家,时间和场景是相互交织的关系。
比如中午去公司食堂吃饭,到点了你就必须停下,返回工位工作。
(4)原因(Why)
工作中每个人都有“目的”,也就是为什么要做这件事情的原因。
比如产品上线后,你决定跟进客户的使用情况,决定实际去轮岗。
(5)做什么(What)
而带着上面这个原因,你需要连接他人去完成这件事,无论是选客户,做申请,还是约具体时间。
(6)怎样去做(How)
轮岗说起来简单,但具体去做需要考虑很多的方面,以轮岗为例。
首先是轮岗前需要确认轮岗目的和注意事项,同时需要规划大致的轮岗路线。这一步是确定我去要做什么,做到轮岗的有的放矢。
然后在过程中记录具体情况,调查具体问题,并不断去验证自己之前的假设。重点在于信息的挖掘和采集。
最后就是将信息与对方确认,尽可能保证信息的客观性,在回来之后将结果整理上报。这样就大致完成了这次轮岗。
最后尝试着用这个方式描述一个业务场景。
背景是我们系统支持上级派发任务,下级执行任务,但没有下级上报问题的方式,而目前针对这个问题的业务场景是这样的。
小王是一名店长,每天上班都会检查门店情况,为了便于留证,有问题则需要及时上报给上级人员知晓。
02、观察和验证你讲的故事
讲故事最容易出现的问题,就是借助自己的想象力,补全故事的细节。
这点对于 SaaS 产品经理来说,尤其需要警惕。
要知道, SaaS 产品的场景都是真实存在的,是需要在真实业务中去验证的,也就是在你描述完之后,别人是否有清晰的画面感。
如果对方觉得他实际工作中不是这么做的,那这个时候就需要警惕了,接下来需要进一步的跟进,去确定哪部分细节有问题。
举个例子
小明是一名督导,上级安排他每周完成 10 家门店的巡检,当他到了某家门店后,打开 App 开始执行任务,提交后就去下一家门店继续巡检。等门店全部巡检完,再将每家门店存在的问题标注出来,提交并让店长完成整改。
这是我最初的理解,但后来才发现是我理解的有问题,实际上他们是边巡检边发起整改,提交后店长马上进行整改。
因为大多数情况,巡检多家门店不可能一天完成。
这就是我想当然地描述场景,造成业务理解上的偏差。
写在最后
因此在业务调研时如何能回归业务、梳理场景,最后以讲故事的方式与其他人沟通,这需要不断刻意的去训练。
这个过程,会不断培养提高我们对业务的理解。
但这种理解是抽象的,而方法论只是一个拐杖,更重要的是我们在实践中加深自己的理解。
希望你我能都能借助这个拐杖,让这些方法论成为我们做事的习惯。