从项目交付到产品沉淀，绝非简单的功能堆砌。本文深入剖析能源类工业数字化项目中常见的产品化困境：当报表、规则和流程看似完美解决客户需求后，为何在下一个项目中仍面临复用难题？揭示从具体项目方案中提炼可复用产品能力的五大关键判断，帮你跨越'功能集合'与'产品能力'之间的认知鸿沟。

前面几篇文章，我们一直在讨论一件事：产品经理真正进入项目以后，不能只是把客户的话记下来，再按原样传给研发。客户为什么提出这个功能，项目到底想解决什么问题，现场条件能不能支撑，合同里已经承诺到哪里，本期又应该做到多深，这些都需要重新判断。项目做完以后，还要回过头看一眼，哪些东西只是这次交付需要，哪些经验和做法值得继续留下。

这些判断慢慢建立起来以后，产品经理的工作状态会发生一些变化。他不再只是需求的接收者，也不只是跟着项目节奏往前走，而是开始能够站在项目整体上，看清目标、问题、现场和交付边界之间的关系。做到这一步，至少说明我们已经不容易被一张功能清单牵着走了。

可项目看懂了，下一道难题也就跟着来了，我们知道什么值得留下，并不等于知道怎样把它变成产品。一个方案在当前客户这里跑通了，换到另一个客户为什么还能成立？项目里形成的规则、流程和页面，哪些值得由产品长期负责，哪些只是这个客户的特殊情况？产品已经有了基础能力以后，新的项目需求又该怎么进来，才不会每做一个项目，就往产品里再塞一批功能？这些问题，往往比判断一个需求做不做更难。

项目结束以后，团队通常也不会什么都不做，新开发的功能会合入版本，客户专属名称会被改掉，实施人员会补一份配置说明，产品经理也会把其中一部分需求继续放进后续规划。站在当时看，该留下的似乎都留下来了。可等到下一个相似项目启动，原来以为能够直接复用的内容，很快又会露出问题：产品经理还要重新确认口径，实施不知道从哪里开始配置，研发也不敢判断旧逻辑能不能动。碰到关键问题，大家最后还是得把原项目的人找回来，再问一遍当时为什么这样设计。

功能、代码和文档虽然都保留下来了，但它们还是离不开原客户的业务条件，也离不开原项目人员对设计背景和使用方式的解释。换一个客户、换一批人以后，这些成果往往就不能直接被理解和使用。说到底，项目交付的结果只是被保存了下来，还没有真正变成能够离开具体客户和项目、被持续复用的产品能力。

因为我平时接触得更多的是能源类工业数字化项目，后面讲这些问题时，会穿插一些能耗统计、异常管理、费用分摊之类的场景。这些例子大多来自实际项目，未必是最标准的产品案例，但放到具体工作里，反而更容易看清有些问题究竟出在哪里。

这篇文章想先把这一阶段的底层逻辑搭起来，产品可能是从第一个项目里慢慢长出来的，也可能已经有了一条相对稳定的主线，再由后续项目不断补充和修正。无论是哪一种情况，真正需要完成的都不是一次功能整理，而是把项目里的具体答案，慢慢变成产品能够长期承担的能力。

产品不是项目功能的集合。项目功能只是产品形成时最容易被看到的结果，真正需要留下来的，是结果背后能够反复成立的能力。

一、项目做完了，产品为什么还没有自然形成

一个项目通过验收时，团队最关心的，通常还是客户的问题有没有解决，合同范围有没有完成，系统能不能在现有现场条件下正常运行。只要这些都没有大问题，从项目交付的角度，这套方案基本就站住了。可同样的内容一旦准备进入产品，面对的就不再只是眼前这个客户。组织结构换了、数据基础换了、管理习惯换了，原来的做法还能不能继续成立，就得重新看一遍。

比如，一个客户提出要按部门统计能源消耗，这个客户的组织相对稳定，大部分部门都有独立区域，现场的计量点也基本能够与部门对应。少量公共区域虽然无法直接归属，但内部已经有一套大家认可的分摊比例。基于这些条件，项目团队做出了部门能耗报表，能够看到各部门的用电量、费用和异常波动，客户也准备用这些数据做内部管理。

