项目和SaaS,一直是B端产品从业人员谈论的热门话题。同样被称为B端产品经理,谈到传统定制项目,标签都是乙方、定制化、实施交付、体验差、服务差等等,而谈到SaaS,标签就变成了商业化、标准化、注重用户体验,如此巨大的差异标签,也让作为大客户定制项目产品的我心向往之。
经历过两年多定制项目的经历后,我也顺利地切换到了公司的SaaS产品线,虽然同为电商OMS产品,但是不管是在产品方案设计上,还是对产品人员的能力要求、协作方式上,都与定制项目有着不小的差异,在SaaS赛道上,我看到了不一样的风景。
一、市场和客户是产品的指路灯
传统IT项目,客户和软件系统是点对点,客户业务需求非常明确,在这种情况下,客户作为付费方,做什么、怎么做,按照客户的要求来执行,是软件供应商最明确的选择。
而SaaS有别于定制项目非常重要的一个特征,就是其面向的客户是一个群体,这个群体对于软件产品的需求,有一些共性的特征。从这个方面讲,SaaS产品虽然是to B的软件系统,但是其理念更趋近于面向C端用户的APP,因此想要做好SaaS产品,就需要借鉴C端产品的分析方法论。
C端产品,在产品落地的前期,会对市场和用户尽可能做详细的分析,前者会根据SWOT等方法论,输出行业/市场调研报告,后者则是通过描绘用户画像,来将面向C端的用户群体进行具象化,从而更好的进行后期落地工作。
因此,SaaS产品在落地之前,同样要对市场和客户群体进行分析,从而确保产品首先要定位好想要服务的客户群体。进而通过对客群的所属行业、业务规模、组织人员配置等一系列指标的抽象,描绘出SaaS产品对应的客群画像,进而才能够设计出符合这个客户群体的产品。
清晰的客群定位,不一定能让产品成功,但是如果没有一个清晰的客群定位,就会导致产品设计的时候,偏离客户。
例如:在过往针对大客户的定制项目时,我们习惯将功能按照岗位职责进行拆分,但是如果SaaS产品面向的客户是小客户,人员配置少,一人兼顾多岗位,此时同样的功能设计,会为小客户带来大大的不便。
二、团队协作是支撑产品良性运作的灵魂
传统的IT项目,销售和实施是割裂开的,销售的提成,与合同直接关联,至于后续交付时的过程与结果,却没有那么重要。这也就造成销售团队竞标时画的饼,最终都变成了实施团队交付时流的泪。
其次,大部分的定制项目,除了关键的项目经理、开发、产品、测试这几个核心岗位,其他相关的人员基本没有保障,所以经常出现项目人员身兼数岗的情况,整个项目管理过程,也非常乱。
而SaaS产品线,除了在人员和岗位配置上,进行了非常细分的配置,包含了售前、销售、运营、产品、开发、测试、实施、服务等岗位,人员各司其职,同时各个岗位之间的协同方式以及运作方式,也大大的不同。
首先,售前和销售的目标不在以签订合同为重要权重指标,续费率同样变成了关注的重点,正因如此,销售团队需要结合产研团队的现状及规划进行客户匹配。
其次,岗位人员配置齐全,专业的人做专业的事情,运营负责接受和处理客户的需求和问题,产研负责需求落地,测试负责保证产品质量,实施负责新客户的前期实施和运维工作,服务团队负责老客户的运维工作,整个团队井井有序,大大降低了产研团队在琐碎事情的精力投入。
此外,对于需求的生命周期管理,也越来越趋向于C端的精细化管理,运营接到客户需求后,进行第一层过滤后流转至产研团队,需求经历了第二次过滤后,才会进入产研阶段,大大降低了无效投入。
为了保证需求的开发质量,在测试完成后,会有版本的灰度发布,优先选择当前版本发布需求提出的客户方,作为灰度发布的客户,在灰度发布后,产研团队可以及时跟近需求的质量,从而确保在正式发布后,能够带来较好的用户体验。
三、实施运维的成本,决定了SaaS产品的下限
产品业务兼容性决定了SaaS产品的上限,而实施和运维的成本决定了SaaS产品的下限。大型定制项目,面向单一客户,客单价非常高,因此虽然资源投入多,但是仍然可以维持正常盈利。
但是SaaS产品,往往面向的都是中小型客户,其特征是客户数量多,客单价低,由此就带来一个问题,如果单客户实施成本居高不下,那么产品是很难盈利的,甚至还会处于亏损。
因此,产品经理在设计方案时,不但要注重产品兼容性设计,产品的易用性以及易维护性同样是产品关注的要点,通过操作引导、个性化配置、详细的操作手册等方式,可以大大降低整个产品的实施成本,进而确保SaaS产品的盈利能力。
虽然SaaS产品虽然和定制项目产品在能力要求等方面有着区别,但是两者都对产品经理的业务能力最为看重,因此有意从定制项目产品转行到SaaS产品的小伙伴,可以在工作中着重思考差异点,以便于构建自己的能力模型,为后续的职业规划带来更多的选择。
给作者点赞,鼓励TA抓紧创作!
来源:https://www.woshipm.com/pmd/5290578.html
本站部分图文来源于网络,如有侵权请联系删除。