UX 背景的产品经理如何打造 B 端产品？

编者按：本文笔者分享了自己与团队伙伴打造 B 端产品的经历，详细分析了做 B 端和 C 端产品在各个产品阶段的区别，B 端产品更注重业务和逻辑，我相信这和强调用户体验的 C 端产品是不同的，但并不是矛盾或互斥的。

上个月在求职季高峰时，每天几乎都有 2-3 场产品经理的面试，除了原本就在 B2B 领域深耕多年的候选人外，也许是受到 2018 年中末的互联网寒冬影响，不乏有从 B2C、B2B2C 领域想要转为 B2B 领域的产品经理。

从面试过程当中，有不少候选人反应目前 B 端领域的学习资源较少，行业横向可比性比 C 端产品来的低，让我不禁回想起当初踏入 B 端领域时，也经历了一段挣扎期。

在这个月初刚好一个机会在上海的 UIUX Meetup 上分享我与我的团队伙伴是如何打造 B 端产品，并通过 C 端与 B 端产品的对比，提供想要、或是即将进入 B 端领域的你一些参考。

TO B or NOT TO B，什么是 B 端产品？

在正式进入主题之前，先同步下我们所理解的 C 端与 B 端：

• C 端，正确来说是 B2C (Business to Consumer)，企业面向大众消费者的商业模式，以社交平台举例，最有名的产品就是微信；
• B 端，则是 B2B (Business to Business)，企业面向企业的商业模式，以社交平台举例，最有名的产品就是钉钉。

B 端产品的发展趋势

从去年中开始，移动互联网时代告一段落，流量红利殆尽后，投资人越发谨慎，IT 从业者感受到残酷的互连网寒冬。今年初我参加了蚂蚁金服体验科技大会，开场的时候体验科技部的负责人玉伯提到，随着 SaaS 的极大丰富，整个大环境对 SaaS 程序员和设计师的需求都在急剧增加。而 SaaS 市场有一大部分是 B 端产品，在欧美比较有名的产品是甲骨文 Oracle、Salesforce、SAP 等，但在国内这尚未有具有垄断性的领头羊产品出现，相比于 C 端产品的红海，在 B 端领域里仍是一片蓝海。微信公众号「线性资本」在今年初发表的文章 —《 做2019的幸存者 》也提到，接下来互联网即将从 To C 时代迈入 To B 时代。

我是如何进入企业里做 B 端产品的

在企业转型阶段，企业除了聘请国际咨询公司制定内部转型战略外，在外部也会成立各个新事业，通过内部改造、外部影响来促进企业转型。而我就是在企业外部的新事业体，为母集团提供调研洞察、IT 产品策略与 0-1 产品搭建。新事业就好比是一个新创公司（Startup），相比于步调快速的新事业，企业转型是个是一个缓慢的过程，因此当转型战略开始落地实施时，通常都需要花上几年的时间才可以看到成效。

而企业外的新事业体没有决策权，决策权都在母集团内部。当方案策略被制定推进后，总会想著最后落地的成效。去年 3 月因为公司人事调整因素，加上当时希望深入企业来跟进咨询策略落地，因此因缘际会下，就加入了母集团并参与一个数据相关的项目，也就是我当前的项目。

Sales Force Automation System 销售自动化系统

Sales Force Automation System 销售自动化系统就是我与团队正在搭建的系统，这个项目最早在两、三年前我还未正式加入母集团前，就已经有改版的需求，我们从组织架构调研开始做起、到策略提供直至产品开发落地，经历了一个相当完整的过程。

那什么是销售自动化系统呢？这个 B 端产品其实不难理解：

每个人家里一定都有一些快速消费品（FMCG, Fast-moving consumer goods），例如调味品、沐浴用品等，以调味品的酱油为例，你是在哪里买到这瓶酱油的呢？家附近的小卖店、大卖场，或是从网上订购；如果家里不开伙，到餐厅吃饭时，厨师有可能也会用到酱油做菜。这些消费者可以买到酱油的地方，统称为「消费者接触点（Customer Touch Points）」。而这些消费者接触点的酱油从哪里来的呢？可能是从批发商、经销商、分销商那里获得；而这些中间商基本上都从食品公司拿到商品，如此从生产制造、销售渠道到终端消费者，就构成了基本的零售链路。

对于食品公司来说，仅仅把酱油卖出去获取中间利润是不够的，为了可持续性的经营企业，食品公司希望能知道消费者在什么时间、地点、买了哪些商品，以及竞品最近有哪些动作、我品该采取哪些市场策略来应对。由于食品公司辐射地区有限，需倚赖经销商来销售商品，但经销商大多不会帮食品公司来收集这些第一线的市场数据，因此数据收集的工作就需要倚赖市调公司、或是公司内部的销售业务员，在维护终端门店的客情关系时，一并收集市场数据。而 sales force automation system 销售自动化系统，就是给公司内部销售业务员与销售部门使用的产品。

