1.业务场景究竟是什么?
如何定义业务场景?这是进行产品设计时第一个回答问题。
在定义场景时,不仅仅是简单的说一句用户在什么情况下使用这个功能,这样的描述还是太简单,对于业务场景的描述需要更有颗粒度,用程老师的话说就是:“我要把这个产品给你描述完,立马你就有画面感的,才叫场景。”
怎样才是有画面感的场景描述呐?关键在于,能够包含七个要素,分别是——
用户、环境、动机、目标、介质,交互,动作。
只有包含这七个要素,才能够叫做有“画面感”的场景描述。你对业务场景的理解,能否到达这个颗粒度,会对你的产品设计结果带来很大差异。
在有赞内部,发生过很多次类似的事情,产品经理们因为对于业务场景理解的不同,会提出完全不同的解决方案。
比如说,现在让你给有赞设计一个店铺装修功能,你会如何做? 通用的解决方案可能是:
给商家做好基础功能,商家在后台可以自由的搭配界面,拼装颜色,调整图片大小尺寸。他能够把有赞店铺像装修淘宝店铺,京东店铺一样特别好看,这样,无论什么时候来,不同的店铺都能够有不同的主题。
这个方案确实是有效,他也确实是”店铺装修“,但它真的是最适合用户的解决方案吗?
要回答这个问题,仍旧应该是回到原点——清晰描述客户的业务场景。
这个过程,其实就是思考什么样的用户需要这个功能?什么时候需要这个功能?他想要这个功能解决什么问题,实现怎样的效果?通过怎样的方式解决这个问题?为了解决这个问题他需要使用怎样的介质?这个过程中要执行怎样的动作?
回到店铺装修这个问题上,对于有赞的商家来说,他们使用店铺装修功能的场景可能是,头部的20个品牌商家,在春节期间,为了决定突出品牌调性,获得更多的用户认可,同时为了增强跟顾客之间的这种互动,提高大家对他的好感度,所以他决定在春节期间上线一些新的活动。同时把它整个的页面设计的更符合春节的这种气息一些。于是它在后台里面选择了一套模板,并安排美工,设计一些符合这种气息的这种图片上传到后台里面,来达到这样的效果。
在这个回答当中,大致将刚刚提到的七个要素体现出来。这时,我们会发现,其实特别自由的店铺装修功能可能并不最合适,节庆期间的活动,如果店铺装修太过复杂,只会让商家感到反感。他们需要把大量的时间花在店铺装修上,针对于时间就是金钱的大促来说并不值当。而且,这样繁复的装修,在日常使用当中却又使用不到。
最终,这个功能的方案是,只设置针对不同节庆的基础模板,商家可以自己上传图片,符合节庆的氛围。但是,店铺的具体样式并不能调整。
当然,具体的功能设计,当然还有很多考量,我们这里只是简单的讨论,业务场景理解对于产品设计的价值。
2.产品价值是什么?
对产品的业务场景有了基本的理解之后,第二步可能需要理解一下,你的产品或者功能,对于用户的价值究竟是什么?
一般而言,对于To B类的产品,用户价值这件事无非两点 :
- 商家的经营效率是否提高?
- 商家的经营效果是否提高?
用户使用你的产品,工作效率是不是提高了、是不是能够赚到更多的钱,这两条是评判SaaS产品的核心标准。
如果在这两条中,一条都不占,那么,你这个需求可能就没法上了。
有赞内部之前经常有类似的需求,对于他们自己来说是有价值的,但对于商家而言,可能并不能提供价值,这时,也是考验产品经理的产品设计水平的时刻。
还是以有赞为例。
有赞运营曾向产品提出过这样一个需求,希望在商家注册或者使用付费功能时,能够填写自己的经营类目。
比如说,你是一家水果店,那么就在注册时,填写自己的类目为零售。你是一家按摩店,就填写自己的类目为服务。
之所以需要增加这一步,是为了有赞能够对于自己服务的商家有更全面的了解,之后能够提供更为优质的服务。对于商家来说,凭空在注册流程中增加这一步,短期之内他们的经营效率没有太大的帮助,而且,反而会增加操作成本。
但是,另一方面,这个需求也确实对于有赞有价值,所以也不可能直接把运营的需求拒绝掉。
这个时候,就需要产品的同学能够提出更有效的解决方案。
最后采取的方案是,让内部的数据同学,把同一商家ID下面的商品名称数据进行分析,进而得出商家的类目。
商家在使用有赞SaaS时,一定会录入商品名称,比如说水果店就会有苹果,香蕉,哈密瓜等商品名,便利店可能就会有各种饮料,零食等商品。这些商品的名称基本都是独有的。
数据同学可以在后台抽样选择20个商品,看看商品名称都落在哪个类目,进而推断商家所处的类目,这样,不仅能够得出不同商家的经营类目,而且从结果上看,反而比商家自己选择自己的经营类目更加精准一些,对于运营的同学更有价值。
而这样的案例,其实对于有赞来说时常发生。对于SaaS产品,很多功能或许是需要做的,但是,究竟是否可以做,则需要反复思考,这个功能是不是真正能够为用户提升价值,如果不能,我们倾向于不要做,这也是在SaaS产品中第二个关键的问题。
3.如何判断功能的优先级?
最后,当你开始有大量的需求之后,应该如何判断产品功能优先级?
针对这个问题的解决方案,无论是在C端还是在SaaS,判断准则都差异不大。 大致的判断标准基本都是公司战略重心、行业发展趋势、资源限制以及收入等要素来考虑。
关于如何进行宏观的考量,此处就不再过多赘述了。
4. 一个优秀SaaS产品经理的判断标准
对于产品经理而言,其实无论是在C端还是B端,能力要求都是近似的,大约都是这样一个框架——
1. 首先是需求分析产生的能力。我们对于业务场景的理解,对于产品价值的判断,这些前置性的思考,其实都是基于产品的理解和思考。这是一个基础能力,通过这种方法,形成产品需求;
2. 第二个就是产品设计的能力。很多C端的产品经理,会将产品设计能力定义为UI设计能力,交互逻辑的设计能力以及一些流程或者细节的优化。坦率来说,我认为这个能力在SaaS解决方案里面是最不重要的。对于SaaS而言,最重要的是能够提供可用的解决方案,产业互联网的第一优先级就是可用。没有做到可用,但是足够好看,是无法解决本质问题的。所以,这里的产品设计能力,特指的是能够针对所服务的行业提出可行的解决方案的能力;
3. 第三个是项目跟进的能力,就是你是否有能力主导整个项目,它能够如期按时交付,能够组织大家所有的参与者按照设定的目标推进并最终实现它,甚至是提前上线等等;
4. 最后一个就是对行业的敏感能力,这是一个很重要的能力点,为什么说它重要?因为对于前三个能力来说,其实都有清晰的方法论,是可以训练,可以交付的,包括三节课正在开设的课程都是在解决这个问题。
但是,行业敏感度很难进行批量的训练,它有一个前提是你对这个行业要有足够的热爱,如果做不到这一点,后续都很困难。在热爱的基础上,可能需要你学习和训练一些信息获取的能力、分析调研的能力、以及全局的思考能力等等,通过对行业的掌握,最终获得这项能力。
总结
在与程老师的交流当中,我们会有这样一个感觉或认知:对于一个SaaS产品经理而言,最重要的能力或技能,并非产品设计,而是能够提出一个好的“解决方案”的能力。
好的“解决方案”并不等于好的“产品”。或者说,好的产品只是诸多解决方案的一种。
就像前文中提到的例子,既要解决运营的问题,又不打扰用户,在这个过程中,考验的就是产品经理能不能跳出产品的思考框架,真正从解决问题的思路去思考。
根据艾瑞咨询发布的报告显示,国内SaaS市场在2014-2015年经历了短暂的爆发式增长,增速分别高达71.3%和65.4%。从2016年开始,SaaS市场进入相对理性平稳的发展阶段,将保持30%-40%的按年增长率。预计2020年国内SaaS市场规模将达到473.4亿元,未来发展空间十分广阔。
对于许多产品经理而言,今年SaaS企业可能也会逐渐成为他们职业选择的一个方向,而这个方向究竟是不是适合你,初入这个行业的你,又该如何做?希望今天的这篇文章,能够带给你一些帮助。
最后,这是三节课产品学院研究院出品的首篇内容,我们的研究院致力于关注行业新兴岗位、动态、方法等一系列相关信息,关于to B的内容,后续还会有一系列研究,敬请关注!