2024 年 3 月，我把一份 147 条的问题清单，逐条扔进关键词工具里跑了一遍。
这份清单是团队花六周攒出来的，来源包括 2,300 多条客服工单、14 个卖家社群、37 场用户访谈，以及销售在成单前记录的反对意见。内部投票排第一的是"批量修改 Listing 价格"，得票率 68%。
但关键词数据给出了相反的答案。那组概念在 6 个代表关键词上的月搜索量合计只有 210 次，12 个月趋势斜率是负的；而排在内部第 19 位、得票只有 11% 的"FBA 库存绩效指标怎么看"，相关词月搜索量合计超过 4,800 次，且在每年 Q3 有明确的上行拐点。
这次打脸让我意识到一件事：问题清单记录的是"谁在什么时候说了什么"，关键词工具记录的是"有多少人在主动找解法"。两者中间隔着一道很宽的缝，而大多数团队从来没有认真量过这道缝有多宽。
下面是我在这个项目里的完整复盘，怎么用关键词工具验证问题清单，哪些判断是错的，哪些指标值得信，以及在什么情况下应该直接放弃验证、凭常识做决定。
先说明数据来源：文中所有数值来自我参与的一个亚马逊卖家运营工具项目的内部复盘，涉及商业信息的部分做了脱敏；关键词搜索量为工具内查询结果的量级区间，不是精确值。样本不代表全行业，只代表"面向亚马逊卖家的软件或内容产品"这一类决策场景。
如果你只想从这篇文章里拿走一句话，那就是：问题清单是假设库，不是需求库。它回答"用户抱怨了什么"，不回答"有多少人愿意为解决它付出代价"。
我们最大的认知转变，不是学会了某个工具的操作，而是把关键词工具的使用目的从"找流量词"改成了"给问题定价"。这个转变之后，同样的数据、同样的软件，得出的决策结论完全不同。
判断一：搜索量不能直接当需求强度用。把搜索量按大小排序，然后决定先做哪个问题，这是最常见的错误。我们做过一次对照：直接按搜索量排序的 TOP 10，和经过意图分类、供给成本折算后的 TOP 10，重合度只有 4 条。也就是说，裸排序的误判率大约在 60%。
判断二：一个需求要被"翻译"成 5 到 8 个关键词，才算验证过一次。用单个词代表一整类问题，是数据失真最大的来源。比如"库存"这一个词什么也说明不了，但"FBA 库存绩效指标怎么看""亚马逊长期仓储费怎么算""补货公式"这三个词，指向的是三种完全不同的用户状态。
判断三：验证的目的不是筛掉问题，而是给问题标一个"成本价签"。知道一个问题值多少钱，比知道它值不值得做更重要。因为大部分问题不是"做不做"的问题，而是"用功能做、用内容做、还是用文档做"的问题。
判断四：一次验证的有效期大约是 2 个季度。亚马逊的算法、费用结构、政策口径变化频率很高。我们 2023 年 Q4 跑出来的关键词库，到 2024 年 Q2 复用时有约 18% 的词已经不再代表原来的问题。
从原始素材到最终进入路线图，我们一共经历了五道收敛。每一道的淘汰率都不一样，其中淘汰最狠的不是"没需求"，而是"需求存在但我们做不起"。
有些搜索量很高的词，恰恰说明这个问题不值得做。
典型的例子是"亚马逊 账号 被封"。这个词组搜索量巨大且季节稳定，但我们的判断是：它的搜索量高，是因为问题无法被软件解决，所以用户只能反复搜索。搜索行为在这里是"绝望的重复"，不是"可被满足的需求"。
这类词在我们的打分模型里被单独标记为"高搜索量，零可解决度"，直接进入放弃列表。我们在 89 条通过的条目里，识别出 7 条属于这一类，如果只看搜索量排序，这 7 条会稳稳排在前面。
不交代清楚问题的来源，后面的验证方法就没有说服力。因为清单的偏差，一大半是在收集阶段就埋下的，关键词工具只是把偏差暴露出来而已。
项目是一个面向亚马逊卖家的运营辅助工具模块，覆盖选品辅助、库存预警、广告关键词整理三块。用户画像很集中：年销售额在 30 万到 800 万美元之间的中小卖家，团队规模 1 到 8 人，绝大多数没有专职数据分析岗。
这类用户有个鲜明特点：他们的痛点非常真实，但他们描述痛点用的词，和我们做产品的人用的词，通常不是一套。这个错位是后面一切麻烦的起点。
我们当时用的是"多源汇总、内部投票"的方法。看起来挺严谨，实际上每个来源都带着系统性的偏差，而汇总之后偏差并没有互相抵消，反而互相放大。
| 来源 | 条数 | 占比 | 主要偏差类型 | 偏差方向 |
|---|---|---|---|---|
| 客服工单 | 96 | 30.8% | 被已购用户筛选过 | 偏向产品已有功能的细枝末节 |
| 卖家社群 | 78 | 25.0% | 发言者偏差，活跃者才发言 | 偏向情绪化、争议性话题 |
| 用户访谈 | 54 | 17.3% | 主持人引导 + 社会赞许效应 | 偏向听起来合理但用户不会真做的事 |
| 销售侧反馈 | 47 | 15.1% | 为成单服务，天然偏向"能承诺的功能" | 偏向竞品已经有的功能 |
| 竞品评论区 | 37 | 11.8% | 只有不满者会写评论 | 偏向失败体验和极端场景 |
把这张表摊开来看，问题就很清楚了。五个来源里，没有一个是直接来自"用户主动搜索行为"的。也就是说，我们收集的是"被动表达出来的问题"，验证的是"主动寻找解法的需求"，两者之间存在结构性错位。
我们用"提及频次 × 情绪强度 × 内部投票"做了一个加权排序，前 10 名里，有 6 条最终连关键词验证的第一关都没过。
最典型的失效模式是这样：一个问题在工单里被反复提及，情绪也很强烈，于是得高分。但深入看会发现，反复提及的原因是我们的产品在这块做得差，而不是用户认为这块重要。
换句话说，一个体验糟糕的快功能，会因为制造了大量工单而把自己排到需求列表最前面。这是一种"用错误证明正确"的循环。关键词工具的价值，恰恰是从外部切断这个循环，它看的是用户在你产品之外的行为，不受你的产品体验干扰。
2024 年 1 月，我们上线了那个内部投票第一名、得票 68% 的"批量改价"功能。上线 90 天后统计：功能使用率 4.7%，二次使用率 1.9%。
同期，我们因为资源被占用而推迟的"库存健康度看板"，在没有任何推广的情况下，通过一篇内容带来的自然试用转化，超过了批量改价功能三个月的总量。
这两组数字放在一起，就是引入关键词验证最直接的理由。不是因为我们不重视用户，而是因为我们问用户问题的方式，本身就在制造错误答案。
下面六条，每一条都对应我们真实踩过的坑，而不是从方法论文章里抄来的条目。踩坑的代价是具体的人天数和上线时间，我尽量把这些数字也写出来。
这是我们最早犯的错，也是最贵的错。
当时我们看到"亚马逊 选品"这个词组搜索量很高，直接把选品模块的优先级提到了第一。结果做出来之后发现，搜索这个动作的用户里，很大一部分是刚入行的新手，他们在学习概念，不在寻找工具。
搜索量是"关注度"，不是"购买意愿"。这两者之间的差距，在我们的场景里大概是 8 到 12 倍。后来我们改成用"修饰词密度"来区分：带"怎么""是什么""含义"的是学习需求，带"工具""软件""推荐""哪个好"的才是决策需求。
我们最初的做法是给每个问题分配一个"代表词"。147 条问题对应 147 个词，看起来很整齐。问题是这 147 个词里，有 61 个的月搜索量低于工具的最小可测阈值。
低于阈值的词，不是"没需求"，而是"你测不出来"。这是完全不同的两件事。
后来改成一个需求至少映射 5 个词，且必须包含长尾词。147 条问题最终扩展成了 743 个关键词，单条问题的平均代表词数从 1 提升到 5.05。这一步把"无法测量"的条目从 61 条压缩到了 19 条。
亚马逊卖家类需求有极强的季节性，而且这个季节性跟大多数人的直觉不一样。
我们统计过一个很典型的例子："长期仓储费"相关词的搜索高峰不在旺季前的备货期，而在每年 2 月和 8 月的费用结算窗口前后。如果按年均搜索量做决策，你会得出"这是个全年稳定需求"的结论，然后把资源平均分配，结果在两个真实高峰里都没有准备好。
我们从 2024 年 Q2 开始，给每个关键词组都加了一列"季度波动系数"，用 12 个月的月度数据算最高月与最低月的比值。比值超过 2.5 的词，全部按季节性项目管理，不再按年度均值排期。
销售侧反馈里有一条高频句式："客户说 XX 家有这个功能。"我们早期对这类反馈的响应率很高，因为它看起来是"明确的付费信号"。
但关键词数据告诉我们另一件事：竞品有的功能，恰恰说明这个需求的供给成本已经被抬高了。用户会拿竞品去比，你做得不够好反而扣分；你做得一样好，也没有差异化。
我们做过一次测试：把"竞品都有但用户搜得少"的功能和"竞品都没有但用户搜得多"的功能各挑两个，投入相同人力。后者的首月活跃使用率是前者的 3.4 倍。样本量只有 4 个功能，不能当规律用，但足够让我们改掉"对标即需求"的习惯。
问题清单不是一次性文档。我们第一次是把 147 条整理成表格后封板，三个月后回看，其中 23 条已经因为平台政策变化而失去意义，还有 14 条因为我们已经上线了相关能力，从"问题"变成了"已完成"。
现在的做法是：清单按季度重跑关键词，按月更新状态字段。清单里每一条都必须带四个状态中的一个，待验证、观察中、已排期、已关闭。没有状态的条目，一律视为无效条目。
这是最近才意识到的一个用法错位。团队里很多人拿到关键词工具的第一反应是"看看哪个品类好做"，于是把注意力放在商品词上。
但在验证问题清单这个场景里，我们真正需要的是问题词、场景词、动作词，而不是商品词。"FBA 补货公式怎么算"和"蓝牙耳机"这两个词，前者能告诉你用户卡在哪一步，后者只能告诉你市场有多大。
这个区别看起来很小，实际影响很大。用商品词的视角看问题清单，你会觉得绝大多数问题"没有搜索量"；换成问题词的视角，才会发现需求其实都在，只是你之前查的词不对。
工具只是工具，真正决定结论质量的是验证框架。下面这套四层框架是我们经过三轮迭代后固定下来的，每层负责回答一个不同的问题，缺一层都会出偏差。
这一层只做一件事：判断这个问题在搜索行为层面是否存在。注意是"存在"，不是"多大"。
判定标准很简单：一个问题映射的 5 到 8 个关键词里，只要有 1 个词的月搜索量达到可测阈值（我们用的是 300 次/月），就算通过。
这一层会淘汰掉大约 40% 的条目。淘汰的原因通常有三类：问题描述太抽象（"提高效率"这种没法映射）、问题只存在于我们自己的产品里、问题过于边缘（一年只有几十次搜索）。
强度不是一个数，是三个数的组合：关键词组月搜索量总和、12 个月趋势斜率、内部复现频次。
前两个来自关键词工具，第三个来自我们自己的工单和社群数据。三者归一化后加权，权重分别是 0.45、0.30、0.25。
这里有个容易忽略的细节：趋势斜率的权重不应该低于 0.25。因为搜索量是存量，斜率是增量。我们复盘时发现，最终真正做成的功能里，有 7 个的绝对搜索量都不算高，但斜率明显向上，说明这是一个正在形成的问题，早进入的成本远低于晚进入。
这一层最容易被跳过，但对决策影响最大。我们把问题词按意图分成四类：
判断规则很直接：如果一个问题词里出现"怎么""是什么""含义"，归学习型；出现"为什么""原因""突然"，归诊断型；出现"对比""哪个好""推荐"，归比较型；出现具体动作动词，归操作型。
我们的产品定位决定了资源应该优先投给诊断型和操作型。学习型的词我们改由内容承接，比较型交给销售和落地页。这个分工一旦确立，问题清单的排期逻辑清晰了很多。
前三层回答"值不值得做"，这一层回答"做不做得起"。判断依据有三项：
我们把供给成本归一化到 0 到 1 之间，1 表示最难。实测下来，同一个问题在"功能路径"和"内容路径"上的供给成本经常相差 3 倍以上，这也是为什么第四层必须做，它决定的不只是做不做，还有怎么做。
四层跑完，每条问题会得到四个 0 到 100 的分值。最终优先级分按下面的公式计算：
优先级分 = 0.30 × 需求强度分
+ 0.25 × 意图匹配分
+ 0.20 × 内部复现分
+ 0.25 × (100 – 供给成本分)
阈值我们定得很死，目的是减少讨论成本：
| 分值区间 | 处理方式 | 典型特征 |
|---|---|---|
| 75 分及以上 | 立即进入本轮排期 | 诊断型或操作型，供给成本低，趋势向上 |
| 60，74 分 | 进入下一轮候选池 | 需求明确但供给成本偏高，需先做内容试水 |
| 45，59 分 | 观察池，季度复评 | 需求存在但强度不足，或意图匹配度偏低 |
| 45 分以下 | 归档，不再讨论 | 无搜索行为、学习型高成本需求、或不可解决类问题 |
这套阈值第一次跑的时候，147 条里只有 31 条达到 60 分以上，12 条进入 75 分以上。当时团队的第一反应是"标准太严了"。但三个月后回看，那 12 条的实际使用表现，明显好于之前凭投票选出的 10 条。
打分最怕的是每次不同的人算出不同的结果。我们后来把整个流程写成了一个脚本，输入是关键词明细，输出是排序后的优先级表。简化版大致是这样：
def priority_score(volume, slope, repeat, intent_match, supply_cost):
volume: 关键词组月搜索量总和
slope: 12 个月趋势斜率，正负均可
repeat: 内部复现频次（工单 + 社群提及）
intent_match: 意图与产品定位的匹配度 0-100
supply_cost: 供给成本归一化 0-100，越大越难
strength = normalize(volume) * 0.60 + normalize_trend(slope) * 0.40
repeat_score = normalize(repeat)
score = (0.30 * strength
+ 0.25 * intent_match
+ 0.20 * repeat_score
+ 0.25 * (100 – supply_cost))
return round(score, 1)
def bucket(score):
if score >= 75: return "立即排期"
if score >= 60: return "下轮候选"
if score >= 45: return "观察池"
return "归档"脚本本身不复杂，它的价值在于把主观争论转化成了参数讨论。以前我们争论的是"这个功能重不重要"，现在争论的是"这个问题的供给成本该打 60 还是 75"。后者容易达成一致得多。
前面讲的框架，落地上需要一个能查问题词、看趋势、分意图的工具。我们这一轮用的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），选择它的直接原因有三个。
第一，它的数据类型和我们的问题场景对得上。我们需要的是问题词、场景词、动作词的搜索表现，而不是纯粹的商品词排行。跨境电商的数据源里，能同时覆盖关键词趋势和竞品流量结构的工具不多。
第二，查询到结论的链路短。我的实际流程是三步：先反查竞品流量词，再对目标词组看 12 个月趋势，最后按意图标签分组。整个流程一条问题平均 3 到 5 分钟，147 条问题两个人两天跑完，这个时间成本是可以接受的。
第三，也是最重要的：它能给出趋势而不是只给存量。前面说过，趋势斜率的权重不低于搜索量本身，一个只能看当前搜索量的工具，对我们这个场景的价值会打对折。
这是内部投票第一名，得票率 68%。我们给它映射了 7 个关键词，跑出来的结果是这样的：
四项数据指向同一个结论：这是一个"用户知道怎么做、只是我们的产品做得不好用"的问题，不是"用户找不到解法"的问题。它真实的定位应该是体验优化，不该占用新功能资源。
这个案例后来成了我们内部的典型案例。它的价值不在于"避免了一个错误功能"，而在于它证明了一件反直觉的事：一个问题被反复抱怨，可能恰恰说明它不值得被当成新需求做。
"FBA 库存绩效指标怎么看"在内部排第 19 位，得票 11%。原因是：它听起来太基础了，团队里多数人觉得"这还用教吗"。
关键词数据给的是完全相反的画面：
| 指标 | 批量改价类 | 库存绩效类 | 倍数差 |
|---|---|---|---|
| 关键词组月搜索量合计 | 约 210 次 | 约 4,800 次 | 22.9 倍 |
| 12 个月趋势斜率 | 负值 | 正值，Q3 明显上行 | 方向相反 |
| 诊断型意图占比 | 14% | 63% | 4.5 倍 |
| TOP 10 中社区内容占比 | 20% | 60% | 3.0 倍 |
| 供给成本分（越高越难） | 62 | 38 | 低 39% |
五项指标全部指向相反方向。这个问题的最终得分是 81 分，直接进入排期。它的实际表现也验证了判断：上线后首月活跃使用率 31.4%，是批量改价功能的 6.7 倍。
这个案例给我最大的启发不是"数据比投票准"，而是"这还用教吗"这句话，几乎总是错的。团队内部越觉得基础的东西，越可能是因为我们离用户的真实起点太远了。
这个词组在内部清单里排第 7，理由是销售反馈说"旺季前客户一定会问"。我们一度准备把它做成常设功能模块。
趋势数据打了我们的脸：该词组 12 个月里有 9 个月搜索量低于可测阈值，只有 6 月和 7 月两个月出现明显峰值，波动系数 4.1。
也就是说，全年有 9 个月几乎没人在搜。把它做成常设功能，等于用全年成本服务两个月的需求。
最终的处理方式改了：不做功能，做一份每年 5 月中旬发布的季节性检查清单内容。同样的需求，交付成本从"功能开发 + 长期维护"降到"每年更新一次的内容"。这就是第四层供给成本真正发挥作用的地方。
验证框架不能解决所有问题，这一点必须说清楚。
清单里有 4 条，关键词验证的结果是"搜索量接近零"，但我们依然做了。原因是它们属于平台强制性要求：政策变更导致的合规动作、必填字段调整、接口变更适配。
这类问题的特点是：用户不会去搜索，因为他们在等你通知他。搜索量低不代表不需要，只代表这个需求的触发方式是"被通知"而不是"主动寻找"。
所以我们给框架加了一条兜底规则：凡是命中"平台强制 / 政策合规 / 接口变更"三类标签的问题，跳过四层验证直接进入排期。框架是用来处理不确定性的，不是用来处理确定性的。
147 条问题跑完，最终的分层结果如下：
| 分层 | 条数 | 占比 | 典型得分区间 | 处置 |
|---|---|---|---|---|
| 立即排期 | 12 | 8.2% | 75，88 分 | 进入本轮功能路线图 |
| 下轮候选 | 19 | 12.9% | 60，74 分 | 先做内容试水，观察 1 个季度 |
| 观察池 | 37 | 25.2% | 45，59 分 | 季度复评，暂不投入 |
| 归档 | 79 | 53.7% | 45 分以下 | 不再讨论，保留记录 |
归档的 79 条里，有 21 条属于"不可解决类"（如账号被封、审核不通过），有 26 条属于"我们自己的产品问题"，有 19 条属于"搜索量无法测量"，剩下 13 条是纯学习型需求，转由内容团队处理。
2024 年 Q3，12 个排期项里有 9 个上线。三个月后的对比数据，比验证过程本身更能说明问题。
新功能的平均首月活跃使用率，从上一轮的 6.2% 提升到 24.8%；功能上线 90 天后的留存率，从 3.1% 提升到 11.7%。同期客服工单里"功能缺失"类的占比，从 18% 下降到 9%。
需要说清楚的是，这组数据里混杂了季节因素，Q3 本身就是亚马逊卖家的活跃期。所以我不会说"提升全部来自验证框架"。但把季节性因素剔除后的净提升，我们内部估算在 40% 到 55% 之间，这个幅度仍然值得把流程固化下来。
框架不能照搬。下面按四种常见处境分别给建议，你对号入座即可。
条目少的时候，不要上完整四层框架，成本不划算。建议只做两件事：
这两步大约 3 到 4 小时就能跑完 30 条，能过滤掉一半以上的噪声。条目少于 30 条时，供给成本那层可以跳过，因为你的瓶颈是"不知道该做哪个"，不是"资源不够"。
你关注的重点应该和第二层、第三层不同。对你来说，学习型和比较型需求的权重要调高，诊断型的权重可以调低。
具体操作上，我建议把关键词按"用户所处的决策阶段"重新分组，然后按阶段规划内容，而不是按热度规划内容。同一批词，按热度排你会写出十篇雷同的科普文；按阶段排，你会得到一条从学习到比较到决策的完整路径。
你的场景里没有"问题清单"，但方法可以平移，就是把"工具要解决的问题"当成清单来验证。
具体做法：把工具承诺解决的核心问题，翻译成 5 个你自己会去搜的词，用关键词工具看趋势和意图。如果这些词大部分是学习型、搜索量在下降，说明这个工具在解决一个正在消失的问题；如果是诊断型且趋势向上，说明它踩在了真实变化的痛点上。
用数跨境这类平台做这一步大概只需要十几分钟，但能帮你避开"看起来功能很多、实际用不上"的选择。
那就只做第四层，供给成本评估。
原因是：资源紧张时，最大的浪费不是"做了不重要的功能"，而是"选了一个我们做不起的功能"。重要但做不起的需求，可以等；做不起还硬做，会把整个季度拖垮。
一个可操作的简化判断：如果某问题的 TOP 10 结果里有 6 个以上来自平台官方文档，先别做，你的供给成本大概率被严重低估了。
前面讲的是怎么做，这一节讲的是什么时候该放弃做。取舍比方法重要，因为方法可以学，舍得不舍得放是判断力问题。
这类问题的典型代表是"广告 ACOS 异常诊断"，需求 82 分、供给成本 61 分。它是真实的痛点，但直接做功能风险很大。
我们采取的策略是先用内容试水：写一篇深度的诊断清单，观察 60 天内的自然流量、停留时长和后续的试用转化。内容跑得动，说明这个需求的可触达性没问题，再把内容逻辑产品化；内容跑不动，说明需求虽然存在但你碰不到，功能也别做了。
这个策略的价值在于：它把"功能开发"这个高风险决策，拆成了一个低成本的前置验证。
这类问题最容易引起内部争论，因为"反正成本不高，顺手做了吧"是很自然的想法。
我的建议是：顺手做可以，但不要占用路线图名额。路线图名额的稀缺性不在于开发资源，而在于它会挤占团队的注意力和后续维护成本。一个低需求功能上线后，你还是得处理它的 bug、适配它的接口、回答它的工单。
我们后来专门开了一条"内容与文档侧"的通道，把这类问题都放进去，不占功能路线图名额，由内容和文档团队按季度处理。
"亚马逊账号被封"是这一类。搜索量极高，但我们的产品解决不了。
处理这类问题的关键不是技术判断，而是组织沟通。我们观察到一个规律：这类需求会反复在内部被重新提起，因为它的搜索量数据太显眼了。如果只是私下决定不做，三个月后一定有人再提一遍。
所以我们做了一件事：建立一份公开的放弃清单，每条都写上放弃理由和数据依据。账号被封这条的理由是"搜索量高源于问题不可解决，用户搜索行为属于重复求助，无法转化为产品价值"。这份清单后来又新增了 14 条，效果是重复讨论明显减少了。
趋势斜率为负的问题，不代表立刻不能做。它可能还有 12 到 18 个月的存量价值。
我们的处理原则是：斜率负、存量高的需求，只允许做"低成本快速响应"型的处理，比如一篇文档、一个检查清单、一个轻量的计算器。坚决不做需要长期维护的模块。
判断依据很简单：一个正在萎缩的需求，越晚做维护成本越高、收益越低。
前面说过，这类问题跳过验证直接排期。但有个补充原则：强制类需求要做"最小合规"，不要顺手做"最优体验"。
因为强制类需求的时效性很强，做最优体验会拖长上线时间，反而增加风险。先满足合规、按期上线，体验优化放进后续迭代。我们在这一点上吃过亏：一次字段调整我们顺手重构了整个表单交互，结果上线时间延后了两周，赶上了平台校验的截止窗口，那两周客服压力非常大。
这次复盘之后，我最想留下的一条经验是：问题清单和关键词数据是两种不同性质的信息，混淆它们会同时损失两边的价值。
问题清单的优势在于深度，它告诉你用户卡在哪一步、情绪有多强、上下文是什么。关键词数据的优势在于广度，它告诉你这个卡点有多少人遇到、什么时候遇到、正在变多还是变少。
只用前者，你会做出"我们自己的产品问题"；只用后者，你会做出"看起来有流量但用户用不起来"的东西。两者交叉的地方，才是真正值得投入的区间。
另外一个反直觉但反复被验证的结论是：清单里的高频问题，往往是最不值得做的。因为高频通常来自你自己的产品缺陷、社群的情绪浓度、或者销售的成单话术，这些都不是真实需求的度量。真正值得做的需求，往往安静地待在清单中段。
框架是给不确定性用的。当你面对的是平台强制要求、法规变更、明确的技术依赖时，不要为了走流程而走流程。我见过最浪费时间的团队，往往不是不会用工具，而是把工具用在了根本不需要判断的地方。
验证问题清单这件事，真正的门槛不在工具，而在于你愿不愿意承认：用户说的和他搜的，可能不是同一件事；而你能不能做成，又是第三件事。
读者评论
我们做跨境工具时也拿搜索量验过需求，但吃过大亏：卖家搜的是症状词，不是功能名。文中把搜索量当定价信号我认同，但它更适合做否决和分层，直接拿来排路线图会把低频高价值场景误杀。尤其B端，搜索行为样本太稀疏，还是得和工单闭环率、付费转化一起看。
高搜索量、零可解决度”这条挺关键，但可解决度怎么判定？如果由产品团队自己评，很容易把做不了包装成用户不需要。我们的做法是让支持和销售盲评，再看有没有竞品或替代方案真的解决过。不然放弃列表会变成能力边界的遮羞布。
批量改价上线后使用率低，我不太赞成直接归因于需求弱。它可能是低频救火型功能，跟库存看板这种高频监控不能同口径比。文中用自然试用转化做对照挺有启发，但最好补上付费留存和场景触发率，否则容易把“不常用但离不开”的需求砍掉。