那么，我与我的团队是如何打造这个 B 端产品呢？C 端与 B 端产品有哪些不同之处？以下介绍的几个概念与方法，不仅局限于 sales force automation 产品，也适用于大部分的企业级产品。

项目初始阶段 ：定位核心问题

在企业内部做产品很常出现因为高层命令，就要组建团队开发某某产品的情况发生。这样的产品往往没有很好的考虑企业核心需求，往往在产品开发过程中，因为找不到产品价值而逐渐迷失方向，当发现本质问题时，无论是要调整方向或是放弃项目，对已经投入人力与资源的情况下，都是两难的抉择。也因此，定位产品想解决的企业核心问题，是项目初始阶段最为重要的课题之一。

当时我们的核心问题是：公司旧有的销售自动化系统已经运行了 6 年，由于采买自第三方系统，在拓展性有比较大的限制，加上老系统运维不易，无法满足日新月异的市场销售需求，于是自行开发新的销售自动化系统就日趋重要。
在我加入的前三个月，这个项目正式成立。当时的项目负责人（目前公司的产品总监）从 CEO 得到授权来展开此项目。这个授权对于日后推动产品的发展非常有帮助，由于 B 端产品支持著公司的主营业务发展，因此无论是在产品设计时的调研、开发阶段的沟通，以及上线后的推广，都需要跨部门配合，高层授权在传统行业来看，格外重要。

项目初始阶段：明确设计挑战

核心问题定位清楚后，设计挑战也就呼之欲出：

1. 我们如何基于现有业务模式，从 0-1 打造数字产品
2. 我们如何探索较好的交互设计模式，提升销售人员数据录入效率
3. 我们如何迁移历史数据，打通系统间数据交互，形成闭环

项目调研阶段：行业壁垒

项目初期，团队大约花了 1-2 个月进行产品深度调研，从业务背景收集、快消品行业知识学习，接著访谈公司销售主管与业务、考核主管与活动策划人员，一直到跟著销售业务员走访大大小小门店进行田野调查，累积了厚实的调研文档，而这份文档也奠定了后续产品设计的基础。

对于 C 端产品来说，很可能我们自己就是这个产品的主要使用者，例如电商、社交平台，因此无论是功能操作、用户场景，都有一定的熟悉度。但 B 端产品具有很强的业务特性，如果不是实际参与在相关工作当中，需要花较长的时间了解业务与行业知识。以卖场里的货架来举例，虽然逛卖场的经验大家都有，但不一定了解货架的属性。货架粗略来分可以分为常规免费货架和付费特殊货架，转换成产品功能时，就需要了解其中的差异，在产品功能划分上清楚区分两种货架，减少销售人员的误操作。

行业壁垒高的特性，让许多第一次参与 B 端产品开发的成员在进入项目初期感到吃力甚至是挫折感，考验个人的快速学习能力与知识体系的建构能力。

项目调研阶段：用户画像

C 端产品的用户画像具备明显性格、行为特征，群体较单一，通常会有一个符合产品定位的核心 TA（Target Audience 目标族群），以及延伸范围的 TA，像一个同心圆。而 B 端产品是强业务性质，由岗位职责驱动，在企业组织架构下，不同级别不同职责的岗位构成 B 端产品棋盘状的用户画像，横向是部门，纵向是职级，每一格的用户都具备不同的任务。

在这里你可能会发现，B 端产品的用户画像仍然离不开行业特性，每一个棋盘里的角色与之所对应的工作，都与业务相关。在疏理用户画像的过程当中，倚赖的是在设计师阶段培养的用户直觉能力，能将每个用户的特性清晰的描绘下来；与此同时，也考量著产品经理的全局组织与产品规划能力，这些棋盘上的角色最终落实为用户权限。

在我们的 CRM 系统里共有 300 多的岗位角色，你总不想你的产品后台配置了 300 多个权限吧，因此在用户画像之后，就需要进行用户细分，最终我们产品的后台权限通过了用户细分，设置了约 20 个角色，这个部分内容又可以继续展开，后续有机会再和大家分享我们是如何清洗数据、规划产品的用户权限。

项目调研阶段：田野调查

很多的 C 端产品，考虑的更多的可能是通用性、提升用户体验这样问题，田野调查大多会选在用户私人生活遍及的地方，例如用户的家。但 B 端产品，需要考虑的是行业垂直化、提升使用效率的问题。产品的挖掘的行业深度越深，越能挖掘到深层的业务痛点，为企业创造的服务价值会越高。一般来说，B 端产品的田野调查因为面向企业的原因，在企业机密信息保护下，通常很难进入一间企业来做田野调查，信息缺失的部份，就需要倚赖大量的二手调研信息来补足。而我们是在公司内部做产品，因此这个限制是不存在的。

