产品做出来了，但为什么每笔交易还是像第一次？从产品到商品，中间隔着一层被大多数团队忽略的「商品基线」。本文深度拆解商品基线的五个核心问题——谁买、为什么买、买什么、怎么交易、怎么交付，帮你把「卖出去过」变成「可复制的稳定交易」。

回看前面几篇文章，我们花了很长时间处理一个问题：项目里做出来的东西，哪些应该留下来，成为公司愿意长期承担的产品能力。

从项目需求怎么进入产品，到产品基线怎么形成；从客户差异怎么接，到版本怎么保持自己的演进节奏。做到这一步以后，一个产品至少在公司内部已经逐渐稳定下来。产品经理知道它解决什么问题，研发知道哪些能力属于标准版本，交付也开始知道什么能做、什么不能继续往产品里塞。

到这一步，不少产品经理容易产生一种感觉：产品已经完成了，后面的事情交给销售就可以了。但产品真正开始走向市场时，会发现又冒出来一堆以前没有真正解决过的问题。

同样一套产品，销售会问：这个到底卖给什么客户？客户如果只要其中几个模块，应该怎么卖？软件、实施、硬件和接口是一起报价，还是分别报价？客户规模扩大一倍，价格为什么要增加？私有化部署和标准部署是不是一个商品？销售答应了一个接口，交付为什么说不在范围内？

这些问题看起来好像分别属于销售、售前、商务和交付，但实际上它们指向的是同一件事：产品已经形成了，但围绕这套产品到底怎么完成一笔相对稳定的交易，还没有真正定下来。这就是从产品走向商品时，需要继续补上的那一层。

一、产品和商品解决的是两类问题

很多项目交付型公司其实很容易把产品和商品混在一起，甚至并没有特别明确的“商品”概念。只要一套系统已经有名称、有功能、有标准版本，甚至已经做过几个项目，大家通常就会认为：“这就是我们的产品，也就是我们拿出去卖的东西。”

但如果静下来仔细想想，会发现产品和商品关注的其实不是同一件事。产品首先解决的是公司内部对能力的组织，一个需求到底要不要进入产品，某项能力是不是应该长期维护，这个功能属于标准能力还是客户特例，产品边界在哪里，后续版本按照什么方向演进，这些都属于产品要回答的问题。

说到底，产品是在确定：公司以后准备持续解决哪些问题，并为哪些能力长期负责。这也是我们前面几篇文章一直在讨论的一件事儿，就是建立产品基线。有了产品基线以后，项目再回来一个新需求，我们至少有了一套判断依据。这个东西究竟是产品本来就应该具备的能力，还是某个项目为了完成当前交付做出的特殊处理，不再完全依赖项目现场临时决定。

但当产品开始往市场上卖时，需要面对的就是另外一组问题。谁会为这套能力付钱？客户为什么现在愿意花这笔钱？他最终买到的是整套产品，还是其中某一部分？软件、服务、硬件、接口和实施应该怎样组合？公司按照什么方式收费？合同签完之后，这个价格到底对应哪些交付责任？这些问题即使产品已经非常成熟，也不会自动得到答案。

到了这里，其实需要换一个视角来看问题：产品是在组织公司的能力，商品是在组织公司的交易。前者解决的是“我们长期做什么”，后者还要继续回答“这些能力到底怎么被客户买走”。一个产品可以在内部定义得非常完整，但只要外部交易仍然依赖销售临场解释、售前重新组合、领导临时报价和项目团队重新确认边界，它就还没有真正完成从产品到商品的转换。

所以产品和商品之间，看起来只隔着“拿出去卖”几个字，实际中间还隔着一层关于交易的重新定义。

二、卖出去过，也不能证明商品已经形成

产品卖出去过，也并不意味着产品商品化已经完成，这一点在项目型公司里尤其容易被忽略。因为很多产品最早本身就是在项目里做出来的。做完第一个项目以后，又接到第二个、第三个项目，于是公司很自然地认为：这个产品已经得到市场验证了。

但项目成交和商品成立，不能简单画等号。比如我们有一套设备管理产品，某个客户我们通过老板关系进入，公司为了拿下项目，销售按照客户现场需求做了一套完整方案；客户提出几个原产品里没有的功能，研发加进去；售前根据客户预算重新组合模块；报价最后由领导拍板；交付团队又根据实际现场调整实施范围。

