决胜B端 - 产品经理升级之路 - 管理篇

B端产品经理、产品运营、业务运营三者的工作职责往往有交叉和重叠，需要理解三者的工作目标、工作方式。希望本思维导图对你有所帮助！

决胜B端 - 产品经理升级之路 - 管理篇

• 11 B端产品的数据分析
  • 11.1 数据分析的流程
    • 11.1.1 明确主题
      • 主题比较泛化时，需要将其细化、明确
    • 11.1.2 提出假设、验证假设
      • 数据分析就是不断提出假设、验证并修正假设，最终获取真相的过程
    • 11.1.3 得出结论
  • 11.2 数据分析的要点
    • 11.2.1 方法工具
      • 统计学：掌握基本统计学尝试，理解方差、均值、中位数、众数等概念
      • Excel
      • SQL：快速提取原始数据，并完成数据预处理
      • 数据可视化：瀑布图、直方图、桑基图等
      • 计算机数据基础：编码基础知识（ASCII、UTF-8等），常见数据存储格式（CSV、JSON、XML等）
      • 正则表达式
      • 数据分析方法论，AARRR、RFM、COHORT等
      • 高阶：Python、SPSS、ETL、数据仓库等
      • 参考书籍：
        • 统计学：《深入浅出统计学》
        • 数据分析：《深入浅出数据分析》
    • 11.2.2 业务知识
      • 行业知识、领域知识、公司商业模式、运营流程细节
    • 11.2.3 细心耐心
  • 11.3 数据分析报告
• 10 B端产品的迭代优化
  • 10.1 B端产品的需求管理
    • 10.1.1 需求的收集
      • 需求收集要点
        • 通过各种渠道全面、迅速收集建议
        • 无论采纳与否，都要给出反馈，形成持续良性互动
      • 需求价值判断
        • 需求背后真正的问题是什么
        • 是否有简单快速的解决方法
        • 影响面有多大，是否是个案
        • 优先级和紧急程度如何
      • 解决业务问题，而非用户痛点（怎么理解）
    • 10.1.2 需求池管理
      • 需求池和迭代计划可分开管理维护
      • 主要目的是实现清晰准确的需求管理、迭代计划管理，并做到项目进度透明
  • 10.2 B端产品的迭代管理
    • 10.2.1 迭代中的研发资源管理
      • 需要充分调用并利用研发资源，避免因时间窗口不匹配导致研发资源的闲置
      • 需要维护人力资源安排图
    • 10.2.2 迭代中的技术优化资源分配
      • 日常迭代升级中，必须给技术优化预留足够的资源，不能只做产品功能需求，不做技术优化
      • 初创阶段
        • 重点在于活下去，可以只预留10%资源做技术优化
      • 瓶颈阶段
        • 技术债出现，同时业务需求井喷，一半资源来解决系统问题
      • 重构阶段
        • 系统问题严重，业务需求让位于技术问题，80%资源应进行技术优化
      • 稳定阶段
        • 业务和系统稳定，80%资源用于业务
    • 10.2.3 典型的双周迭代模式
      • 不随意改变需求和计划，是确保功能高质量按期交付的前提
    • 10.2.4 双周迭代模式的局限性
      • 无法保证最小功能集合可以在一个迭代周期内实现
      • 跨端项目协同非常复杂，研发节奏相互依赖
        • 一般是多组人一起开会，通过最终时间倒排节点
      • 很难准确预估工作量投入
      • 变通
        • 复杂跨端项目可以按项目机制来推进
        • 部分需求的上线时间可以灵活调整
        • 不采用双周迭代，只保证每周固定时间评审需求，需求开发与上线节奏不相关
    • 10.2.5 选择合适的迭代模式
      • 瀑布模式
        • 传统软件产品非常复杂，稳定、成熟的管理体系可以保证系统架构的合理性、稳定性
        • 传统企业没有快速迭代的诉求
        • 核心环节
          • 需求分析
          • 方案设计
          • 开发编码
          • 验收上线
      • 敏捷开发是一种理念
        • 本质上讲，敏捷模式是容纳并拥抱快速变化市场环境和商业特征的一种理念
        • 产品经理需要思考的问题
          • 是否有随时接受需求变更的勇气和心态
          • 是否允许存在瑕疵但可以快速支持业务的产品方案去抢占市场
          • 是否会说服研发人员为了快速上线而暂时采用并不合理的设计方案，并在合适的时间窗口帮助研发团队顶住业务压力，给研发团队争取足够时间来重构系统
