作为一位已经做了10年产品的老司机，C端、B端（包含To G）产品都做过不少。在拥抱产业互联网的今天，作者想为大家分享一下近几年做To B产品的一点体会，希望可以对大家的工作带来帮助。

首先是概述，讲述什么是B端产品，分类是如何的，接下来是“策划相关”，主要涉及产品调研和行业研究、架构设计、功能模块设计和一些基本功能设计的通用化方案；最后会涉及长期运营和迭代涉及的体会。

一、做B端产品的总体感受

B端产品也叫“2B（Bussiness）”产品，使用对象是组织或企业。B端产品帮助企业或组织通过系统化的数据共享和协同办公，使线下流程线上化、系统化，解决基于某个业务领域的实际问题，帮用户提高效率、减少成本，甚至提高收入、控制风险。

我做过的B端产品算一算应该有10+个了，大体上做B端产品的感觉是：

1. 产品难以标准化，多是定制开发

B端产品一般是针对固定的企业或者组织开发的，而在不同的企业和组织里面，大家的角色分配、职责还有流程都不同，所以很难做出通用性很强的产品，就算是WMS（仓库管理系统），这基本是每一个生产型和销售型企业都必备的，但却千变万化。

2. 不懂业务，不懂技术就别做B端产品

做B端的产品经理，需要既懂业务，又要懂技术，算上腾讯，我已经在3家公司做过B端产品这个岗位，回想起来有一半是业务转做产品经理，四分之一是开发同学转做产品经理，而像我这样科班做产品的也只有四分之一。确实B端产品是专门服务一个领域，如果你对这个领域不深入了解，如何抽象出系统服务这些专业人士？

设计B端产品时，整体架构、用到的相应技术等，产品经理都需要有一定的知识储备，比如微服务、SOA，这样才能在设计产品时少走弯路，做出最佳解决方案，也避免了未来因为无法适应业务而造成的重构。

3. 尽可能的抽象流程，做到功能可配置和通用化

作为一位B端产品经理，这是最挑战你个人能力的地方，基于对业务的理解，把现实的流程和场景变成抽象的系统和模块，从现实的规律变化转为抽象的数据流。上面我提到，B端产品很难做到通用，但是如果你能尽可能的做到可配置，一个功能适应和满足大多数场景，同时如果业务流程调整了，你通过配置，就能马上适应，会为你节约出很多开发人力，还能快速响应业务。

4. 注重效率，放弃体验

如果你是从To C产品经理转成To B产品经理，这一点可能是最难适应的，尤其是我这种以前做C端，又是处女座的产品经理，但是没办法，就那么多人力，业务的需求应接不暇，而且每个业务都催你，认为自己的需求都是P0优先级，面对这种情况，你只能在业务目标和用户体验之间取一个平凡，换句话说，你不得不为快点上线而牺牲掉用户体验。

5. 做B端产品，没法“抄作业”

B端产品一般都是在公司内部部署和使用的，就算是SAAS化的产品，你想体验也要花高额代价，这就对新入行就做B端产品的同学挑战巨大，一方面你要学习行业知识，一方面你连竞品长啥样都不知道，就算看到，也可能和你要做的适合你部门业务的系统差距甚远；这就需要产品经理在深刻了解业务的情况下，独立去“创造”一套适合你部门或公司的系统。

二、B端产品的分类

首页按照用户群体，可以划分为3类：

1. 定制化产品：就是俗称的外包，按客户要求，帮客户做一个完全定制化的产品，用户就是所谓的“甲方”
2. 标准化产品：对外销售的私有化部署或者SAAS化的产品，用户是市面上有需求的公司或组织
3. 内部产品：供公司内部使用，不对外销售的产品，用户自然就是公司的同事

部署方式分为：

• 私有化部署：就是说软件服务公司上门安装，把他们的软件安装在客户公司特定的主机上运行。这种安装特点是比较安全、网速快；缺点是：软件维护困难，成本较大。
• 云部署（SaaS化）：指把软件部署在云服务器，客户通过公共Web软件体验服务。这种安装特点是方便、简洁、容易维护、成本较低。缺点是：安全性较低，可能出现网络堵塞。

技术架构可分为：

• B/S架构：即Browser/Server，浏览器/服务器模式，用户通过自己电脑上的浏览器访问系统体验服务。目前市面上大部分B端产品都是这种架构方式。
• C/S架构：即Customer/Server，客户端/服务器模式，这是早期PC软件经常使用的架构方式，用户需要安装客户端才能体验服务，客户端还要经常更新，非常繁琐。

