2B产品的隐藏陷阱：销售驱动

编者按：这是TOB产品必定会面对的问题，这个问题的背后是公司要有一个决策，是做定制产品还是普适产品，作者给出的解决方法很有参考意义，故转载。

近年来听到越来越多2C衰退，2B兴起的声音，虽然我对这种说法保留意见，但认识的同行也有越来越多人考虑转到2B行业。作为过来人，本文分享的是2B产品（特别是大）里面做产品规划的一个很常见但有很需要解决的深坑，是需要这行的产品经理去面对和解决的。（当然如果你给自己的定位就是原型仔和需求编写工，那接下来的文字对你没啥意义）

相信很多2B企业市场的产品经理都会遇到这种情况：产品规划里面出现了一些功能是专门做给特定客户的“一锤子买卖”。当发生这种情况之后，恭喜你，你的公司要不已经进入了一种“销售驱动”的产品发展路线，要不就是即将进入了。

“销售驱动”的一大特点是，产品研发的重点落到了某些特定的客户上，代价是牺牲了产品核心价值的创新、新的功能、质量提升和技术优化。

用这种“驱动方式”发展下去的产品，最终会失去寻找到真正不可替代的价值点的机会，甚至发现“销售驱动”的产品变得更难销售了，更不用说能成为Scalable的商业模式了。可怕的是，团队可能往往意识不到为什么到达了这种地步，甚至没有意识到出现了问题。所以首先，我们应该正本清源，从根本分析一下问题的所在。

一、产品和项目

在说“销售驱动”之前，首先我们要理清做产品和做项目的区别，跟2C产品不一样，2B产品是很容易混淆做产品和做定制项目两件事情的。先来看一下两者有什么不一样。

企业软件行业的老前辈阿朱的《走出软件作坊》里面曾经做过产品和项目的对比，我印象一直十分深刻，虽然成书已经过去了一段时间了，那时候甚至还没有云、SaaS这些概念，但这个差异的本质我认为到现在依然适用，大意如下：

• 做项目，就是一两个程序员往客户那一驻扎，您说你想要啥我们就做，做完您看行就验收，不行我们再改，觉得没问题我们就回去了；
• 做产品，是标准的，不会特意为客户修改，您要觉得拿点不顺眼不想买了我也没办法，我们不修改，我们不改您就不买我们也没办法，您要买了，那我们就上门安装、实施，就这样。

最难的就是说产品不是产品，说项目不是项目的东西。一个东西，本来是给A客户做的项目，然后B客户看着不错也要，然后把A客户的项目代码改改给B客户用，这下麻烦了，A客户代码里面有了B客户要求的功能，这下软件既不是A客户的，又不是B客户的，然后之后再掺和进C、D、E客户，就更是头疼得要命。

阿朱是从开发和代码管理的层面，来看混淆产品和项目两者之间关系的弊端的。我们还能更进一步，从商业和财务层面分析两者之间的区别。

做产品的公司销售的是标准的产品，一个产品可以不断重复地销售给不同的客户，这样单位的边际成本低于单位价格，这样才能形成一个可持续的模式。做产品的公司都是前期投入大，要把销售量到收支平衡点，超过收支平衡点之后的销售后额绝大部分都是高利润了。

做定制项目的公司就不一样了，每一个项目是单独核算的，目就是要确保每一单都是赚的。客户提出越多的需求，项目能够赚更多的钱（当然前提是客户承认新需求产生的工作量，这个也是很需要项目团队的管理水平的），每个客户都能够得到独立的产品。

很多做项目的公司都会尝试开始把项目转化成通用产品，不过一般而言很难善始善终，新的定制项目会不断打断所谓的“产品化工作”，毕竟项目是可以马上来钱的。

产品和项目两者模式并不分高下，只要世上还有共性需求和个性需求之分，两者都可以赚钱。但对于2B产品来说，很容易不知不觉中地走入一种两者混合的模式：一种半定制的软件，需要不断投入研发人员来支持新的需求，但又不是通过定制项目的工作量而是软件授权的方式来报价，往往折中报价方式又过低，用这种方式发展的客户数也不足以达到收支平衡点。

很多时候我们遇到的很多困难，例如开发资源无法支撑大量客户的需求，销售觉得开发部门不给力响应慢，开发部门又觉得销售乱承诺客户给自己挖坑需求怎么做都做不完，这些都是表面上的困难，根本原因就是这种混合模式就是根本无法大规模扩张的模式。

“销售驱动”是怎么产生的

接下来说清楚“销售驱动”的模式是怎么在公司里面产生的， 分为下面几步：

1. 一个正常的产品驱动的路线是怎么规划的；
2. 客户定制的“一锤子功能”的出现；
3. 接下来会发生的累积和一系列连锁反应

