引言#

工作中最容易出错的一步，往往不是执行，而是把问题定义错了。需求来了，先排期；数据掉了，先优化；用户反馈多了，先加入口；业务说要提客单价，先做活动工具……每一个动作都很合理，也都很像产品经理应该做的事。可真实的项目失败，很少是因为团队不会解决问题，更多是因为团队太早拥有了解决方案。

我们不是缺少做事能力，而是太容易在没有想清楚之前，就把事情做起来。那么回到具体工作里，到底该怎么做出更可靠的判断？认知只停在「我知道要判断」，其实没有太大用。难的地方在于，当业务很急、排期很紧、方案看起来也很合理的时候，你能不能把手从原型和排期上拿开，先把问题定义清楚。

用户表达、业务方案和数据异常都只是输入，当这些输入已经被团队翻译成一个项目时，产品经理如何判断这个项目的起点是否成立？这里有一个很容易被低估的动作，叫「暂停」。它不是拖延，也不是犹豫不决，目的更不是证明自己比别人更聪明，而是想在所有人准备开工之前，先问一句：我们现在要解决的问题，真的已经被定义清楚了吗？这句话如果问早了，可能会让项目少走很多弯路；如果问晚了，它就会变成复盘时的一声叹气。

6.1 暂停方案——先看原方案解释不了什么#

我有一次做大促营销产品时，差点把一个「看似很合理」的方案推进开发。那时我们刚完成一场大促活动，事后运营团队在复盘会上展示了一组让所有人都不太舒服的数据：主活动用的是满减营销工具，政策是「满 199 减 30、满 299 减 50」，虽然大促期间 GMV 同比上涨了，但客单价相对日常仅上升 11%¹。按常理说活动规则并不复杂，满减门槛就摆在那里，用户只要稍微多买一点，客单价应该可以被明显拉起来，但实际情况和预期差了一大截。还有一个数据更刺眼，大促期间的订单在 7 天内退货率持续上升，近 40% 的退货理由集中在「不想要了」「买多了」「买重复了」这类原因中。这些退货商品里有 70% 集中在 1～20 元价格带，比如垃圾袋、厨房湿巾、保鲜膜、袜子、抽纸这类低价品，看起来就是用户后悔了，但不像商品质量问题¹。

运营团队的第一反应很自然：用户不太会用满减，我们得帮用户凑。思路很快就定了下来，做一个「凑单专区」：用户购物车差几十块到满减门槛时，购物车底部放一个「找凑单商品」的按钮，点击后弹出商品列表，里面全是平台筛选好的低价凑单商品，9.9 元的垃圾袋、12.8 元的湿巾、15.9 元的抽纸、18.9 元的保鲜盒，用户只需点一下就直接加购。这个方案从业务上看逻辑简单直接，满减门槛明确、低价商品充足、运营资源可控、开发路径也清晰。品类和活动运营同学整体支持，因为低价商品池可以提前准备，供应商也能配合；运营负责人、活动运营更在意排期，因为平台除了年度几场大促，基本每个月还有不同级别的活动，窗口期一直很紧。大促项目最怕的不是没有想法，而是方案迟迟定不下来，影响下一个活动节奏。在这些压力下，这个方案很快就得到产品团队的评审交付，大家觉得这个功能早该做了：用户凑单不就是缺便宜东西吗？我们给他便宜东西，不就解决了吗？

我当时的直觉是，这个方案回应了「客单价没有拉起来」的问题，但它解释不了另一个更刺眼的现象：为什么 40% 的退货理由集中在「不想要了」「买多了」「买重复了」。如果用户真的是「找不到便宜商品凑单」，那更合理的结果应该是不下单或者下单后不退货。可现在的情况是，用户下单了，也退货了，而且退货集中在低价凑单商品上。这只能说明一件事：用户在支付那一刻觉得划算，收到货以后改变了想法。这个改变很关键，它让原来的解释开始站不住了：用户不是没有完成凑单动作，他完成了；用户不是完全不知道便宜商品在哪里，他加了；问题不在于他有没有东西可买，而在于他加进去的东西，在收货之后不再被他认为值得。

于是我把这个判断摆到运营团队面前，建议先暂缓研发投入，给我一点时间把原因再拆一轮。运营负责人并不太高兴，但最后还是同意先给出一段分析时间，同时也把条件说得很清楚：如果没有找到更有说服力的原因，就必须按原计划尽快推进凑单专区上线。