项目最终签了300万元，系统也交付上线了。

从经营结果看，这当然是一笔真实的收入，但如果第二天来了一个同类型客户，我们仍然要重新回答：应该卖哪一套？多少钱？哪些功能属于标准范围？客户少100台设备和多1000台设备，价格差在哪里？接口包含几个？需要多少实施工作量？哪些要求需要额外报价？

如果这些问题每次都要重新判断，那么上一单成交真正证明的只是：有一个客户愿意为那一次解决方案付钱，它还没有证明公司已经形成了一个稳定商品。

这也是在实际业务场景中很容易出现的一个状态，项目在不断成交，收入也在产生，看起来公司已经有产品、有市场、有客户。但每来一个新项目，产品经理、销售、售前、研发和交付仍然要重新坐下来“设计一次这笔生意”。

客户换了，卖法变了；销售换了，报价逻辑变了；项目经理换了，交付范围又变了。这种状态下，公司真正积累下来的，可能更多是一套很强的项目组织能力，而不一定是商品能力。这两种能力都重要，也没有必要分高低，项目能力强，本来就是很多公司的核心竞争力。复杂客户来，能够把售前、产品、研发和交付组织起来，最后把事情做成，这本身就非常有价值。

但如果我们的目标，是让一套已经形成的产品持续进入更多相似客户，那就还得再往前走一步，让下一笔类似交易，不能一直从零开始。

所以判断一个商品有没有真正形成，不能只看“有没有卖出去过”，更值得问的是：下一次遇到相似客户时，我们是不是已经知道该卖什么、为什么这样卖、怎么收费，以及成交以后双方各自承担什么。当这些问题仍然高度依赖个人经验时，商品其实还没有定下来。

三、真正缺的往往不是包装，而是一条商品基线

很多公司意识到产品“卖得不好”以后，第一反应通常是做包装，重新做一套宣传PPT，把功能描述改成价值描述；做几份行业解决方案，培训销售，再设计几个标准报价模板。这些工作当然有价值，但它们解决不了所有问题。

因为很多时候，销售讲不清楚并不是销售表达能力差，而是公司自己还没有决定清楚到底在卖什么。例如一套能源管理系统，产品里面有能源采集、能耗分析、异常告警、能源报表、设备管理、数据接口等一系列能力。

如果客户只需要能源分析和报表，能不能单独卖？

采集网关算产品的一部分，还是独立硬件？

第三方系统接口包含几个？

标准报价里到底包含多少个采集点？

客户已经有采集系统，只需要软件，价格应该怎么变化？

客户想按年付费，我们是否支持？

这些问题看起来很具体，但背后其实是在反复问同一件事：我们到底在卖一个什么东西？如果产品经理、销售、商务和交付对这些问题没有相对稳定的答案，再好的宣传材料也只能让客户更容易听懂，却没有真正解决交易本身的不确定性。

所以从产品走向商品，真正需要建立的不是一套新的包装，而是一条新的基线。这条基线可以称它为：商品基线。

如果产品基线回答的是“公司长期承担什么能力”，那么商品基线要回答的是：公司准备以什么方式，把这些能力稳定地交给市场。

这条基线最终都绕不开五个问题：

谁买：产品可以适用于很多客户，但真正值得围绕它设计商品的，是那些有明确问题、有预算来源，也具备购买条件的客户。

为什么买：客户不会因为我们拥有多少功能就天然形成采购。真正决定购买的是某个问题已经严重到值得投入预算，或者某项价值已经足以推动客户启动一笔采购。

买什么：客户最终购买的是整套平台、一个行业方案、几个模块，还是软件加设备、实施和服务组成的一整套交付物，这需要重新定义。

怎么交易：按项目一次性收费、按年订阅、按设备数量、按点位、按用户数量，还是平台建设费加年度服务费，不同交易方式背后其实对应着不同的商品结构。

怎么交付：一个价格到底对应多少实施工作、几个接口、什么部署方式、什么验收标准，以及哪些内容超出标准范围，都应该在商品层提前形成相对清楚的约束。