B端产品按业务方向可分为：

• 业务支撑类产品：支持企业经营管理或核心业务的开支，比如仓配系统和CRM。
• 办公协同产品：支持企业内部办公协同，比如OA系统、HRM系统。

三、To B产品经理的工作

我把B端产品工作大致分为3个阶段：

• 立项调研及分析
• 实施上线
• 运营反馈迭代

1. 立项调研及分析

我在上文中也提及，按用户分，把ToB产品分为3类，每一不同类型，实际上在立项调研及分析阶段是不同的：

1、定制化产品：因为是甲方直接告诉你要做什么，所以通常行业、市场分析这种都不用做，最关键的是要对甲方做足用户访谈，了解其真正痛点是什么，为什么要做这样一套系统，给他们带来什么样的收益，甲方的要求是什么，验收标准是是什么；了解清楚这些问题以后，竞品分析是不可少的，行业多少会有类似相关产品，可以做一轮研究，看看是否有一些优秀的行业解决方案或者标准（暂不考虑投标等）

2、标准化产品：因为要对外销售，所以行业分析、市场分析、竞品分析、用户分析和需求分析一个都少不了

3、内部产品：因为主要是公司内部使用，所以用户分析和需求分析很重要，竞品分析也是需要的

行业分析：

• 渠道来源（who）：百度指数、微信指数、艾瑞指数、易观数据、行业论坛。
• 分析内容（what）：行业背景、行业发展、行业领军、行业需求、行业产品、解决方案。
• 分析评估（how）：专业易读、数据可靠、理解透彻。

市场分析：

市场分析四步走方法论：行业背景、前后市场、用户分析、商业模式。

1. 行业背景：PEST分析、行业技术、行业预测。
2. 前后市场：市场规模、当前市场、未来市场。
3. 用户分析：用户需求。
4. 商业模式

竞品分析：

• Why：确定竞品分析的目的；确定目标，才会明确竞品分析的方向。
• What：确定竞品；明确哪些可以作为竞品，直接竞品OR间接竞品。
• How：如何分析；善用SWOT分析，善建KANO模型，明确用户需求与KANO模型之间的关系。

用户分析：

• 调研目的：明确用户分析的目的，为下一步工作做好准备。
• 用户画像：根据用户画像，明确目标用户；步骤：收集-分析-验证-优化。
• 用户问题：对用户和问题的分析，用户体验分析，DAU和转化率。
• 得出结论：根据调研的报告输出用户分析的报告。

需求分析：

• 数据分析方法：多维事件分析、漏斗分析、留存分析、行为序列分析、A/B testing、用户分群。
• 竞品分析方法：上文中已经提过，不再赘述。
• 需求来源：用户研究、用户反馈、数据分析、竞品分析、公司内部

2. 实施上线

• 整体方案设计
• 细节方案设计
• 功能原型文档
• 需求评审
• 开发跟进
• 测试

3. 运营反馈迭代

• 产品推广
• 跟进反馈及问题处理
• 需求管理及迭代
• 数据分析及报告

四、B端产品经理需要了解企业架构

B端产品往往涉及复杂的业务关系和场景，该如何开始着手设计和策划一款To B产品呢？在埃森哲的时候，接到一个新Case，同事们一般会结合企业架构的方法论来出解决方案，确实，企业架构是一个很好的工具，按照现成的方法论，一步一步熟悉了解项目，最终产出解决方案，这就是我们咨询顾问的工作。在这里，作为一个To B的产品经理接触到新项目的时候，同样适用。

很多同学看到这里，一定会说，我只是个小小产品经理，做个产品，咋都扯到企业架构去了？但产品经理这个词语最初在宝洁公司诞生的时候，便是要对经营负责，与商业运营紧密相关的。

对于一个成熟的产品经理来说，快速梳理清楚自己负责或将要负责的产品的业务流程是必须能；这样不但可以帮助你尽快融入，也可以让你有一个清晰的业务认知，不会在面对复杂设计的产品时不至于手足无措。

并且B端产品属于复杂系统，不是简单地画画原型搞搞需求分析就能搞定，而是涉及到业务功能复用、数据共享、数据安全、互操作性、技术债等一系列复杂问题。B端产品经理需要培养一种全局观念，通过企业架构模型将企业组织要素、业务功能要素和技术要素进行构建和链接，分离出不同利益相关者的关注点，构建安全的业务实施边界，构建基于组织能力的交付解决方案。