暂停一个已经顺利通过评审的方案，比在会议上提出一个新方案难得多。因为你不是在一片混乱里建立秩序，而是在一个已经形成秩序的地方制造停顿。支持这个方案的人不是没有道理，运营同学也不是不懂用户。恰恰相反，他们的判断来自一线活动经验：用户确实会因为差几十块满减而犹豫，低价商品也能帮助跨过门槛。所以问题不在于原方案荒唐，而在于原方案解释不了全部关键现象。

客单价提升有限，支持「需要凑单工具」这个方向；低价商品退货高，则挑战了「用户需要便宜商品」这个解释。如果只看前一个信号，凑单专区很合理；如果把后一个信号放进来，问题就变复杂了。用户凑了单，但凑完以后后悔，产品要解决的，也许不是「帮他更快找到低价商品」，而是「帮他更低成本地判断这件东西加进去后还值不值」。这两件事差别非常大，前者会让你做低价商品池，后者会让你重新定义推荐逻辑。

6.2 拆解问题——从差异里找到关键变量#

带着这个疑问和可能性，我并没有直接将这个猜测落地为新方案，而是转头干了三件事：拉数据、拆路径、验证意向。

拉数据：先看行为，不先看结论

我把上次大促所有「购物车总价在 120～189 之间」的用户路径调出来看，这批人占比超过 30%¹，他们离 199 门槛不远，正是最容易被凑单影响的人群。用户行为大致分成两类：一类人放弃凑单，直接结算；另一类人成功凑到 199，但加进去的商品高度集中在 9.9 元的垃圾袋、12.8 元的湿巾、15.9 元的抽纸。第二类人的退货方式出现了一个高频的现象：整单全退，凑单商品和主商品一起退，退款时间集中在签收当天。这说明用户不是过了几天发现质量不好，也不是用了一段时间不满意，而是在拆开快递那一刻就觉得这单不对。

但还有一小部分用户的行为不一样：他们也凑单了，也跨过了满减门槛，退货率却明显更低。我把这批「凑单成功但没退货」的用户路径单独拉出来看，发现他们加购的凑单商品不是 9.9 元的垃圾袋，而是 39.9 元的牛奶、49.9 元的洗衣液、55.9 元的坚果。价格更高，但退货率更低，这已经是一个很强的信号：低价不是关键变量，意向才可能是关键变量。

拆路径：把两批人并排看

我把两类用户的完整行为路径并排放在一张表里看。退货那批用户的动作是一路试出来的：购物车里一双 139 元的鞋，差 60 元到 199，他先加一个垃圾袋，总价 148.9，不够；再加一包湿巾，161.7，还是不够；再加一提抽纸，177.6，仍然差一点。这个过程很碎，他一直在找更便宜的、更能填平门槛的东西，动作已经不是「买需要的东西」，而是在「填金额」。没退货那批用户则几乎一步到位，翻到的是自己搜过、收藏过的商品，两件加起来超过门槛，直接结算。

表 6-1　两类用户的凑单路径对照

第一类用户在找便宜的，第二类用户在找自己需要的，这句话看起来简单，但它把问题拆开了。用户加低价商品，不代表用户需要低价商品，那可能只是他在没有更好选择时，临时做出的凑数动作。这个动作在支付页成立，在收货时不成立，因为支付页上用户看到的是「我省了 30 元」，收货时看到的是「我多买了一堆没用的东西」。

验证意向：回历史记录里找证据

我调了所有凑单用户的浏览历史，把「凑单成功但退货」和「凑单成功没退货」两组人做了对比。退货组里，凑单加购的商品在他们过去 30 天的浏览记录里出现次数趋近于 0，他们之前没有看过这些商品，就是临时翻到、临时加的；没退货那组人，凑单加购的商品在他们过去 30 天的浏览记录里平均出现过 2.3 次，他们之前看过、收藏过，或者加购过，本来就对这些商品有意向¹。这个差异非常干净，用户退货不是因为凑单这件事本身有问题，而是因为凑进去的东西不是他本来想要的。如果凑进去的东西本来就在他的意向里，凑单就不再像被活动逼着多买，而像把本来要买的东西提前一起买了。

