销售说：产品太拖后腿了
To B 人，很多可能都听到过销售、售前团队这么抱怨产品团队。
抱怨基本上会集中在产品这需求那需求不支持，研发的交付太慢，系统不稳定三个方面。在 To B 领域，这个问题很常见，不用过分紧张。
问题的症结也是 To B 相比 To C 的一个显著不同：To B 的链条太长了。
从客户反馈，到产品设计、实现，或者从产品功能发布，到客户升级、使用，时间可能已经过去 3 个月了。产研团队很难去判断销售、售前口里的客户需求，到底是真的客户需求，还是只是为了商务关系给客户夸下的海口，也很难持续跟进需求在客户侧的落地情况，客户使用的时候，产研团队可能已经在忙其他需求了。
说下我曾经的解法，我当时负责一款产品的研发和商业化工作。
我们的售前团队又称解决方案团队，负责客户的前期需求沟通和方案设计工作，打单竞标过程是重点参与的，售前团队承担着和产研提需求，沟通排期交付时间，推动 PoC 及反馈客户意见的职责。
当面临和产研，主要是跟产品团队的冲突时，我的做法是”相信售前，但坚定站产品“。
我做了三件事。
首先，和售前 leader 建立彼此的信任。告诉他自己知道产品现在的能力还不够，但希望产品团队能保持对产品的控制力，面对你们俩的冲突我会站产品，你可能会觉得委屈，但你可以找我对话，我也会帮你担责。
第二，我会记录售前提的但被拒掉的需求，当一段时间有多个类似的需求提过来，或者某个需求从生意的角度来看很重要，我会去推动产品，调整研发节奏，做需求插队。
第三，销售不直接跟产品经理提需求，客户需求沟通需要售前参与，需求由售前统一收口后提给产研团队。
这里要明确一个背景，因为当时是我们商业化起步的前几年，重点还是在建设和完善产品的能力，不希望为了做营收，产品团队丧失对产品的控制力和判断力，被大客户的需求拖着鼻子走。To B 起步阶段如果唯一目标就是做营收，会很危险，一个大客户几百万的单子，很可能就把一个创业团队拖死了。
为什么由售前统一收口客户需求，要回到建立售前团队的另一个初衷，避免销售过度承诺给产研挖坑。这倒不是怪销售，销售很辛苦，尤其产品还没有太多业界口碑的时候，但偏短期业绩导向的激励模式使得这个问题不可避免。所以我一直坚持售前团队归属于产研线，而不是销售线，但他需要和销售共背一些目标。
最终我们形成的产品迭代策略是这样的：
- 只做在产品 pipeline 里的需求，按 Q（季度）发版本，我们称为 LTS 版本（Long Term Support / 长期维护版本），销售侧只能提前卖下一个 Q 规划的能力。
- 客户需求如果在产品的长期规划中，经评估后，可以酌情做插队处理。
- 每月会发布迭代版本，如果某些 feature 会影响到成单，可以提前给客户交付，但大的 bug-fix 或改动，不会基于迭代版本做，需要升级至 LTS 版本。
- 产品的 SaaS 版按月度迭代版本全量更新。
关于客户的定制需求，我们一开始是坚决不做的，只提供和客户内部系统集成相关的开发支持，比如和企业内员工系统的对接。在产品的不断稳定和客户拓展到一些行业纵向后，会考虑做有限的定制开发支持，两个策略：
- 通过合作方来做，产品要建设一定的开放能力，让第三方可以基于 API 做定制开发。
- 自建定制化开发团队，我们是先放在交付实施团队。这里有一个原则是定制需求一定不是产品的主线需求，主线需求只会由产品的产研团队承接，如果出现某个客户的定制需求被验证具备可复制可能，要移交产研团队加到产品主线版本。
以上是第一种方法。
第二种方法是我从海外一家厂商学来的。
该厂商为了解决销售、售前、产品脱节的问题，内部研发了一个需求 ticket 系统，销售和售前都可以在系统里录入客户需求，所有该产品的销售、售前可以在系统里给某个需求 ticket 点赞，系统会根据点赞数做需求 ticket 的排名。
产研侧承诺每个迭代周期会留出固定的人力投入，对点赞数靠前的需求做评估，优先实现。
第三种方法，是一种岗位职责上的重塑。
既然售前/解决方案岗位最接近客户，也直面市场挑战，那索性客户问题到产品需求抽象的职责交由售前/解决方案团队承接。
具体分工是这样的，售前/解决方案团队对接客户，收集和分析市场需求，做需求抽象后转交产研团队。产研团队针对这些抽象需求，做高质量的产品设计，以及开发实现。
这个方法其实是把长长的链条从中砍断，产研团队只对产品实现和交付质量负责，产品的规划和发展由售前/解决方案团队负责。
最后，关于销售、售前和产研的关系我有两个观点：
第一，双方存在良性对抗不是问题，反而代表着一种比较健康的状态。
第二，服务好客户、帮客户解决好TA面临的问题是 To B 生意能持续做下去的决定因素，但如果前线团队动辄用「客户第一」名义，高举高打喊口号来胁迫产研，生意能持续做下去的几率很低。