作为一位已经做了10年产品的老司机，C端、B端（包含To G）产品都做过不少。在拥抱产业互联网的今天，作者想为大家分享一下近几年做To B产品的一点体会，希望可以对大家的工作带来帮助。
首先是概述，讲述什么是B端产品，分类是如何的，接下来是“策划相关”，主要涉及产品调研和行业研究、架构设计、功能模块设计和一些基本功能设计的通用化方案；最后会涉及长期运营和迭代涉及的体会。
B端产品也叫“2B（Bussiness）”产品，使用对象是组织或企业。B端产品帮助企业或组织通过系统化的数据共享和协同办公，使线下流程线上化、系统化，解决基于某个业务领域的实际问题，帮用户提高效率、减少成本，甚至提高收入、控制风险。
我做过的B端产品算一算应该有10+个了，大体上做B端产品的感觉是：
B端产品一般是针对固定的企业或者组织开发的，而在不同的企业和组织里面，大家的角色分配、职责还有流程都不同，所以很难做出通用性很强的产品，就算是WMS（仓库管理系统），这基本是每一个生产型和销售型企业都必备的，但却千变万化。
做B端的产品经理，需要既懂业务，又要懂技术，算上腾讯，我已经在3家公司做过B端产品这个岗位，回想起来有一半是业务转做产品经理，四分之一是开发同学转做产品经理，而像我这样科班做产品的也只有四分之一。确实B端产品是专门服务一个领域，如果你对这个领域不深入了解，如何抽象出系统服务这些专业人士？
设计B端产品时，整体架构、用到的相应技术等，产品经理都需要有一定的知识储备，比如微服务、SOA，这样才能在设计产品时少走弯路，做出最佳解决方案，也避免了未来因为无法适应业务而造成的重构。
作为一位B端产品经理，这是最挑战你个人能力的地方，基于对业务的理解，把现实的流程和场景变成抽象的系统和模块，从现实的规律变化转为抽象的数据流。上面我提到，B端产品很难做到通用，但是如果你能尽可能的做到可配置，一个功能适应和满足大多数场景，同时如果业务流程调整了，你通过配置，就能马上适应，会为你节约出很多开发人力，还能快速响应业务。
如果你是从To C产品经理转成To B产品经理，这一点可能是最难适应的，尤其是我这种以前做C端，又是处女座的产品经理，但是没办法，就那么多人力，业务的需求应接不暇，而且每个业务都催你，认为自己的需求都是P0优先级，面对这种情况，你只能在业务目标和用户体验之间取一个平凡，换句话说，你不得不为快点上线而牺牲掉用户体验。
B端产品一般都是在公司内部部署和使用的，就算是SAAS化的产品，你想体验也要花高额代价，这就对新入行就做B端产品的同学挑战巨大，一方面你要学习行业知识，一方面你连竞品长啥样都不知道，就算看到，也可能和你要做的适合你部门业务的系统差距甚远；这就需要产品经理在深刻了解业务的情况下，独立去“创造”一套适合你部门或公司的系统。
首页按照用户群体，可以划分为3类：
部署方式分为：
技术架构可分为：
B端产品按业务方向可分为：
我把B端产品工作大致分为3个阶段：
我在上文中也提及，按用户分，把ToB产品分为3类，每一不同类型，实际上在立项调研及分析阶段是不同的：
1、定制化产品：因为是甲方直接告诉你要做什么，所以通常行业、市场分析这种都不用做，最关键的是要对甲方做足用户访谈，了解其真正痛点是什么，为什么要做这样一套系统，给他们带来什么样的收益，甲方的要求是什么，验收标准是是什么；了解清楚这些问题以后，竞品分析是不可少的，行业多少会有类似相关产品，可以做一轮研究，看看是否有一些优秀的行业解决方案或者标准（暂不考虑投标等）
2、标准化产品：因为要对外销售，所以行业分析、市场分析、竞品分析、用户分析和需求分析一个都少不了
3、内部产品：因为主要是公司内部使用，所以用户分析和需求分析很重要，竞品分析也是需要的
行业分析：
市场分析：
市场分析四步走方法论：行业背景、前后市场、用户分析、商业模式。
竞品分析：
用户分析：
需求分析：
B端产品往往涉及复杂的业务关系和场景，该如何开始着手设计和策划一款To B产品呢？在埃森哲的时候，接到一个新Case，同事们一般会结合企业架构的方法论来出解决方案，确实，企业架构是一个很好的工具，按照现成的方法论，一步一步熟悉了解项目，最终产出解决方案，这就是我们咨询顾问的工作。在这里，作为一个To B的产品经理接触到新项目的时候，同样适用。
很多同学看到这里，一定会说，我只是个小小产品经理，做个产品，咋都扯到企业架构去了？但产品经理这个词语最初在宝洁公司诞生的时候，便是要对经营负责，与商业运营紧密相关的。
对于一个成熟的产品经理来说，快速梳理清楚自己负责或将要负责的产品的业务流程是必须能；这样不但可以帮助你尽快融入，也可以让你有一个清晰的业务认知，不会在面对复杂设计的产品时不至于手足无措。
并且B端产品属于复杂系统，不是简单地画画原型搞搞需求分析就能搞定，而是涉及到业务功能复用、数据共享、数据安全、互操作性、技术债等一系列复杂问题。B端产品经理需要培养一种全局观念，通过企业架构模型将企业组织要素、业务功能要素和技术要素进行构建和链接，分离出不同利益相关者的关注点，构建安全的业务实施边界，构建基于组织能力的交付解决方案。
在企业架构领域，B端产品经理应该扮演好领域专家和产品设计师的角色，和技术架构师、数据专家家一起工作，共同完成业务架构、产品架构、数据架构和技术架构的交付。
企业面临各种内外部变化，要快速响应这些变化，这就必须有一套“企业结构图”，从企业战略、业务能力、IT战略、价值流、组织等不同维度描述企业的业务，以及各维度之间的关联关系。相当于为物理世界中的企业在数字世界建立模型，从而帮助企业在此基础上进行变化的影响评估。这就是企业架构。
企业架构（EnterpriseArchitecture），简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。
企业架构是一个业务和IT对齐的战略执行工具，一种设计、管理、沟通的工具。通过企业架构，我们可以达到：
给大家简单解释一下，这里企业架构，大家不要认为企业指的就是腾讯，实际可以是你所在的部门，可以是你所属的这个业务组织，而上面复杂难懂的定义，可以简单理解为企业架构（业务组织架构）是关于理解所有构成业务团队的不同元素，以及这些元素怎样相互关联的。
好比，人体就是一个组织，包括血液循环系统、消化系统、神经系统等等。头痛可能是因为呼吸系统感染引起的，也可能是因为神经系统出了问题。在制订解决方案前，医生必须要做出全面的评估，才能确认问题出在哪里，避免“头痛医头，脚痛医脚”，而从医生问诊到最后把病治好，并且还让你健康保健、延年益寿的全过程就是“企业架构”的方法了。
企业架构方法有很多，但TOGAF是最主流的，已经有超过15年的历史。不仅有80％的福布斯（ Forbes）全球排名前50的公司在使用，而且支持开放、标准的SOA参考架构。
TOGAF 是一个架构框架，简而言之，是一种协助开发、验收、运行、使用和维护架构的工具。TOGAF将企业架构抽象为四个层次：
TOGAF架构开发方法（ADM）为开发架构提供经测试的可重复的过程。ADM中的各阶段如下：
总的来说，产品说到底是为用户服务的，To B产品解决的是计划性的标准化需求。而To B产品的构建，无论从产品逻辑层面，还是从产品规划层面，都值得我们产品经理花费更多的时间和经理去探讨。
作者：leochaowang，腾讯TEG产品运营
来源公众号：腾讯大讲堂（ID：TX_DJT ），聚焦前沿，打造互联网人的高光时刻
本文由人人都是产品经理合作媒体 @腾讯大讲堂 授权发布，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。