换到另一个客户，同样一句“按部门统计能耗”，背后的情况可能完全不是一回事，表计按照楼栋、配电箱和设备安装，计量边界与部门边界对不上；一块区域可能有几个部门共同使用，内部也没有商量清楚公共负荷怎么分；组织还经常调整，设备今天归这个部门，过一段时间又换到另一个部门。此时把原来的报表复制过来并不难，真正难的是这些数据到底应该归给谁，以及最后谁愿意对这个口径负责。

回过去看，前一个项目交付的其实不只是一张报表，报表背后还站着组织结构、计量关系、分摊口径和管理责任。客户的问题、现场条件、合同要求的深度，以及项目中为了工期和现状作出的取舍，都已经被揉进了这个功能里。项目验收只能说明这套组合在当前条件下有效，却不能直接证明，它已经适合成为产品。

如果产品最后只留下页面、字段和查询入口，留下的仍然只是结果。下一次面对新的客户，团队还得重新问一遍：统计对象是什么，数据从哪里来，边界怎么划，无法直接计量的部分怎么处理，最终由谁确认。项目交付留下来的，其实是一套围绕当前客户拼起来的答案；产品如果想继续往前走，就得把这套答案重新拆开看看，哪些关系换了客户以后依然成立，正常情况下应该怎么做，现场不一样时又允许怎么变。

所以，从项目走向产品时，最先要放下的一个念头，可能就是“这个功能已经做过了”。做过，只能说明团队手里有一份可以参考的答案。它能不能成为产品，还要看这个答案背后，有没有一套换了客户以后依然说得通的逻辑。

二、项目和产品之间，其实存在两种不同的关系

说到“项目转产品”，我们很容易在脑子里形成一个比较顺的过程：先做完一个项目，再把里面有共性的功能挑出来，改成标准版本。但真实公司的情况往往没有这么整齐。项目和产品之间，至少存在两种很不一样的关系。

第一种，是产品本身就从项目里慢慢长出来。公司刚进入一个新的行业或业务方向，手里没有成熟产品，往往是先拿到第一个客户项目，再跟着调研、设计、开发和交付，一点点理解这个行业有哪些业务对象，数据怎么流动，规则怎么运行，客户又在怎样管理。这个时候，项目既要完成当前交付，也在帮助团队认识未来的产品。

这里最容易踩的坑，是第一个客户不知不觉就变成了产品本身。在首个项目时按照集团、工厂、车间、产线四层结构管理，系统底层就跟着写死四层；客户习惯按自然月统计，所有分析就默认自然月；为了赶工临时增加了Excel导入，后来也一直被当成标准入口。等第二个客户进来，组织层级、统计周期和流程都不一样，团队才发现所谓标准产品，其实只是第一个项目换了个名字。这个坑很常见，而且往往不是一开始就能看出来。

所以，产品从项目中孵化时，真正要做的不是尽快把首个项目包装成产品，而是在前几个项目里慢慢确认：哪些问题会反复出现，哪些对象和规则值得成为产品基础，什么能够作为典型场景下的默认做法，哪些只是当前客户的习惯，还有哪些判断现在根本下不了结论，需要后面的项目继续验证。第一个项目可以决定从哪里开始，却不能太早决定产品以后只能长成什么样。

第二种情况，是公司已经有了相对稳定的产品主线。项目团队基于产品完成客户交付，产品团队负责标准版本和后续演进，项目里出现新的问题、新的指标和新的场景，再被带回产品侧判断。这个时候，产品经理面对的就不是从零建立产品，而是分辨这次项目反馈到底意味着什么。

客户提出一张新报表，可能只是现有产品没有被正确配置；看起来全新的指标，也可能通过已有计算规则就能实现；某个场景开始在多个客户中重复出现，可能更适合形成一套模板，而不是修改底层结构。当然，也会有一些反馈真正暴露了原有能力缺口，需要产品继续往前走。几种情况表面上都是“项目有新需求”，背后对产品的意义却完全不同。

一种是在项目中慢慢建立产品，另一种是用项目不断验证和修正已有产品。起点虽然不一样，但绕到最后，处理的还是同一个矛盾：项目里的真实经验需要进入产品，可当前客户和当前交付，又不能直接替产品作决定。

