决胜B端

决胜B端：B端产品也叫2B（to Business）产品，使用对象是企业或组织B端产品帮助企业或组织，B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担这为企业或组织提高收入，提升效率，降低成本，控制风险的重任。

决胜B端

• 通用的企业级应用架构设计
  • 企业级应用架构设计的建议
    • 业务定位和边界要清晰
    • 系统要实现松耦合、高内聚
    • 不要让易变的新业务影响现有业务的稳定性
    • 系统之间要实现数据的单向流转
    • 综合考虑架构的合理性和业务发展的需要
    • 优秀的架构师和 CTO 要懂得在合理架构设计和灵活多变的业务需求之间做出权衡
    • 深入思考新系统与旧系统的关系
• B端产品的数据分析
  • 数据分析的流程
    • 数据分析的方法论很多，从本质上讲，可以将数据分析的过程抽象为四个步骤（如图 11-1所示），分别是明确主题、提出假设、验证假设、产生结论
  • 明确主题
    • 任何数据分析工作都需要有一个明确的主题，即数据分析工作的目的或目标。
  • 数据分析的要点
    • 做好数据分析工作需要三个核心要素，分别是方法工具、业务知识、细心耐心，三者缺一不可。
• B端产品的迭代优化
  • C端和B端的需求的产生背景和动机完全不同，前者是为了解决用户痛点，而后者是为了解决业务问题。
  • 需求池管理
    • · 业务线：描述需求所在业务线（或对应的系统），例如 CRM系统或客服系统等。
    • · 需求类型：需求类型包括以下可选项：
      • 产品需求、产品需求（插入）、技术需求、技术需求（插入）、线上Bug
      • · 主题:需求的一句话概述。
      • 内容:需求的具体描述。
      • · 来源:需求的提出者，比如来自一线的某员工，或业务运营部某同事。
      • 需求提出日期:收到需求的日期
      • · 优先级:优先级是管理需求迭代计划的重要判断依据。
      • · 迭代版本:如果采用了敏捷开发模式，就需要标记需求排期开发时的迭代版本。
      • 业务负责人:涉及业务规则调整、流程变更及核心功能变化的 B端产品，需要有业务部门相关负责人确认并一同推进
      • 产品经理:负责跟进并管理需求。
      • 研发负责人:研发负责人一定是研发的整体负责人，而不应该分成后端负责人、前端负责人，因为那样很可能导致两者各自负责自己的工作，但是对于技术实现的整体方案和进度没有把控，相当于没有技术负责人。
      • · 测试负责人:如果研发负责人全权管理研发、测试工作，则不需要单独指定测试负责人。
      • · 状态:状态用来描述需求的生命周期，状态值可以包括如下选项：待跟进、需求调研,PRD编写，待prd评审，待技术评审，待排期，待开发，开发编码，待测试，测试验证，待验证，待上线，已上线，挂起，拒绝。
      • 计划上线日期：计划上线日期是在技术评审结束后，研发负责人确定工时和资源投入后给出的目标上线日期。
      • 实际上线日期：实际上线日期是系统的真正上线时间。
      • 前端开始日期/前端结束日期。