我把这个发现整理同步给了运营团队和产品团队：原来的凑单专区，给用户推的是平台认为适合凑单的东西，但数据告诉我们，用户没有退的凑单商品，是他本来就想要的东西。这两类东西不是一回事，这意味着问题定义变了。原来的问题定义是「用户需要便宜凑单商品」，新的问题定义是「用户在购物车临近满减门槛时，不是缺少便宜商品，而是缺少一个低成本判断：哪些本来就想买的东西，正好可以帮他跨过门槛」。这个定义一变，方案就全变了：

• 原方案：运营手动维护一个低价商品池，用户在购物车点击「找凑单商品」，弹窗展示这个池子里的商品。
• 新方案：没有手动池子，也没有弹窗。系统自动抓取用户近 30 天的浏览记录、收藏记录、加购记录，筛选出「用户有过意向且价格刚好能帮用户跨过满减门槛」的商品，再按意向强度排序展示。用户在购物车看到的，不是一堆平台准备好的低价凑单品，而是「你昨天看过的牛奶」「你收藏的那箱坚果」「你加购过的洗衣液」。交互也变得更轻，购物车页面底部显示「还差 XX 元可减 XX 元」，下面直接展示三件「你最近看过」的商品，标明价格和满减后实付。没有「帮我凑」的按钮，没有弹窗，也没有让用户再进入一个低价池慢慢翻，用户如果看到自己本来就想买的东西正好能凑单，点一下就加进去了。

这个项目最让我印象深的，不是后来方案跑出了数据，而是问题定义改变了方案形态。只要问题仍然是「用户找不到便宜商品」，产品就会自然走向低价池、弹窗、按钮、运营配置；一旦问题变成「用户缺少判断加购商品是否值得的依据」，产品就会自然走向意向商品、历史行为、价格门槛和低干扰展示。所以方案不是问题，方案只是团队对问题的一种猜测，猜测有可能对，也有可能只是解释了最容易看到的那一层。产品经理最容易犯的错误，是把「用户行为」直接翻译成「用户需求」，用户凑单的时候加了一堆便宜的东西，我们就觉得「用户需要便宜的东西」，但用户那么做，只是因为他没找到更好的选择。

6.3 抽离方法——问题定义五步法#

如果只停在案例本身，那还不够，需要沉淀一套可复用的问题定义动作：看见现象、暂停方案、还原任务、定义代价、锁定改变。

图 6-1　问题定义五步法　五个动作从左到右依次推进，每一步都把上一步的结论变成下一步的输入。

看见现象：先把异常凑齐

现象不是问题，但问题通常从现象里冒出来。大促 GMV 增长、客单价只提升 11%、低价凑单商品退货高，这些都只是现象。产品经理第一步要做的，不是急着解释，而是把现象看完整。很多团队会在第一个现象出现时就动手，比如看到客单价没上来，就判断「用户凑单能力不够」；看到页面转化低，就判断「页面引导不清」；看到内部工具没人用，就判断「入口不明显」，这些解释不一定错，但它们太早了。看见现象的关键，是把同一问题周围的异常放在一起。客单价低是一类异常，退货集中是另一类异常，退款理由是第三类异常，商品价格分布是第四类异常。只有它们一起出现，「用户后悔」这个方向才会浮出来。

暂停方案：先问它解释不了什么

暂停不是否定方案，而是问原方案能不能解释关键现象。凑单专区能解释「用户差一点到门槛」，也能解释「用户需要更方便地找商品」，但它解释不了「为什么用户已经买了低价商品又在签收当天退货」。一个方案如果只能解释支持自己的那部分数据，却解释不了反常识的那部分数据，就不能直接进入开发。暂停方案其实是非常需要勇气的，因为它会触碰排期、资源和人情。方案是运营同学提的，品类同学支持，供应商也准备配合，老板也觉得早该做，这时候你说「先停一停」，很容易被理解成产品在挑刺。但产品经理如果永远不在这种时候暂停，问题定义就永远只是文档里的流程，不会影响项目。

还原任务：把行为拆回意图

还原任务是把「用户做了什么」拆回「用户想完成什么」。用户加了低价商品，这是行为；用户想跨过满减门槛并且不后悔，这才是任务。很多错误的问题定义，都是把行为直接当成任务：用户点了推荐，不代表他需要推荐；用户搜索低价，不代表他只在乎低价；用户反复打开看板，不代表他想在看板里待更久；用户不用定时群发，不代表他不会设置时间。还原任务时，可以尝试问几个很笨但很有效的问题：用户当时为什么来到这里？他离开这里后还要做什么？他不使用我们方案时怎么解决？他现在的绕路方式说明了什么？这些问题不适合写成华丽的模型，却能把产品经理从方案里拽出来，重新看用户到底在完成什么事。