三、两种情况下，项目成果进入产品都绕不开五个判断

如果产品本身就是从项目里慢慢长出来的，团队一开始其实没有一个现成答案，只能一边把当前客户的项目往前推，一边从里面判断，哪些东西可能成为产品后面的基础。可如果公司已经有了一套相对稳定的标准产品，情况就不一样了。这时项目带回来的问题，更像是在不断检验原来的产品：哪些地方还站得住，哪些地方确实需要补上，又有哪些变化只是当前客户的特殊情况，不能轻易写进产品。

但再往下看，两种情况下真正要完成的事情，其实没有太大区别，项目里出现的真实问题、具体方案和交付经验，都不能原封不动地进入产品。它们首先服务的是眼前这个客户，里面会混着现场条件、合同范围、交付周期，甚至还有一些当时为了把项目先跑起来作出的取舍。只有重新看过一遍，它们才有可能从服务一个客户的项目成果，慢慢变成产品能够长期承担的能力。

这个过程，当然不是项目结束以后开一次复盘会，把功能分分类，再决定哪些合入标准版本就够了。真正摆在产品经理面前的问题要杂得多。项目里已经做出来的功能，到底在解决什么问题？这个问题是不是产品以后准备持续解决的？当前方案中，哪些部分依赖客户现场，哪些部分换一个客户以后仍然成立？这些稳定部分被找出来以后，典型项目应该怎样直接使用？客户出现差异时，又应该调整参数、补充模板，还是重新扩展产品？

再往后，项目里带回来的新需求，到底是在补充产品、修正原来的判断，还是正在把某个客户的特殊情况重新写进产品，也得继续分辨。即使功能已经进入标准版本，换一个产品经理、换一批研发和实施人员以后，这项能力能不能被真正理解和使用，同样决定了沉淀到底有没有完成。

把这些问题摊开来看，项目成果真正进入产品，大致绕不开五个判断：

1.确定产品长期承担什么问题

这里不是重新讨论完整的产品定位，而是在目标客户和业务场景已经基本确定以后，继续判断产品准备把问题解决到哪一步。哪些内容由产品长期承担，哪些仍然依赖客户管理、实施服务或者项目定制，至少要先划出一个大概范围。这个边界不一定一次就能定得很准，但不能完全没有。

2.从项目方案中形成稳定的能力结构

一个项目里做出来的页面、规则和流程，往往混合着客户自己的特点和项目中的临时处理。产品需要继续看清，解决这类问题真正离不开哪些业务对象、数据关系、规则、状态和角色。说得直白一点，就是把“这个客户怎么做”往后退一步，看看“这类问题到底靠什么被解决”。

3.建立产品基线和变化边界

新项目启动时，团队不应该再面对一片空白，而是已经知道正常情况下应该建立什么、启用什么、做到什么程度。同时，客户之间又不可能完全一样，产品还得为这些差异留下合理的变化空间。哪些变化可以通过参数、模板和流程调整，哪些已经超出了原来的产品结构，不能等到项目做到一半再去猜。

4.判断项目如何推动产品演进

新的客户、新的现场和新的需求，会不断检验过去的判断。产品需要根据这些证据决定哪些地方值得调整，哪些内容只属于当前项目。这个分寸其实不太好拿：既不能把真实项目带来的问题都挡在外面，也不能让每一个项目都重新定义产品。

5.验证能力是否真正脱离项目

功能进入标准版本，只能说明它被放进了产品。换一个客户、换一批人以后，这项能力还能不能被理解、配置、交付和继续维护，才决定它是不是真的离开了原项目。很多时候，问题就是在这一步才暴露出来。

这几个判断并不是一套严格按照顺序执行的流程，真实项目里，它们经常会来回反复。一个新的客户可能让团队重新认识产品到底应该负责什么；一种新的现场条件，也可能暴露原来拆出来的能力结构并不完整；有时候产品的基础方案已经形成，后续项目却证明原来的默认做法只适合少数客户。做产品这件事，很少真的像流程图一样一步一步往前走。

项目提供真实问题和具体答案，产品要做的，是从中慢慢形成能够长期成立、允许合理变化，并且可以持续演进的解决方式。

