产品V1.0只是起点，真实项目才是检验产品假设的试金石。当项目反馈不断涌来，产品经理如何避免陷入“做与不做”的极端？本文提出一套从业务证据到承接层再到产品规划的决策框架，帮助产品团队在项目修正与产品主线之间找到平衡，让产品在真实场景中持续进化。

上一篇文章里，我们讨论的是一件偏“生成”的事：怎样从项目里抽出真正值得沉淀的价值，重新确定产品要解决的问题、长期承担的责任和可以独立交付的能力结构，最终形成产品V1.0。到这一步，产品终于不再只是原项目功能的整理版。销售知道它主要解决什么问题，研发知道哪些能力要被稳定建设，实施也不用每次进入项目都从零开始搭方案。

但产品V1.0形成以后，并不意味着产品已经成熟，太多时候真正麻烦的地方，恰恰是产品进入后续项目之后才开始出现。新客户会带来新的生产计划、数据条件、组织分工和现场约束；原来以为可以配置解决的问题，到了交付现场可能还是要找研发；原来被划给实施承担的工作，可能在多个项目里反复变成成本；原来以为只是个别客户才会出现的情况，后面才发现它其实是一类客户的共同问题。

这时候项目团队会不断把问题带回来：客户要求增加字段，现有流程走不通，能源管理系统的计算口径和客户现场不一致，某类数据采不到，某个项目又需要一套标准产品里没有的规则。产品经理如果只盯着“这个需求做不做”，很快就会被拉进两个极端。做，担心项目需求不断塞进产品，产品主线重新被打散；不做，又可能是在用“标准产品”保护原来并不准确的设计，最后让实施、研发和项目团队用人工流程、隐藏配置、临时代码替产品还债。

这篇文章要讨论的，不是普通意义上的需求回流，也不是多建几个评审表、需求池就能解决的问题。更贴近真实工作的是：项目带回来的问题先要还原成业务证据，再决定它由哪一层承接；如果确实要进产品，还要继续看当前项目怎么处理、产品什么时候接管、是否打乱既有规划；再往上，如果很多项目都在反复打穿原来的假设，就不能继续把问题当成单点功能修修补补，而要重新确认产品本身的目标和边界。

所以这篇的主线可以压成一句话：先看证据，再定去向；再定时间，再排规划；如果规划也解释不了，就重新检查产品本身。产品不能拒绝真实项目的修正，也不能让每一个项目重新定义产品。

一、产品V1.0之后，项目开始承担验证产品的作用

产品1.0形成时，团队一定会做出一组业务取舍：服务哪类客户，优先解决什么问题；哪些责任以后由产品长期承担，哪些差异通过配置承接；哪些能力进入1.0基线，哪些内容继续留在项目和实施层。没有这些取舍，产品就无法从原项目里独立出来。

但这些取舍并不会因为写进产品规划、需求文档和代码，就自动变成事实。产品V1.0更像是一份阶段性答案，它能不能站得住，仍然要在后面的真实项目里反复校准。

比如一套能源管理系统，在1.0里可能重点支持能源数据采集、费用测算、能耗分析和基础告警。团队当时认为，影响能耗基准变化的主要因素是能源价格、气候条件和设备运行效率，所以产品围绕这些因素设计了修正能力。这个设计在最早几个项目里也许够用。

等产品进入更多制造类客户后，情况就会复杂起来。有的企业生产计划变化很大，有的产线频繁切换，有的客户新增设备后没有同步调整采集点位，有的现场把原本外包的工序收回来，导致能耗结构发生变化。项目这时提出“基准要支持重新调整”，表面看是一个新增功能，实质上可能是在提醒产品团队：1.0对能耗基准变化原因的理解还不够完整。

要注意的是，项目中出现的差异，并不一定都意味着产品本身有问题，客户可能签订了特殊合同，现场实施也可能偏离了标准流程；有些看似缺失的能力，实际上产品已经具备，只是项目团队没有正确理解或使用。原因没有被分清之前，任何项目反馈都不能直接被翻译成一条产品需求。

但这并不意味着产品团队可以用“客户特殊”“实施不到位”解释掉所有问题。产品V1.0进入真实项目以后，原来在设计阶段做出的业务取舍、使用条件和能力边界，都会开始接受实际交付的检验。项目反馈首先提供的不是修改指令，而是一组新的证据：它可能证明产品原来的判断仍然成立，也可能暴露某些判断只在有限条件下成立，甚至已经不再成立。

