2B产品需要解决的深坑—销售驱动

近年来，我听到越来越多的2C衰退和2B兴起的声音。虽然我对这一说法有所保留，但越来越多的同行考虑转向2B行业。作为一个有经验的人，本文分享了2B产品（尤其是大型产品）中一个非常常见但需要解决的深坑，这需要产品经理来面对和解决。（当然，如果你把自己定位为原型男孩和需求编辑，下一个词对你来说毫无意义）我相信很多2B企业市场的产品经理都会遇到这样的情况：产品规划中的一些功能是专门为特定客户做的“一锤交易”。当这种情况发生时，恭喜你，你的公司要么进入了“销售驱动”的产品开发路线，要么即将进入。“销售驱动”的一个主要特点是，产品研发的重点是一些特定的客户，以牺牲产品核心价值的创新、新功能、质量改进和技术优化为代价。用这种“驱动”开发的产品最终会失去寻找真正不可替代的价值点的机会，甚至发现“销售驱动”的产品更难销售，更不用说成为Scalable的商业模式了。可怕的是，团队可能没有意识到为什么会达到这一点，甚至没有意识到问题。所以首先要从根本上清理源头，分析问题。在谈到“销售驱动”之前，我们应该首先澄清产品和项目之间的区别。与2C产品不同，2B产品很容易混淆产品和定制项目。让我们来看看两者之间的区别。企业软件行业的老前辈阿朱在《走出软件作坊》中对产品和项目进行了比较，给我留下了深刻的印象。虽然成书已经过去一段时间了，当时甚至没有云和SaaS的概念，但我认为这种差异的本质仍然适用于现在。大意如下:做项目，就是一两个程序员驻扎在客户那里。你说你想做什么我们就做。我们不能再改变了。如果我们认为没有问题，我们会回去；制造产品是标准的，不会特别为客户修改。如果你觉得不好看，不想买，我也没办法。如果我们不修改它，你就不会买它。如果你想买它，我们会上门安装并实施它。就这样。最难的是产品不是产品，项目不是项目。最困难的是产品不是产品，项目不是项目。一件事，最初是为A客户做的项目，然后B客户看起来不错，然后将A客户的项目代码改为B客户，这很麻烦，A客户代码有B客户要求的功能，软件既不是A客户，也不是B客户，然后混合到C、D、E客户，更是头疼。从开发和代码管理的角度来看，阿朱混淆了产品和项目之间关系的缺点。我们可以从商业和财务层面进一步分析两者之间的区别。产品公司销售标准产品，产品可以反复销售给不同的客户，使单位的边际成本低于单位价格，从而形成可持续的模式。做产品的公司前期投入大，销量要达到收支平衡点，超过收支平衡点后的销售额大部分都是高利润。定制项目的公司是不同的，每个项目都是单独计算的，目的是确保每个订单都是赚钱的。客户提出的需求越多，项目就能赚到的钱就越多(当然前提是客户承认新需求产生的工作量，这也需要项目团队的管理水平)，每个客户都能得到独立的产品。许多从事项目的公司会尝试将项目转化为通用产品，但一般来说，从头到尾都很困难。新的定制项目将继续打断所谓的“产品工作”。毕竟，这个项目可以立即赚钱。只要世界上有共同的需求和个性的需求，产品和项目都可以赚钱。但对于2B产品，很容易无意识地进入混合模式：半定制软件，需要投资研发人员支持新需求，但不是通过定制项目的工作量，而是软件授权报价，往往折扣报价太低，客户数量不足以达到收支平衡。很多时候，我们遇到了很多困难，如开发资源不能支持大量客户的需求，销售认为开发部门响应缓慢，开发部门认为销售承诺客户挖坑需求如何做，这些是表面困难，根本原因是这种混合模式是不能大规模扩张模式。“销售驱动”是如何产生的？接下来，明确“销售驱动”模式是如何在公司产生的，分为以下步骤：如何规划正常的产品驱动路线；客户定制的“一锤功能”的出现；一般来说，对于已经形成的“产品驱动”路线规划，下一个积累和一系列连锁反应，开始找到自己的Product/MarketFit产品，为了让产品健康发展，R&D团队投入的精力一般包括四个部分:看得见摸得着的功能提升:新功能、用户体验和可用性的提升、对竞争产品功能的响应。等等；各种“基础设施建设”和“性能提升”：可用性、可扩展性、安全性等。；各种“测试、修复和操作”：修复bug、测试用例、DevOps、填写技术债务等；不断学习和验证：用户研究、数据分析、原型设计，更深入地了解一线用户，验证理念，为产品的下一次创新做准备。这四个部分有理由得到不同的人的支持：市场和销售希望产品能够向客户销售更强大的功能，因此他们会鼓励不断创建新功能；技术人员最了解软件平台中的技术风险和缺点，因此他们希望在架构、工具和重建方面投入更多资金（即快速填补剩余的坑）；实施/客户服务可以尽量减少客户的投诉或疑问，因此，他们更愿意投资于bug修复和提高可用性，使暴露给客户的问题越少越好；老板希望产品有进一步的突破，但他们往往把突破和创新视为个人态度努力而不是科学方法的结果。他们往往需要投资于实验和验证的低成本。作为产品经理，在进行产品规划时，我们将在上述方面分配有限（永远不够）的研发资源，如投资组合，妥协和平衡，希望这种投资组合能使产品更加健康和可持续发展。作为产品经理，在进行产品规划时，我们将在上述方面分配有限（永远不够）的研发资源，如投资组合，妥协和平衡，希望这种投资组合能使产品更加健康和可持续发展。就像玩星际一样，我们应该平衡攀登技术和爆炸性士兵之间的资源。所以哼哼一轮，我们可能会产生这样一个基于以下资源分配的产品路线图。路线图看起来不错，然后老板也通过了。然而，几天后，销售团队反馈说，一个大客户有点需要定制的“小功能”，所以梦想慢慢开始……“XX客户希望实现这个功能”产品的用户提出新的功能需求是很自然的（毕竟，微信也有1亿人教张小龙做产品）。在2C产品或小B市场，有成千上万的用户，单独的用户不会直接影响我们产品路线的变化。产品团队将广泛吸收各方面收集的优化点，可能来自用户的直接反馈、数据的收集和分析、行业和环境的观察、竞争产品的分析等。总之，单个客户很难影响产品路线。但对于企业市场来说，客户规模(以及随之而来的影响)会更大，数量也会更少。客户的合同很可能占公司总收入的5%。在这种情况下，单个客户对产品决策的影响会比2C或小B大得多。这些客户经常向销售人员提出个人需求，包括：与客户的其他系统集成、工作流程调整、报告定制等；销售人员将如何处理这些需求？首先，看看销售人员的专业知识和思维模式：销售人员一般乐观，不轻易放弃，特别擅长与人打交道，找到组织中促进事物进步的关键人物；善于说服：利用他们强大的说服力，将客户的需求分解成我们的大部分产品可以满足他们的应用场景（尽管事实并非如此），再次投标；企业对销售人员的绩效评价标准非常简单和粗糙：签署订单是成功的（就像电子竞技行业一样：没有结果，甚至呼吸也是错误的）；激励销售人员的方式(销售佣金)让他们100%专注于手头的客户和销售机会。因此，当客户向销售人员提出一些产品原路线图所不包括的需求时，销售人员自然会要求产品经理实现这些功能。因此，当客户向销售人员提出一些原始产品路线图中不包括的需求时，销售人员自然会要求产品经理实现这些功能。通常，他们得到的第一个答案通常是“我们先记录下来，然后在下个季度考虑”或“这不是最后一个阶段”，而不是“这个想法很棒，我们会立即这样做”。就在产品经理天真地认为自己已经完成了事情的时候，别忘了销售人员不会轻易放弃，善于说服和发现关键人物的特长。这些专业知识可以帮助他们给外部客户留下深刻印象，自然也可以帮助他们影响内部管理，然后管理层会从销售人员那里听到以下声明：“这个客户是我们的重要大客户，对我们具有战略意义。签单/收款和销售目标是完成这些需求的必要条件。”；“这个需求很简单”；“这位客户知道他想要什么，并将成为我们市场的基准客户。”；“我们采用敏捷的开发方法，所以研发计划应该能够灵活调整。”；“这是市场的一般需求，而不是单个客户的需求，我们谈到了很多客户都想要这个功能，这个功能应该做很长一段时间”这些说法看起来合理（我们也希望他们真的合理，所以产品比现实简单得多），因为销售团队花所有的时间在客户身上，从这个角度来看，他们真的可以认为他们是最了解客户的真实需求。然后下一个推论就会变成，因为这些客户对我们来说太重要了，我们必须找到为他们服务体重资源的方法。然后下一个推论就会变成，因为这些客户对我们来说太重要了，我们必须找到为他们服务的重量资源的方法。因此，基于整体的产品规划将为这些特定的客户需求让路。即使产品想挣扎，与销售人员相比，原因更像是逃避和抱怨，常见的包括：没有空闲人员做这些事情；如果你想在原计划中做XXX和XXX；客户不了解我们软件的现状，所以我们需要仔细分析他们的需求，初步判断这些是一个巨大的工作量；如果需求是一般需求，然后我们早就把它放在我们的高优先级工作上了；等等，但这些反对最终通常是无用的，我们仍然必须把这些需求放在我们的产品路线图中。在我们之前分析的几类工作中，只有最后一类——学习和验证，相对来说是最不紧急的，而从这些工作中抽调人员在短时间内影响最小。在我们之前分析的几类工作中，只有最后一类——学习和验证，相对来说是最不紧急的，而从这些工作中抽调人员在短期内影响最小。因此，我们的新资源投资组合如下。似乎没有什么大问题(虽然牺牲了一些长期回报的投资)，但往往事情并没有那么简单。当我们真正开始开发这些客户定制的需求时，我们会不断发现新的坑：新的过程需要改变我们现有的数据流模式；现有的客户系统采用不标准的对接模式；一些看似简单的UI个性化需求应重写为灵活的配置形式，否则将成为两组代码进行维护等。当然，也有最坑的。事实上，客户一开始并没有想清楚或说清楚。他必须改变他所做的事情。然后，为了赶上客户给出的时间点（这经常发生），我们不得不交付一个产品，承担大量的技术债务，甚至没有经过严格的测试。这种设定时间点即将完成的功能，往往会让我们忘记(或避免谈论)来验证这些需求背后的真实性和意义。所以事实上，我们的投资组合已经变成了这样。然而，好消息是，经过一大轮的工作，我们在deadline之前交付了功能。客户很快签署了订单/付款。每个人都很高兴老板、产品、研发和销售。你认为事情已经结束了，可以回到我们原来的产品路线吗？没那么简单。在上述“成功案例”进入“销售驱动”模式后，管理和销售部门都尝到了甜味，知道产品和研发部门可以为客户定制需求，这样（似乎）并没有给公司造成任何损失。这个先例一开，以后就会成为惯例。其他销售人员开始遵循葫芦，承诺客户定制功能（一般也有时间要求）来完成他们的签署目标，甚至管理层也会开始要求研发部门优先完成这些帮助签署功能开发，我们原来的投资组合其他部分，进一步积压，最终成为这样。因此，我们产品研发的决策模式已经从考虑整体市场的方式转变为每一份真金白银合同附带的功能。单独看，每一个决策似乎都没有错，但整个产品在不知不觉中陷入了局部最佳死循环：优先考虑客户个性化定制需求—>最重要的是牺牲产品的整体水平(不仅是功能，还有稳定性和可用性，能够真正为广大客户解决真正痛点的能力)—>只有依靠销售人员来说服客户，满足客户的定制需求，我们才能签署订单—>优先考虑客户定制需求—>....在这个阶段，一系列的连锁反应会慢慢发展和爆发，表现在：来自不同客户的需求，以及严格的时间要求，它也使我们无法为需求深入研究背后的真正痛点做出根本解决方案。这些功能点往往没有真正的战略价值。这些碎片化需求影响产品的内在一致性和长期发展能力；产品经理已经从“产品首席执行官”转变为被动应对客户需求，实际上已经成为服务客户的项目经理和原型/需求编辑，不再积极规划自己的产品；R&D/设计师会因为被迫接受客户指定的需求和时间点而失去热情，而不是通过学习和探索来开发产品。在这些客户的需求完成后，很少有积极的反馈（通常是问题）