第 6 章 · 问题定义

引言#

其实在认知篇中我已经把产品经理最难的一件事说出来了：我们不是缺少做事能力，而是太容易在没有想清楚之前，就把事情做起来。需求来了，先排期；数据掉了，先优化；用户反馈多了，先加入口；业务说要提客单价，先做活动工具…每一个动作都很合理，也都很像产品经理应该做的事。可真实的项目失败，很多时候不是因为团队不会解决问题，而是因为团队太早拥有了解决方案。如果我们已经知道不能只做功能，那在具体工作里到底怎么做出更为合理的判断？认知只停在“我知道要判断”，其实没有太大用，真正考验产品经理的，是当业务很急、排期很紧、方案看起来也很合理的时候，你能不能把手从原型和排期上拿开，先把问题定义清楚。

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

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，于是在活动页翻商品。翻到的都是 9.9 元、12.8 元、15.9 元的低价品，先加一个垃圾袋，总价 148.9，不够；再加一包湿巾，总价 161.7，还是不够；再加一提抽纸，总价 177.6，仍然差一点。这个过程很碎，用户一直在找更便宜、更凑数的东西。最后有的人放弃，有的人继续加到 199，但整个过程已经不是“买需要的东西”，而是在“填金额”。没退货那批用户，路径不一样。购物车里同样有一件 139 元的主商品，发现差 60 元到 199，然后在活动页里翻到了自己上周搜过的牛奶，又找到了自己收藏过的坚果，两件加起来超过门槛，直接结算。这个过程不是在找最便宜，而是在找“本来就想要、现在顺手买也可以”的东西。

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

第三件事，验证意向

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

我把这个发现整理后，约运营团队和产品团队进行信息同步。原来的凑单专区，给用户推的是平台认为适合凑单的东西，垃圾袋、抽纸、湿巾。但数据告诉我们，用户真正不退的凑单商品，是他本来就想要的东西。这两类东西不是一回事。这个信息代表着问题定义发生了改变，原来的问题定义是“用户需要便宜凑单商品”，新的问题定义是“用户在购物车临近满减门槛时，不是缺少便宜商品，而是缺少一个低成本判断，哪些本来就想买的东西，正好可以帮他跨过门槛”。这个定义一变，方案就全变了：

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

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

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

如果讲到这里，那这只是案例复盘，我们这章最核心的希望将这样一种判断落成方法，但是任何方法都不是凭空长出来的，也不应该是纯理论刻板的，从这个案例中，我抽象出了一个相对稳定的问题定义方法：看见现象→暂停方案→还原任务→定义代价→锁定改变。

第一步：看见现象

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

第二步：暂停方案

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

第三步：还原任务

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

第四步：定义代价

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

第五步：锁定改变

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

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

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

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

只有动作，没有理由

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

方案证据全在自证

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

目标大，不落地

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

还有一个我越来越重视的事：方案前把退出条件讲清楚。很多项目一旦启动，就只剩“做完”和“延期”两种状态，很少有人在开始前说清楚：什么事实出现时，我们承认问题定义错了？满减案例里，如果意向商品凑单后退货率没有下降，就说明“意向”不是关键变量；如果用户根本不点击这些商品，说明展示位置或价格门槛判断错了；如果退货下降但客单没有变化，说明它解决了后悔问题，却不一定解决活动目标。不同信号对应不同修正方向，不能上线后只用一句“数据没达预期”把所有问题混在一起。

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

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

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

问题定义做完以后，方案经常会变小。当然这也不是绝对的，但在我经历过的案例里，这是一种高频出现的现象。很多人以为重新定义问题会让项目变得更复杂、更宏大、更像战略。实际正好相反，真正把问题定义清楚之后，产品动作通常会收缩到一个更精准的位置。满减凑单就是这样，原方案功能更多：低价商品池、购物车按钮、弹窗列表、运营配置、供应商维护。新方案反而更轻：购物车直接展示三件用户近期有意向且能跨过门槛的商品。它不是做得更大，而是做得更准，上线后的结果也比较干净。因为新方案没有按钮，信息直接展示在购物车里，曝光率接近100%；通过这个模块加购的商品，退货率比自然凑单低了将近60%；使用这个模块的用户，整单退货率比没用的人低了接近一半。用户加进去的是自己本来就想要的东西，收货后自然更少后悔。但我不想把这个项目写成一次”产品经理力挽狂澜”的胜利，毕竟真实情况没那么漂亮。新方案上线后数据确实有上升，但因为原方案没有真正落地、没有A/B对比，组织里仍然会有疑问：这是不是过度设计？如果当时就做低价凑单专区，会不会也能跑出不错的数据？我们是不是为了一个更精巧的判断，牺牲了一部分速度？这些疑问都合理，产品经理不能因为自己做出了一个正向结果，就反过来证明当初所有判断都是唯一正确的。满减项目里，我们能证明的是：意向商品凑单确实降低了退货率；我们不能证明的是：低价池一定失败，因为它没有被同条件验证过。

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

之前讲过的商学院案例也是同一种变化，当时团队原本准备升级商学院，因为小B晋升大B转化率低、转化时长长。学习路径、课程体系、成长任务都能解释”用户需要成长”，这个方案听起来很合理，但焦点小组之后，我们发现经销商当时最缺的不是更完整的学习体系，而是关键任务节点提醒和可直接使用的素材工具。问题定义一变，方案从大规模商学院改版，变成了成本更低、离任务更近的节点提醒和素材工具。它和满减凑单本质上是同一种变化：从“做一个看起来完整的系统”，退回到“用户在某个关键场景里到底卡在哪里”。所以问题定义不是刻意把产品做小，而是让产品站对位置。站错位置时，功能越完整，浪费越大；站对位置后，一个很小的动作，也可能改变关键结果。

闲言碎语#

产品经理做到后面，很容易被期待快速给答案。业务问你能不能做，技术问你范围多大，老板问你什么时候上线，运营问你大促前赶不赶得上。你如果说“我还想再确认一下问题”，会议室里有时会出现一种微妙的停顿。这个停顿很难受，因为它让你看起来不够果断。我以前很怕这个停顿，怕别人觉得我不专业，怕团队觉得我拖节奏，怕业务觉得产品又在讲道理。于是很多时候，我会用更快的方案来填掉这个停顿。后来吃过几次亏，才发现真正该怕的不是停顿，而是所有人都觉得顺的时候，没有人再问一句“我们是不是定义错了问题”。

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