在产品上线后，我们全部的项目成员包括开发人员，也进行过 1-2 次的田野调查，实际走访门店来看产品落地的情况。对于开发人员来说，这是个了解业务的绝佳机会，提供在写程序时的思路。我们产品有一个小功能深受用户好评，就是由开发人员在跟线过程中观察到的用户痛点，进而提出能够提升产品用户体验的功能。

产品规划与开发阶段：设计重点

在做 C 端产品时，项目上讨论最多的就是用户喜欢什么、在什么时候会想到我们的产品、市场是否有潜力……到了 B 端项目，产品规划阶段团队每天讨论最多的就是这个业务场景什么、为什么这个用户需要开启这个功能的权限，是基于哪个业务场景下？考量点从用户切入转为用户切入。

很多人会说 B 端产品不重视用户体验，其实不尽然。B 端产品与 C 端产品最大的区别就是用户的动机不同，例如用户使用微信是用户「自己想使用」；但用户使用钉钉就不是这么一回事，大部分都是因为工作上需要，因此使用钉钉，毕竟周遭朋友都不使用钉钉，花钱也不需要家人朋友审批，所以 C 端与 B 端产品的用户动机一个是自趋力、一个是业务驱动。不是 B 端产品不重视用户体验，而是这个用户体验要基于业务才有存在的意义。

产品规划与开发阶段：体验与效率

C 端产品关注用户想要什么，如何通过吸眼球的视觉、让用户上瘾的产品体验来实现最大的市场价值。相对于 C 端产品的创造性，B 端产品注重的是逻辑性。一些企业系统例如 ERP（Enterprise Resource Planning 企业资源规划系统）、OA（Office Automation 办公自动化）、CRM（Customer Relationship Management 客户管理管理系统） 等，这些系统不强调交互流畅或是介面具设计感，因为它们的本质是为了解决企业管理的效率问题，让企业的业务流动起来，有效的管理企业资源。

B 端产品在产品规划阶段，通常都需要较长的需求疏理时间，明确各个业务场景与业务方之间的交互流程，了解不同终端用户的核心需求，以及数据在系统中的流向。

举一个实际发生过的例子，我们项目团队从数据部门接收到一個收集销量数据的需求。对于销售业务来说，销量数据最准确获取的方法，是从卖场的 POS 机取得。他需要跟卖场建立良好的客情关系，才有办法高频率获取 POS 机的数据；有部分的促销人员，年纪大多在 40、50 岁以上，对于这群用户而言，连操作微信都有难度，更何况是收集数据的系统；而对于卖场而言，他们不希望因为品牌商收集数据的动作影响客人的购物体验，甚至会对促销人员下达工作期间禁用手机的规定。

从这个例子我们可以看到，如果只在产品上开了这样一个数据收集的功能，但没有考量到这些特殊的业务场景，造成终端用户的操作负担、降低工作效率，那么即使收集到这些数据，你也会怀疑这些数据的真实性。

产品规划与开发阶段：数据架构

B 端产品还有一个核心关键：「数据架构」。C 端产品的数据应用是在产品上线后，例如用户留存量、转化率；而 B 端产品则是在产品规划阶段，需要根据业务规则考量各个系统间的数据架构，例如人员、客户、商品、活动等信息从哪个系统来、收集到的数据又该流向哪些系统、不同的事业体但相同的数据分析需求在数据架构上该如何划分……
上面这个示意图是比较理想的情况，但往往在企业的发展过程当中，各个系统的替换、搭建中需要迁移各样的数据，在没有好的数据架构规划下，容易造成各个系统重功或是数据流不明晰的情况。

我通常在需求疏理阶段时，会一并将相关的数据源、数据的分析运用以及上下游系统之间的交互关系与对接人初步厘清之后，连同业务、功能流程以及基本的数据流给到开发人员（如上图所示）。

而对于一些数据分析的产品来说，例如 BI 系统（Business Intelligence 商业智能分析），这类的产品经理就需要具备数据分析的能力，会使用 SQL, Python 等数据分析软件，来辅助更好地理解业务数据分析需求。

推广上线与运维阶段：产品提升

C 端产品可能更多是聚焦在体验上，通过体验的创新，吸引更多用户关注，提升转化率；然而对 B 端的产品经理来说，我们关注的视角不只是自己产品的业务梳理或者逻辑层面，企业中的产品是与整个企业甚至行业生态圈环环相扣的，B 端产品经理需要站在一个相对高的维度，来考量商业层面资源整合的问题。

上周听 ThoughtWorks 分享搭建中台，ThoughtWorks 在帮助这么多公司推动企业转型之下，他们发现以 IT 来推动企业转型是最快、最有效的方式。当企业的业务流程都在 IT 架构下有一定的规范后，无论资源整合、人事异动、政策发布实施等，都可以通过 IT 系统交互串起企业里的每一个业务。

