|
项目和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产品的小伙伴，可以在工作中着重思考差异点，以便于构建自己的能力模型，为后续的职业规划带来更多的选择。
注：文章及图片转载自网络，如有侵权请联系删除
|