这五个问题不会在一开始就完全固定，尤其商品形成初期，本来就需要不断验证和调整。今天我们觉得某种收费方式合理，做了几个项目以后可能会发现不适合；原来认为某项能力应该做标准配置，后来也可能发现真正需要它的客户并不多。这些变化都很正常。

但调整和每次从头设计，是两回事，真正重要的是，从这个阶段开始，我们不能再只是拿着一份产品功能表出去卖，而要开始有意识地回答：市场上那个真正可以被客户买走的东西，到底是什么。

接下来更重要的，是看这五个问题怎样连成一笔交易。只有它们能够彼此解释，商品基线才不只是五个概念，而是真正开始发挥作用。

四、商品基线真正稳定的，是一笔交易

真正到了实际工作里，商品基线难的不是分别回答这五个问题，而是让它们前后衔接。前面任何一项发生变化，后面的商品组合、价格和交付责任都会跟着动。

比如目标客户没有确定，同一套产品卖给制造企业和政府公共机构，购买原因就可能完全不同；购买原因变了，客户愿意买的内容也会跟着变；“买什么”变了，收费方式和价格依据自然又要调整。到了最后，前面的价格能不能成立，还得回到实际需要投入多少实施和交付工作。

这也是为什么商品化不能简单理解为“把产品拿出去卖”，我们在产品阶段已经把能力逐渐组织清楚，但到了交易阶段，还需要重新回答这些能力到底以什么方式进入客户采购。这里最容易出现的一个误区，就是直接把产品内部的结构当成商品结构。产品内部可能按照能源管理、设备管理、告警中心、报表中心来划分，但客户真正想买的，可能只是“把重点用能设备管起来”。为了完成这件事，公司内部可能同时调用多个产品模块，再加上数据采集设备、实施服务和第三方接口。产品结构本身没有问题，只是它解决的是能力怎么管理，而客户此时关心的是：为了把这个问题解决，我到底需要买什么。

同样的逻辑还会继续往后传，如果“买什么”没有定义清楚，“怎么交易”就很难稳定。一个客户购买的是纯软件，另一个客户购买的是软件、硬件和实施服务的组合，两者即使都使用同一套产品，价格逻辑也不应该完全一样。客户规模扩大以后，到底应该按照设备数量、采集点位、用户数量还是实施工作量调整价格，也取决于前面我们究竟把什么定义成了商品。很多公司报价长期依赖“参考上一个项目”，表面上是没有统一价格，实际上更早的问题往往是：价格到底对应什么，还没有完全说清楚。

再往后，“怎么交付”又会反过来检验前面的商品定义是不是真的成立，一个项目在报价时看起来利润很好，但进场以后才发现需要大量接口开发、数据治理和现场实施，那么问题就不能简单归结为“交付成本没控制好”。有时候是因为前面根本没有把这些工作算进商品范围。也就是说，谁买、为什么买、买什么、怎么交易最终都要落到交付上接受检验。如果每卖一次都需要重新增加大量非标准工作，那么前面的商品定义和价格规则就需要重新检查。

所以商品基线的价值，不只是让销售以后有一套标准说法，也不是为了做出一张统一报价表。它真正解决的是：当一个新的客户出现时，公司不再从零开始设计这笔生意，而是可以沿着一条已经存在的逻辑去判断——这个客户是不是我们真正要做的客户，他为什么会买，需要购买哪些内容，这些内容应该按照什么方式收费，最后公司又要承担什么样的交付责任。

所以从这个角度看，商品基线真正稳定的，不是五个孤立答案，而是一笔交易的基本逻辑：谁买，决定我们在解决谁的问题；为什么买，决定这笔交易为什么发生；买什么，决定客户真正购买的对象；怎么交易，决定价格和合同如何形成；怎么交付，决定公司最终承担什么责任。

而如果这条交易逻辑始终没有形成，每个项目还是需要重新组合、重新报价、重新承诺，那么问题最终也不会只停留在销售端。那些临时形成的交易承诺，迟早还会重新回到产品和交付里。

五、商品基线不是把交易做死，而是让变化有依据