从这个角度看，后续项目既不是来重新定义产品的，也不应该只是被动服从现有产品。它更像一次持续发生的验证过程，让产品团队逐渐看清：1.0中的哪些能力可以稳定复用，哪些差异仍然适合由配置和实施承接，哪些原本被认为是个别现象的问题，已经开始反复出现，需要重新审视产品原来的规划和基线。

而要让项目真正承担这种验证作用，仅靠解决方案阶段核对功能范围还不够，在项目进入交付前，产品线和项目线还需要进一步对齐当前产品基线：哪些能力可以标准交付，哪些差异由配置或实施承接，哪些已知缺口可能影响项目，哪些判断还需要在实际交付中继续验证。

这些内容对齐得越清楚，后续出现问题时，团队才越容易找到正确的参照。否则，当项目中出现偏差时，团队很难分清究竟是产品原有能力需要修正，还是客户场景本身超出了产品边界；是规划中的缺口被项目提前暴露，还是项目从一开始就没有按照既定条件使用产品。

二、先别急着接需求，要把项目问题还原成业务证据

项目现场不会很客气地把“产品哪里需要修正”整理好交割产品线。项目带回来的，往往已经是客户、销售或交付人员加工过的一套解决办法：增加一个按钮，开放一个配置项，支持一套新公式，增加一个审批节点，允许人工改结果。

这些说法都很具体，也很容易让产品团队产生错觉：问题已经清楚了，接下来只要评估成本、排期和优先级就行。但实际工作中，越是这种看起来明确的需求，越要先慢下来。因为它描述的是项目当前希望怎么解决，不一定描述了产品真正缺什么。

同样用能源管理系统基准能耗功能举例，项目团队提出“系统要支持客户直接修改年度基准”。如果直接接这句话，讨论很快会进入功能层：入口放哪儿，谁能改，改完要不要审批，能不能赶上验收。但对产品来说，真正重要的问题是：客户为什么要改基准？

如果是生产计划发生了长期变化，原来的基准确实不能代表新的正常用能水平，这可能说明产品缺少一类稳定修正因素。如果系统本来支持基准修正，只是实施人员不知道怎么配置，问题就不在产品能力，而在交付资产和培训。如果客户因为节能效果不理想，希望通过抬高基准改变收益结果，这就已经接近合同边界和证据规则，产品不能简单提供一个“想改就改”的口子。还有一种情况，当前项目合同条款确实特殊，问题真实存在，但它不应变成所有客户共同承担的标准能力。

同一个项目诉求，背后可能是四种完全不同的事情：产品能力缺失、已有能力没有交付好、合同责任没有说清楚、单个客户的特殊安排。如果这一层没有还原清楚，产品后面所有决策都会偏。

所以，项目问题进入产品视野时，第一步不是填进需求池，而是把它还原成一份业务证据。这个证据至少要回答四件事：

1. 它发生在什么业务条件下；
2. 现有产品为什么承接不了；
3. 项目现在靠什么方式绕过去；
4. 如果不处理，后续同类项目会不会反复付出成本。

这四件事并不复杂，但很容易被跳过。很多所谓“需求评审”之所以最后变成吵优先级，就是因为大家讨论的是客户提出来的功能名，而不是这个功能名背后证明出来的问题。销售说客户很重要，项目说验收很紧，产品说不够通用，研发说技术成本高。每个人都在讲自己的压力，却没有把问题还原到同一个业务对象上。

一个能用于产品演进的项目证据，不需要写得很复杂，但要能说明它挑战了产品原来的哪项业务取舍。原来认为很少出现的情况，是否正在成为目标客户的常见情况；原来划给项目承担的工作，是否已经反复要求产品和研发介入；原来认为足够灵活的配置，是否在真实交付中始终无法稳定使用；原来假设客户会有某个管理角色，现场是否根本没有这个人。

只有先把项目诉求转成业务证据，才能判断它是否进入产品，这一步不是为了显得产品经理更严谨，而是为了避免把现场第一次提出的解决办法直接固化成产品能力。产品要吸收的是项目证明出来的业务规律，不是项目当下喊出来的功能名字。

三、证据成立以后，先定承接层，不急着进产品主线

