编辑导读：C端行业已经是一片红海，流量红利几乎已经见顶，不少企业将目光转向了B端行业。尽管B端产品未来可期，但是初次接触B端的产品经理还是一头雾水，更有观望者迟迟不能下定决心。本文作者从自身工作经验出发，分享总结了快速上手B端业务的几点方法，与大家分享。

不是在找工作就是在找工作的路上，这句话基本概括了我今年一年的状态：

• 从初识产品到软件销售
• 从软件销售到产品助理
• 从产品助理到产品经理
• 从to C到to B

C端呢接触不深，B端呢也仅是皮毛。

在入职当前这家公司前，二轮的时候领导跟我说过一些话：说我当前太浮，缺乏一个机会沉下去，缺乏一个行业磨炼。

我觉得很中肯，很贴切我当前的状态，而且这也是我接下来的目标。

所以，今天这篇文章聊聊我在这家公司的感受，希望其中一些经历能够帮助到你。

一、产品篇

产品的价值是能够解决“目标用户”的“问题”。

C端产品解决了自然人的需求，B端产品解决了法人的诉求。

B端客户使用你的产品一定是你能够满足他的诉求，即你的产品能为我带来什么，而不是我使用你的产品能做什么。

为了进一步作区分、这里将B端产品分为三类：

1. 协同产品（OA、ERP、WMS等）
2. 业务产品（专注于某个行业中的某个链条提供解决方案）
3. 标准产品（SAAS平台、PaaS平台）

而B端产品又不同于C端产品，不会出现一夜爆火的“合成大西瓜”。

做好B端产品一定是持续的做好某一类事，这也是因为其本身业务模式复杂、商业领域宽广

面对的对象不同，也决定了B端产品的工作性质。C端，是尽可能的去熟悉用户。而B端，是尽可能的去熟悉业务、了解商业模式。但对于企业来说，面对不同的产品，他们选择的决定因素往往是产品能满足“我”的哪一类诉求

即：

在我看来，B端产品更注重结果，B端客户选择你的产品，更多的是边际结果效应（即我花钱花你的产品能够满足我诉求的最终效果）。花钱去买一个未知的东西，抱歉，企业家不是在做公益，所以他们更期望以“已知甚至是超预期”的结果为导向。

再来说下我当前的状态，如果说B端产品的经验，那我的经验可能就是产品的第一份工作——软件销售，每天面临着不同的客户。B端产品的经验基本为0，所以我很珍惜每一个岗位，也期望在每一个岗位上都能有所成长。

公司墙面上贴着“好的产品，一定是三分钟就学会”的几个大字，但公司的产品我足足熟悉了一个星期才摸到门道，更多的原因是因为不熟悉产品所面对的客户的诉求，其中包含了对客户的组织架构、行业流程、业务逻辑和商业模式等的理解。

三分钟就会的产品一定是简单的产品，但B端产品不仅仅是要求简单，更重要的是“有用”。

首要追求的是用，在用的前提下去满足简单。

换了工作后，我是如何去熟悉B端产品的“用”呢，这里有一下几点经验：

（1）寻求帮助，这是我认为能够最快的帮助你熟悉产品的方法，在一家新公司，如果你真的能够碰到哪种很诚心诚意的帮助你、回答你问题的人，那真的是你的幸运呢（仅指打工人）；

大多时候，大家都是丢一个文档给你，需要你自己去通读文档。这个时候文档的内容就很重要的，同样的是需求说明文档，有的包含了流程图、结构图、用例图、原型图等内容，有的文档就只有某个功能的操作步骤说明，稍微好点的会给你加上功能注释说明，说的就是我现在这家公司；

在能够获得最大帮助的前提下，一定要善用周边的人缘关系。

（2）其次就是自力更生，无论是否公司已有相关文档提供学习，个人还是建议重头进行梳理一遍，重头梳理能够让你站在设计者的角度，对当前产品的架构有更深一步的认识。

1）梳理流程

• 业务主流程，侧重于线性流程，更注重于当前整体业务的步骤，而不用分散精力去关注是谁去做的从大体上去描述业务是如何运转的
• 其次是业务子流程，子流程是对主流程的分解，其本身是一个完成处理过程，可以单独启用运行，也可以嵌入到其他流程使用
• 最后是跨角色或系统流程图，主要是梳理各角色或系统之间的分工、模块之间的串联

梳理流程，是理解业务，了解产品的第一步

2）梳理页面

产品存在多少个页面，页面之间的跳转关系是怎样的，是如何进行交互的，怎么跟业务进行关联的，结合具体的流程进行梳理页面，可以进一步帮助我们俯瞰整个产品的组成架构。

利用Xmind将页面进行归纳梳理，优先梳理流程页面，将所有页面列举出来，然后在页面层级列举详尽功能，将业务与功能进行串联。

3）梳理用例