• B端产品的项目 管理与实施工作
  • 如何协调并推动跨端协作
    • 明确项目收益价值：任何项目都应该提前预估收益和投入产出比，从而判断是否有必要推进项目。
    • 项目收益作为一个目标，是引导项目组聚力前行的重要动力。
    • · 明确的项目收益预估是说服其他团队认可并配合项目的有力 “武器 ”。
    • · 明确的项目收益是决策层进行项目资源调拨时的重要参考依据。
    • 找到 KP并积极游说
    • 保持强的推动力与执行力
  • 如何把控项目进度
    • 细化工作，明确交付
    • 通过机制把控进度
    • · 开展定期会议（例会）：定期将项目的各方参与人员聚在一起，回顾上一次会议以来的进展、遇到的困难、下一次会议之前的计划，这非常有必要。
    • ➢ 项目的各方核心参与人员必须准时出席会议，不能随意请假。 ➢ 请参会各方在会议前整理好问题，这样讨论才会高效。 ➢ 控制会议时间，不宜过长或过短。 ➢ 例会一旦确定下来，就必须切实贯彻执行，不能三天打鱼两天晒网。 ➢ 例会不能太过僵化或形式主义，否则会让人厌烦，效果差。
    • ➢ 可以根据不同阶段的节奏对例会的周期做出调整，例如，项目初期每周一次，项目中期两周一次，项目尾声每周两次。
    • · 开每日站会：站会是敏捷开发中经典的工作方式，对于软件研发项目，在团队内部开每日站会的确是非常有效的工作机制。
    • ➢ 每日站会可以保证团队成员的到岗时间不会太离谱（站会的开始时间不能太早，也不能太晚）。
    • ➢ 每日站会可以保证团队快速交流一下前一天遇到的问题和当天要做的工作，快速识别问题，找出解决方案。
    • ➢ 严格控制时间，不能太长，否则容易降低效率。
    • · 形成日报或周报：需要形成项目日报和周报，并发给项目的所有相关人员。
    • 编写内容清晰的项目日报或周报
    • 项目经理要利用项目日报或周报来争取关注度和资源，解决项目中遇到的问题。
    • · 本周进展：简明罗列本周的重要进展。 · 项目风险：一般会用红色加粗文字罗列遇到的项目风险和可能的解决方案，可以 @相关人员强调某些要求。对近期已经解除的风险，可以保留描述，但用删除线划掉。 · 下周计划：简明罗列下周重点工作，以及每项工作的负责人和要求完成时间。 · 整体进度：通过 “甘特图 ”或其他形式说明整体项目计划和关键里程碑，并标记目前项目完成度。
    • 保持足够的责任心在把控项目进度时，团队的责任心，尤其是项目经理的责任心是非常重要的影响因素。
• B端产品的细节方案设计
  • 业务调整的灵活性取决于软件系统的灵活性，而软件系统的灵活性取决于业务数据模型的可扩展性。
  • 业务数据建模能力体现的是设计人员对客观世界的抽象描述能力，只有对业务本质理解透彻，再结合积累的软件设计经验，才能抽象并构建出合理的业务数据模型。
  • 页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。
  • 尼尔森十大可用性原则
    • 反馈原则（ of system status）系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。
    • 隐喻原则（ between system and the real world）系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。
    • 回退原则（ control and freedom）用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。
    • 一致原则（ and standards）同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致。
    • 防错原则（ prevention）系统要避免错误发生，这好过出错后再给提示。
    • 记忆原则（ rather than recall）让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。
    • 灵活易用原则（ and efficiency of use）系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。
    • 简约设计原则（ and minimalist design）对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息
    • 容错原则（ users recognize， diagnose， and recover from errors）错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。
    • 帮助原则（ and documentation）对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引现
  • 报表设计与应用流程
    • 构建分析体系:之所以设计报表，往往是因为需要针对某个业务主题或业务诉求进行监控和分析。
    • 定义观察指标: 理清了分析框架和思路，下一步要确定观察指标，设计具备明确业务含义的指标来考量业务
    • 设计呈现形式:确定了观察指标后，我们要思考以什么形式呈现这些指标，以便用户能够准确、快速地理解、掌握指标以及变化特征
    • 跟踪指标变化:管理要用数据说话，报表数据就是诊断和决策的依据
    • 分析变动原因:如果指标发生了明显的波动，需要跟进分析波动的原因，分析工作可以由数据分析师完成。
    • 跟进处理问题:分析出问题后，下一步当然是给相关部门或人员安排工作，解决问题，这也是报表设计的初衷。
  • 什么是数据埋点
    • 数据埋点的流程数据埋点的流程一般包括申请分析网站账号、获取埋点代码片段、将代码片段埋入网站或 App、观察分析数据.
  • B端产品与C端产品数据埋点的区别
    • B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据。
    • C端产品通过数据埋点来持续优化设计
  • 数据权限设计
    • 针对数据权限的控制，常见的实现方案如下。
    • · 方案一，通过组织机构树控制。该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。
    • 方案二，通过客户地区控制。
  • 文档编写与管理
  • 文档管理要点
    • 一般来讲，我们常常按如下格式对文档进行命名：公司缩写 +事业部 +文档名称 +版本号
  • 跨部门流程图
    • 跨部门流程图是一种相对复杂的流程图，可以清晰准确地描述分角色、跨系统的业务流程，
    • · 开始、结束节点必须用专门的图形（多边形和椭圆形）来表达，这样容易让阅读者较为轻松地识别开始和结束的位置。
    • · 每个流程只有一个开始节点，但可以有多个结束节点。
    • · 尝试调整泳道的顺序，以便保证流程看起来清晰干净，而不是交叉、缠绕在一起。
  • 状态机图
    • 状态机图（ Machine Diagram）也叫有限状态机图（ State Machine Diagram），是一种描述所有状态及状态之间流转规则的图形。
    • · 状态值必须是有限的集合，状态的所有枚举值（即状态值）必须能够涵盖所有实际可能的情况。
    • · 状态值之间要互斥，不能出现二义性。
    • · 为了更准确细致地描述事物，状态还可以具备子状态，比如订单状态 “已取消 ”，可以定义对应的子状态 “客户取消 ”“商家取消 ”“系统取消 ”
    • · 状态应该是能持续一定时长的，而不应该是很快就会结束的瞬时态。
  • 活动图
    • 活动图（ Diagram）是流程图的一种，用来描述一系列过程
  • 用例图
    • 用例图（ Case Diagram）从用户视角来描述系统的操作功能。