项目问题被还原清楚以后，很多团队会马上进入下一轮争论：这个需求到底算不算通用？通用就进产品，不通用就留项目。听起来很直接，实际却把一个复杂的责任判断，压缩成了简单的功能选择。

因为“进不进标准产品”不是唯一选项，一个项目问题有价值，并不代表它一定要变成产品主线功能；它不进入主线，也不代表产品团队就可以不管。在实际场景中，很多问题真正需要的是找到合适的承接层。

1.有些证据确实会动到产品主线：

比如能源管理系统原来只负责展示数据和做基础分析，把数据质量识别、异常采集、设备离线判断都留给实施人员。几个项目做下来后发现，数据缺失和采集异常会直接影响费用测算、能耗分析和节能量核算，实施每次都要人工排查，研发也不断被拉进去核对。这个时候，数据质量识别就不能再被看成项目实施的小事，它可能已经成为产品必须长期承担的基础责任。

2.有些证据不需要改产品主线，但需要形成标准配置：

不同客户的生产班次、结算周期、告警阈值、审批层级可能都有差异。只要这些差异有清晰边界，产品就没有必要为每个客户增加一套固定流程，而应该把差异抽成可控制、可测试、可交付的配置项。这样产品承认差异存在，但不会让差异无限扩大。

3.还有不少问题更适合进入交付资产：

比如每个项目都要重新整理设备台账、梳理采集点位、建立能源分项、配置计算参数。系统功能可能已经具备，但交付团队每次都重新摸索，导致周期长、错误多、成本高。这个问题继续做功能未必有效，真正要沉淀的是实施模板、初始化规则、检查清单和示例数据。

4.再往下，有些问题可以明确留在项目扩展：

某个客户有特殊合同、特殊组织流程，或者某阶段的临时管理要求，项目确实要处理，但公司不准备让所有后续客户共同承担这套逻辑。这里需要的不是假装它不存在，而是明确它的项目边界，避免它以“客户要求”的名义不断进入产品主线。

5.还有一类问题，本来就不该由产品承接：

客户希望系统通过改算法掩盖现场数据问题，或者希望产品承诺无法控制的经营结果，这类内容应回到合同、管理责任和业务边界里解决。产品如果为了配合项目随手开口子，短期可能过了验收，长期一定会带来更大的责任风险。

所以第二步真正要做的，不是“做”或“不做”，而是这件事以后由哪一层负责。是产品主线、标准配置、交付资产、项目扩展，还是合同边界。这个结论一旦清楚，后面的工作就会顺很多。

很多产品被项目带乱，不是因为项目反馈太多，而是因为每个反馈都被挤到同一个入口里讨论。所有问题都用产品功能承接，产品迟早膨胀；所有问题都推回项目，交付迟早失控。真正的产品演进，靠的是把不同性质的问题送到不同责任层。

产品主线从来不是所有有价值内容的收纳箱，一个项目证据真正提供的，也不只是“客户有这个需求”的证明，而是一次重新划分责任边界的机会：哪些问题以后由产品长期解决，哪些差异由配置承接，哪些经验需要沉淀成交付资产，哪些只属于当前项目，哪些从一开始就不应该落到产品身上。

四、当前交付要推进，但不能让临时方案变成永久产品

证据的承接层确定以后，当前项目的处理方式还要需要讨论，在解决方案阶段通常已经确认了交付范围，项目推进也必然以按期上线和验收为先。真正需要继续判断的，不是当前问题要不要处理，而是它应该在本次交付中直接完成产品修复，还是先由配置、项目扩展或人工方案托住，再由正式产品版本接管。

很多公司项目研发和产品研发本来就是同一拨人，难点也不只是资源冲突，而是当前交付节奏和正式能力形成的节奏并不一致。项目需要尽快让现场恢复推进，产品则要确认解决方式是否稳定、会不会影响其他客户，以及当前处理如何进入后续标准版本。

这时候常见的两种做法，一种是产品团队为了保护版本，所有问题都说等项目结束后复盘。这样看起来稳，实际上可能让当前项目靠大量人工补救和临时开发勉强过关。另一种是项目一着急，产品就立刻把现场方案做进系统。这样短期响应快，但很容易把一个还没有被看清的客户表达，变成所有项目都要背的产品逻辑。

更稳妥的做法，是把“当前项目必须解决”和“标准产品必须立即修改”分开看。

