在消费互联网红利开始触达天花板的时候，B端产品开始成为资本与巨头的关注焦点，由此也造就了B端产品热度不断上涨，想转行做B端产品经理的人也不胜枚举，那么入局B端的产品经理都要注意什么呢？打造一款B端产品又有哪些要点呢？
一、互联网的C端产品时代
在过去的几年中，众多C端用户互联网平台纷纷涌现，涉及的领域包括社交、电商、团购、出行、内容等等，这些平台通过链接人&人、人&内容、人&商家产生了大规模流量，这一切的链接和流量都依托于C端互联网平台的核心优势
1. 低边际成本
在经济学和金融学中，「边际成本」指的是每一单位新增生产的产品（或者购买的产品）带来的总成本的增量。
在C端互联网平台中的核心业务是信息&服务，当平台已经搭建完毕后，每服务多一个用户的边际成本是很低的，每一个单独的用户个体对于成本的影响因素是非常小的。
2. 马太效应
很多C端平台都在业务发展成熟期，无论是借助资本还是借助先发优势，都逐渐形成了高集中度的规模壁垒。
而随着集中度越来越高，在相同业务模式下的C端用户越来越聚集在头部平台，而小平台的较难的获客也会逐渐抑制其平台业务边界的扩展，这就形成了互联网的马太效应，使得行业内的两极分化愈发严重。
3. 高技术杠杆
技术代码不涉及库存和资金流占用，对于C端平台来说属于非常轻的核心生产力，沉没成本极低。通过技术可以快速迭代产品体验满足用户需求、标准化产品流程、降低信息匹配撮合成本、提高交易效率等等。
优秀的产品和技术模型架构是各C端互联网平台竞争的核心。
举个例子，在滴滴打车平台中，当分派单引擎和司&乘两端搭建完毕后，服务100个用户和101个用户所带来的成本影响是极小的。
在2014-2016年，滴滴凭借积累的运营&技术&产品经验以及几轮成功的融资，逐渐在出行行业中形成了「先发优势」，使得行业内业务规模第三名以后的玩家生存堪忧。
而到了2017-2018年凭借国际化的业务成功扩展，将业务收入和资本影响力持续扩大，直到2019年基本在出行行业内形成了「赢者通吃」的形势。
二、互联网的由 C TO B
2018年后，C端流量红利逐渐消耗殆尽并且新流量的获取成本上升，整体市场从增量市场变为存量市场，伴随着较为不利的经济形势，各C端互联网平台的业务边界也逐渐稳固，美团&携程打车、滴滴金融、阿里社交、腾讯短视频、头条搜索、百度feed、还有数不清的新上线的直播平台等等等等，各大公司的业务扩展也变得异常困难。
各大互联网的关注点从C端平台向B端业务转移，头部企业阿里和腾讯组织架构调整凸显在其企业内部TO B业务的重要地位，而极具典型场景的TO B业务，也悄然在行业内急速扩张：
1. 以企业为核心的产品/服务
包括：餐饮Saas、开店Saas、人力资源（组织发展、员工福利）、协同办公（Confluence、Teambition）、数据服务（神策数据、飞瓜数据）、云服务、人脸识别、无人驾驶等。
2. 传统行业数据化、智能化、供应链优化
包括：新零售、物流科技、长租公寓、K12教育、AI芯片等。在大行业转型的背景下，由C TO B的转变 对产品经理来说也提出了新的挑战：
1）从「系统」到「服务」。产品并不主要依赖于「系统」的设计，而需要更多关注场景、流程、角色、供应链等等去设计服务。
2）从「体验」到「成本」。C端用户产品使用体验不再是核心，对于企业的可量化收入和成本成为产品设计的核心，需要有更多的商业视角和业务认知。
那么对于一个从「C端消费互联网」到「B端产业互联网」的PM来说，应该抱有什么样的态度和原则可以让更好的设计业务和产品呢？
三、初入 TO B 的几点建议
1. 相信业务专家
B端行业中产业属性非常重，主要体现在有很多线下的场景、细节和业务逻辑。
作为一名PM，无论你的逻辑思维多么优秀，理解能力多么强，想要充分了解这些业务提高决策的有效性，一定是需要足够长的项目积累的，而互联网人往往不是这些场景的直接用户，凭借逻辑演绎决策有效性不高。
2. 心怀敬畏
无论你在之前的业务中多有么闪亮的业绩，面对产业互联网基本上不要总想颠覆。
任何一个业务模式的搭建都是依托于产业的业务场景，前面提到由C TO B的核心转变是对于「系统」依赖逐渐降低，所以凭借互联网产品较为擅长的重构系统设计来颠覆业务模式是行不通的。
对前辈和行业心怀敬畏，在推翻前考究清每个产品设计细节的业务背景，能够帮助你做出更准确的决策。
3. 独立思考
当然，对专家的信任、对前辈的敬畏并不代表着人云亦云的纯执行。
扎扎实实做产品、关注业务中实际存在的问题，遇到问题首先尝试独立思考产出解决方案，在解决问题的过程中逐步提升业务认知，每一次决策后分析与专家和前辈对比思考造成偏差的原因、或者决策正确的关关键因素、多与业内团队交流分享信息，将信息从点到线，由线到面，逐渐完善对产业全貌的认识。
四、B端产品经理的价值
B端产品经理在产业内大致按照面向的用户将产品设计目标分为两类：
面向外部客户：产品解决方案满足需求、服务好、价格合理。
面向内部用户：保障面对客户视角的服务、体验不断改善、提升效率、降低成本。
在我看来产品经理解决问题就是创造价值，解决问题的能力就是产品经理的核心竞争力，俞军老师也在分享中提到「用户不是自然人，是需求的集合」，而对于C端和B端，需求的集合其实是有很大区别的。
1. C端需求的集合
人在场景下的需求。
做好一款C端产品，需要洞察人性本质需求，有很强的同理心，能够透过现象看清本质。
成功的C端产品一定是满足了本质需求，比如微信满足了社交、抖音满足了新鲜感、pornhub满足了性、DIDI满足了出行、拼多多满足了贪欲等等。
2. B端需求的集合
组织在生产中的需求。
做好B端产品，需要PM拥有好的商业感，成为业务专家，能够梳理「供需关系、生产管理、供应链管理、财务管理」等相关信息，解决业务问题为业务的发展提供价值。
PM要有能力挖掘企业的效率、成本的痛点，并打造满足企业需求集合的产品。
四、如何开始设计B端产品
那么如何开始设计B端产品呢？
1. 了解你的客户、业务的痛点
B端业务非生活化场景，对于PM来说缺少过往经验支撑，需要更深入业务场景中进行深度的调研，了解你的客户是谁？而往往B端产品的客户分为两类：核心决策者、产品使用者，这两类客户的需求都需要了解。
核心决策者：
他们是你需求的核心来源，是关系到你的产品是否被使用的关键决策人，了解他的痛点和KPI，衡量这些与你产品功能的满足度与关联度。
决策者的痛点往往就是业务的痛点，衡量你产品价值是在痛点上是否足够有效？产品提供的「新体验」是否能够超过决策者心中的「旧体验+切换成本」。
产品使用者：
他们是真正使用你产品的用户，了解他们的「KPI」或「阶段目标」非常重要，因为这些往往体现了高层对于岗位的核心诉求，衡量你的产品是否能够帮助他们更好地完成他们的目标至关重要；其次是产品在被使用过程中是否存在体验痛点不断迭代和完善。
举个例子来说，目前我所在的团队在今年春季会全量推进一款名为「新未来黑板」的产品，它在在线的应用就非常符合一款B端产品的演化路径。
新未来黑板的客户有两种，「核心决策者」其实是总部和分校校长，希望能够让在线场景下的主讲老师使用一款稳定&效率高的上课软件满足主讲授课需求。
对于2018年的他们来说，旧体验的痛点 可能是在线讲台、英语未来黑板、语文未来黑板、云课堂等等产品的「在线场景稳定性不高」「功能少且更新慢」「在线授课体验适配度不够好」「多种产品混淆」等等。
而新的未来黑板目标是形成在线场景下的唯一授课工具，满足教师在站立直播模式的授课动作，一些核心操作体验的习惯与各个旧产品端差距并不大。
这样在「核心决策者」心中，「新体验」解决了他们在「旧体验」中存在诸多痛点，解决了问题提供了价值。
在「产品使用者」方面我们主要关注的主讲使用体验，经过对于授课场景的探索，对课中教学工具、互动发起、同屏等做了诸多体验优化，解决使用上的问题；同时还发现「产品使用者」在课前的部分备课、课件修改等需求也可以在这里被很好的满足，这就为他们提供了更多的新的产品价值，最终完成了新未来黑板的推广落地。
当你要启动设计或优化一款B端产品，除了解你的客户和痛点外，对当前的业务流程梳理也是非常必要的。在梳理业务流程的过程中，我个人的习惯是从大到小，由主向辅。
1）从大到小
意思是从大的可见的业务流程梳理起，外在可见的业务流基本是通过我们产品体验和初步的认知就可以了解清楚的。
拿在线教育直播课举例，只要体验过一次产品，与你的客户深入聊过几次，列举出业务流中的客户角色以及各角色的显性流程和关键节点是不难的，学生、主讲老师、辅导老师、课前、课中、课后，从这几个维度来梳理「完成一节直播课」所需要的核心流程，这就是「大」。
何谓「小」，小则是你作为什么样的角色，关注哪些模块的流程，专注梳理大框架流程中你关注的业务模块处于何种地位？有何不可或缺的作用？
将显微镜聚焦在你核心客户的业务流程中，结合深入的调研来完成「小」流程的梳理，从而得到一个清晰的业务流，并且也可以弄清楚「小」之于「大」的作用。
在这里说一下，其实我们在初次梳理大流程时，如果迫于条件限制，可以不必保证全部流程的正确性，需要注意的是，「大」流程中愈发接近「小」流程的部分，保证正确性的必要性越高。
2）由主向辅
我们梳理流程的核心目的是产出一份完整的产品架构，所以在梳理完核心流程后，对于辅助流程、分支流程、逆向流程、都要单独的梳理。
比如，在一节直播授课中，主讲老师课中断流后的恢复场景是什么样的？此时如果有前一个互动正在进行中主讲侧呈现的状态是什么？
比如，正常流程是主讲先「下课」后「结束推流」，但如果主讲由于特殊原因忘记了「下课」直接断流，后续的流程会是什么样的？
而类似这些辅助流程和逆向流程，往往都与下游其他在你关注点之外的模块的产品策略相关联，所以在优先了解你的主流程后，对于分支辅流程也要花同样的精力来梳理。
3）提炼产品架构
在拿到全部主辅流程及业务流框架后，你应该对于流程中每一步客户的动作了如指掌，下一步就是落实在功能上，你的产品哪些功能承接着哪些流程动作，将featurelist输出，除了名称外，功能描述、业务动作、输入输出都尽量列举清楚，这时你会得到一个功能表格。
之后要做的就是将功能分类，可以先后按照 主辅流程、产品模块&模式来步步拆分，将功能表格转变成产品架构模块。
很多同学认为到这一步就可以了，完成了产品架构的输出。
其实不是的，对于部分产品来说，用户在使用你产品完成业务动作会有一些「前置条件」「后续影响」、会有一些系统层面支撑的模块不在你关注的核心流程中，这部分系统or功能依赖恰恰会在「大流程」中。
将这些往往以「中台形式」or「底层数据形式」支撑你核心业务流的模块or系统也放入你的产品架构，用特殊的模块特性标出。
这样，才是相对完整的一个产品架构。
依据完整的产品架构，后面无论出于何方需求对于产品中模块的迭代对你来说，才将会是清晰、准确而系统的。
五、只做产品就够了吗？
任何一款产品的诞生，都是服务于公司业务的，而对于一款B端产品来说，如果没有一个有效的「业务运营体系」，你会逐渐发现你的迭代远跟不上业务的目标，你设计的功能不能很好地满足业务诉求，你的客户信任感逐渐降低却不自知等等情况会层出不穷。那什么是一个有效的「业务运营体系」呢？
有效的「业务运营体系」分为对外和对内：
对外来说，业务运营是营销策略、客户服务、培训支持等。要实现业务的增长目标，并为客户提供更好的的业务体验。
对内来说，业务运营是流程管理、数据分析、行业/用户/政策研究及运营支持。
对于不同的B端产品，不一定有特别严格的内&外体系的划分，体系模块也是因公司组织和业务而定的。
我所在的产品线是对内的B端产品线，对我们来说「业务运营体系」需要包含如下几个模块：行业研究、数据分析、运营支持、客户服务体系，这样一个「业务运营体系」目标是保障业务运作的高效、流畅，保障业务决策的有效性、合理性。
在「业务运营体系」中，「客户服务体系」在日常产品迭代和业务运行中至关重要。
好的客户服务体系是由一个根据企业组织结构特性而定制的「服务流程」来支撑运营人员需要管理当前的「服务渠道」作为一切开始的触点，打造让产品的客户方便、快捷的找到你的高覆盖度的服务窗口；一套完整的「培训体系」也是根据客户渠道及画像来定制的，不同的客户理解能力和组织结构层次应该对应不同的培训方式和内容，其中包含：
售前（交付前）：建立客户档案、产品手册、宣传材料、演示账号等；
售中（使用中）：关键决策人维护、产品反馈跟进、产品培训、客服咨询答疑等
售后（使用后）：产品满意度回访、异常&逆向流程支持等
「服务效果追踪」是对于服务体系所呈现的效果进行反馈与跟踪，及时调整服务流程及落地细节，提高最终服务效果。而「服务质量数据闭环」更多是针对「客服人员」本身的服务质量而定义的量化数据，量化的维度除了满意度外，通常还包含：咨询响应及时度、异常处理有效性&时效性等等。
一个良好的「客户服务体系」应该要呈现人效降低而服务质量上升的趋势，同样也适用于「业务运营体系」的有效性衡量标准。