从项目交付走到产品沉淀，中间缺少的从来不只是一次功能归并。更麻烦、也更费脑子的，是把一个只在具体客户和现场中成立的项目答案，重新变成产品可以长期承担的能力。接下来，我们对这个五个判断逐一展开讨论。

四、先确定产品长期承担什么问题

项目结束以后，团队很自然会去找“共性”：这个功能是不是多个客户都提过，这套规则以后还有没有人会用，能不能做成标准能力。可名字相同，并不代表问题真的相同；即使面对的是同一个问题，客户希望系统承担到什么程度，也可能差得很远。

比如用异常管理功能来举例，有些客户所说的“异常闭环”，只是希望系统发现问题以后发一条消息，相关人员能够及时看到，系统的任务就基本完成了。另一些客户希望异常自动生成任务，责任人要填写原因和处理结果，管理人员还要看到处理进度。再往后，有些客户会继续要求复核、逾期升级、整改追踪，甚至把处理及时率放进部门考核。

这些需求都可以叫异常闭环，但系统承担的事情已经完全不同了。它先是帮助客户发现问题，后来开始推动处理，再往后又进入责任追踪和内部考核。第一个项目做提醒，第二个项目增加派单，第三个项目增加复核，第四个项目再接上考核，每一次都有真实需求，可产品的范围也会被一点点拉长。做到最后，团队自己可能都说不清楚，我们提供的到底是异常识别工具，还是一套企业内部管理系统。

这里需要区分一下，产品定位通常回答的是产品面向谁、主要处在什么场景、希望提供什么核心价值；而这一章想讨论的，是在这些已经大致确定以后，产品对某一类问题准备承担到什么深度。换句话说，不是重新决定产品卖给谁，而是决定在这个场景里，产品准备负责到哪一步。

这里说的“长期承担”，也不只是把某个功能放进标准版本，它意味着以后类似客户再遇到这类问题，公司仍然准备通过产品去解决，并持续接住由此带来的交付、维护和演进责任。项目里可以为了当前客户先做一个功能，但只有公司愿意在后续版本和更多项目中继续负责，它才真正进入了产品的责任范围。

比如，能源异常管理可以先把责任划在这样一个范围：企业已经具备基础计量和数据采集条件，系统帮助能源管理人员识别异常、通知责任人，并记录从发现、处理到关闭的基本过程。这样一来，产品面对的是能源数据异常，不是所有生产经营问题；它可以承担识别、通知和基本处理记录，但多级审批、跨部门协同和绩效考核是否继续往里放，就需要结合整体方向重新判断。

责任范围不同，产品最终要建设的东西也会不同，只做识别和提醒，重点在数据规则、异常事件和消息机制；继续承担处理闭环，就要增加任务状态、角色责任、处理记录和关闭逻辑；再进入考核，产品还会碰到组织关系、统计口径和管理制度。只有先想清楚产品准备把问题管到哪一步，团队才知道哪些对象、规则和流程必须进入产品，哪些内容不应该因为某一个项目继续往里扩。

五、再从项目方案中形成稳定的能力结构

责任范围大致清楚以后，项目里已经做出来的功能还需要重新拆一遍，项目交付的是一套围绕当前客户已经组合好的方案，里面既有解决问题必须依赖的关系，也有客户自己的组织和数据特点，还可能混着为了工期和验收先采用的临时办法。它们在项目中可以一起工作，但进入产品以后，不能再混在一起。

能力结构不是一张功能清单，也不是系统的技术架构，它更接近于：产品想稳定解决一类问题，需要围绕哪些业务对象，接入什么数据，按照什么规则运行，经历哪些状态变化，由哪些角色承担责任，最后形成什么结果。页面、报表和流程只是这些关系落到系统里的表现，真正需要留下来的，是它们背后那套换了客户以后仍然说得通的业务骨架。

以能源费用分摊为例，某个客户希望把能源费用分到各部门，有独立电表的部门按照计量数据直接计算，公共区域没有独立计量，只能按面积分摊，部分生产部门还要结合产量和工时进行调整。项目团队按照这些条件做出了一套费用计算方案，客户可以查看各部门费用，确认后再交给财务使用。