如果问题已经阻塞核心业务流程，导致计算结果明显错误，影响客户决策或验收，或者存在安全、合规、系统稳定性风险，那就不能简单等项目结束后再说。比如能源管理系统的费用分摊公式本身算错了，客户已经无法核对结果，这就是当前项目必须解决的问题。

但当前项目必须解决，并不代表一定要马上发布一个标准产品版本，还要看问题是否已经成熟。如果缺陷明确、影响范围清楚、解决方式稳定，就应该在当前周期内修复产品。相反，如果问题成立，但产品化方案还没想清楚，项目可以先用受控方案推进。这个方案可以是有限范围的配置、项目扩展、人工校验或者阶段性数据处理，但它必须被标注为临时方案，而不是悄悄混进产品主线。

临时方案最危险的地方，不是它临时，而是它后来没人管。项目一验收，大家看到系统能跑，就默认问题已经解决。下个项目再遇到类似场景，团队直接复制这段配置、这段代码、这套人工流程。久而久之，一套没有经过产品业务判断的项目方案，就变成了事实上的产品标准。

所以，只要当前项目采用临时方案，就必须说清楚几个问题：它只适用于哪个项目，谁负责维护，哪些内容不能复制给其他客户，产品正式方案由谁接管，什么时候重新评审，正式版本出来后如何清理或迁移。说白了，临时方案可以帮助项目过河，但不能让它在河里变成一座没人负责的桥。

还有一些问题暂时不影响核心交付，客户也处在刚开始使用系统的阶段，这个时候产品不必急着改。很多客户第一次提出的流程调整，其实是把过去的线下习惯搬到系统里；运行一段时间后，客户自己也会改变看法。更合理的做法是继续观察：它出现的频率如何，影响哪些角色，临时处理成本多高，使用稳定后客户是否仍然坚持这个诉求。

项目上线和验收前，产品线和项目线应该再做一次对齐，不是泛泛复盘问题，而是把前面所有临时处理逐项过一遍：哪些已经由产品正式修复，哪些只是项目绕过；哪些临时方案还在产生维护成本，产品什么时候接管；哪些问题确定留在项目层，哪些需要带入后续版本。在项目方案和产品方案之间，最终需要形成一次清楚的交接。

五、和产品规划冲突时，不要比谁急，要比两种代价

上一章解决的是当前项目如何继续推进，以及项目中的临时处理如何交给产品接管。走到这里，一个问题是否需要由产品长期承接，通常已经有了结论。接下来需要处理的，不再是“要不要进入产品”，而是它应该如何进入现有产品规划。

不同问题对规划的影响并不一样，有些只是对已有能力的修正，可以跟随正常版本完成；有些需要产品补充新的能力，要重新安排优先级和版本；还有一些项目证据会进一步证明，产品原来的业务假设、能力边界甚至建设顺序已经不再成立，原有规划也要随之调整。

因此，这里要判断的是，这项能力什么时候进入正式版本，以及它是否值得改变已有安排。产品已经决定承接，并不意味着必须立刻插入当前版本；但已有规划也不是不能动。如果真实项目已经证明原来的排序依据出现了问题，继续按原计划推进，反而可能让产品在错误的前提上越走越远。

这项能力究竟以什么方式进入规划，可以从三层判断。

1.首先要看，它有没有改变当前规划的前提：

产品规划之所以先做A后做B，通常是因为团队认为A更影响客户价值，或者A是后续能力的基础。如果几个项目都证明，真正卡住交付和客户使用的不是A，而是另一个被低估的问题，那么这份项目证据就不是普通插队需求，而是在提醒产品原来的优先级可能错了。

比如产品原本计划继续增加综合能源分析报表，因为团队认为客户最需要的是更丰富的展示和分析。但几个项目做下来发现，现场设备离线、采集点缺失、数据跳变太严重，导致报表再漂亮也没有可信度。这个时候，数据质量识别和异常处理就不再是一个“顺手补一下”的需求，而是在动摇原规划的前提。继续做更多报表，只会让产品在不可靠的数据基础上扩张。

2.其次要看，它能不能并入正在建设的能力：

有些需求看起来很急，实际上和产品当前建设方向并不冲突。比如项目证明能耗基准需要支持生产计划修正，而产品团队正在重构能耗核算模型。这个需求就不一定要单独插队，而应该并入模型重构一起设计。当前项目先受控承接，正式产品在已有规划中统一完成，反而比单独开一个临时功能更稳。