定义代价：代价决定该降什么

定义代价是把「用户有问题」这句话翻译成产品可以回应的事情。用户付出的代价不是「找商品麻烦」，而是判断成本、后悔成本和整单退货成本；他在活动页翻十几分钟，是在判断这个东西加进去值不值，而不是在享受购物；他签收当天退货，退掉的也不只是一包垃圾袋，还有整个订单的价值感。定义代价很重要，因为代价决定产品该降什么。如果代价是时间，就减少路径；如果代价是等待，就减少等待；如果代价是解释，就补口径；如果代价是担责，就补确认、撤回和留痕；如果代价是后悔，就补判断依据。你把代价定义错了，方案就会降错成本。

锁定改变：只改一个最小结果

问题定义的最后，不是写一句漂亮的问题描述，而是明确产品要改变哪个最小结果。我们要改变的不是「用户更会凑单」，这个太大，也太虚。真正要改变的是：当用户离满减门槛还差一段距离时，更快看到自己本来就有意向且能帮助跨过门槛的商品，减少临时加购低价无意向商品带来的退货。这句话虽然不够好看，但它能指导产品动作。它告诉我们不要做低价池，而要做意向商品筛选；不要把入口藏在按钮里，而要在购物车直接展示；不要让用户在弹窗里继续翻，而要给出最少但更准的候选；不要只看加购率，还要看模块加购商品退货率和订单整体的退货率。

把这五步放回满减案例里，每一步的判断都可以被反证，下表第三列给的是反证信号：那一列的现象一旦出现，这一行的判断就不成立。

表 6-2　五步法的判断与反证信号

在项目进入方案之前，可以先把这套动作压成三个问题：

• 原方案解释不了哪个关键现象？如果它只能解释支持自己的那部分数据，解释不了反常识的那部分数据，就还不能进入开发。
• 用户要完成的任务是什么，我用什么事实支撑它？行为不等于任务，用户加了低价商品，不代表他需要低价商品。
• 如果出现什么事实，说明我们定义错了问题？说不清楚这一点，问题定义就只是把原方案换了一种说法。

这套方法不复杂，也不应该复杂，问题定义不是为了写出更厚的文档，它想让项目早期的几个关键判断不要被跳过去。我在带团队时，不害怕产品同学不会写方案，而是方案写得太顺。背景写得很顺，目标写得很顺，用户诉求写得很顺，方案也很顺。顺到最后，你会发现里面没有冲突，也没有反证信号。好的问题定义，应该允许自己被推翻。满减案例里，如果意向商品凑单后退货率仍然很高，说明问题可能不在商品选择，而在活动门槛、价格感知或用户整体消费压力；如果用户看到意向商品也不加购，说明展示位置或价格门槛还要重新看。问题定义不是让产品经理显得更确定，而是让不确定变得可验证。

6.4 固化机制——让问题定义留在评审与复盘里#

如果一个项目能被定义清楚，只是因为某个产品经理临时警觉，那这件事很危险。因为下一次这个人不在或者他被排期压住，项目还是会沿着最顺的方案往前走。所以问题定义不能只靠一个聪明人，它要变成一种工作机制。产品经理不能每次都靠「我觉得这里不对」来暂停项目，一个团队如果只听个人直觉，最后会比谁更有经验、谁更强势、谁更接近老板。稳定的机制，应该让每个重要项目在进入方案之前，都必须把问题说清楚。我在带团队做需求内审时，会特别留意几种情况：

只有动作，没有理由：没回到具体场景

在 PRD 或内审讲解中，只讲了要做什么，没说清楚为什么做。比如「新增购物车凑单专区」「优化数据分析看板」「升级商学院」「新增定时群发快捷入口」，这些都是建设内容，它们不是不能做，而是没有回到具体场景：哪个角色，在什么场景下，因为缺少什么信息、能力、判断或控制，导致什么任务无法完成，并付出了什么代价。这句话不一定一次写对，但它会逼团队把讨论从「做什么」拉回「为什么做」，如果理由写不出来，说明团队现在掌握的材料还不足以支撑方案。