如果最后只把项目结果留下来，产品很容易变成几种公式的集合：按表计分、按面积分、按产量分、按工时分。可换一个客户，分摊对象可能不是部门，而是租户、车间、产线或成本中心；费用来源也可能不是实时表计，而是账单金额和内部结算价格；公共损耗怎么处理、规则之间有没有先后顺序、历史月份能不能重算，也都可能不同。继续增加公式，只会让产品拥有越来越多的答案，却还是不知道这类问题到底由哪些关系构成。

真正需要重新建立的，是分摊对象、费用来源、分摊依据、规则生效、结果确认和历史追溯之间的关系。费用到底分给谁，被分的是用量、账单费用还是公共损耗，多种规则怎样组合，在什么范围和时间内生效，结果能不能调整，由谁确认，数据缺失以后怎么处理。只有这些关系被看清，费用分摊才不再只是几条项目算法，而开始变成产品能够理解和承载的能力。

拆到这里，项目里的内容其实会走向不同位置，解决这类问题时反复出现的对象、规则、状态和责任，要进入产品结构；不同客户按照部门还是租户管理、费用来自账单还是表计、采用面积还是产量作为依据，这些合理差异需要形成映射、参数、模板或流程机制；接口还没做好时先导入Excel、数据不足时暂时用固定比例、客户规则没有统一时允许人工修正，则更像是当前项目或过渡阶段的处理。

难点并不只是把它们分成三类，而是分完以后真的让它们去不同的地方。稳定部分进入产品结构，合理差异形成变化方式，临时妥协则被留在项目或明确的过渡阶段。如果最后什么都往产品里放，第一个客户的组织方式、特殊口径和验收补丁，就会和真正的产品能力一起被永久保留下来。后来的人只能看到系统里有这些字段、入口和开关，却很难再说清楚它们为什么存在。

六、有了能力结构，才能建立产品基线和变化边界

当业务对象、规则、状态和责任关系逐渐清楚以后，产品已经不再只是保存页面和代码。但这时候形成的，更多还是一组可以组合的能力。它们很重要，却不一定能直接拿到项目里使用。

很多行业软件都很强调配置能力，组织可以配置，指标可以配置，规则可以配置，报表和流程也可以配置。理论上看，各种客户都能支持。可新项目真正开始以后，产品经理和实施人员还是要重新讨论：应该建立哪些对象，启用哪些能力，默认配什么规则，流程做到什么深度，客户要准备哪些数据，一个标准项目最后应该交付成什么样。

所有内容都能配置，却没有人知道正常情况下应该怎样配置，原来需要研发重新开发，现在变成产品经理和实施人员重新设计。代码可能真的复用了，方案却还是从头开始。

所以，在稳定结构之上，产品还需要给出一套典型场景下可以直接使用的基础方案，也就是我们常说的产品基线。产品基线其实回答的是一个很实际的问题：新项目开始时，产品已经替团队想清楚了什么，而不是还有哪些事情要重新讨论。

一套有用的产品基线，不只是列出系统有哪些功能，它应该告诉团队，典型客户需要建立哪些核心对象，默认启用哪些能力，采用什么基础规则和流程，标准交付做到什么程度，又需要客户具备哪些数据和管理条件。比如能源异常管理，可以默认支持计量点和设备的数据中断、固定阈值和历史偏差类异常；异常产生以后通知责任人，记录处理情况，并在数据恢复或人工确认后关闭。新项目可以调整阈值、责任人和通知方式，但不需要重新讨论异常管理应该从哪里开始。

当然，基线也不能变成一套写死的标准答案，如果只有基线，没有变化方式，产品会把某一种典型客户当成所有客户；如果只有大量配置能力，没有基线，产品又会变成一个什么都能搭、每次却都要重新设计的平台。真正可持续的产品，既要说清楚正常情况下怎么做，也要说清楚客户不一样时可以怎么变。

这里提到的变化边界核心是：在产品解决的问题、核心对象和责任关系没有改变的情况下，客户可以在哪些地方不同；一旦这些基础关系都发生了变化，就不再只是参数或配置的问题，而可能已经是新的产品能力，甚至是另一段产品范围。

