产品上线后如何推向市场？许多团队陷入“边卖边补”的困境。本文系统梳理产品商品化的关键步骤：从区分产品版本与商品版本，到定义商品、制定价格，帮助产品经理找到明确的结束节点，让产品真正准备好交给市场。

上一篇里简单聊过产品和商品的区别，但真正做到产品准备往市场推的时候，问题会又不一样，很常见的一种情况是，产品已经做得差不多了。核心功能有了，正式版本也发布了，产品经理手里没有什么特别紧急的新功能要继续往前赶。这个时候公司说，接下来要开始推市场。

听起来是很自然，但是轮到自己往下做的时候又比较迷茫，下一步到底应该干什么？是先做一套产品PPT，还是先定价格？是先给营销培训，还是先找几个客户试着讲？现在这套产品能不能直接卖？需不需要再拆一个基础版、专业版、高级版？做到什么程度以后，才可以比较确定地告诉营销：这个东西准备好了，可以正式往外推了？

产品研发阶段结束的节点可以很清晰判断，需求有没有做完、测试有没有通过、版本有没有发布，都有比较清楚的节点。到了推市场这一步，很多公司反而没有一个明确过程，往往是产品上线了，销售先拿出去讲，客户问到哪儿再补到哪儿。价格没定透就先参考以前项目，客户问行业方案再临时做，销售不会讲就产品经理陪着跑充当售前。

做了几个项目以后，PPT越来越多，报价也越来越多，行业方案也积累了一些，但下一次换一个客户，很多事情还是重新讨论。产品明明已经稳定了，市场这一头却一直处在“边卖边补”的状态。

产品商品化不是说再做一次产品，也不是单纯给产品包装一套销售资料，而是在产品已经相对稳定以后，把原来只存在于产品经理脑子里、项目经验里、销售临场判断里的东西逐渐整理出来，让这套产品开始有一个比较明确的市场形态。

客户正常可以买到什么，价格大概怎么形成，营销拿什么去讲，客户通过什么材料理解它，哪些事情可以直接承诺，什么时候公司可以正式告诉营销“可以卖了”，这些事情确定下来以后，产品才算真正做好了推向市场的准备。

从这个角度看的话，商品化其实是在给产品开发和正式进入市场之间补一个以前经常被忽略的阶段，也给产品经理补一个相对明确的结束节点：做到这里以后，这个产品才算真正准备好，可以交给市场了。

一、产品版本和商品版本，先别混在一起

产品开始准备推市场以后，有一个很容易混淆的概念：产品版本与商品版本。我们做产品时本来就一直在做版本，V1.0、V1.1、V2.0。到了商品化阶段又冒出来基础版、专业版、高级版这些说法。两个地方都叫“版本”，说的不是一回事儿。

这个地方如果没分清，后面很容易越做越乱，产品版本记录的是产品能力的变化。比如一套能源管理产品，V1.0先做数据采集、分项统计、基础报表；V1.1增加异常分析和更完整的报表能力；到了V2.0，又增加能源绩效、重点设备分析。产品版本不断往前走，本质是在管理产品能力本身的演进。

商品版本不同于产品版本，基础版、专业版、高级版，描述的是同一套产品能力在市场上准备怎么卖。客户买基础版得到哪些能力，什么样的客户需要专业版，高级版为什么比专业版贵，这些都是购买层面的划分。所以这两个概念不能直接画等号。

产品第一次准备商品化的时候，完全可以只有一个商品，比如能源管理产品已经做到V1.0，公司现在就只卖一套“能源管理平台”。客户正常购买的就是这一套软件，具体项目里可能点位不同、接口不同、有没有硬件不同，但没有必要为了显得商品化，就硬拆出三个版本。

这种情况下关系很简单：能源管理产品V1.0，对外就是一套能源管理商品。

以后产品升级到V1.1，商品还是这一套，只是商品里面承载的产品能力升级了。客户甚至不一定关心我们内部到底是V1.0还是V1.1。