方案证据全在自证：没人问解释不通的部分

方案里全是支持自己的证据，用户说想要，业务说着急，数据里也能挑出一个往下降的指标，竞品似乎也这么做。材料越顺，我越会让产品同学补一个问题：有没有哪个事实解释不通？这几个案例，前面几章讲过两个，解释不通各不相同。满减案例里的解释不通，是「如果用户只是找不到便宜商品，为什么会下单后退货」；确认订单页加价购里的解释不通，是「如果用户只是想买更多东西，为什么他们在确认订单页只停几秒、反复返回购物车，而不是主动逛推荐」；CMS 的数据看板里的解释不通，是「如果运营需要一块更完整的看板，为什么他们看完一个数又立刻把它搬到 Excel 和飞书里」。这个追问不舒服，但很有用，它能把团队从寻找支持材料里拉出来，去看原方案最薄的地方。

目标大，不落地：大到无法指导方案

目标写得太大和方案本身强行关联，提升客单价、提高转化率、改善用户体验、降低运营成本……这些目标都对，但太大，无法指导方案。能指导方案的，是更小的改变：让用户少做一次判断，少等半天数据，少解释一次口径，少承担一次发错内容的风险，少在签收后产生后悔。最小改变目标越清楚，方案越容易变小，也越容易验证。

还有一件事必须落在流程里：方案前把退出条件讲清楚。很多项目一旦启动，就只剩「做完」和「延期」两种状态，很少有人在开始前说清楚：什么事实出现时，我们承认问题定义错了？问题定义五步法里每一步列出的反证信号，就是退出条件该有的样子：它回答的是判断错了会看到什么，而不是判断错了会有什么感受。满减案例里，如果意向商品凑单后退货率没有下降，就说明「意向」不是关键变量；如果用户几乎不点这些商品，说明展示位置或价格门槛判断错了；如果退货下降但客单没有变化，说明它解决了后悔问题，却不一定解决活动目标。不同信号指向不同的修正方向，不能上线后只用一句「数据没达预期」把几个问题混在一起。

评审之外，复盘也要固定下来：我们当初定义的问题是否还成立？用户行为是否证明了我们的代价判断？有没有新的反常识信号？如果数据没达到预期，是方案形态错了，还是从一开始问题就定义错了？这一步如果不做，团队就很难积累判断能力，每次项目都像一次孤立战斗，赢了归功于方案，输了归因于执行。需要做的是在复盘里把问题定义是否正确这件事单独拿出来讨论：如果问题定义成立，方案效果不好，就继续优化方案；如果问题定义不成立，继续优化方案就是消耗资源。很多团队复盘时跳过这一步，功能不好就优化功能，数据不好就加入口，看起来很勤奋，但不一定有用。因为你不知道自己是在修一个正确问题上的错误方案，还是在给一个错误问题继续加码。

但这里还有一件更现实的事：产品经理不能把「暂停」说成一句冷冰冰的否定。很多产品同学在评审会上其实有判断，但表达方式太像反对。「这个需求不成立」「我们要先定义问题」……这些话可能都对，但在组织现场听起来像不配合。更好的表达，是先承认原方案为什么合理，再指出它解释不了什么，比如满减案例里，我不能一上来就说「低价凑单专区不对」，更合适的说法是：「这个方案能解决用户找低价商品的问题，也能赶上大促节奏，所以我理解为什么它会被优先考虑。但现在有一个数据解释不通：如果用户只是找不到便宜商品，为什么他们已经下单后又在签收当天退货？我想花点时间确认一下，退货和购买意向之间有没有关系。如果没有关系，我们继续按原方案推进；如果有关系，推荐逻辑要改，否则可能会把退货问题放大。」这段话的重点，不是语气更委婉，而是把暂停变成了一个可验证的判断动作：明确指出当前方案能解释什么、解释不了什么、我们要验证什么、验证结果分别对应什么动作。越到后面，这种表达越重要，它要的不是圆滑，是让判断在组织里站得住。

一个判断如果只让别人听见一个不字，它就很难进入讨论；一个判断如果能说清「为什么先不这样做，以及我们用什么事实决定下一步」，它才有机会变成团队共同的选择。问题定义不只发生在立项前。立项前，它帮助团队别太早进入方案；上线后，它帮助团队判断下一步该继续调方案，还是该承认一开始就定义错了。前者决定项目怎么开始，后者决定项目怎么退出或修正。

