‘壹’ B端公司如何进行产品运营
相比目前市场上C端运营的一片百花齐放，B端产品的公司大多都是没有做产品运营的，只有部分做sass产品的公司才会专门进行运营相关的工作。
B端公司不做产品运营的原因通常是认为B端产品的运营能为公司带来的收益与价值有限，与其将资源投入到运营上，不如加强渠道的建设。产品运营就是做内容建设、用户维护和活动策划，除了用户维护有价值外，其他内容投入产出比太低，这是B端公司不变的认知误解。
但事实上，内容建设、用户维护、活动策划都是产品运营的方法。产品运营的本质就是通过各种途径去达成既定的产品指标，而方法只是工作内容的表象，因此对于B端产品来说渠道建设也是运营，更宽泛的说，市场即运营。
对于C端产品AARRR模型五个环节的指标就是产品运营的核心目标，而B端产品的指标则简单粗暴——公司产品业绩，或者直接点说就是销售额。
相比较来看，C端产品的运营比较强调运营的方法与手段，在完成各个数据指标时需要使出奇技淫巧，而B端则不重技巧与手段，客户源稳定所以各环节相对固定，所以运营方法用好，建立起框架是B端公司的主要方向。
表1-1 C端与B端运营对象区别
表1-2 B端产品的运营对象
二、运营框架
在运营B端产品时，建立一套运营框架是必要的，在框架的各个环节采取对应的方法指导运营，以提升产品业绩。
B端的运营框架是从市场渠道-产品传播的通路，类似于C端从用户的生命周期开始建立框架模型，B端从产品自身与客户接触的流程出发，来建立运营框架模型。
B端产品运营的框架分为5个环节：打通渠道、客户服务、品牌建立、口碑传播、内容投放。所有运营的方法都分布在这五个环节中，而运营工作也是基于这五个环节展开的。
1.打通渠道
触达客户，即通过什么样的渠道/路径找到目标用户群。通过运营的方式，寻找到目标客户，并将目标客户转化为产品客户。诚然，最好的运营是让客户主动找上门来，对于B端的产品来说，打通渠道非常依赖于公司内的市场资源与业务人员的市场运作，渠道通路是直接影响销售额的主要因素。
2.客户服务
客户服务主要作为产品的辅助手段存在，有助于实现产品的快速落地及价值转化。客户服务的重点在于提升客户对于产品的满意度。
在客户服务的过程中，维护大客户和老客户的关系是重中之重，原因在于B端产品的获客成本非常之高，所以把握住已有的客户资源是客户运营的关键一点。
如何建立起一套客户服务的标准化流程，主要从客户培训、方案实施、异常响应处理、后期维护等四个角度出发，处理各种服务过程。
3.品牌建立
品牌对于企业来说是非常重要的门面，他能很好的体现一个产品的价值。所以，在B端产品拓展市场的过程中，除了渠道资源，最重要的就是品牌，业务B端产品与业务是深度关联的，产品价值很难直观的展现给客户，只有投入到业务后客户才能感受到产品价值。
因此，建立一个能为产品背书的品牌，使产品必然会受到客户的欢迎，这是一本万利的做法。品牌传播的本质是提升产品影响力，塑造产品价值，提升公司影响力地位，使收获更多客户资源，从而达到创收目的。
4.口碑传播
口碑传播，即当产品为用户创造价值，并得到用户认可后，运营将这一内容以案例的形式传播出去。与品牌建立类似，口碑传播让客户来为产品背书，尤其是行业内的知名公司——灯塔效应。对客户来说，行业内竞争对手使用的产品对其更具有吸引力，口碑传播对于B端产品有远远大于C端口碑的客户转化率。
5.内容投放
在基本搭建完成品牌与口碑之后，运营需要尝试向社会平台进行内容投放，简单来说就是软文与广告投放，通常B端产品运营只针对那些有一定客户基础的产品，这样能使效益最大化。
在内容投放时，做好用户画像，确保精准投放，这点与C端运营的本质是相同的。明确哪些是产品的潜在用户，对于那些相对封闭的B端产品做内容投放是重中之重，因为内容投放的价值是有限的，所以内容投放一定要提前做好方案，规划策略。
三、总结
综上，B端产品的运营目标是提升产品销售额，为公司带来可见的利润增长，运营方法的核心指标在于提升客户的“产品价值预期”与“使用满意度”。
B端产品的运营框架并不必严格按照流程执行，五个环节间的关系依赖程度不高，但是存在相互促进的作用，后期的环节的完成度一定程度上可以帮助公司进一步的拓宽渠道。因此，搭建品牌提升产品价值，提升满意度使行业内客户口碑传播，精准的内容投放，均可以帮助产品拓宽已有渠道，实现公司盈利。
‘贰’ B端产品员工管理优化及其历史数据处理
总结一下最近做的一个优化点，由于涉及到底层的东西，所以在此优化中，历史数据的处理是最麻烦的。有时我们认为最简洁、大家一致认同的方案不一定是最适合的。
这里提到的是企业管理软件中的员工管理与登录账号的管理。如果没有过相关经验不容易理解的话，可以联想一下OA系统，我们身为公司的一员，需要在OA系统中处理一些公司的业务，我们拥有OA账号。你的OA登录后看到的内容一定与你的领导登录系统看到的内容是不一样的，因为你们拥有的权限不同。同样小王也是公司的一员，但其是基层员工，在OA系统中可以查到小王的基本信息，但小王并没有OA的登录权限。
对于一款B端管理系统，系统要管理企业的所有员工，根据员工的不同岗位，管理员分配给员工不同的系统权限，或者没有系统权限（即没有系统的登录账号）。一些传统的ERP软件把这一点做的相当灵活，可能满足很多极端的场景。事情是相对的，足够的灵活，便要牺牲掉易用性，势必会对用户造成困扰。
上两张图是一些传统的ERP的管理模式，先建立员工，员工有自己对应的岗位，然后建立账号，每个账号有对应的角色（角色可以理解为权限的打包体，不同的账号可以共用同一个角色，即拥有角色中包含的权限，修改角色的权限，则拥有该角色的账号的权限一并被修改），然后把员工与账号绑定建立关系。这样做就相当的灵活，员工与账号是两条独立的线，最后把其关联起来。员工不绑定账号即代表此员工无系统的登录账号，账号不绑定员工即可能这是一个管理员的账号，没有具体的人操作。
这样做的缺点，一是操作复杂，一个员工如果要使用系统，其资料要到两个地方建立，学习成本与维护成本高；二是容易造成混乱，一个员工给了销售员的岗位，但在其绑定的账号里却给了收银员的权限。下图是一个真实的案例，客户实在是搞不明白员工、岗位、账号、角色之间的关系，为了给员工某个权限时，把所有的岗位都配给了该员工，但该员工仍没有想要的权限。
即然不同的岗位会拥有不同的权限，那为什么不在岗位上直接设置权限呢，而在员工的创建时直接选择是否开通登录账号，减少操作、减少客户要接受的概念。
方案中，在新增员工时选择是否开通登录账号，如果开通，则给出默认登录账号与密码，无需客户再设置；页面左侧可按岗位对员工进行筛选，然后可以对岗位进行权限的设置。这样客户就可以在这一个页面中完成员工与登录账号的维护，方便快捷，且不容易出错。
优化后的整个流程的确是要整洁很多，但是我们这不是一个从零开始的系统，做这种大的改动时一定要考虑到历史数据的处理。我们现有的客户该怎么办？新的改版会对他们造成哪些影响？这就需要我们拿新的设计方案与原有的系统做比对，原有系统中的每一个字段每一个概念，到新的设计中要怎么体现。如角色，这个概念将在新的设计中消失，账号列表也将不复存在，这样的改动，历史数据要怎么呈现呢？老客户对新的设计是否适应，是否需要重新学习？学习成本的高低？
为了处理历史数据，对设计方案做出了调整，把账号管理的入口放在员工管理页面，使其弱化。之前账号与角色的概念仍然存在，弱化账号与角色的概念，减少点击率。新增员工，如果开通登录账号，则账号管理列表自动生成一个账号；新增岗位时，便自动生成一个对应的角色，对岗位进行权限的设置，即是对角色设置权限。以前的逻辑仍在，仍能满足老数据，对于新签的客户，只要建立岗位与员工即可，方便快捷。 而老客户，在发版后第一次进入此页面时，给出浮层提成，告知客户这里的变化。
在开发之前，抽样几个老客户进行了调研，客户一致认为新的设计比之前更加简洁、容易理解，并表示弱化账号管理可以接受。
我在文章中只提取了主流程，实际上历史数据的处理相当复杂，有些数据的处理是我们在前期做设计时考虑不到的，这就需要后期与开发人员再不断的沟通，这种情况要提前与开发哥哥打好招呼，预留足够的开发时间。
翻阅客户数据，有时我们考虑的复杂的情况其实并不存在。如，没有绑定员工的账号，极少，数百家店 上千条的账号里，只有十几条账号没有绑定员工，其中三分之二的数据是因为之前复杂的流程造成的错误数据，已被禁用，剩余的几个是集团管理员的角色，这几个账号极少被使用到。通过与几家客户的沟通发现，他们使用系统是为了记录，如果哪里出错了可以有据可寻，可以通过系统去查找哪个环节的错，谁出的错，如果账号不绑定员工那就责任不到人了。虽然传统ERP的方案很灵活，但使用起来不方便，容易把人绕晕，并且这所谓的灵活在实际的场景中并没有被用到。
做B端产品最忌讳大而全，然而B端产品很容易被做的大而全，因为我们面对的是不同的客户，客户之间虽然有很多相似性，但他们也有自己的独特性，一旦满足不了他们的独特性 我们将有可能失去该客户，我们失去的极有可能是几十万、甚至上百万的收款，而这直接关系到KPI的完成，对于这种情况，领导会让我们以客户的需求优先。久而久之，基本功能加上各种独特的功能，就成了一个大而全的系统了。有一定工作经验的产品经理或者设计师，在做设计之前会考虑各种各样的情况，这些情况可能是真的存在，也可能是我们虚构出来的。这就需要一些取舍了，根据对市场调研以及与行业专家的访谈，来定义我们产品功能的留舍。
企业管理软件的体验任重道远，身为交互设计师，不仅要从页面布局、层次结构等方面优化产品，更要了解行业，从整个操作流程上做优化！
‘叁’ B端产品如何做好竞品分析
相比C端产品，B端产品很难做竞品分析，原因大概有以下几点：
除非是一些标准化程度很高的行业（比如财务管理系统、图书管理系统等），否则很难找到功能相似度很高的竞品。标准化程度高的行业里基本没必要做 竞品分析 ，因为经过红海中的残酷市场竞争，产品已经同质化（行业标准决定的），小公司被巨头用成本和服务品质碾压。
在标准化程度比较低的行业，通常产业链较长、商业模式复杂、地域差距较大，同时产品受到早期典型客户需求特征影响较大，又因为B端产品迭代周期较长，所以产品形态五花八门，各有各的细分市场。
B端产品不公开发表，客户内部使用，很难找到测试帐号。
最难的一点是，就算拿到测试帐号，看了别人的产品，可能没什么太大的借鉴意义。做B端的产品，每个产品都有自己路，自身条件不同、市场定位不同、商业模式不同、对行业的理解不同、技术不同，走的路可能截然不同，学习功能和产品特征基本很难成功（说是找死也不过分吧）。如果你想从产品中去学习别人对行业的理解，这也不是普通人能做到的。真正的行业专家、解决方案专家、产品架构师，有几个有时间去写竞品分析报告的呢？就算有时间，也只能写给自己看吧，在这个层面上，可以交流的人太少了。
但是不管怎么说，分析同行的产品总能带来一些启发，也是B端产品经理提升的途径之一，如何进行分析，还是有一些方法可循，所以试着归纳几点。
B端产品不像C端的产品的设计逻辑那么明显，或者说有的设计逻辑相当的隐晦。多收集一些背景资料有助于对产品的理解，这些背景资料可能包括：
公司背景，比如成立时间、地点、规模、发展史和关键大事。
技术背景，比如产品使用到的关键技术、技术合作伙伴、技术变革史。
早期版本，对比版本升级路线和行业发展路线可以对行业有更深的理解。
典型客户，典型客户的需求对产品的功能影响很大，也对自己对行业的理解有帮助
政府关系，中国国情，你懂的。
B端产品的定位方法与C端产品不同，C端产品定位的要素是：
细分人群
关键需求
B端产品的定位要素是：
产业链（ 价值链 ？资金链？信息链？）上的位置（在哪个环节）
发展方向（向上游还是下游）
C端产品的用户和客户身份通常是重合的，而B端产品复杂的多。尤其是基于工作流的产品，用户身份会非常多。共性的分析方法里边，以下几个角色是需要在产品里找到的：
交易双方
数据采集人员
决策者
系统实施人员
客服人员
技术维护人员
前三类人用的功能决定了产品的业务逻辑，后三类人用的功能决定了产品的单位客户成本。业务逻辑决定了产品的竞争力，单位客户成本决定了产品的市场生存能力。
业务场景主要有两大类：
生产场景（重视数据采集、协作效能、责任确认等）
管理场景（重视决策分析、风险控制、过程监管、质量控制等）
对于不同的行业和产品你可能能想出各种对业务场景分类的方法，但是做竞品分析真的没必要搞的太复杂。生产场景分析的目标是找出效能优化的手段，这就是需要对行业有深刻理解的地方，管理场景分析的目标是找出卖掉产品的方法，这是客户购买你产品的动力。
在任何行业全产业链产品毕竟凤毛麟角，既然多数B端产品都是只解决一个环节的问题，那与其它产品的集成方式就很重要，友好的集成方式决定了你的生存空间。一个没有API的B端产品就像食谱特别窄的生物物种，离开特定的环境根本没办法生存。粗略的分析产品生态大致可以看这几个方面：
是否有开放式的帐号系统（接受第三方帐号授权，开放帐号API）
是否有数据交换机制，比如文件数据交换（导入导出、兼容多种文件格式、兼容数据交换标准）、数据交换API
是否可以适配多种硬件
是否有代理商和 分销商 的支撑体系
分析竞品的生态环境，对比自己产品的生态环境，可以分析出很多问题。
分析商业模式有三个要点：
成本分析。评估竞品的研发固定成本和单位客户变动成本。如果竞品为客户做了大量的定制开发，那他的单位客户变动成本就很高，可能就很难做大。
销售分析。看典型客户数量，代理商数，二次开发商数量，评估销售能力
有无辅助产品线。如果该竞品有其它辅助产品线，已经形成产品群，那要看这个产品在产品群中的定位，是个防守型产品还是进攻型产品。防守型产品负责抵御竞争，进攻型产品可能才是盈利的金牛。
结束语
为什么谈了这么多都没提到产品功能分析？为什么没提到 竞争优势分析 ？B端产品的优势是企业的内功，绝不是什么功能。产品定位、商业模式、技术积累、成本优化、行业理解和产品生态这都是内功，是心法，产品功能只是招式而已。
‘肆’ 新接手一个产品，如何去思考它的优化方向
这里以B端产品，TMS（物流运输系统）这类业务系统为例。
我认为TMS系统的优化方向和思路主要分四个。
1、满足新的业务场景+业务需求
2、提高物流组的业务效率
3、从指标KPI业绩的角度出发，研究每个环节里指标的异常和可优化的地方，例如物流这块就是签收率（时效）和成本 。
4、从大局和战略的角度出发。从物流管理的角度，去重构业务流程、对系统架构重新设计，或者去优化整个物流运输的体系，例如TMS\OMS\WMS三者流程的配合
也就是，业务、效率、KPI、战略四点。再详细地说每一种类型。
一、新的业务场景+需求
首先，一家公司的物流业务肯定是变化，若一成不变要么发展到了顶峰，要么没钱去扩展新业务，公司走下坡路了。前者国内京东顺丰阿里等也不敢说其物流体系已经成熟了，后者趁早离开为佳。所以对于新的业务场景，那么系统的优化，一是能够嵌入新的业务功能，又使之不会影响大体的流程。二是保证系统的架构合理不臃肿或者从底层的根就是错了，后面加业务场景时，使整个系统长歪，到时整颗树都得砍掉。
二、提高业务员的效率
这里再分两种，一种是老手业务员，一种是新手业务员，因为系统是不断地累加业务和需求的，所以系统结构发展到最后会有些乱和臃肿，这种对老手业务员并没有什么区别，但是对于新手业务员，系统的结构臃肿会导致学习成本比较高。如果结构比较清晰，又不是经常更换业务员的，可以简单地修葺一下结构，优先级不是很高。
对于老手业务员，可以去研究业务员的日常操作，也就是一天的工作流程，现有的工作流程中最占用时间的、最影响效率的、需要大量人工去操作的，这些都可以去评估能否通过系统、算法等来进行辅助或者取代。其次就是去解决他们在操作流程中遇到的问题。例如，导数的过程太慢，例如对账不准采用人工，例如异常单，每次都需要人工去判断……
还有一类方向，就是推智能化和自动化，京东的战略目标一直是这个，刘强东也喜欢搞这个，用无人仓无人机无人车去取代掉仓库作业员，用销量预测和智能补货去取代掉采销人员，无人超市取代掉收银员。同样的任何B端的业务系统都是可以的，例如通过算法实现包裹的自动分配，异常单的自动处理这些……从而去减少人工成本和减少出错率。
三、从KPI的角度
物流运输在提高时效这一块要从整个流程来，例如从订单下单，到签收的整个环节，不仅仅是物流这一块，还有前面的OMS（订单管理），WMS（仓库作业），再到最后的TMS（五路运输）。我了解到的，有时候因为库存不足的原因，一个订单卡在了那里好几天下发不了仓库生产，或者异常单的处理流程繁杂，或者分配物流渠道的算法没有选择最优路径。库存不足这一块怎么去优化？异常单的处理流程怎么去优化？分配物流渠道的算法怎么优化？这些一思考，自然知道系统该怎么做了。
四、从战略的角度
这种一般都是对业务有一个更明确、新的定义，或者对系统有底层性的改造。例如供应链的采购，原本是人工去下单，和根据库存的水位来进行补货。现在采用供应链的拉式补货理论，通过销售来驱动，那么在系统的底层就需要加一个预测模块来支撑整个系统数据的输入，预测销量作为数据的输入项更换后，后面一些被影响到的都要变。再例如物流的运输一开始是通过第三方的物流商来解决，现今公司的业务发展到一定的规模，想通过自建物流渠道的方式来降低成本，那么自身的一个物流渠道运输业务，又会去更改到整个系统的作业流程。
以上，对于B端类型的业务型产品，从这几个角度出发，总有所得。
‘伍’ B端产品个性化需求处理的四个步骤
关于B端产品（企业服务）的个性化需求如何做，这是一个所有B端产品都要面对的重要问题。通常，我们会先用已有方法（C端产品）解决现有问题（其实是新问题：B端需求），失败后，才会发现新特征，总结提炼新方法。
相比C端需求的单点和单线特征，B端的需求更为复杂，有两大特征：更多角色反馈、更多业务场景诉求，听起来声音多、看起来需求杂，而如果产品经理对需求归类不明就会导致功能开发过度或缺失。
B端产品需求复杂的重要原因是其服务对象不再是单个个体、消费者，而是一个行业、一个组织、一个业务。所以B端产品最基础的需求逻辑是要：
企业和产品经理收集了一大堆需求，问题是：做不做、什么时候做、做哪些？这是从业务逻辑到产品逻辑最重要的内容之一：对需求做判定。
B端产品可以划分为两类：行业型B端产品、场景型B端产品。行业型B端产品服务于特定行业，产品一体化，现在各个行业SAAS数字服务商大都如此；场景型B端产品在众多行业的特定场景中服务企业组织及工作者，如：ZOOM、钉钉。两类共性需求维度不同，但两者 最终目标都是：形成有效的业务闭环，完成有效的价值链输出。
刚才讲B端产品最基础的需求逻辑是：满足业务链条的需求和满足组织管理的需要，形成有效的业务闭环则是满足以上两个条件的必要条件。
产品在不同阶段形成的业务闭环可以有不同维度、链条有长短。在前期，产品规划有着非常重要的作用，包括：产业理解、业务梳理、产品定位、架构设计、版本规划、实现路径等，进而能够需求圈层：通过获取全面需求、基于产品定位和业务场景， 做业务结构，圈定呼需求层及相关范围。 开发阶段和运营迭代阶段获取的个性化需求，其实是对需求层的一个再认知和补充完善。
找到的一个需求层做为切入点，一层圈一层，相互独立且相互关系，形成需求圈层，然后细化各需求范围、确认相关需求内容， 详情内容在《B端产品规划如何做》里说明。
个性化需求分析有两大目的：补充和完善已知需求层、提炼发现新需求层。整个过程是：对需求处理和定义，归纳已有属性和发现属性，选择分析模型，设定判断规则，完成需求的归类和判断。总结分为 四步骤：需求定义、归纳属性、聚合模型、需求判断。
需求常常复杂混乱、不清晰不完整、浅层离奇，需要对需求加工处理，判断用户真正的痛点，获取客户真正的需求。
有一句话，很生动地反映出没有正确理解需求的场景： 没见过 汽车 前，用户只想要更好的马车！
C端产品功能的背后，隐藏的二次驱动需求常常是用户的 情感 ， 情感 吸引用户，需求分析模型有马斯洛需求原理和Kano模型。
B端产品功能的背后，隐藏的二次驱动需求常常是客户的利益，利益撬动客户 。以会展行业数字产品举例：服务客户，多是产品需求或服务需求；服务客户的客户，多是关系需求或成功需求。客户需求层次例图：
B端产品的需求，一方面要全面收集，以确保对业务完整掌握，另一方面又因为需求众多、复杂混乱，难以管理。因此需要对所有需求进行装箱归类。
C端产品可以采用ROI（Return of investment，即投资回报率）的方式，归纳为价值、投入两个属性；B端产品可以采用广度、深度、战略、技术通用四属性，而我在做会展行业B端产品时，基于会展行业和自身情况归纳为需求的四大属性、十一小属性。
四大属性：需求广度、客户价值、商业价值、成本周期；十一小属性：共性/频率、入口/链接、产品需求、服务需求、体验需求、成功需求、客户影响、技术引领、营收能力、投入资源、时间周期。
每一个需求，都可以抽象总结出多个维度的标签属性，成为聚合模型的计算因子。
聚合模型是需求分类的一种有效工具，是需求判定的一种前置过程，帮助我们更精细、多维度的理解和划分需求。介绍两类、四种分析模型，两类：单属性分析、多属性聚合分析，四种：痛点/价值曲线图、计分卡、二维四象限图、三维模型。
1）价值曲线图
依据客户流程及其对应需求，提出产品方案思路和评估方案价值，从而衡量确认重要需求和好的产品方案，例图：
2）计分卡
设置需要计分的因子及其权重（总和为100%），进行计分评选排序。当需求来源于销售、运营等各个部门，可由评分小组共同填写评分，过程中发现更多思路，达成目标共识。
3）二维模型
聚合各属性因子，权重评分、二维归纳，举例：价值（共性/频率、入口/链接、产品需求、服务需求、体验需求、成功需求、客户影响、技术引领、营收能力）、成本（投入资源、时间周期），划分排序为：高价值/低成本、高价值/高成本、低价值/低成本、低价值/高成本。二维模型因其属性因子较少，操作简单易懂，适用于较少属性的需求分析。
对复杂的属性需求来说，因子更多，权重计算容易模糊有偏差，常常导致结果不准确。例图：
4）三维模型
聚合各属性因子，权重评分、三维归纳，举例：共性（共性/频率、入口/链接）、价值（产品需求、服务需求、体验需求、成功需求、客户影响、技术引领、营收能力）、成本（投入资源、时间周期），按各自高低标准聚合为8类：{价值高、共性高、成本低}，{价值高、共性高、成本低}，{价值高、共性低、成本低}，{价值低、共性高、成本低}，{价值低、共性低、成本低}，{价值高、共性高、成本高}，{价值高、共性低、成本高}，{价值低、共性高、成本高}，{价值低、共性低、成本高}。
例图：
三维模型评分标准可以是高低、高中低等标准，复杂程度较高，因属性因子划分更精细，聚合分类的种类更全面，需求分析的准确性也更好。
行业特征、业务属性、产品定位、发展阶段各自不同，归纳的属性也不尽相同，不管是在最小化产品阶段（MVP），还是在打磨产品（PMF）、规模增长阶段，都需要 根据自身业务情况优化迭代需求属性、需求模型，让需求判断更准确，让产品开发更准、更快。 B端产品最大陷阱之一，就是不断做加法！
需求判断，依据产品定位和企业情况来设定需求目标、判断标准，让需求站队排列，也就是说： 让需求站到它自己的位置。
所有个性化需求聚类归位，有的归位到已知圈定层，有的产生新分类。归位已知圈定层，我们能知道需求做哪些、什么时候做。发现的需求新分类，则进一步思考： 过去分类方式是否有效和全面，是否需要改进迭代，这些新分类是否能够进一步抽象聚合并找到产品与技术的解决方案，实现产品新机会。
举例说明：企业资源不够，只能做1{价值高、共性高、成本低}的需求，进行快速迭代；企业资源足够，除了1{价值高、共性高、成本低}，2{价值高、共性高、成本高}也可优先，从而提高行业门槛；规模增长阶段，就可以把3､4､5纳入优先序列，通过对差异化需求共性提炼，用功能置配或灵活搭建等方式满足差异化需求，产品渗透更大市场。
特别是 SAAS产品，对各种各样个性化需求抽象还原、形成共性，是非常重要的。发现别人没有发现的需求共性，就是产品机会。
B端需求，重点不是做了多少，而是做了什么。
题图来自Unsplash，基于CC0协议
‘陆’ B端产品初期冷启动，该选择什么推广方式
现在的推广方式有很多种，seo、sem、信息流、开屏广告等等。
但是B端产品的用户毕竟是少数的，这个更倾向于精准推广，所以这里建议前期小规模的seo、sem推广