决胜B端：产品经理升级之路
近期在为一款产品设计运营同学用的后台，发现B端的产品能力还需要进一步加强，于是买了这本书，希望提升一下自己对于B端后台的认知。这本书分了4大部分，较为系统地梳理了B端产品的方方面面。先概括性地介绍了B端产品经理和B端常见的业务种类，接着从一个虚构的分销产品的设计，到产品落地、实施过程中的项目管理、部门协作、迭代计划编排，后期的运营、数据分析，最后延申到企业整体的产品架构，做了全面的讲解，干货满满。
第1部分 B端产品经理概述
在互联网时代以前，网络和电脑尚未大范围普及之前。软件公司经常会设置一个业务分析师（Business Analyst，BA）的岗位，负责承接并管理软件开发项目。BA一般向业务部门汇报，会根据业务需求编写软件需求规格说明书，然后由公司内部开发团队或外包开发团队编码实现。
到了互联网、移动互联网时代，产品经理除了引流与变现，还需要负责公司业务管理软件的建设，对业务效率优化负责。
B端产品也叫2B（to Business）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低成本、控制风险的重任。
B端产品的几个特点：
- 效能第一体验第二：B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于次要地位。
- 强调抽象和逻辑：B端产品背后的业务复杂度高，人员、分工、协作、流程、规则随时可能调整，这就需要产品经理有非常强的抽象能力和逻辑思维，将看似散乱无章的业务抽象出共性，进行合理建模和设计。
- 收益难以量化：B端产品要支持、解决业务问题，但业务成效的影响因素非常多，很多时候并非取决于B端产品设计的好坏。例如，采购部门的核心绩效是找到更多优质低价供应商，但这并不取决于采购软件设计的好坏，而更多地依赖于采购员的人脉和专业技能，以及管理考核体系。很难直接衡量B端产品上线的新功能对业务价值的贡献。这也是B端产品经理经常面临的烦恼。
第2部分 产品设计
这部分讲述了如何从零开始构建一套B端产品，来支持一条业务线。并以虚构的M电商公司的渠道分销产品作为实际案例进行了讲解。
在建设B端和C端产品时，大的原则是类似的，都是先做加法，即充分讨论、穷举所有需求和可能性；然后再做减法，选出最核心的需求点；最后设计具体方案并将其落地，用最短的时间和最低的成本支持业务启动。
但两类产品在细节设计上的关注点完全不同：
- B端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。
- C端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因此不用关心角色、权限管理，而要关注用户的体验，需要在交互设计上投入很大精力。
这部分分为了多个环节和步骤：
业务调研：主要目的是理解公司的经营策略，确保对产品的定位、形态做出准确判断。轮岗实习是指，产品经理深入一线，直接体验一线业务人员的具体工作，这是深入了解业务的最好方法。（假设你是一家外卖公司的配送产品经理，负责设计配送员接单用的App。如果你不了解配送员实际工作的复杂性与突发性，怎么能做好产品设计？最好的办法就是，去做两周配送工作，理解真实工作场景，再总结提炼问题，并设计解决方案）
核心业务流程：从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。这里通常采用泳道图。
产品定位：产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持。
功能模块设计：功能模块图就是一幅完整的规划蓝图，能体现出系统的一二级导航菜单结构，是系统的骨架。
演进蓝图设计：通过绘制系统的功能模块图，可以明确业务和系统的规划脉络。将能想到的功能集合都列出来，这是一个做加法的过程。但是不可能一次实现全部功能，而要根据业务优先级，拆分成几期来完成，所以接下来需要做减法：确认产品的功能规划与实现节奏，就是常说的演进蓝图（Roadmap）。
业务数据建模：业务数据建模也叫实体建模、领域建模，或业务对象建模，是指针对业务特点，归纳并设计对应的底层数据模型的过程。软件系统的模块和功能实际上就是对现实世界的对象和规则的抽象。而软件系统设计的难点恰恰在于合理地总结客观世界的对象和关系，并实现最基本的数据模型设计。
业务流程图和角色：将角色代入进来，对之前步骤的“核心业务流程”进行细化。通过跨职能分系统流程图，可以清晰地看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）。
页面流转图：该图形描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。绘制页面流转图可以帮设计人员审视、思考系统中的页面设计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。
界面设计：产品经理绘制线框原型图；UE设计师完善交互体验，制作交互原型；UI设计师基于交互原型进行美工设计，生成切图文件；前端工程师拿到原型和切图，进行前端开发。
报表设计：业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。产品经理要和业务人员一起，关注完整的体系化指标建设，设计有实用价值的报表
数据埋点：借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据。
权限设计：可以采用经典的基于角色的权限设计，同时需要考虑功能权限和数据权限。
文档编写与管理：产品设计的好坏，首先取决于需求的质量。如果需求质量不高，产品设计再用心，也难以产生价值。实际上，很多需求都只是需求提出者的灵光一闪的想法，并没有经过严谨的思考。对于B端产品，尤其是业务系统，业务方一般都有需求管理团队，负责调研、整理业务需求，提交给产品经理。产品经理首先需要对需求进行判断，如果发现需求质量不高，就需要和业务方反复讨论，判断需求的真实性。
产品经理是否需要懂技术？
懂技术的产品经理在设计产品方案时，能够在一定程度上预估技术实现的可行性和实现成本，或至少能具备基本的认知，知道什么时候、什么情况下需要和技术人员提前沟通讨论，从而保证产品设计合理可行，既能提升合作效率，也能赢得技术人员的尊重和信任。总结好处点如下：
- 避免产品过度设计
- 避免技术过度设计
- 与技术人员沟通顺畅
- 预判需求的可行性
- 评估工时合理性
第3部分 项目管理和实施、运营、迭代优化
PMO或产品负责人要承担设计、修订项目管理制度的职责。合理的规范制度应该既能约束产品研发团队的行为，也能保护产品研发团队的权益。PMO或产品负责人要管理并维护项目管理软件，例如JIRA、Teambition（图8-1），以便产品研发团队能够通过软件来规范项目管理过程，并获取足够的项目管理数据支撑。
明确项目收益价值：任何项目都应该提前预估收益和投入产出比，从而判断是否有必要推进项目。明确项目收益价值是对项目负责的做法，即便很多时候预估的项目收益可能和实际偏差比较大，也是有必要的。
强执行力和推动力就是指能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。这样虽然可能会让某些伙伴有暂时的不舒服感，但只要是为了推动项目，为了要结果，为了有价值，最终大家都会认可并赞扬这种积极的态度。
对于支持内部业务的B端产品运营岗，工作目标是通过挖掘B端产品的能力（即对现有功能进行推广、协助完成产品的升级优化），帮助企业解决业务问题。其中，业务问题可能是营收增长问题，也可能是风险控制问题。
不同的组织架构对产品经理、产品运营人员、业务运营人员三者的合作关系会产生直接影响。调整组织架构和管理关系是解决协作问题的一个非常有效的手段，很多时候，面临团队的低效、猜疑、冲突，可能略微调一下组织结构就解决问题了。互联网公司取得成功的诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中很可能实现破局，或者产生“鲶鱼效应”。
第4部分 企业级整套产品架构
企业级应用架构正是指企业的各个软件系统有机集成在一起的方式。
企业级应用架构正是指企业的各个软件系统有机集成在一起的方式。下面是典型的企业级应用架构图，它可以体现出企业系统设计的整体结构特征、逻辑分层特征，以及功能模块的抽象特征。
感谢阅读，希望这篇文章能给你带来帮助！