• B端产品与C端产品业务调研的区别
  • 产品定位
    • 产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持。
• B端业务调研的目的和分析框架
  • 一是梳理业务现状，二是总结业务问题
  • 准备好访谈大纲提前准备好访谈思路、大纲、问题，选好访谈对象，想清楚通过访谈想要了解什么
  • 从高级别人员开始访谈
  • 提前研究访谈对象
    • 访谈前要从各种渠道了解访谈对象的背景，尤其针对高级别访谈对象，了解得越充分、细致越好。
  • 和访谈对象保持联系
    • 访谈结束后，最好和访谈对象建立长期联系，尤其是一线业务人员。
  • 轮岗实习
    • 轮岗实习是指，产品经理深入一线，直接体验一线业务人员的具体工作，这是深入了解业务的最好方法。
  • 调研问卷
    • 激励用户完成填写问卷调研首先要确保能够回收足够多的、有效的反馈结果
    • 控制好开放式和封闭式问题
    • 避免诱导性问题
  • 数据分析
    • 产品经理要像业务经理那样关心业务运行的各项数据，这样才能了解业务现状，并进行业务诊断.
• B端业务调研的流程
  • 调研目标即调研的目的，有了明确的目标，工作才能朝正确的方向开展，因此这一步非常关键
  • 对于 B端业务调研，调研对象一般包括业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员等
  • 调研方法包括定性分析法和定量分析法，具体包括访谈、轮岗实习、问卷调研等方法
  • 如果前面的准备工作做得足够充分、细致，那么具体执行时就会相对顺利且有效
  • 业务调研的主要目的是掌握业务情况、诊断业务问题。
• B端产品与C端产品建设流程的区别
• B端产品的总体建设流程
  • 产品整体方案设计
    • 核心业务流程：梳理整个业务主干流程
    • · 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。
    • · 应用架构：考虑该产品和公司现有系统的融合关系。
    • · 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。
    • · 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。
  • 技术方案设计
    • 产品的整体方案、细节方案都设计好后，就需要技术人员做技术方案设计了，从而保证软件系统在正确的技术选型和合理的技术架构下进行编码开发工作
• 互联网产品经理本质
  • 经营管理运作的方方面面，流量拉取，流量留存，流量变现，业务模式创新，管理提效，成本控制，风险管理。
• 什么是C端产品
  • c端产品也叫2C（to Customer）产品，是面向终端用户或消费者的产品，往往承担流量获取和转化的责任。
  • C端产品有如下特点：
    • 用户要个体:使用C端的是独立的个人，而不是一个组织机构
    • 强交互体验：C端用户要求低的使用成本和学习成本，他们可能会因为体验上的一点不满意而轻易离开APP
    • 数据驱动设计：C端产品的没一个按钮，组件,页面都要进行全面，精确的数据监控，通过数据分析来调整方案并持续优化，最终达成目标。
    • 收益容易量化：C端产品关注的核心指标主要包括日活，UV,PV,转化率等。
    • 运营决定存亡：对于C端产品来说，产品运营和产品设计同样重要，共同决定了产品的成败。