二、“产品驱动”的路线规划

一般而言，对于一个已经成形，开始找到自己的Product/Market Fit的产品来说，要让产品健康地发展，研发团队要投入的精力一般包括四个部分：

• 看得见摸得着的功能提升：新的功能、用户体验和可用性的提升、对竞品功能的响应，等等；
• 各种“基础设施建设”和“性能提升”：可用性、可扩展性、安全性等等；
• 各种“测试、修复和运维”：修复bug、测试用例、DevOps、填技术债务等等；
• 不断地学习和验证：用户调研、数据分析、原型设计来更深入了解一线用户、验证想法，来给产品下一步创新做准备。

这四个部分都有让不同人支持的理由：

• 市场和销售希望产品能够有更强大的功能卖给客户，所以他们会鼓励不断地做新功能；
• 技术人员最清楚软件平台里面的技术风险和缺点，所以他们会希望能更多地投入在架构、工具和重构上（就是赶紧把留下来的坑填了）；
• 实施/客服能够尽量减少客户的投诉或疑问，所以他们会更希望投入在bug修复、可用性提升，让暴露到客户的问题越少越好；
• 老板希望产品有更进一步的突破，但他们经常会把突破和创新视为个人态度努力而不是用科学的方法进行推进的结果，他们往往会低估需要在实验和验证上需要投入的成本。

作为产品经理，我们在做产品规划的时候，会把有限（永远都不够）的研发资源，像投资建立投资组合一样，折中和平衡分配到以上几个方面，希望这种投资组合能够让产品更健康和可持续地发展。就像玩星际一样，要在把资源在攀科技和爆兵之间做平衡。

于是哼哧哼哧一轮，我们可能会诞生一个这样的基于以下资源分配的产品路线图。

路线图看起来不错，然后老板也通过了。然而没过几天，销售团队反馈说，某个大客户有点需要定制的“小功能”，于是恶梦慢慢开启……

三、“XX客户希望能实现这个功能”

产品的用户提出新的功能需求是人之常情（毕竟强如微信也有一亿人要教张小龙做产品）。在2C产品或者小B市场里面，有成千上万的用户，单独某个用户不会直接影响到到我们对产品路线的改变。产品团队会广泛吸取各方面收集到的优化点，这些优化点可能来自于用户的直接反馈，也可能来自数据的收集和分析，对于行业和环境的观察，对于竞品的分析等等。总之，很难会出现单独一个客户就能影响产品路线的情况。

但对于企业市场来说，客户规模（和随之而来的影响力）会更大，数量也更少。很可能某个客户的合同就会占到公司5%的总收入。这种情况下，单独一个客户对于产品决策的影响力就会比2C或小B大得多。而这些客户也常常会给销售人员提出他们的个性需求，常见的包括：跟客户的其他系统进行整合、工作流程的调整、报表定制等等；

销售人员会怎么处理呢这些需求呢？先看看销售人员的特长和思维模式：

• 销售人员一般都乐观、不轻言放弃，还特别擅长和人打交道和在组织里面找到推动事情前进的关键人物；
• 擅长说服：能用他们强大的说服力，把客户的需求重新掰成我们的产品能够大部分满足他们的应用场景（尽管实际上不是这样），再进行投标；
• 企业对于销售人员的业绩评价标准十分简单粗暴：能签单就是成功（就像电竞界一样的：没有成绩，连呼吸都是错的）；
• 对销售人员的激励方式（销售提成）让他们百分百专注于自己手头上的客户和销售机会。

所以当客户跟销售提出一些产品原来路线图所不包括的需求时，销售人员就会很自然地要求产品经理去实现这些功能。正常来说，他们首先得到的答复一般是“我们先记录下来，然后下个季度再来考虑”或者“这个排不上期”而不是“这个想法太棒了，我们立马做”。

正当产品经理天真地以为自己已经把事情完结了的时候，不要忘记销售人员不轻言放弃、擅长说服和找到关键人物的特长。这些特长能够帮助到他们在外打动客户，自然也能帮助到他们对内对管理层施加影响，然后管理层就会从销售人员那听到下面这些说法：

• “这个客户是我们重要的大客户，对于我们具有战略意义。完成这些需求对于签单/收款和达到销售目标是必须的”；
• “这个需求很简单”；
• “这个客户很清楚想要什么，会成为我们市场里面的一个标杆客户”；
• “我们采用敏捷的开发方式，所以研发计划应该可以灵活调整的才对”；
• “这个是市场通用的需求，而不是单个客户的需求，我们谈过很多的客户都希望有这个功能，这个功能其实早就应该做了”

