编辑指南： c端行业已经是红海，流量红利几乎名列前茅，很多企业都把目光投向了b端行业。 尽管b端产品前景光明，但初次接触b端产品经理还是一头雾水，更让观望者难以下定决心。 作者根据自己的工作经验，分享了快速着手b端业务的几种方法，并与大家分享。

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

从第一次产品到软件销售从软件销售到产品助理从产品助理到产品经理从to C到to BC端很少接触。 b侧也不过是皮毛。

现在进入这家公司之前，两轮的时候，领导对我说了几句话。 我说我现在太浮躁了，没有机会下沉，行业锻炼不够。

我很高兴，我觉得很适合我现在的状态。 而且这也是我的下一个目标。

所以，今天这篇文章谈谈我在这家公司的感受，希望其中有对你有用的经验。

一、产品篇

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

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

b终端客户使用你的产品，一定是你能满足他的诉求。 也就是说，是你的产品能给我带来什么，不是我能用你的产品做什么。

为了进一步区分，这里将b端产品分为三类。

联合产品(OA、ERP、WMS等)业务产品)集中在某个行业的某个链条上提供解决方案)标准产品) SAAS平台、PaaS平台)不同，B端产品与C侧产品不同，是一夜之间爆炸性的“

制作b端产品，一定会持续做某种事情。 之所以这么说，是因为其自身的商业模式复杂，商业领域广泛

面对的对象也决定了b端产品的工作性质。 c方是尽可能熟悉用户。 b方是尽可能熟悉业务，了解商业模式。 但是，对于企业来说，面对各种各样的产品，他们选择的决定因素往往是产品能够满足“我”的哪些诉求

也就是说：

在我看来，b端的产品注重结果。 b端客户选择你的产品，是边际结果效应(也就是我花钱可以用你的产品满足我诉求的最终效果)。 很抱歉花钱去买未知的东西，但企业家并不是做公益的，所以他们希望重视“已知或超预期”的结果。

另外，说一下我现在的状态，说一下b端产品的经验，我的经验可能是产品的第一份工作——软件销售，每天都面对不同的客户。 因为b端产品的经验基本上是0，所以我很珍惜所有的岗位。 另外，期待着能够在所有的职场中成长。

公司墙上贴着“好产品，三分钟必到”的大字，而公司产品我十分熟悉一个星期才接触到大门，是因为我不熟悉产品所面临的客户诉求，其中包括客户的组织结构、行业流程、行业流程

3分钟能完成的产品一定是简单的产品，但b端的产品不仅简单，“有用”也很重要。

第一追求的是使用，在使用的前提下满足简单性。

转行后，我是怎么熟悉b端产品的“使用方法”的？ 我在这里有一些经验：

求助。 我想这是我能最快帮助你熟悉产品的方法。 在新公司里，如果你真的能遇到真诚帮助你，回答你问题的人，那真的是你的幸运(仅指兼职的人)；

大多数情况下，大家都会给你弄丢文档。 你需要自己通读文档。 此时，文档的内容很重要。 同样是要件说明文件，有包含流程图、结构图、用例图、原型图等内容的，也有只包含某个功能的操作步骤说明的。 稍微好一点的东西附上功能注释说明。 就是说我现在在这家公司。

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

)2)接下来是自力更生。 个人建议重新整理一下，不管公司是否已经提供相关文件提供学习。 通过重新整理，可以站在设计者的立场上，更深刻地认识当前产品的结构。

1 )整理流程

的主流程侧重于线性流程，侧重于当前整个业务的步骤。 不用在意是谁去的，我就大致说明一下业务是如何发挥作用的。 子进程是主进程的分解，其本身可以单独启用运行，也可以将其合并到其他进程中使用。 最后是角色和系统之间的分工，模块之间的合并整理过程，主要是理解和理解业务

2 )整理页面

产品存在几个页面，页面之间的跳转关系是怎样的，如何互动，如何与业务相关，通过结合具体的流程来整理页面，从而俯瞰整个产品的结构体系结构

用Xmind汇总整理页面，优先整理流程页面，列举所有页面，在页面层面列举详细功能，连结业务和功能。

3 )整理用例

简单地说，就是整理系统有什么样的作用，每个种类的作用都可以用这个系统做什么。

完整的用例图就像骨骼支撑着整个身体。 在设计产品的时候，我们往往从架构出发，这样在整体架构出来之后，细节就不会影响大局。 熟悉产品的时候，多从细节出发，就像医生在看病一样，医生不会载你直接手术检查。

4 )整理权限

b侧的产品是

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

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

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

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

二、需求篇

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

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

存在几点错误：

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

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

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

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

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

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

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

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

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

最后

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

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

作者：不知名的干净的蚂蚁；公众号：不知名的干净的蚂蚁

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

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