商品版本什么时候才需要出现？是市场上开始反复出现几种明显不同的购买方式时。比如跑了一些客户以后发现，一类客户只想解决“先把能源看清楚”，主要需要采集、分项和基础报表；另一类客户已经有基础数据，更关心异常、分析、绩效；还有一些客户希望把能源分析、设备管理、节能管理一起做起来。这几类客户需要的东西确实不一样，而且不是偶然碰到一次，是反复出现。到了这个时候，把一套产品整理成基础版、专业版、高级版才有意义。

底下还是同一套产品，只是到了市场上以后形成了几种不同的买法。

甚至以后产品从V2.0升级到V2.1，基础版、专业版这些商品版本名称都不需要变，只需要根据产品能力变化调整里面包含的内容。反过来也有可能产品一行代码都没改，市场跑了一段以后发现原来三个商品版本太难卖，最后合成两个。

所以我们需要把它们分开来看：产品版本是能力的演进，商品版本管的是客户怎么买。这两个东西有关，但没有固定的一一对应关系。有了这个认识以后，商品化开头就不用急着问“要拆几个版本”，应该先看当前产品到底有没有必要拆。

如果市场现在还没有明确证据，那就先卖一套标准商品。等后面客户真的出现稳定分层，再拆。很多时候，少做一个版本比多做一个版本更省事。

二、版本概念理清楚后，才真正开始定义商品

商品化里最核心的一步：把产品整理成市场上真正准备卖的那个东西，这一步没必要搞得特别复杂，最开始甚至可以拿一张表来做。

可以先把已经稳定的产品能力列出来，然后换一个角度，不再只看“产品有什么”，而是开始想“客户最后到底买什么”。因为客户不会按照我们的产品模块来理解商品。他更关心的是，买下这套东西以后，能解决什么问题，默认包含哪些内容，还需要额外配置什么。所以商品定义不能只是把现有功能重新抄一遍，而是要把这些已经稳定的产品能力，重新整理成客户能够理解和愿意购买的一套东西。

真正开始整理的时候，我觉得可以先从几个最基本的问题往下走。

先要说清这个商品主要是给谁的：

比如目前这套商品更适合已经有一定计量基础的酒店、园区、公共机构，还是基础计量完全没有也可以直接承接。这个边界会影响后面销售筛客户，也会影响项目是不是一上来就变成硬件改造。

接着是这个商品主要解决什么问题：

这里尽量不要写“提供能耗分析能力”这种产品描述，站到客户那里，可能是看不清能源花在哪里、异常用能发现不了、每个月靠人工统计、做了节能改造以后也不知道效果。

再往下商品到底包含什么：

软件包含哪些能力，部署方式是什么，默认包含几个接口，有没有基础实施，有没有培训，年度服务怎么算。硬件如果是商品的一部分，也要说明；如果硬件只是根据现场另行配置，也不要含糊。

同时把可以增加的内容列出来：

比如额外采集设备、第三方接口、数据治理、专项报表、驻场服务，这些都可以在标准商品之外增加。

最后还要留一个地方专门写：哪些东西目前不属于这个商品：

这一项特别重要，商品刚开始推市场时，很容易什么都想接。客户一提需求，销售觉得产品好像也能做，就先答应下来。时间久了，商品慢慢又被拉回项目模式。所以第一轮商品定义，不光要告诉营销“可以卖什么”，最好也让他知道“哪些事情现在不要直接答应”。

如果目前只有一个商品，这一份东西做到这里就已经够了，如果市场已经出现稳定购买层次，那就在这个基础上再拆商品版本。但版本怎么拆，有一个很重要的原则：就是最好按照客户为什么愿意多花钱来拆，不要按照功能多少来拆。

比如基础版解决的是“能看见”；

专业版进一步解决“能发现问题、能管理”；

高级版再往前做到“能分析、能持续优化”。

这样营销才知道客户为什么应该从基础版升级到专业版，如果版本之间只是少三个菜单、多五个菜单，产品经理自己看起来很清楚，到了客户那里未必有人愿意为这几个菜单多付钱。

商品定义最终最好沉淀成一份固定材料，可以叫《商品定义说明》，名字其实不重要。关键是里面至少把几个问题说清楚：卖给谁、解决什么问题、卖的是什么、如果有多个版本怎么选、默认包含什么、可以增加什么、什么不在正常范围里。后面的报价、材料、培训基本都会从在理开始，如果这一层没定下来就急着做PPT，到后面大概率还是得回来改。

