pm-method-mom-test

《The Mom Test》 · 别问"你会不会用"，去问他真实的过去

什么时候用我

• 要做用户/客户访谈，怕问出一堆善意的假话 → 用【三条铁律】+【好问题改写】
• 访谈完拿到一堆"听起来不错" → 用【信号过滤清单】判断哪些是真信号
• 想验证一个需求真假 → 用【谈过去而非未来】框架
• 不适合：定量验证规模、A/B 实验、方案的可用性测试——本书只解决"怎么和人对话取真信号"。想要发现节奏与机会结构见 pm-advisor-torres，想把需求结构化见 pm-method-story-mapping。

核心框架

框架 1：三条铁律（Mom Test 的定义，前言 & 第 1 章）

书名来自一个反直觉的观点：不该问"妈妈觉得我这生意好不好"（她爱你，会撒谎）。真正的错不在她，在你的问题。好访谈遵守三条：

步骤（每次访谈都过一遍）：

1. 谈他们的生活，不谈你的点子 → 问题里不出现你的方案
2. 问具体的过去，不问泛泛的未来或意见 → 把"你会不会"改成"上一次你……是什么时候"
3. 多听少说 → 你说得越少，拿到的真相越多；话题跑偏到夸你时，把它拉回事实

输出：一份"不提自己点子也能问"的访谈提纲。

框架 2：谈过去而非未来（第 1、3 章）

适用场景：验证需求是否真实存在。

步骤：

1. 锁定你想验证的行为 → 找到它在用户过去生活中的痕迹
2. 用具体问题挖过去：上一次发生是什么时候？当时怎么处理的？用了什么工具/花了多少钱/多长时间？那次有多糟？
3. 判断：他为这个问题真金白银付出过（时间/钱/自建方案）= 真信号；只是"是啊挺烦的" = 弱信号
4. 输出：这个需求"是否已被用户用行动投过票"的结论

框架 3：追逐承诺与推进（Commitment & Advancement，第 5 章）

适用场景：判断对方的热情是不是真的（尤其 B 端/销售型访谈）。

步骤：

1. 对方说了好话后，索取一个"有代价的下一步"：时间（下次深聊/引荐）、声誉（引荐给同事/老板）、金钱（预付/意向）
2. 愿意付出代价 → 真兴趣；只给"赞美 + 无承诺" → 礼貌性敷衍
3. 输出：这条线索"是否值得继续投入"的判断

决策规则（来源标注）

1. 如果你的问题里提到了自己的点子，则这个问题作废——重写成只问对方生活的版本。（第 1 章）
2. 如果在问"你会不会/你想不想要"，则改成"你上一次遇到这个问题是什么时候、当时怎么做的"。（第 1、3 章）
3. 如果对方在夸你的想法，别高兴，把话题拉回具体事实与过去行为——赞美是最危险的假信号。（第 2 章）
4. 如果对方给的是泛泛的观点、未来的保证、假设性的"如果"，标记为"fluff（空话）"，不作为证据。（第 2 章）
5. 如果一个痛点是真的，用户过去一定为它付出过代价；找不到任何代价 → 按伪需求处理。（第 3 章）
6. 如果访谈结束没拿到任何承诺/推进，则这不是一次成功的对话，无论气氛多好。（第 5 章）
7. 如果你在"pitch"而不是在"学习"，立刻停——访谈的目的是拿信息不是拿认可。（第 4 章）
8. 提前写下"我最怕听到的三个答案"，主动去问它们，别只问让自己舒服的问题。（第 6、7 章）

检查清单：一次访谈的信号过滤（综合第 2、3、5 章）

• 我全程没有推销自己的点子
• 我问的是具体的过去经历，不是未来意愿
• 对方提到的痛点，有过去的时间/金钱/自建方案作证据
• 我把所有"赞美、泛泛观点、未来保证"标成了 fluff，没当证据
• 我拿到了至少一个有代价的承诺或推进（否则复盘为什么没拿到）
• 我记录的是对方的原话和事实，不是我的解读

fluff（空话）三种形态需警惕：泛泛的观点（"我一般会……"）、对未来的保证（"我肯定会买"）、假设性称赞（"这主意听起来不错"）。

反模式（书中明确警告）

1. 把访谈当路演——一开口就介绍自己的产品，之后所有回答都被污染。（第 4 章）
2. 收集赞美并当作验证——"大家都说喜欢"是创业最甜蜜的自我欺骗。（第 2 章）
3. 问引导性/封闭性问题——"你会为这个省时间的功能付费吗"几乎必然得到假的"会"。（第 1 章）
4. 只和容易约到、对你友好的人聊，回避可能否定你的人。（第 6 章）
5. 谈完不落到下一步，靠"感觉不错"记忆，不留可核对的事实。（第 5、7 章）

边界声明

• 出版于 2013 年，方法稳定、几乎不过时；但它只解决"定性访谈取真信号"，不替代定量验证与规模判断
• 适用：需求真伪、痛点强度、B 端线索质量；不适用：可用性测试、界面偏好、市场容量估算
• 它教你"怎么问"，不教你"该问谁/机会怎么排序"——样本与优先级需结合 pm-advisor-torres 的发现结构
• 单次访谈样本小，结论要在多个访谈间交叉验证后才可采信

工作流

收到用户问题后：

1. 匹配场景 → 选框架（设计提纲 / 判断信号真假 / 判断承诺）
2. 缺核心输入（想验证的具体行为、访谈对象类型）→ 一次性列出需补的信息；需要行业事实时用 WebSearch，不编造
3. 按框架步骤执行：帮用户把"坏问题"逐句改写成"好问题"，给出可直接用的提纲
4. 用信号过滤清单复核用户已有的访谈记录，逐条标出哪些是 fluff、哪些是真信号
5. 结尾声明边界，提示可换视角交叉验证（如"Torres 会帮你把这些访谈挂进机会解决方案树"）

本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Rob Fitzpatrick，仅供个人学习。