这些说法看起来都合理（我们也倒是希望它们是真的合理的，这样做产品就比现实上简单多了），正因为销售团队所花的所有时间都是在客户身上，从这个角度来说，他们也的确可以认为自己就是最了解客户真实需求的人。

然后接下来的推论就会变成，因为这些客户对于我们太重要了，我们一定要找到办法来体重资源来服务他们。于是，我们前面那些立足于整体的产品规划就会为这些特定的客户需求所让路。就算产品想挣扎一下，说出来的理由跟销售人员的相比，更像是推卸和牢骚，常见的包括：

• 现在已经没有空余的人手来做这些事情了；
• 如果要做这个那原定计划中的XXX和XXX就要延后了；
• 客户不了解我们软件的现状，所以他们提的需求我们需要从头认真分析，初步判断这些是很大的工作量；
• 如果这个需求是通用需求，那我们早就把它放到我们高优先级的工作上了；
• 等等

然而这些反对意见一般最终都没有什么用，我们还是不得不把这些需求排进我们的产品路线图当中。而我们之前分析的几类工作当中，也只有最后一种——学习和验证，相对来说最不紧急，而从这些工作中抽调人手在短期内影响最小。于是我们新的资源投资组合就变成了以下这样。

看起来还没有啥大问题（尽管牺牲了点有长远回报的投资），不过往往事情没有那么简单。当真的开始开发这些客户定制的需求的时候，就会不断发现有新的坑：新的流程需要改变我们现有的数据流转方式；客户现有系统用着不标准的对接方式；一些看起来简单的UI个性化需要，要重写成可灵活配置的形式，不然就要变成两套代码来维护等等。

当然还有最坑的，其实客户自己最开始也没想清楚或者说清楚，做着做着还得改。然后为了赶客户给出的时间点（这是经常发生的），不得不交付出一个背负大量技术债务、甚至还没有经过严格测试覆盖的产品出去。

这种定了时间点就要完成的功能，也往往会让我们忘记（或者避而不谈）去验证这些需求背后真实性和是否真的存在意义。于是实际上，我们的投资组合结果变成了这样。

不过好消息是，经过一大轮赶工之后，于是我们赶在了deadline之前把功能交付了出去，客户爽快地签单/付款了，老板、产品、研发、销售大家都皆大欢喜。是不是以为事情就告一段落，可以回到我们原来的产品路线上呢？没那么简单。

四、进入“销售驱动”模式

有了上面这一次“成功的案例”之后，管理层和销售部门都尝到了甜头，知道了产品和研发部门是能够为客户做定制需求的，这种方式（看起来）也没有给公司造成什么损失。这个先例一开，后面就会成为惯例。

其他的销售人员就开始照葫芦画瓢，用答应客户的定制功能（一般还附带时间要求）来完成自己的签单目标，甚至管理层也会开始要求研发部门优先去完成这些有助签单收款的功能开发，我们原来的投资组合的其他部分，被进一步积压，最终变成了这样。

于是我们的产品研发的决策模式，也从考虑整体市场的方式，变成为每一单真金白银合同所附带的功能所开路。单独看，每一次决策好像都没什么毛病，但整个产品已经不知不觉中陷入了一种局部最优的死循环里面：

优先做客户个性定制需求—>牺牲了产品的整体水平（不仅仅是功能、还有稳定性、可用性，最重要的，真的能为广泛客户解决真实痛点的能力）—>只能更依赖销售人员说服客户和满足客户的定制需求才能签单—>优先做客户定制需求—>……

到了这一步，一系列的连锁反应就会慢慢发展和爆发，表现在：

• 需求来自不同的客户，附带的严格的时间要求，也让我们没法为一个需求深究其背后的真实痛点做出根本的解决方案，这些功能点也往往不存在什么真实的战略价值，这些碎片化的需求影响了产品的内在一致性和长远发展的能力；
• 产品经理从“产品的CEO”，变成了被动地应对客户需求的状况，实际上变成了服务客户的项目经理和原型/需求编写工，不再能积极主动地规划他们的产品；
• 研发/设计人员会失去积极性，因为他们被迫接受客户指定的需求和时间点，而不是用一种学习和探索的方式来开发产品。而这些客户的需求完成后也很少会有正面的反馈（一般都是出问题了才来找你）；
• 销售团队也会慢慢发现自己的日子不大好过了，客户依然会不断地提出新的定制需求而且胃口越来越大，而研发的排期也因为其他的客户需求堆积，变成了一个长长的队列，再也无法像之前那样快速地去响应客户，想继续用这种方式谈新的客户也会越来越艰难；
• 整个公司的利润率会下降：软件产品商业模式的魅力原本是很低的边际成本，但在现在的既不是产品又不是项目的方式下，软件的授权费用未必真的能覆盖客户定制需求的成本；
• 市场份额增长缓慢，因为让路于客户定制，产品不再有新的亮点来扩张新的市场了。