有些差异只是名称不同，例如“厂区”和“基地”、“责任部门”和“成本中心”，只要承担的业务角色一致，可以通过映射处理；有些是阈值、周期、价格和生效时间不同，可以放进参数；有些是一组常见规则组合，可以形成场景模板；还有一些差异发生在流程和角色上，只要仍然围绕同一个问题和责任关系，就可以通过流程机制承载。若连业务对象、问题目标和核心责任都发生了变化，继续增加配置项通常已经不合适，需要重新判断是否扩展产品能力，或者干脆由项目继续承接。

我更愿意把配置化理解成一种“控制变化”的方式，而不是让所有东西都能改。基线给产品一个起点，变化边界则告诉团队，哪些地方可以变、怎样变，变到哪里以后已经不再是原来的能力。两者放在一起，新项目才既不用从空白开始，也不会因为客户条件不同就只能重新定制。

七、项目应该推动产品演进，而不是把产品重新拉回定制

产品有了基本责任、能力结构和基础方案以后，项目里的新需求并不会减少。相反，客户越多，新的场景、规则和使用问题只会越来越多。这个时候，产品经理面对的就不再只是“需求有没有价值”，而是这次反馈到底在说明产品哪里需要变化。

产品演进不是产品跟着项目不断增加功能，是新的项目证据让团队有理由重新检查原来的责任范围、能力结构、产品基线和变化边界，并决定哪些地方真的需要调整。新增一个页面、一个报表或者一个开关，可能只是补丁；只有原来的产品判断被验证、修正或补全，产品才算真正往前走了一步。

一个客户提出新的报表要求，可能只是现有产品没有被正确配置；一项看起来全新的指标，也许通过已有计算规则就能实现；新的场景在多个项目里反复出现，可能值得形成一套模板，而不是去改底层结构。当然，也会有一些反馈真正暴露了产品能力上的空缺，需要进入后续版本。几种情况表面上都是“项目有新需求”，对产品的意义却完全不一样。

如果缺少这层判断，项目需求就会直接变成产品需求，客户需要一张特殊报表，产品就新增一张报表；流程不同，就增加一个开关；计算口径不同，再补一套逻辑。每次修改都能找到真实项目作为理由，产品却会慢慢失去自己的主线。名义上项目和产品已经分开，实际上还是每一个客户都在重新定义产品。

更健康的关系，是让项目为产品提供证据，而不是直接替产品作决定。产品经理需要继续判断，这个问题是否还在产品已经承担的责任范围里，现有能力是不是真的无法解决，差异能不能被已有的变化机制接住。如果确实需要扩展，它更适合进入基础版本、场景模板、扩展模块，还是以后某个版本；如果只服务当前客户，就应该坦然留在项目范围内。

项目必须交付的内容，也不一定都由产品长期承担，有些需求已经写进合同，本期肯定要做，但它高度依赖客户的特殊组织和流程；有些问题值得产品长期解决，当前项目却只能为了时间先用一个临时方案；还有一些成果更适合形成实施模板、专业服务、售前案例或者项目经验。它们都有价值，只是价值的去向不一样。

一项能力进入产品以后，公司承担的不只是一次开发，历史客户是否兼容、版本怎样升级、测试要增加多少场景、实施怎样配置、售前能承诺到哪里，都会变成后续责任。当前增加一条规则可能只需要几天，可未来能不能切换、历史数据怎么追溯、报表接口是否兼容，可能会跟着产品很多年。

所以，产品化并不是对一个好需求的奖励，也不是项目价值唯一的归宿，它意味着公司决定以后持续解决这一类问题。产品不能为了保持标准而拒绝真实项目带来的修正，也不能因为当前项目压力，让每个客户都重新改写产品。项目不断把真实问题和使用反馈带回来，产品再根据这些证据调整责任、结构、基线和变化边界，产品才是在往前走，而不是一次次退回定制。

八、能力能够离开原项目，沉淀才算真正完成

即使产品责任已经说清楚，能力结构和产品基线也已经形成，研发把功能做进了标准版本，沉淀仍然可能只完成了一半，因为系统里存在一项功能，并不代表公司真的拥有了这项能力。

“能力离开原项目”并不是说以后完全不需要任何人解释，也不是多补几份文档就算完成，更实际的状态是，原本依赖少数人记忆的判断、配置方式、交付方法和维护责任，已经逐渐被团队接住。即使原项目人员不再参与，新的团队也能知道这项能力为什么存在、适用于什么条件，客户差异该怎么处理，后续再出现新的需求，又应该放到产品、配置、版本还是项目里继续承接。

