关于SaaS产品的分类，可以分为通用型和行业型

关于SaaS产品的分类，可以分为通用型和行业型。

• 通用型就是指不限于某个行业的产品，所有行业都可以用，比如CRM、HR、OA、ERP系统等。
• 行业型就是指只针对某个垂直行业来做企业的信息化产品，比如生鲜行业、餐饮行业、金融行业等。

随着SaaS产品的发展，目前我们还可以分为工具型和商业型。

• 工具型就是指我们只是给企业提供一个信息化的工具，可以给企业增效降本，但是具体如何操作，需要企业自己去摸索，就好比某个人肚子饿了，我只负责提供餐具和炊具，至于如何解决肚子饿的问题，管不了。
• 商业型就是我们需要让企业成功，需要深入到企业的业务里面去，帮助其打通上下游链路，最终帮企业创造价值并获得商业成功。比如企业是一个药店，我们需要帮助药店提升利润，帮助其赚到钱。前面说的那个肚子饿的问题，在这里就是需要给那个人提供丰盛的食物，而不仅仅只是给他提供工具和食材那么简单了。

三、商业分析

关于如何分析SaaS产品的商业环境，有一个模型可以用，即波特五力模型：

• 现有竞争者——就是你选择的赛道，目前跟你一起跑的产品。
• 新入竞争者——新加入你这个赛道的产品。
• 替代品竞争者——就是客户可以不用你这个产品，改用其他解决方案，同时有其他产品可以提供这种解决方案。
• 供应商议价能力——这个其实是指做这个产品的成本，主要还是人力资源成本。
• 买家议价能力——客户购买你这个产品的意愿，关键还是续费的动力。

前期需要对负责产品的商业环境进行充分了解，可以询问高层及其他决策人员，也可以直接问产品经理。

四、协助产品

这个过程主要是协助产品经理完成一些工作，包括参与对需求进行分析等。

1. 梳理产品目标

目标是第一位的，有了正确的方向才好沿着正确的道路一直走下去。

我们可以先了解行业背景，比如我们的产品是属于哪个行业的，或者是针对多个行业的通用产品。另外可以了解下我们服务行业的上下游全链路，我们是处于末端环节、中间环节、还是头部环节。有了这些准备工作后，开始重点了解目标了。

目标其实有很多，企业在不同的发展阶段，其目标也是不一样的，比如某年的目标，以及拆分到季度和月度的目标，另外还有3到5年的战略发展目标等，这个目标我们也可以理解为商业目标。我们的用户也有用户目标，就是用户希望通过使用这个产品达到一个什么期望。有了这么多的目标，也不是全部都要遵守的，这个时候产品经理需要去平衡商业目标与用户目标，最终得出产品需要遵循的目标，即产品目标，以此作为后续工作的指导思想。

作为交互设计师，我们主要是参与这部分工作，用自己专业的交互知识帮助产品经理去梳理出最终的产品目标。

2. 梳理业务流程图

这里需要分两种情况，如果是0到1的产品，我们需要分析线下的实际业务流程，先梳理出来，然后考虑要是搬到线上解决时，应该如何来设计业务流程。

如果是1到N的产品，应该已经有了业务流程图，我们要做的就是去熟悉，了解产品的业务流程；如果没有，我们要做的就是对照实际系统去梳理出业务流程图。

做这个工作的最主要目的还是帮助我们先有一个全局的产品感觉。

3. 梳理功能架构图

同上，这里也需要分两种情况，0到1的产品，可以先对需求文档进行分析，将里面的功能点提炼出来，绘制功能架构图。如果需求文档编写还没有开始，则可以参与对需求进行处理，并细化成功能点，然后再绘制功能架构图。

关于需求搜集，我们一般是把零散的需求丢进需求池进行管理。关于需求处理，则可以用需求四象限法则来处理。这个方法需求分析师和产品经理用的多，主要是对需求池里的需求进行优先级排序，十字轴里面纵向代表紧急程度，横向代表重要程度。重要又紧急的自然是优先处理的，以前很多体验问题都被放在不重要不紧急的尴尬位置，随着体验时代的到来，体验估计会被提升到战略高度。

1到N的产品，功能架构就比较简单了，对着需求文档或者对着实际系统去梳理出来就行。目的就是让自己对产品的整体功能点有个大致了解。

4. 整理权限说明、字段表

我个人觉得，在需求文档中，这部分内容属于底层的部分。可以对产品写好的需求文档进行分析，提炼出权限说明和字段表。如果产品写的需求文档中没有此部分内容，则需要找产品经理面对面沟通了，这样做主要是了解产品的底层逻辑。

5. 协助完成PRD文档

如果产品经理已经完成了PRD，我们就用自己专业的交互方法去协助产品经理优化PRD文档。如果产品经理没有开始写PRD，就可以用以上几步去协助产品经理来编写PRD文档。

主要是业务规则、输入输出等的编写。