编辑导语：B端产品在成长过程中一定要做好自身的产品定位，做好需求优先级排序，避免因为企业的诉求不同而导致功能设计上的混乱的现象发生。本篇文章里，作者就B端产品成熟期中、产品应当如何找准自身定位做了总结，一起来看一下。

书接上文《【B端产品生命周期】C端产品夭折早，B端产品童工多（一），上文我们讲了B端产品的孕育和童年成长过程，如果你负责的产品有幸从童年步入到少年青年阶段，开始小规模对外商业化，那么一定会遇到上述问题。

你的公司招聘了一堆销售或者叫客户成功，他们四处奔走，游说客户购买产品，此时我们的产品还不太成熟，于是销售从客户那边收集回来许多需求。其中肯定有销售/客户成功同事拍着你的肩膀或者拍着桌子说：“产品目前还不支持这个功能，客户说了做了这几个需求，他们就下单了，你们赶紧安排吧，不然商机转瞬即逝”。

有时你可能就真的立马照做了，但是发现后面好像也没有客户使用呀，那面对这样的问题，以后我们应该怎么甄选出那些需求我们应该做，那些需求我们应该拒绝，并且能够拒绝得冠冕堂皇呢？

别急，看完下文，你将解开这个疑惑。

一、B端产品成长期：产品应该【垂直深耕】还是【横向拓展】？这是一个必须解决的问题！

当B端产品推向市场化运作后，面临越来越多的客户提出各种各样貌似合理的需求时，有时我们会一头雾水，不知所措，做也不是，不做也不是，陷入两难。

直接根据销售反馈做，感觉被销售和客户牵着鼻子走，不知道这个功能通用性如何；不做吧，潜在的客户白白流失，稍有不慎，季度总结大会上，还要背起销售部门/客户成功部门甩过来的大锅，他们会说都是产品不行，啥都不支持，客户不买单呀，此时我们一口老血吐出，有口莫辩。

举个例子，当时我们在做审批时，我们发现小企业的诉求往往我们在早期就已经满足，但是当我们不断拓展客户时，就会无止境地收到以下需求：

1）我有一个政府客户，他们希望审批能够有红头文件的表单样式，要是有这个功能，他们年底就迁移到我们产品上。

2）我有一个非常大的企业，5000人，他们要求我们的OA需要像传统的OA一样具备非常强大的流程引擎功能，他们目前用的是蓝凌，体验比较差，所以如果我们支持了强大的引擎，他们立马组织员工迁移过来，另外他们还希望表单更加丰富一些……

3）我有一个400人的企业，他们想一站式办公的企业，之前他们的审批流程都是分散到不同的系统，考勤里面有请假，资产管理系统里面有用车申请，合同管理系统里面有合同审批，他们希望我们可以提供一套系统，将请假、合同、用车审批聚合起来，一并处理，这样比较高效……

如果是你，你会怎么定义产品边界和需求优先级呢？你会为了获取眼前的客户，将客户的需求一一实现吗？还是说你能够定义清楚产品的走向，从而有的放矢，让产品成长得更加健康呢？

这个时候，我们就需要分两步走，破解这个问题。

1. 第一步：剖析用户需求，还原需求背后的本质

其实上面的问题，作为B端产品我们每天都会遇到，此时我们需要将上面的问题抽象一下，总结为以下三类，再寻求破解之法。

1）针对不同行业用户，提升产品的行业适配性

上面第一个问题属于行业适配性问题，由于各个行业的特殊性，每个行业都有自己独特的属性，如果你不告诉你的销售同学们，你们产品目前优先支持的哪些行业，那么他们会将会漫无目的推广，产品就会被推广到不同的行业。

不同行业的客户必然会提出他们日常认为必不可少的一些特色功能，这些功能不一定通用，但是如果你不做，那么你的产品必然进入不了这个行业。

比如上面提到的，如果我们的审批不支持红头文件的格式，那么我们肯定不能获得对应这个行业的客户，这个时候你如何决策？我们需要做行业适配吗？

2）针对不同规模用户，提升产品业务场景适配性

上面第二个问题属于产品的业务场景适配性问题，小企业人员少，场景简单，简单的产品就能满足需求。

但是员工规模上千上万的企业，流程复杂、环节繁多、协作精细，简单的产品不仅不会加快他们运作效率，反而会将流程变慢，一般在小企业行得通的产品，到大企业就行不通了。

相反，如果此时你立马倾向大企业，将产品做得越来越复杂，使用门槛直线升高，小企业慢慢觉得你产品臃肿不堪，他们已经学不会如何操作了，那么小企业会逐步抛弃你，此时你会如何决策呢？

3）针对非产品核心诉求，扩宽产品的边界

上面第三个问题，其实产品与产品的边界问题，我的产品里面有一小部分功能需要与其他产品做衔接，用户更希望两个系统是天然打通的。

但是做这个业务的系统有好几百家，我不可能都去打通吧，打通的成本可能和我开发一个对方简单的业务系统差不多，这个时候我要去开发一个简单的业务系统吗？这样对增强产品的核心竞争力有好处吗？

刚刚我们抽象了需求背后问题的本质，那么接下面就针对这几个抽象的问题，给出破解之法。

2. 第二步：明确产品定位，拒绝将产品打造成四不像