• 8 B端产品的项目管理与实施工作
  • 8.1 为什么需要项目管理
    • 团队变大以后，需要从作坊式的生产模式转变为标准化、专业化的生产模式
    • 优秀的项目管理
      • 在复杂环境下保证软件开发按计划推进、落地
      • 保障产品研发效率和质量
  • 8.2 互联网项目管理的工作重点
    • 设计并优化项目管理制度
      • 公司发展到一定规模后，就需要制订项目管理制度并严格执行
        • 注意点1：是公司发展到一定规模而非团队，公司发展快会使团队面临复杂的业务和爆发增长所带来的问题
        • 注意点2：管理的本质不变，需要根据公司业务和团队文化特点对业界最佳实践做出调整
      • 合理的规范制度应该既能约束产品研发团队的行为，也能保护产品研发团队的权益
    • 负责大中型项目的立项实施
      • 项目经理需要准确理解整体方案，以及各团队负责的工作范围
  • 8.3 如何对B端产品做好项目管理与实施工作
    • 8.3.1 B端项目管理面临的挑战
      • 容易发生跨端现象：子系统多，各团队负责不同系统，引发跨端现象，导致难以获得其他团队的支持，或是难以取得整体的排期等等；
      • 项目周期长：出现跨端现象或流程改造等复杂需求时，会拉长项目周期，导致各种变数和不确定问题。
    • 8.3.2 如何协调并推动跨端协作
      • 明确项目收益价值
        • 项目收益作为一个目标，是引导项目组聚力前行的重要动力
        • 明确的项目收益预估是说服其他团队认可并配合项目的有力武器
        • 明确的项目收益是决策层进行项目资源调拨时的重要参考依据
      • 找到KP并积极游说
        • 有些时候，产品和项目是自下而上演进的
        • 这种方式的关键是找到关键人物并积极游说
      • 保持强的推动力与执行力
        • 能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果
        • 耐心+技巧
    • 8.3.3 如何把控项目进度
      • 细化工作，明确交付
        • 前提是解决方案本身是正确的
        • 明确责任人、交付物、时间点
      • 通过机制把控进度
        • 例会
          • 进展、困难、计划
          • 提前整理问题
          • 控制会议时间
          • 避免形式主义，可调整例会频率
        • 站会
          • 保证到岗时间
          • 快速识别问题并找出解决方案
          • 严格控制时长
        • 日报与周报
          • 通报进展
          • 警示风险，推动责任人去解决
      • 编写内容清晰的项目日报或周报
        • 目的：争取关注度和资源
        • 内容
          • 本周进展
          • 项目风险
          • 下周计划
          • 整体进度
      • 保持足够的责任心
        • 制度只是提供了工具和方案，还需要成员的责任心来用好
        • 项目经理需要串联起流程，其他人大多只负责各自的部分
• 9 B端产品的运营管理
  • B端产品经理、产品运营、业务运营三者的工作职责往往有交叉和重叠，需要理解三者的工作目标、工作方式
  • 9.1 B端的产品运营岗
    • 分类
      • SaaS方向，偏销售、BD，属于销售管理和客户开发
      • 供给端运营方向（商家、店铺运营）
      • 针对内部业务系统的方向
    • 9.1.1 B端产品运营岗的工作内容
      • 定义
        • 没有公认的定义
      • 目标
        • 通过挖掘B端产品的能力，帮助企业解决业务问题
      • 工作内容
        • 产品功能推广培训
        • 问题解答处理
          • 提供快速有限的服务支持
          • 归纳总结问题，把共性问题提交产品进行优化
        • 需求采集过滤
        • 项目效果分析
        • 业务诊断分析
    • 9.1.2 B端产品运营与C端产品运营的区别
      • 团队定位
        • B端——配合业务部门达成业绩目标的支持团队，间接对业绩指标负责
        • C端——对业绩直接负责
      • 工作目标
        • B端——挖掘产品能力，提升管理效能、改善核心指标
        • C端——帮助提升核心指标，包括用户量、活跃度、转化率等
      • 技能要求
        • B端——业务领域知识、数据分析、文案编写
        • C端——创造性思维、热点时事与新媒体运作、数据分析、文案编写
      • 职业方向
        • 细分领域业务专家
        • 细分行业运营专家
  • 9.2 B端的业务运营岗
    • 9.2.1 B端业务运营岗的管理模式
      • 业务部门分为一线业务单元及支持其运作的业务运营部
    • 9.2.2 B端业务运营岗的工作内容
      • 业务支持
      • 流程管理
      • 策略制定
      • 绩效考核制度制定
      • 培训考核
      • 系统运营
      • 项目管理
      • 合规质检
      • 数据分析
  • 9.3 产品经理、产品运营、业务运营如何高效协作
    • 调整组织架构改善合作关系
      • 方案一
        • 产品部和业务部平级，产品经理和产品运营贵产品部管理
        • 优点
          • 能够统一调度研发资源，避免浪费，和业务部没有隶属关系，一些问题的处理可以对其形成牵制，便于充分讨论
          • 产品有权利和义务在某些时刻跳出业务线，从客户利益和公司整体利益出发，对业务线说不
          • 产品和运营的工作互补
        • 缺点
          • 距离业务有一定距离
          • 容易与业务运营下属的系统运营产生冲突
          • 缺少决策人，两边的冲突需要上升一级处理
      • 方案二
        • 产品运营和系统运营均归属到业务运营下面
        • 在业务模式较重的创业公司常见
        • 优点
          • 控制人力成本，避免工作内容重复
        • 缺点
          • 产品权利弱化
      • 方案三
        • 业务线产品划归到业务部门下，在业务模式较重的创业公司、独角兽公司中被尝试
        • 产品经理直接向业务部门负责人汇报
        • 优点
          • 更加贴近业务
          • 更容易推动方案落地
        • 缺点
          • 判断和决策带有倾向性
          • 缺少全局观
          • 不能最大限度发挥产品经理价值
      • 方案四
        • 基于方案三，产品运营部归属产品部
        • 优点
          • 更多发挥产品经理价值
        • 缺点
          • 缺少牵制力，产品运营不能代表业务运营发声