三、商品定下来以后，价格不能再完全靠项目经验

商品大概长什么样确定以后，价格才真正有了基础，以前的时候做项目，价格很多来自经验。上一个项目80万，这个客户规模差不多，也先按80万谈；预算少一点，就看看哪些功能能去掉；现场复杂，就再往上加一些。早期这种做法很正常，而且很多项目就是这样签下来的。

但产品准备作为商品往市场推以后，报价不能再完全依赖上一个项目差不多，否则销售换个人、客户换个行业，价格又得重新问一遍。定价的时候有一点需要注意的时，不要一上来就拍一个标准价。

先翻以前做过的项目，几个类似项目分别卖了多少，软件、硬件、实施、接口各占多少，哪些工作每个客户都会发生，哪些内容一变化成本就明显变化，哪些项目最后看着合同额不低，实际做下来特别累甚至亏钱。很多价格规则其实是从这里看出来的。

如果已经有几个商品版本，可以给每个版本先定一个基础价格，再把真正影响成本的变量单独列出来。如果商品目前只有一套，那就先说清这个标准价格建立在什么条件上。

比如软件包含1000个采集点、两个标准接口、一次部署和基础培训；硬件另算；超过1000点怎么加；增加接口怎么加；历史数据治理或者特殊开发需要重新评估。

产品经理在这里不应该自己闭门造价格，这个阶段最好把商务、营销、交付一起拉进来。商务知道历史成交情况，销售知道客户对价格的真实反馈，交付知道哪些东西看起来只是多一个需求，实际后面工作量很大。产品经理需要做的是把这些信息重新拉回商品里，最后真正留下的东西不需要特别多。

一份标准报价，告诉内部正常情况下卖多少钱。

一份计价说明，说清楚这个价格怎么来的。

再加一份价格调整规则，告诉营销什么情况可以按规则增减，什么情况已经超出标准报价，需要重新回来评估。

这套规则做出来以后，最好别急着相信自己，拿以前几个真实项目套一遍。如果十个项目套进去，八个都变成“特殊情况”，那说明价格规则没有抓住真正影响价格的东西。

正常情况下，一个普通客户来了以后，销售和商务至少应该能自己形成一个大概靠谱的价格范围，真正复杂的，再回来讨论。

我觉得做到这个程度，第一阶段基本也就够用了。

四、材料要分两套做，内部能用和客户能看不是一回事

前面的商品和价格差不多定下来以后，接下里就开始需要准备材料了，这一块需要特别注意，因为很多公司最后就做成“一套PPT走天下”。内部培训用它，第一次见客户用它，客户要资料也发它。东西越塞越多，最后五六十页，产品经理自己看着觉得挺完整，销售拿起来却不太好用。

我建议是把材料分成两套，一套给营销自己用，另一套是营销拿给客户看的。内部材料不用追求多漂亮，它最重要的是让营销真正知道这个商品该怎么卖。先要有一份比较完整的内部商品手册。前面定下来的东西都放进去：适合什么客户，目前是一套商品还是几个版本，版本怎么选，标准价格怎么来，哪些内容属于增项，哪些情况不能直接承诺。

如果营销团队对业务不够熟，我还会补一份首次沟通时应该关注的问题。比如能源管理，第一次接触客户时不一定要拿表逐项问，但心里至少要知道：一年能源费用大概多少，现在有没有系统，计量基础怎么样，谁负责能源管理，为什么现在突然想做，最近有没有节能考核或者成本压力。这些问题不是销售话术，而是帮助营销判断这个客户值不值得继续往下走。

再就是产品应该怎么讲，第一次客户沟通先讲什么，产品什么时候带出来，Demo哪些页面一定要演示，哪些功能第一次没必要展开，正常一场演示最好控制在什么范围。同一个产品，不同人讲出来差别特别大。有的人一打开系统就从菜单开始点，十分钟过去客户还没搞明白为什么要买。所以Demo也应该商品化。