到这里，很容易产生另外一个疑问：既然商品需要建立一条相对稳定的基线，是不是意味着以后面对不同客户，都要按照同一套内容、同一个价格、同一种方式去卖？

并不是，因为对于项目交付场景来说，客户规模、现场条件、已有系统、建设目标和预算都不可能完全一样。如果所谓商品化最后变成了“不管客户什么情况都只能买这一套”，那不是商品基线，而是把原本需要判断的问题简单做成了固定套餐。

商品基线真正要解决的，是变化从哪里开始，以及变化以后应该怎么处理。

比如同样购买一套能源管理商品，一个客户已经具备完整的计量和采集系统，另一个客户需要从电表、采集网关开始建设，两边最终合同金额当然可以不同；一个园区只有几十个采集点，另一个有几千个点位，实施投入和价格也不可能完全一样。商品基线并不是消灭这些差异，而是让我们知道：哪些内容属于这个商品原本就包含的部分，哪些变化会引起商品组合变化，哪些变化又会进一步影响价格和交付责任。

这样一来，面对新项目时，讨论方式就会发生变化。以前是客户来了以后，销售、售前、产品、交付重新坐下来讨论一次“这次到底怎么做”；有了商品基线以后，更多是在已有结构上判断：这个客户属于哪一类购买场景，需要哪些标准内容，有哪些选配，哪些地方已经超出了现有商品边界。项目仍然可以有差异，但这些差异不再默认从零开始处理。

这也是“基线”和“固定”的区别，基线不是要求什么都不能变，而是先给变化一个参照。如果连原来的标准是什么都没有定义清楚，就很难判断客户这次提出的要求究竟是正常组合、合理扩展，还是已经进入了新的项目定制。最后所有变化都会被一句“客户需要”带过去，销售觉得可以谈，交付觉得工作量增加，产品又不知道这项能力以后到底要不要长期保留。

再往后，这些问题甚至会重新影响已经稳定下来的产品。比如商品里没有明确第三方接口的数量和范围，销售为了当前项目先承诺“现有系统都可以接”，合同签订以后，这句话就会从销售表达变成交付责任。交付做不完，最终又会变成一句很熟悉的话：“这个已经卖出去了，产品必须支持。”表面上看，是项目又回来影响了产品；实际上更早的问题是，这笔交易从一开始就没有清楚地区分什么属于商品范围，什么属于项目变化。

所以商品基线真正带来的，并不是让销售失去灵活性，而是让这种灵活有边界。客户可以不同，商品也可以组合，价格可以变化，交付范围也可以调整，但这些变化应该能够找到原因，也能够说明它相对于原有商品发生了什么变化。

如果每个项目都可以变，却没有人说得清楚为什么变、变了什么、应该增加多少成本和责任，那么公司依然是在一个项目一个项目地重新设计交易。反过来，当大部分变化都能够基于已有商品进行判断时，我们才开始真正拥有一个稳定的商品，而不只是拥有一套可以不断拿来做项目的产品。

六、从产品基线走向商品基线

通过今天这篇文章讨论，我们对产品和商品之间真正差的那一步已经比较清楚了：产品基线解决能力的稳定，商品基线解决交易的稳定。前者让产品不再跟着每个项目重新变化，后者让一笔类似交易不必每次都从零开始。

后面几篇，我们会沿着这条商品基线继续往下拆：谁买、为什么买、买什么、怎么交易、怎么交付。这里不用再把五个问题重复解释一遍，只需要先记住，产品走向商品不是某一个动作完成以后突然发生的变化，而是一个逐渐收敛的过程。

先有一套相对稳定的产品能力，再围绕真实客户和真实交易，把这五个问题一点点定下来。客户可以变化，项目也可以有差异，但这些变化开始有一条共同的基线可以参照。

等这条基线基本形成以后，还需要继续验证：换一个相似客户、换一个销售、换一个交付团队，这套商品是不是仍然能够按照大致相同的逻辑完成交易。这个问题后面再单独讨论。

前面几篇，我们一直在试着让产品不再随着每一个项目重新变化。从这里开始，要继续解决的是另外一件事：让一套已经相对稳定的产品能力，不再随着每一笔交易重新定义一次，而是逐渐形成一个真正可以被市场稳定购买的商品。