编者按：本文来自微信公众号“梵天DaoZen”（ID：fantian-daozen），作者梵天，36氪经授权发布。

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

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

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

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

产品和项目

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

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

做项目，就是一两个程序员往客户那一驻扎，您说你想要啥我们就做，做完您看行就验收，不行我们再改，觉得没问题我们就回去了；

做产品，是标准的，不会特意为客户修改，您要觉得拿点不顺眼不想买了我也没办法，我们不修改，我们不改您就不买我们也没办法，您要买了，那我们就上门安装、实施，就这样；

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

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

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

做定制项目的公司就不一样了，每一个项目是单独核算的，目就是要确保每一单都是赚的。客户提出越多的需求，项目能够赚更多的钱（当然前提是客户承认新需求产生的工作量，这个也是很需要项目团队的管理水平的）。每个客户都能够得到独立的产品。很多做项目的公司都会尝试开始把项目转化成通用产品，不过一般而言很难善始善终，新的定制项目会不断打断所谓的“产品化工作”，毕竟项目是可以马上来钱的。

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

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

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

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

一个正常的产品驱动的路线是怎么规划的；

客户定制的“一锤子功能”的出现；

接下来会发生的累积和一系列连锁反应

“产品驱动”的路线规划

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

看得见摸得着的功能提升：新的功能、用户体验和可用性的提升、对竞品功能的响应，等等；

各种“基础设施建设”和“性能提升”：可用性、可扩展性、安全性等等；

各种“测试、修复和运维”：修复bug、测试用例、DevOps、填技术债务等等；

不断地学习和验证：用户调研、数据分析、原型设计来更深入了解一线用户、验证想法，来给产品下一步创新做准备。

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

市场和销售希望产品能够有更强大的功能卖给客户，所以他们会鼓励不断地做新功能；

技术人员最清楚软件平台里面的技术风险和缺点，所以他们会希望能更多地投入在架构、工具和重构上（就是赶紧把留下来的坑填了）；

实施/客服能够尽量减少客户的投诉或疑问，所以他们会更希望投入在bug修复、可用性提升，让暴露到客户的问题越少越好；