• 什么是B端产品
  • B端产品也叫2B（to Business）产品，使用对象是企业或组织B端产品帮助企业或组织，B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担这为企业或组织提高收入，提升效率，降低成本，控制风险的重任。
  • B端产品有如下特点：
    • 目标用户是一个群体：B端产品用户群体是某个业务团体或组织。
    • 效能第一体验第二：B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于次要地位。
    • 强调抽象和逻辑：B端产品背后的业务复杂度高，人员，分工，协作，流程，规则随时可能调整。
    • 收益难以量化：B端产品要支持，解决业务问题，但业务成效的影响因素非常多，很多时候并非取决于B端产品设计的好坏。
  • B端产品按业务方向可分为：
    • 对企业内部的B 端产品，又可以分为以下两类：
      • 业务支撑类产品：支持企业经营管理或核心业务的开展，例如仓配系统，CRM系统。
      • 办公协同类产品：支持企业内部办公协同，例如OA系统，HRM系统。
      • 对企业外部的B端产品，主要是指商家端的产品，即平台型企业给卖家提供运营管理支持的系统。
• 什么是数据与策略产品
  • 数据类产品是对企业内外部所有数据进行挖掘并列用的产品，通过数据反映出来的深层次信息来有效提升对应业务的绩效
  • 数据与策略产品经理有以下工作方向：
    • 数据仓库建设
    • 报表设计
    • 算法策略输出
    • 数据监控
  • 数据与策略产品分为：
    • 对内产品
    • 对外产品
  • 从事数据与策略产品建设，一定要认识到数据的挖掘，探查，分析和价值输出才是产品的“灵魂”，而报表，可视化工具只是产品的表面。
• 什么是商业变现产品
  • 商业变现类产品，顾名思义，就是帮助互联网企业将流量转化为收入的产品。
    • 搜索引擎营销
    • 广告投放平台
    • 在线广告联盟
    • 增值服务
• 什么是AI产品
  • 凡是利用人工智能技术的产品，都属于AI产品。AI技术使产品更智能，更迎合新时代的需求。
• 广告变现
  • 广告变现是在互联网行业发展早期便摸索出来的的第一大变现方式
    • 广告变现模式下的互联网，既要创新的C端产品保证流量，又需要稳定的商业产品持续变现，还需要更强大的CRM,呼叫中心等B端产品支持业务运作。
• 增值服务
  • 增值服务是从互联网发展早期开始采用的第二变现方式，具备经久不衰的潜质和魅力。
  • 增值服务是任何互联网企业都非常容易采用的变现手段，尤其是虚拟化的增值服务。
• 佣金提成
  • 佣金提成是平台型互联网企业的经典变现手段。
• B端产品概述
  • 业务模式越来越重要
    • 无论以平台形式还是自营形式接入线下模式，复杂的业务运作流程与庞大的线下业务团队管理都将是不可避免的，而这必须依靠B端产品助力。
  • 全面的能力培养
    • 逻辑思维与抽象能力
    • 技术知识储备
    • 复杂项目管理能力
    • 复杂项目管理能力
  • 具备壁垒性的专业经验
    • 作为一名 B端产品经理，如果想在某个细分领域深耕，需要做到如下几点。 · 掌握该领域的所有方法论和专业知识。 · 对该领域的业务运营特点和难点有深刻的认知和总结。 · 对市面上所有该领域的商业化软件产品如数家珍，优缺点了然于心。 · 了解市场上所有类似业务模式公司的业务特点、产品特点。 · 认识行业内的相关专家，形成圈子，经常聚会探讨 理解公司的业务现状、痛点，知道如何将行业最佳实践结合公司特点进行规划落地。
  • 业务平台方向
    • Relationship Management，客户关系管理。
    • Chain Management，供应链管理。
    • · WMS： Management System，仓储管理系统，用来支持仓库管理业务。
    • TMS： Management System，运输管理系统，用来支持配送管理业务。
    • ERP: Enterprise Resource Planning，企业资源计划管理。
    • Call Center:呼叫中心。
    • Passport：企业客户账号管理体系
    • Data Management，主数据管理。
    • · Auth： Management，权限管理平台。
    • · Org： Management，组织架构管理平台。
    • · Msg： Service，消息服务。
    • · SSO： Sign On，单点登录服务。
  • 交易平台产品线
  • 办公协同方向
    • OA:office Automation,办公自动化
    • 内部IM:内部沟通工具
    • · HRM： Resource Management，人力资源管理软件
    • · 财务管理系统：这是专业性最强的业务系统，公司一般会采购成熟的财务软件。
  • 商家管理方向
  • 小结