3.最后还要比较，是延后代价和调整规划代价谁更高：

如果不现在做，后续会不会有多个项目继续重复开发，实施是不是会持续靠人工补救，产品后续能力是不是还会建在错误假设上；如果现在做，原计划里什么内容必须延期，被挤掉的是核心基础能力，还是一个可以暂缓的优化项。

很多规划争论之所以没有结果，是因为只看到了新问题的价值，却没有把被推迟的内容摆出来。任何一个需求提前，本质上都是另一个事项延期。只有把这两个代价放在一起，优先级才不是拍脑袋。

经过这几层判断，项目问题最终会以不同方式进入产品规划，可能并入正在建设的能力，也可能进入后续版本；可能因为延后代价过高而提前进入近期版本，也可能因为项目证据已经推翻了原有规划的前提，促使团队重新调整路线图。还有一种情况，是产品已经确认承接，但依赖条件尚未成熟，当前仍由项目中的受控方案继续托住，等正式能力形成后再完成迁移。

六、如果旧规划解释不了新问题，就要重新看产品本身

前面几步解决的，基本都是在既有产品方向下怎么吸收项目修正。产品还是服务原来的目标客户，解决原来的核心问题，只是在能力、责任和版本顺序上做调整。

但实际工作里还会有更难的一类情况：不管怎么补功能、调版本，项目里暴露的问题还是解释不通。它不是某一项能力不完善，而是原来定义产品的依据本身可能已经变了。

这类变化有时来自项目证据的持续积累，比如公司最开始把能源管理系统当成一套可以独立销售的软件产品来做，规划重点放在功能完整度、配置能力和客户自助使用上。但多个项目交付下来发现，客户真正愿意付费的并不是一套软件，而是包含现场诊断、数据治理、节能改造、运行优化、收益核算和持续运营的一体化服务。系统仍然重要，但它只是服务闭环中的一部分，无法独立完成客户购买的价值。

这时候，如果产品团队还在围绕软件继续补报表、补配置、补流程，可能补得越多越累，却始终没有解决真正的问题。因为项目带回来的已经不是功能缺口，而是在挑战产品形态、责任边界和商业模式。

还有一种变化来自公司经营目标，公司原来希望产品独立销售，后来决定主要让产品支撑项目交付；原来面向大型客户，后来转向中小客户；原来追求市场覆盖，后来更重视利润和实施效率。产品名称可能没变，但它在公司内部承担的任务已经变了。

一旦公司目标变了，原来的需求评审标准也可能失效，过去值得长期投入的能力，在新的目标下可能只需要维护；过去被认为过于特殊的场景，可能因为目标客户变化，反而成为新的产品核心。这个时候继续拿旧路线图评估新问题，就会越评越乱。

真正需要做的，是重新说清楚产品现在服务谁，解决什么问题，哪些责任以后还由产品承担，哪些能力继续发展，哪些能力停止扩张，新一版产品基线从哪里开始。公司层面一句“产品要更贴近项目”“以后重点支持销售”“下一阶段减少定制”，都不能直接替代这些具体边界。

如果方向性语言没有转化成新基线，不同团队会各自解释，项目团队可能把“贴近项目”理解成项目需求全部优先，产品团队可能把“减少定制”理解成拒绝现场反馈，销售则可能认为重点客户可以重新定义产品。最后公司以为自己调整了方向，实际只是制造了新的信息差。

产品重新定义时，还要处理存量项目，公司可以改变产品方向，但不能假装已经签订的合同和过去作出的产品承诺不存在。旧项目可能仍要按原基线完成交付，旧能力可以只维护、不再扩展，新项目则从明确时间点开始执行新的产品边界。

这里最容易失控的地方，是新战略直接覆盖历史责任，或者旧项目无限期拖住新产品。前者会让正在交付的项目替公司战略变化买单，后者会让新产品永远走不出来。比较稳的方式，是把旧基线和新基线分开管理：哪些客户继续按旧基线维护，哪些能力只修缺陷不扩展，哪些新项目必须按新边界售前，哪些存量能力未来要迁移或退出。