不是要求销售背稿，而是至少有一条比较成熟的演示路线，常见问题也可以慢慢补。客户已有采集系统怎么办、能不能只买软件、接口怎么收费、支持不支持私有化、有没有定制、正常多久能上线。这些问题只要被问过几次，就没有必要每个销售再重新找产品经理问一遍。

对外材料就不是这个逻辑了，客户没兴趣知道我们内部怎么划商品，也不需要第一次见面就把所有能力听完。

最基础的还是产品介绍PPT，但最好别照产品模块组织。比如酒店能源管理，先从能源费用为什么看不清、空调和热水为什么难管、节能改造以后效果怎么持续看开始讲，再把产品能力带出来。这样客户先看到的是自己的问题，后面才是我们的产品。

还要有一份更短的材料，一页、两页或者三四页都可以，客户第一次只是想大概了解一下的时候，没必要一上来就发几十页。如果面对几个行业，就逐渐准备对应的场景方案。不是重新做几套产品，而是把同一个商品放进不同客户的业务环境里重新讲。

再往后是案例、价值说明、收益测算和技术资料。这些东西不一定第一次全部发给客户，但项目往下走时得能拿出来。

材料做到什么程度算够，也不用一开始就想着全部做好。第一轮先把最常用的做好，然后营销出去跑。客户反复问什么，就回来补什么，营销每个项目都临时找产品要同一种材料，就说明这份东西应该正式沉淀下来。

这时候我比较建议的是产品经理自己跟一段时间销售或者售前，不是去替销售背业绩，而是真的跟着跑几次客户，很多东西坐在办公室里很难判断。我们觉得特别重要的一页，客户可能根本不看；我们觉得一句话能解释清的地方，销售每场都卡；产品经理设计的Demo路线，到了现场可能五分钟就跑偏。

商品化初期，产品经理亲自听几次客户怎么问、销售怎么讲，通常比回来听二手反馈有用得多。

五、东西准备好以后，要正式让内部知道“现在可以卖了”

商品、价格、内部和外部材料差不多齐了以后，就该做培训和发布了，内部商品培训和产品培训是不一样的。产品刚上线时做的培训，重点一般是功能、操作、版本变化。到了商品培训不用再把这些内容从头讲一遍，真正要讲的是营销接下来怎么用这个商品，什么客户适合。

现在正常卖哪一套，如果有几个商品版本怎么选、价格怎么形成、第一次见客户拿什么材料、Demo怎么讲、客户问到什么程度，营销可以自己判断、什么情况必须回来找产品，培训完以后，我觉得最好别直接结束。

可以模拟一下真实的客户场景，让营销自己走一次。比如一个酒店客户，年能源费用不低，现在只有基础计量，没有能源管理系统。让营销自己判断推荐什么，第一次怎么聊，拿什么材料，Demo怎么演，价格大概受哪些因素影响。这个过程比产品经理再讲半小时有用。

很多问题只有真正让营销自己走一遍才会暴露，商品版本分不清，说明商品定义有问题。

价格规则根本算不出来，说明定价还得改。材料找不到，说明资料体系没做好。Demo讲不顺，说明产品经理自己设计的方式不适合真实销售场景。

这些东西解决完以后，我才会把这一步看成真正的对内发布。它表达的就是一个明确的信号：公司从现在开始，正式认为这个商品可以卖了。

然后才是对外，对外发布未必非得搞一次大活动。官网正式上线产品页面，公众号开始发布，产品手册正式启用，营销拿统一材料去见客户，这些都可以。关键重要的是从某一个时间点开始，公司正式告诉市场：这个东西现在可以买。对外发布之前，产品经理最好再把所有公开材料过一遍，官网、宣传册、产品PPT、商品名称、版本叫法，别最后各说各话。

最重要的是不要把外面的口径写得比内部真正准备好的商品更大，内部明明只验证过几类接口，对外写“兼容所有第三方系统”；目前主要做酒店和园区，对外直接写成“覆盖所有行业”。这种东西宣传时很好看，后面都会变成客户预期，商品发布不是把话说得越大越好，至少要保证客户外面看到的那个东西，和我们内部真正准备卖的那个东西大致是同一个。

六、第一轮商品化做没做完，要看营销能不能自己往前走