B端产品长期来看，你是可以在一个领域里面做成巨无霸的，但是在短期的5年规划中，你必须有清晰的规划，否则就会被上面的三个问题纠缠不清，最后产品做成四不像，没有讨好任意一类用户，随时会被竞争对手抛弃。

那么如何做B端产品的定位呢？

第一，确定我们要深耕产品还是深耕客户？

如果我们要深耕产品，那么我们在产品的深度上下功夫，我们可以先推出小企业轻量版本，再推出中大企业复杂版本，再做不同行业的解决方案；通过产品强大的可配置能力，满足所有类型客户的单一场景需求，做到某个场景的前几名；最后整个行业只有你能够满足不同类型客户的诉求，并且你的研发和销售成本是最低的，这就形成了非常大的优势。

salesfore就是运用这个策略取得巨大成功。salesfore2001年推出中小企业版本的CRM，中小企业的付费能力有限，生命周期也相对短，所以导致客户的生命周期总价值LTV（Life Time Value）不高。到2004年Salesfore上市的时候，仍然只是一家市值10亿美元的小公司。

随后为了支持中大企业对CRM的诉求，2008年，Salesforce推出了世界上第一个可以在统一架构上部署应用的PaaS平台——Force.com。通过引入应用开发者以及支持中大企业通过更低的成本完成一些定制场景的开发，完美解决这大企业的CRM诉求，快速占领了销售管理这个场景的市场，成就了今天2000亿美元的估值。

如果我们要深耕客户，那么我们需要在产品广度上下功夫，深耕客户意味着我们只满足某一规模或某一行业的客户，此时我们产品的深度可以稍浅，但是为了提升产品的竞争力与性价比，那么我们和深度产品竞争时，用户花一份钱，可以达到买3个同类产品的效果，那么必然会选择我们。

像国内的传统企业服务商大都走这个思路，蓝凌、泛微做的OA横向拓展了许多企业办公场景，其核心场景是审批流程。用友等友商也是这个思路，究其核心原因是因为很早些时候，他们靠软件起家，功能越多，价格越贵，所以边界问题的优先级就低于了赚钱的优先级。

现在很多企业还在延续这种思路，这样其实会导致产品日益复杂，体验上会存在很大的问题，这也是为什么钉钉、飞书、企业微信推出后，很多企业会从传统的软件迁移到体验更好的产品上的原因之一。

第二，根据产品的定位，来排需求优先级。

如果深耕产品，则我们优先满足不同规模企业适配性问题，再满足不同行业适配性问题；如果我们深耕客户，那么我们优先满足第不同产品边界需求，再考虑不同企业、不同行业适配性问题。

相信通过对问题的剖析，读者们以后在判断B端产品需求的时候，在产品定位明晰的情况下，我们就不会被客户和销售牵着鼻子走，并且我们可以明确告知销售和客户成功，我们目前优先支持那一类客户，让他们将重心放在这类客户身上，他们再提需求时，我们就能有理有据地坚持自己的原则。

二、B端产品成熟期：只要不作死，都有一段躺着赚钱的美好时光

如果一个B端产品在你手里经历了风风雨雨，一把屎一把尿地养大了、成熟了，那非常值得可喜可贺；和风险投资是一样的，因为B端产品长大不易，一旦突破这个窗口，那么将进入高回报的周期，产品将表现出强有力的生命力，在新的技术更迭之前，有一段躺着赚钱的时光，因为以下两个原因。

1. 竞品复制成本高，复制周期长

一款B端产品成熟意味着他能够解决产品定位领域的大部分问题，这个需要一个专业团队在这行业不断摸索踩坑，与不同类型客户共创，不断提升产品的通用性和可塑性，需要比较长时间的积累才能形成面对各种各样问题的解决办法；竞争对手如果想全面模仿，需要一定时间的周期。

与C端产品不同，C端产品，一个小团队真的是可以在3个月开发出一个抖音的，因为C端产品核心功能就那么多，成功取决于市场、运营、机遇等各种因素。

另外，成熟的产品长期占据着优质用户，在不断满足客户诉求中，产品得以不断完善，不论是产品丰富的场景适配能力、高度的稳定可用性，都是留住老用户，开拓新用户无可比拟的优势。

2. 一旦被雇佣，替换成本高

第一，B端产品会沉淀公司重要的经营数据，里面有客户的数据、公司运作的数据，一旦切换产品这些宝贵的数据资产可能变得残缺不全，给公司造成损失，切换的成本比较高。

第二，每次切换系统要么涉及一个部门要么就是全公司，第一需要消耗公司的人力资源，另外这么多人适应一个新产品需要时间，一旦切换后没有满足大家的预期，那么推动人员不但无功，非但有过，所以各负责人都是抱着“如非必要勿增实体”的心态。

因此B端用户切换产品的成本很高，除非你自己不思进取或者自己作死，否则用户的稳定性很高，新用户由于口碑效应也会源源不断。当然随着新技术的革命，产品也需要不断做迭代。

聊完【B端产品的生命周期】，下一期我想和大家聊一聊【如何制定B端产品的产品战略和产品策略】，比如：如何确定产品的竞争策略？什么时候要开始做行业的解决方案？什么时候要PAAS化等问题的探讨！

作者：公众号【ToB一线】，微信公众号：ToB一线

本文由@公众号【ToB一线】 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议