这个章节其实非常重要，因为这类问题通常不会在某一个项目中集中爆发，而是在多个项目反复交付、不断付出额外成本之后，才逐渐显现出来。单独看每一次反馈，都可能只是一个功能缺口、一次特殊需求或者一项交付问题；当项目问题反复出现、怎么调版本都解释不通时，就不要继续在功能层死磕。这时真正需要检查的，是产品在公司里究竟承担什么任务。变化的到底只是某项能力，还是产品服务的客户、解决的问题和承担的责任已经发生了变化。这个问题如果没有分清，后面的能力取舍、版本规划和项目判断，就会继续建立在已经失效的依据上。

七、让项目证据进入闭环，而不是留在某个人脑子里

前面这些业务判断，听起来像全是产品经理的工作，但实际不可能靠产品经理一个人在需求评审会上完成。项目团队知道现场发生了什么，实施人员知道交付成本在哪里，研发知道临时兼容会带来多少复杂度，销售知道哪些能力正在影响签约，产品只是把这些信息放回产品主线里做取舍的人。

所以项目线和产品线不需要实时同步所有信息，但必须在关键节点形成结论。这里说的结论，不是“已沟通”“后续跟进”这种模糊记录，而是要明确问题是什么、当前项目怎么处理、未来由哪一层承接、产品什么时候接管。

项目启动时：先对齐产品基线，这个项目用的是哪一版产品，哪些能力可以直接交付，哪些差异由配置和实施承接，哪些内容不在产品责任范围内，哪些假设需要在项目中继续观察。这个动作如果省掉，后面很多争论都会变成各说各话。项目认为产品应该有，产品认为项目早该知道没有，实施夹在中间补救。

项目执行中：不是所有客户反馈都要进产品，操作咨询、单次数据异常、临时想法如果全部同步给产品，只会形成噪声。真正需要产品介入的，是那些已经影响核心流程、反复出现、明显增加交付成本，或者开始挑战产品基线的问题。这个节点要完成的，是前面三件事：把诉求还原成证据，确定承接层，决定当前项目怎么推进。

版本和迭代评审时：再把已经确认需要产品吸收的问题放入规划比较，这个时候不要继续争客户急不急，而要看它是否改变规划前提，是否能并入现有建设，延后代价和调整规划代价谁更高。只有这样，评审才不是各部门争资源，而是对产品演进节奏作出业务取舍。

上线、验收和复盘时，要专门清理临时方案。项目能验收，不等于产品问题已经消失，哪些问题已经被正式版本接管，哪些只是项目绕过，哪些临时方案还在产生维护成本，哪些证据已经在多个项目中形成规律，都要在这个阶段说清楚。否则项目一结束，问题也跟着人一起散了，下一次又从头来一遍。

这套闭环最重要的价值，是避免真实项目经验被消耗在单个交付里，很多团队并不是没有项目经验，而是经验没有进入产品。项目做完了，客户验收了，现场问题也解决了，但产品没有因此变得更清楚，交付没有因此变得更稳定，下一次项目仍然靠人重新补。

每一次正式对齐后，至少要留下几个结果：现场问题证明了什么，当前项目用什么方式处理，后续由产品主线、配置、交付资产还是项目层承接，产品是否需要在某个版本接管，在接管前由谁负责临时方案，什么时候重新检查。只要这些结果留得住，项目证据才真正进入了产品演进闭环。

结语：产品演进的结果，不是功能越来越多，而是业务判断越来越准

从项目中形成产品V1.0，是把一次性交付里的价值抽出来，变成可以重复交付的产品能力，产品进入后续项目以后，工作的重点变了。它不再是继续从功能里拼产品，而是让真实项目不断校准已经形成的产品。

项目会证明哪些场景被漏掉了，哪些责任边界划得过于理想，哪些配置只在文档里成立，哪些工作正在持续消耗实施、研发和维护成本。项目也会提醒公司，有些变化不是一个功能能解决的，而是产品形态、目标客户和经营任务已经开始变化。

如果产品拒绝这些真实修正，它会变成一套只在规划和文档里成立的标准产品。项目仍然会继续交付，现场问题也仍然会被解决，只是复杂度都被转移到了人工流程、项目扩展、临时代码和隐性维护里。

如果产品不加业务取舍地接受每一个项目诉求，它又会重新回到功能堆积。每个项目都可以增加自己的规则，每次交付都可以改变产品结构，产品最终只剩下越来越庞大的版本和越来越模糊的责任边界。

真正健康的产品演进，不是功能越来越多，而是在经历更多真实项目以后，产品对目标问题的理解越来越准确，长期承担的责任越来越清楚，不同项目差异的承接方式越来越稳定。