商品化这个事情很容易一直往下做，商品说明还能继续细化，价格还能继续优化，PPT永远可以再改，案例肯定越积累越多。如果等所有东西都完善了再宣布商品化结束，那基本没有结束的时候。

所以第一轮商品化最好还是有一个相对清楚的完成节点，这个节点我觉得不是看文件夹里有多少材料，也不是一定要已经卖出多少单。更接近实际的判断是，看现在把一个正常客户交给营销以后，他能不能不依赖产品经理全程陪着，自己先往前走一段。

比如一个客户来了，营销大概知道这个客户是不是我们现在想做的客户，也知道正常情况下应该推荐哪套商品。如果已经拆了几个商品版本，他大概知道怎么选，而不是每次先回来问产品经理“这个客户到底卖哪个版本”。

价格也一样，未必要求营销自己把所有复杂项目都算得特别准，但正常客户至少应该有一个基本报价规则，不至于每一单都先问老板“这个大概报多少”。

第一次和客户沟通，手里有正式的产品介绍；客户继续往下谈，有对应的场景方案、案例、价值说明或者技术资料可以接着用。客户问到一些常见问题，比如已有系统怎么接、能不能只买软件、接口怎么算、支持什么部署方式，营销自己基本能够回答。

真正碰到超出正常商品范围的情况，比如客户要求大量定制、特殊接口或者完全不同的交付方式，再回来找产品一起判断，这才是比较正常的状态。

如果这些基本都能做到，我认为这个产品已经完成了第一轮商品化，可以正式拿到市场里去验证了。

不过有一点是需要区分一下的是，商品化完成，不等于商品已经成功，商品化完成只是说明我们准备好了。客户到底买不买，版本划分对不对，价格是不是合适，这些事情要等真正进入市场后，才会有答案。

七、商品推向市场以后，产品经理要开始修的可能已经不是产品了

商品真正出去以后，反馈很快就会回来，这个阶段很容易又回到我们以前熟悉的习惯：客户说不好卖、销售说功能不够，产品经理第一反应就是继续做需求。这里要稍微停一下。

市场反馈回来以后，需要先判断它到底是产品问题，还是商品问题。比如原来设计了基础版、专业版、高级版，跑了半年以后发现90%的客户都买专业版，基础版几乎没人问，高级版销售自己都讲不清为什么值这个钱。这时候未必需要改产品，可能只是商品版本拆错了。

原来把第三方接口当成额外选配，结果十个客户有八个都需要两个接口，那也许不是每次都当特殊项目，而是应该重新考虑标准商品是不是就应该包含两个接口。

材料也会暴露问题，产品经理做了一套特别完整的50页PPT，销售基本不用，客户每次真正关心的反而是一份两页的价值说明。那下一轮要改的不是产品，而是材料。

所以商品出去以后，我觉得应该隔一段时间专门回头看一次商品本身：

• 哪些客户最容易往下谈；
• 哪些商品版本卖得最多；
• 哪个版本最难解释；
• 最终成交价格一般落在哪里；
• 客户反复问什么；
• 销售反复缺什么材料；

哪些原来认为是特殊情况的东西，现在已经越来越常见。

这些信息会一点点把第一版商品修正得更接近真实市场，其中有些反馈最终确实应该回到产品。是需要我们判断一下的，比如不同客户反复提出一个产品当前完全不具备、但明显属于目标市场共性的问题，那就要回到产品规划。还有反馈，其实改商品就够了：改版本、改价格、改材料、改目标客户、改表达方式等。

这个判断不做，很容易市场上一有问题，就继续往产品里加功能，最后产品越来越大，商品还是不好卖。所以产品进入商品阶段以后，产品经理其实多了一项新的工作：不只判断产品该不该改，还得判断商品该不该改。跑得时间长一点以后，产品和商品就会形成两条互相影响、但又不完全相同的演进线。产品继续按照自己的能力和版本往前发展，商品则跟着市场真实的购买方式不断调整。

我觉得走到这里，我觉得一个产品才算真正跨过了“做出来”这道坎，后面要面对，已经不再只是产品有没有能力的问题，而是市场到底愿不愿意按照我们预想的方式买它。