当然，我们项目在实际运行的过程当中，时常遇到系统已搭建完毕，但人事运作跟不上，部门同事还是保有旧有的繁琐流程、线下工作以及部门间信息断链的情况发生，这时候产品开发团队就需要协同运维团队，不仅针对产品使用作推广，也需要一并推动新的、高效的业务流程。

与团队一同搭建产品至今，我们已经完成了全国销售业务全面使用新系统的里程碑，但对于产品经理来说，挑战才正开始：如何通过 IT 产品的创新，来为企业带来销售的增长。

我们正在尝试新的技术、新的可能，希望很快有成果与大家分享。与此同时，下面是我的一些建议，为即将入 B 端这个坑、或是已经在坑里的你，提供一些思考点：

了解自己的长处与兴趣

成为 B 端产品经理之前，我也参与过几个 C 端产品的搭建。相比于 C 端产品与市场运营强关连（例如我在美国工作的时候，设计部门就在市场部门隔壁），我更喜欢业务逻辑强关连的 B 端产品，了解组织架构、业务流程后，产品经理站在 IT 专业上，有更多的话语权来建议业务部门产品应该如何搭建。

而 C 端产品时常会遇到与产品价值相矛盾的情况，例如视频产品最核心的用户体验就是让用户不间断地看视频，但往往碍于公司生存压力，不得不在视频播放时插入广告金主的广告内容。但 B 端产品则不然，Facebook AI 团队设计总监 Amanda Linden 曾经提到：

为企业和其他付费应用设计的美好恰恰在于，最终用户的利益与业务利益是一致的。只有当用户成功使用了这个应用，你的公司才真正获益。设计企业产品，你是在组织并帮助员工实现他们的目标，帮助所有的企业更好地运转。

找到自己的兴趣，深入行业

上个月我大约参与了 10 多场产品经理的面试，有一位相当资深的候选人令我印象深刻，他做过通讯、金融、外卖平台，也自己尝试做过生鲜电商。令我深刻的原因不是他过去的经验行业跨度大，而是惋惜他并不了解行业知识的深度，是产品经理不可取代的能力之一，以致于他在过去十几年的工作经验，都只是浅浅的走过这些行业，失去了深入了解、建构这个行业产品知识的机会。

即使是 B 端产品，也必须要深入行业的知识体系来规划整个产品，因为你必须要知道行业的变化可能会对产品带来哪些影响、数据出自于什么原因需要收集、正在执行工作的用户需要 IT 人员给到哪些支持。

做产品，保有初衷与热情

去年 11 月我在经历了 2-3 次产品大规模产品推广后，我发现有一段时间对于工作失去热情。我是个典型工作狂，个人成就感与满足感大多来自于工作，因此这件事对我来说非同小可。

有一天突然在人人都是产品经理看到一位 B 端产品前辈，分享产品经理在企业里除了产品设计本职工作外，不同部门很容易找到你来处理产品相关的大小事情，从产品使用、数据系统架构，甚至到业务流程、人事异动等包罗万象的问题，这时候产品经理的精力容易被耗尽。

纵使我们有运维和客服团队，但其他部门的同事也坦承直接找到我最快最清楚，不仅可以得到大概的业务全貌，甚至能提供策略方案给他们。

后来我的解决方法是：当这个问题是产品手册、运维和客服团队也能回答的问题时，我选择延迟回答。如何让所有员工都跟上转型的速度，也是企业在数字转型时的挑战之一。

当然，也有业务方不了解系统特性，而有不合理的需求提出时，产品经理需要清楚企业里每个系统的定位与界线，站在 IT 专业的角度来与业务方理性沟通。

覆盘、覆盘、再覆盘

对产品经理而言，没有什么比覆盘再重要不过的工作了。产品经理每天会议满档，跟进产品开发的同时，又容易被团队的问题而打断工作节奏，以至于能有一段完整思考产品的时间不多。

虽然忙碌的工作节奏看似充实，但实际对于产品的学习帮助不大，而通过覆盘来沈淀自己，便是产品经理学习的一个最好机会。

我个人的覆盘相当简单也很有效：找一个不被打扰的时间（往往是下班后），写下一整天的行程并标注时间段，通过整理一天所发生的事情，将可以改进的地方找出来，罗列待学习的部份，包括工作内容、产品学习、沟通技巧、情绪管理等，进行一个全方位检视。

整个覆盘过程大约 5-10 分钟就可完成，坚持个一个月、三个月、半年再回头看每一天记录的情况，会发现自己的成长是很惊人的。「21 天培养一个习惯」，从今天起就开始自我的覆盘吧！

转载自 人人都是产品经理 作者 @YvonneWu 原文地址