在企业架构领域，B端产品经理应该扮演好领域专家和产品设计师的角色，和技术架构师、数据专家家一起工作，共同完成业务架构、产品架构、数据架构和技术架构的交付。

1. 什么是企业架构

企业面临各种内外部变化，要快速响应这些变化，这就必须有一套“企业结构图”，从企业战略、业务能力、IT战略、价值流、组织等不同维度描述企业的业务，以及各维度之间的关联关系。相当于为物理世界中的企业在数字世界建立模型，从而帮助企业在此基础上进行变化的影响评估。这就是企业架构。

企业架构（EnterpriseArchitecture），简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。

企业架构是一个业务和IT对齐的战略执行工具，一种设计、管理、沟通的工具。通过企业架构，我们可以达到：

• 组织对企业现状（as－is）和企业愿景（to-be）有一个整体的的理解和行动方针；
• 确保在持续交付的过程中IT建设和战略目标对齐。
• 如果没有一个清晰的架构，就不能保证正确的决策和好的实现，EA是理解和实现企业IT建设的保障

给大家简单解释一下，这里企业架构，大家不要认为企业指的就是腾讯，实际可以是你所在的部门，可以是你所属的这个业务组织，而上面复杂难懂的定义，可以简单理解为企业架构（业务组织架构）是关于理解所有构成业务团队的不同元素，以及这些元素怎样相互关联的。

好比，人体就是一个组织，包括血液循环系统、消化系统、神经系统等等。头痛可能是因为呼吸系统感染引起的，也可能是因为神经系统出了问题。在制订解决方案前，医生必须要做出全面的评估，才能确认问题出在哪里，避免“头痛医头，脚痛医脚”，而从医生问诊到最后把病治好，并且还让你健康保健、延年益寿的全过程就是“企业架构”的方法了。

2. TOGAF架构开发方法

企业架构方法有很多，但TOGAF是最主流的，已经有超过15年的历史。不仅有80％的福布斯（ Forbes）全球排名前50的公司在使用，而且支持开放、标准的SOA参考架构。

TOGAF 是一个架构框架，简而言之，是一种协助开发、验收、运行、使用和维护架构的工具。TOGAF将企业架构抽象为四个层次：

1. 业务架构（Business Architecture）定义了业务策略、治理、组织和关键业务过程。
2. 数据架构（Data Architecture）描述了企业的逻辑物理数据资产和数据管理资源的结构。
3. 应用架构（Application Architecture）为要部署的单个应用系统、它们之间的交互和它们与组织的核心业务流程之间的关系提供蓝图。
4. 技术架构（Technology Architecture）描述了需要支持业务、数据和应用服务的部署的逻辑软硬件能力。

TOGAF架构开发方法（ADM）为开发架构提供经测试的可重复的过程。ADM中的各阶段如下：

• 预备阶段（Preliminary Phase）描述了准备满足新企业架构业务指示所必须的准备和启动活动，包括组织特定的架构（Organization-Specific Architectures）框架的定义和原则的定义。
• 阶段A：架构愿景描述架构开发周期的初始阶段。它包括关于定义范围、识别利益相关者、创建架构愿景和获得批准等信息。
• 阶段B: 业务架构（Business Architecture）描述了业务架构的开发，以支持达成共识的架构愿景。
• 阶段C：信息系统架构（Information Systems Architectures）描述了架构项目的信息系统架构的开发，包括数据和应用架构的开发。
• 阶段D: 技术架构（Technology Architecture）描述了架构项目的技术架构的开发。
• 阶段E: 时机和解决方案（OpportunitiesSolutions）为之前阶段中定义的架构引导出初始实施规划和交付载体的识别。
• 阶段F: 迁移规划（Migration Planning）使用一个支持的实施和迁移计划来处理一套过度架构的详细次序的制订。
• 阶段G：实现治理（Implementation Governance）提供一个实施的架构勘误表。
• 阶段H: 架构变更管理建立管理新架构变更的过程。
• 需求管理（需求管理）检查管理架构需求的流程，其贯穿整个ADM。

总的来说，产品说到底是为用户服务的，To B产品解决的是计划性的标准化需求。而To B产品的构建，无论从产品逻辑层面，还是从产品规划层面，都值得我们产品经理花费更多的时间和经理去探讨。