矛盾开始会爆发，然后就会开始乱找病因、乱开药方，“产品经理应该要更快速响应客户的需求，哪怕先做个方案响应一下客户”、“开发人员效率是不是太低了，他们能不能加班赶上进度？”“销售能不能不要乱给我们挖坑？”然而这些都不是问题的根本所在。

根本的问题就在于组织形式和盈利模式的错配：单个客户的需求优先，让我们牺牲了为广阔市场去规划和研发产品的能力，做着一个个隐藏在产品外衣之下的外包项目，为一棵树放弃了一片森林。

五、如何解决问题

上面说的这些问题，是一个系统性的问题，不是单个产品、研发或者销售人员可以凭借自己的力量去解决的，而是应该是跟管理层一起，开诚布公地讨论和解决问题，尝试用以下的方式来解决：

（1）识别自己是否正处于这种“销售驱动”的状态当中：整体分析一下产品和销售的运转遇到了瓶颈了，新客户的获取是否越来越依靠于定制开发？可以把最近的一段时间（例如半年到一个季度）的研发投入拿出来分析，有多大的比例是用在为单独的客户定制功能上，又有哪些所谓的“提升产品水平的通用功能”实际上只有一两个客户在用？我们所做的新的功能是否跳过了验证的步骤？

（2）公司究竟是做产品还是做项目才是真正满足市场需求的？彻底分析自己所在的行业和要满足的需求到底是否能够用通用产品去满足，还是需要一个一个的定制项目去做，企图采用折中的方式一定异常艰辛。

（3）该是定制项目的，就按定制项目的模式去报价，然后去应用专业的项目管理的方式来管理客户的需求，不要幻想着为客户定制的需求能够变成通用的产品，虽然不是完全不可能，但这概率就跟刮彩票一样，刮到了算是赚了，但不能指望着刮彩票来过日子。

走定制项目路线的，也可以让专门的研发力量去打造平台和工具（例如PaaS或者现在很火的中台概念），来提升整体的研发效率。

（4）该是做标准产品的，就要正视问题和管理好“销售驱动”的问题，用运营产品的思路去规划和管理产品，例如：

• 从用户的获取、转化、留存等角度来思考产品，尽力去优化自己整体的LTV和CAC；规划需求的出发点也不再是“做了这个需求可以满足什么客户”，而是要推理和假设一个需求能为整体客户市场带来什么，然后去验证他们；
• 从整个研发力量划分出一个坚定的底线，客户的一锤子需求不能够超过特定的比例（例如一个季度不超过两周的时间），所有的定制需求的需要的资源都不能超出这个资源池来获取，需要销售部门自行给所有客户定制需求划分优先级；
• 调整不同的激励方式：例如销售团队通过销售标准产品可以获得完整的提成，但对于定制需求则需要按照实现成本的一定比例进行扣除；
• 谨记资源是有限的，有额外的东西安排进来，必定有其他工作被牺牲掉，这些牺牲掉的，可能是产品的长远利益；
• 把定制工作从产品的核心中剥离开来，定制工作一定要按照定制工作的方式来定价，甚至可以考虑和专业的定制项目公司合作，把定制工作外包出去，由专业的人来处理专业的事，自己的产品团队则专心在产品的核心；
• 客户提出的需求也不是完全拒绝，而是要总结归纳出共性的地方，思考出有共性的产品方案来解决客户的真实的痛点，可以用通用需求通过配置的方式来满足一定的个性化需求，而不是通过定制，但是对这些解决方案要有足够的耐心和投入足够的精力进行学习和验证。

总结

当公司盈利的时候，很多问题可能都不是问题（就像赢球可以掩盖很多问题），但是当公司增长受困，作为产品经理，就要从产品的角度来分析和解决问题的根本所在了。

而销售驱动的产品方式，对于2B公司来说的确是一个常见的因素（当然还有很多其他原因），要知道如何识别和解决这些问题，产品经理，是有责任去扫清产品发展的一切障碍的。

参考:

• RICH MIRONOV：《[The Slippery Slope of Sales-Led Development]》
• 阿朱：《走出软件作坊》

• 白鸦：《SaaS业务的价值评估》

  
  作者：梵天，公众号：梵天Daozen（fantian-daozen）
  本文由 @梵天 原创发布于人人都是产品经理。未经许可，禁止转载
  题图来自 Pexels，基于 CC0 协议

转载自 人人都是产品经理 作者 @梵天 原文地址