很多团队都会遇到类似情况，产品经理知道这个功能为什么做，研发知道代码写在哪里，原项目实施人员也知道怎么配置。换一个项目以后，新实施却不知道需要准备哪些数据，也不知道几十个配置项应该怎样组合；测试只验证页面能不能操作，没有覆盖真实业务场景；售前告诉客户系统支持完整闭环，到了交付阶段才发现标准能力只做到消息提醒。最后，大家还是要把原项目的人叫回来。

这说明功能虽然进入了版本，能力却还留在少数人的经验里，真正完成沉淀，需要让不同角色对这项能力形成相对一致的理解。产品经理要说清楚它解决什么问题、适用于什么场景、默认做到什么程度；研发要知道哪些结构需要稳定、哪些位置允许扩展；测试要知道标准场景、变化场景和异常条件怎样验证；实施要能够根据明确的前置条件和默认配置，把能力在新项目里真正跑起来；售前也要知道哪些属于标准能力，哪些还需要单独评估。

这些内容最后还是要落到产品说明、配置模板、测试场景和交付方法里，但关键并不在文档有多少。更重要的是，不同角色能不能对这项能力形成相对一致的理解，并且真正接住各自的责任。到底有没有完成，可以放到几个很现实的变化里看。

换一个客户。新的组织、数据和管理要求出现以后，团队能不能站在已有产品基础上调整，而不是重新定义整套能力？如果换一个客户就要重做，说明能力仍然绑在原现场。

换一批人。原项目产品经理、研发和实施不再参与，新的团队还能不能理解、配置、测试和交付？如果人一换就不会用了，说明能力仍然绑在个人经验上。

再出现一个新需求。团队能不能判断这次变化应该进入参数、模板、流程、能力扩展还是基础方案调整，而不是每次都增加一套特殊逻辑？如果所有变化最后都变成新的分支，产品还没有形成真正可以继续生长的结构。

只有经过这些变化，项目成果才算真正离开某一个客户、某一批人员和某一次交付，成为公司能够反复使用、持续维护和继续演进的产品能力。

九、项目做得越多，产品应该越来越清楚

走到这里，产品经理面对的问题也和以前不一样了，他不再只关注当前项目有没有完成，也不再停留在判断哪些成果值得留下，而要继续想：产品准备把问题管到哪一步，项目方案中哪些东西可以形成稳定结构，典型客户默认应该怎么做，客户差异应该放在哪里，什么样的项目证据足以推动产品变化，以及这项能力最后有没有被组织真正接住。

这些问题背后，对应着产品能力建模、产品基线构建、产品演进判断、共性与差异处理、产品边界控制和复用验证等能力。名字听起来不少，但它们并不是几套互相独立的方法。说到底，都在推动同一种变化：产品经理不再只负责把当前项目做完，而是开始让项目中已经验证过的价值，慢慢变成公司能够长期使用的产品能力。

产品沉淀也不意味着以后所有项目都完全一样，更不意味着项目团队不再需要调研和判断。真正发生变化的是，团队不再从一张白纸开始。它已经知道产品主要解决什么问题，典型场景默认怎么运行，客户差异可能出现在哪里，什么可以通过参数和模板调整，什么需要推动产品继续演进，什么仍然应该留在项目里。

项目做得越多，产品应该越来越清楚，而不是功能越来越多、配置越来越复杂、历史逻辑越来越不敢修改。项目功能只是产品形成时留下的表面结果，真正值得沉淀的，是已经被看清的问题、相对稳定的能力结构、经过验证的基础方案、明确的变化边界，以及公司愿意长期承担的责任。

后续，我们先从第一种典型场景继续展开，很多产品最初并不是完整规划出来以后再进入市场，而是从第一个客户项目中慢慢长出来的。首个项目既提供了真实问题和最初方案，也会把客户自己的组织、流程、口径和临时处理一起带进系统。当产品从项目中孵化时，怎样让第一个项目成为产品的起点，而不是未来产品的限制？这是下一篇要继续讨论的问题。