时间: 2021-08-03 09:19:22 人气: 25 评论: 0
继上篇介绍了 B2B 行业趋势以及项目调研阶段的关注点，本篇将继续分享产品规划与开发阶段、推广上线与运维阶段的概念与方法，以及对于 B 端产品经理的建议。
在做 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 天培养一个习惯」，从今天起就开始自我的覆**吧！
作者：Yvonne Wu，微信号：yvonneyvonnewu 领英：Yvonne Wu
本文由 @YvonneWu 原创发布于人人都是产品经理。转载请标明原作者与出处。
题图来自Unsplash，基于CC0协议