6.5 收敛方案——让产品动作变小但更准#

问题定义做完以后，方案经常会变小，在我经历过的案例里，这是一种高频出现的现象。很多人以为重新定义问题会让项目变得更复杂、更宏大、更像战略，实际正好相反，把问题定义清楚之后，产品动作通常会收缩到一个更精准的位置。

满减凑单就是这样，原方案功能更多：低价商品池、购物车按钮、弹窗列表、运营配置、供应商维护。新方案反而更轻：购物车直接展示三件用户近期有意向且能跨过门槛的商品。它不是做得更大，而是做得更准，上线后的结果也比较干净。因为新方案没有按钮，信息直接展示在购物车里，曝光率接近 100%；通过这个模块加购的商品，退货率比自然凑单低了将近 60%；使用这个模块的用户，整单退货率比没用的人低了接近一半¹。用户加进去的是自己本来就想要的东西，收货后自然更少后悔。

但我不想把这个项目写成一次产品经理力挽狂澜的胜利，毕竟真实情况没那么漂亮。新方案上线后数据有上升，但因为原方案没有落地、没有 A/B 对比，组织里仍然会有疑问：这是不是过度设计？如果当时就做低价凑单专区，会不会也能跑出不错的数据？我们是不是为了一个更精巧的判断，牺牲了一部分速度？这些疑问都合理，谁都不能因为做出了一个正向结果，就反过来证明当初所有判断都是唯一正确的。满减项目里，我们能证明的是：意向商品凑单降低了退货率；我们不能证明的是：低价池一定失败，因为它没有被同条件验证过。

在有限信息下选一个更有证据支撑、后果更可控的方向，比证明自己永远对更重要。问题定义的价值不在于让质疑消失，而在于你可以说清楚为什么暂停原方案，为什么调整问题定义，为什么选择新方案，也可以说清楚如果数据不成立，下一步退回哪里。这种说得清楚的能力，在组织沟通中尤其重要，很多时候，组织不是不愿意听判断，而是不愿意听一个没有证据的否定。你直接说「低价凑单专区不该做」，对方听到的是产品在反对业务；你说「低价池能解决找商品问题，但解释不了签收当天退货和历史意向差异，所以我建议先把问题改成降低用户判断成本」，对方听到的才是判断。前者是结论，后者是问题定义。

之前讲过的商学院案例也是同理，问题定义一变，方案从大规模商学院改版，变成了成本更低、离任务更近的节点提醒和素材工具。它和满减凑单本质上是同一种变化：从「做一个看起来完整的系统」退回到「用户在某个关键场景里到底卡在哪里」。所以问题定义不是刻意把产品做小，而是让产品站对位置。站错位置时，功能越完整，浪费越大；站对位置后，一个很小的动作，也可能改变关键结果。

闲言碎语#

试着想象一下，你说「问题可能还没定义清楚」，当场没有人反驳，但也没有人把这句话接下去，那一刻你能感觉到，桌上每个人都在等你给一个干脆的答复。这半分钟的停顿很难受，因为它会让你在别人眼里显得不够果断。我曾经很怕这种停顿，怕别人觉得我不专业，怕团队觉得我拖节奏，于是有一段时间，我会用更快的方案把它填掉：先把排期应下来，先把入口加上去，先把进度推起来，直到方案做完、数据也体现了，团队才发现我们解决的并不是原来那个问题。所以真正该怕的是另一种场面：一切都很顺，没有人再问一句「我们是不是定义错了问题」。

承认问题没定义清楚，不是一件体面的事。它意味着你要承认自己现在还不知道，承认前面的方案可能要推翻，承认团队已经投入的一部分讨论可能要作废。对于一个资深产品经理来说，最难的不是不会给答案，而是明明给得出答案，却知道自己不该这么快给。我现在反而很珍惜那种不舒服的停顿，因为它至少说明，有人愿意把项目从「怎么做」里拽出来，重新看一眼它当初的出发点。不是每一次停顿都会带来更好的方案，也不是每一次重新定义问题都能跑出漂亮数据，但它会让团队少一点惯性，多一点诚实。真正的成熟，是在方案已经很顺的时候，还能多问一句：这个问题，真的被定义清楚了吗？这句话问出口，可能会让会议慢十分钟，但有时候，它能替团队省掉三个月。