简单来说就是梳理系统中有哪些角色，每一类的角色能使用这个系统做什么。

一个完整的用例图，就像一幅骨架支撑着整个身体。在设计产品时，我们往往从架构出发，当一个整体架构出来后，细节的地方不至于会影响大局。而在熟悉产品时，往往是从细节出发，就像医生看病，医生不会让你上来就直接手术检查。

4）梳理权限

B端产品不同于C端产品，B端产品更注重权限的管理，对权限控制的要求更高。所以，在B端产品设计时，需额外注意权限的控制问题。

梳理所有角色的不同页面权限、数据权限、功能权限一定是放在熟知产品一定阶段后，在此阶段再去梳理权限，更加容易理解整个系统是如何基于现实业务场景进行设计的。

公司的墙面上还贴着这样几句话“基于场景做方案，基于场景做服务，基于场景做产品”、我觉得加上业务会更好——“基于业务场景做方案，基于业务场景做服务，基于业务场景做产品”，在B端产品设计中，场景的考量一定是贴合业务的，脱离业务场景的需求，大多数是不可做的需求。

另一句是“做产品之前，先将自己变成用户”，放在C端，这句话我是认同的，但在B端，我是不认同的。

二、需求篇

B端的需求来源于产品所面向的客户，定位的客户不同，产品设计的业务流程、功能侧重点都不同，此时，需求的判断和筛选就显得格外重要。

在来这家公司入职的第四天，我被派到外省出差驻点服务，期间接到一个需求，针对这个需求，当时只是简单的向甲方相关人员了解了下，然后就想当然的去做了，直到第一次与甲方过完需求后，才发现牛头不对马嘴，最终的结果只能是重新梳理需求，直到现在，这个需求仍有没有考虑周全需要优化的地方。

存在几点错误：

1. 盲目自信，误以为自己理解了需求，想当然的就按照自己的想法去做了
2. 没有反复的跟客户进行确认，在没有充分的了解业务场景的前提下，就开始着手工作
3. 只顾全了单方面角色使用的情况，欠缺考虑多方协同的情况，在B端产品，大多时候会涉及到多方参与
4. 未去深入了解系统，不熟悉公司的开发方式，跟研发人员欠缺前期的需求沟通，未站在更高层次去看待需求

为什么会说未站在更高层次去看待需求呢？在B端，需求可能没有真伪，只有可做可不做，就比如客户告诉你这个需求要做，因为他花了钱。既然是花了钱的东西，就要体现出物有所值，你的服务响应也是体现的一方面。其次就是老板的想法，你得找到充分的理由告诉他，这个需求到底是怎样的一个需求，值多少钱？如果不值钱的需求，做出来最后也只会落得一地鸡毛。

在C端，用户会被贴上不同的标签，用于进行区分，在B端同样，也需求对客户进行分级，所以才会有标准化产品和定制化产品。

不同的客户需求存在差异性，这也导致B端的需求往往很难做到统一标准化来满足不同客户的需求差异。

在面对B端需求时，这里有几下几个建议：贴合业务场景、深入一线调研、主动引导客户、持续接收反馈。

“贴合业务场景”，任何脱离业务场景的需求都不是必须要做的需求，前文说过，B端需求，大多只有可做可不做。这个可做围绕的是业务上的必要，而不是提出人的必要。可通过最终呈现的结果为导向，贴合业务场景进行综合判断。

“深入一线调研”是指在了解需求时，找到需求提出人是很重要的。如果不了解需求提出人提出的原因，就无法真实的还原需求的业务场景，最终导致理解偏差。深入一线不仅仅是需要理解需求，还需要发散需求，考虑需求涉及的参与角色，足够深入，才能有足够的理解。

“主动引导客户”是指通过主动引导客户转变需求方式，比如客户最终想要的结果是A，系统却只能实现B，这时，不到迫不得已的时候不要给客户选择方案，结合客户的需求，将客户引导到在B的基础上完善去满足A，结合业务场景进行线上、线下的协同方式。最重要的是主动判断，而不是被动的接受。

“持续接收反馈”是指对客户做好回访需求，在B端通过问卷、访谈的形式收回的反馈效果可能不佳，因为你永远无法做到满足不同岗位、不同人员的要求，他们在使用系统的时候，考虑更多的是自己使用的方不方便。可以依据客户层级构建不同反馈渠道，持续的接收不同层级用户反馈的需求以及问题，然后带到产品中进行验证，提取真实有效的标准化需求。

最后

从我开始接触产品时，我便一直认为产品经理的最终价值是发现问题并解决问题，到现在为止依然没有变过。发现问题容易，解决问题才是难点，推动方案落地并对其负责更甚。

希望大家在产品这条路上有希望、有梦。

作者：不知名的魏某某；公众号：不知名的魏某某

本文由 @不知名的魏某某 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。