SaaS产品经理进阶

SaaS只是一种产品形态。一起来学习SaaS产品经理知识与进阶，适合ToC产品经理向SaaS产品经理的转型。（本导图有两页）

• • 来自公众号本源社 1.关于架构与功能
• • 产品设计
    • 梳理业务流程
    • 梳理页面元素及交互
    • 面对多个类似需求
      • 先梳理框架
        • 理解业务模块的边界
      • 再设计功能
        • 解决用户的需求
  • SaaS业务需求个性化的本质原因是场景不一样
    • SaaS产品有非常抢的业属性
    • 如果缺乏框架思考 单点设计功能将会让你精疲力竭
  • 缺乏框架性思考
    • 内部
      • 不断地堆砌功能，开发成本会越来越高
    • 外部
      • 用户所需信息繁杂，无法高效完成任务
  • 如何解决
    • 设计功能前需要厘清【架构】
    • 以一种抽象的框架视角来全局思考
• • 什么是架构
    • 架构是一套将功能依据业务进行分类整合形成的抽象画的业务模型
    • 架构可以帮你厘清每个业务模块/功能间的便捷，以及他们之间的关系
    • 理解业务是梳理功能架构的前提
• • 架构的作用
    • 标准化
      • 梳理一套标准化业务模型，搭建框架
    • 低成本
      • 最终是为了高效满足用户的不同需求
    • 后端标准化，前端个性化
• • 来自公众号本源社 2.SaaS通用的架构
• • 通用架构
    • 商业活动的通用架构
    • 管理活动的通用架构
• • 业务目标
    • 商品管理
      • 让商品有更好的卖相，同时高效管理商品
    • 订单管理
      • 了解商品的销售情况，产生最大化创收
    • 客户管理
      • 让熟客产生的复购和推荐，同时高效管理
• • 商品管理模块
    • 商品管理
      • 上架商品的增删改查等基础操作
    • 商品分类
      • 商品的分类与加标签，便于管理
    • 商品包装
      • 商品介绍的包装和展现
    • 库存管理
      • 商品库存、采购订单的管理
    • 商品信息
      • 管理最基础的不同类型的商品信息
• • 订单管理模块
    • 订单详情
      • 订单列表的查看，支付产生的新订单
    • 订单处理
      • 正向交易有关业务： 实物发货/到点核销，取消订单
    • 订单退款
      • 逆向交易有关业务： 交易后处理退款/退货等
    • 评价管理
      • 处理评价/维权等
• • 客户管理模块
    • 客户管理
      • 客户信息的基本信息管理，包括增删改查
    • 客户运营
      • 查看客户人群情况，进行场景化营销
    • 客户权益
      • 厘清不同等级客户所享有的权益，以及不同等级成长值设置
    • 客户分群
      • 客户的分群与标签，便于Push
    • 客户积分
      • 厘定客户的积分消费规则
• • 采购管理
• • 库存管理
• • 店铺管理
• • 物流管理
• • 大部分模块都是基于这三个模块生长起来的
• • 管理活动
    • 管人
      • HRM
      • 人是管理活动的基石
    • 管事（项目）
      • OA
    • 管资源
      • ERP
• • SaaS产品的架构是“长”出来的
• 会员管理
• 营销管理
• 资金管理
• 数据表盘
• • 订单管理
  • 订单详情
  • 订单处理
  • 订单退款
  • 订单评价
• • 商品管理
    • 客户管理
  • 商品管理
    • 客户管理
  • 商品分类
    • 客户运营
  • 页面模板
    • 客户权益
  • 库存管理
    • 客户分群
  • 商品信息
    • 客户积分
• 四、SaaS产品设计——架构与功能

• • 来自公众号本源社 3.如何梳理符合业务的架构
• • 梳理架构三步走
    • 将场景需求清单拆解到功能
      • 借助流程图梳理
    • 将功能按不同维度进行分类整合
      • 找到符合通用模块的功能
      • 归类整合，切忌重复造轮子
      • 非通用模块单独整合
    • 梳理模块之间的逻辑关系
      • 先梳理静态模块（不产生数据流）
      • 再梳理动态模块（产生数据流）
• • 工资管理 发放工资 查看详情 审核工资
• • Tips
    • 每一个功能需明确解决一个具体的业务问题
    • 表面上是数量架构图 背后是对业务深刻的理解
• • 4.基于架构设计功能，满足个性化需求
• • 如何设计一个功能满足绝大多数的需求？
    • 运用【可配置】：解决两种层面问题
      • 前端：简洁高效，元素清晰，满足不同用户的业务需求
      • 后端：配置项归类清晰
• • 如何运用可配置高效满足个性化需求
    • 业务流程与现有方案差别小
      • 从功能层面进行配置
    • 业务流程与现有方案差别大
      • 从系统层面进行配置
• • 高可用配置的误区
    • 高可用配置会造成低易用性
      • 配置过多会带来页面不简洁，流程不高效
      • 用户要的不是配置项，耳屎低成本实现目标的功能
    • 高可用配置会带来极高的开发成本
      • 配置项没有高效实用，是对开发资源的浪费
• • 判断功能要不要做成配置项的四象限参考
• • • • • 高
          • 模式切换频率
• • 弱
• • • • • 低
• • 如何设置默认配置项
    • 回归【场景】
    • 基于核心场景下的需求提供默认配置项
• • SaaS产品设计的原则
    • 产品定义
      • 回归场景是一切的基础
      • 好的产品满足用户价值并带来商业价值
      • 产品模式必须是持续正向增长的
    • 产品设计
      • 最小可用需求满足所有角色核心场景下的需求
      • 每个客户都应该是独立的、个性化的
      • 产品结构及呈现方式需要可延续、可拓展
    • 产品研发
      • 系统稳定是前提
      • 文案要说人话，拒绝设置专业门槛
      • 永远保持一致的表达方式
    • 产品运营
      • 不轻易下线任何一个功能
      • 先有，再高效，然后易用，最后好看
      • 不骚扰客户
• • SaaS产品的架构是“长”出来的
• 少数用户不一样， 模式之间切换频率高 考虑做成付费功能
• 多数用户都不一样， 模式之间切换频率低 考虑投入产出比，低沉本满足
• 少数用户不一样， 模式之间切换频率低 不需要做成配置项
• 强 需求长尾程度
• 多数用户都不一样， 模式之间切换频率高 可以做成配置项
• 四、SaaS产品设计——架构与功能