| name | pm-method-mom-test |
| description | 《The Mom Test》方法论。把 Rob Fitzpatrick 的用户访谈框架转化为可执行规则，
用于：设计不被善意误导的用户访谈、从对话中提取真实信号、判断一个需求是真是假。
每条规则标注原书章节，可追溯。
触发词：「Mom Test」「妈妈测试」「用户访谈」「客户访谈」「怎么问用户」「需求验证」
「访谈提纲」及"用户说想要但不确定真假"类场景。
|
《The Mom Test》 · 别问"你会不会用"，去问他真实的过去
什么时候用我
- 要做用户/客户访谈，怕问出一堆善意的假话 → 用【三条铁律】+【好问题改写】
- 访谈完拿到一堆"听起来不错" → 用【信号过滤清单】判断哪些是真信号
- 想验证一个需求真假 → 用【谈过去而非未来】框架
- 不适合：定量验证规模、A/B 实验、方案的可用性测试——本书只解决"怎么和人对话取真信号"。想要发现节奏与机会结构见 pm-advisor-torres，想把需求结构化见 pm-method-story-mapping。
核心框架
框架 1：三条铁律（Mom Test 的定义，前言 & 第 1 章）
书名来自一个反直觉的观点：不该问"妈妈觉得我这生意好不好"（她爱你，会撒谎）。真正的错不在她，在你的问题。好访谈遵守三条：
步骤（每次访谈都过一遍）：
- 谈他们的生活，不谈你的点子 → 问题里不出现你的方案
- 问具体的过去，不问泛泛的未来或意见 → 把"你会不会"改成"上一次你……是什么时候"
- 多听少说 → 你说得越少，拿到的真相越多；话题跑偏到夸你时，把它拉回事实
输出：一份"不提自己点子也能问"的访谈提纲。
框架 2：谈过去而非未来（第 1、3 章）
适用场景：验证需求是否真实存在。
步骤：
- 锁定你想验证的行为 → 找到它在用户过去生活中的痕迹
- 用具体问题挖过去：上一次发生是什么时候？当时怎么处理的？用了什么工具/花了多少钱/多长时间？那次有多糟？
- 判断：他为这个问题真金白银付出过（时间/钱/自建方案）= 真信号；只是"是啊挺烦的" = 弱信号
- 输出：这个需求"是否已被用户用行动投过票"的结论
框架 3：追逐承诺与推进（Commitment & Advancement，第 5 章）
适用场景：判断对方的热情是不是真的（尤其 B 端/销售型访谈）。
步骤：
- 对方说了好话后，索取一个"有代价的下一步"：时间（下次深聊/引荐）、声誉（引荐给同事/老板）、金钱（预付/意向）
- 愿意付出代价 → 真兴趣；只给"赞美 + 无承诺" → 礼貌性敷衍
- 输出：这条线索"是否值得继续投入"的判断
决策规则（来源标注）
- 如果你的问题里提到了自己的点子，则这个问题作废——重写成只问对方生活的版本。（第 1 章）
- 如果在问"你会不会/你想不想要"，则改成"你上一次遇到这个问题是什么时候、当时怎么做的"。（第 1、3 章）
- 如果对方在夸你的想法，别高兴，把话题拉回具体事实与过去行为——赞美是最危险的假信号。（第 2 章）
- 如果对方给的是泛泛的观点、未来的保证、假设性的"如果"，标记为"fluff（空话）"，不作为证据。（第 2 章）
- 如果一个痛点是真的，用户过去一定为它付出过代价；找不到任何代价 → 按伪需求处理。（第 3 章）
- 如果访谈结束没拿到任何承诺/推进，则这不是一次成功的对话，无论气氛多好。（第 5 章）
- 如果你在"pitch"而不是在"学习"，立刻停——访谈的目的是拿信息不是拿认可。（第 4 章）
- 提前写下"我最怕听到的三个答案"，主动去问它们，别只问让自己舒服的问题。（第 6、7 章）
检查清单：一次访谈的信号过滤（综合第 2、3、5 章）
fluff（空话）三种形态需警惕：泛泛的观点（"我一般会……"）、对未来的保证（"我肯定会买"）、假设性称赞（"这主意听起来不错"）。
反模式（书中明确警告）
- 把访谈当路演——一开口就介绍自己的产品，之后所有回答都被污染。（第 4 章）
- 收集赞美并当作验证——"大家都说喜欢"是创业最甜蜜的自我欺骗。（第 2 章）
- 问引导性/封闭性问题——"你会为这个省时间的功能付费吗"几乎必然得到假的"会"。（第 1 章）
- 只和容易约到、对你友好的人聊，回避可能否定你的人。（第 6 章）
- 谈完不落到下一步，靠"感觉不错"记忆，不留可核对的事实。（第 5、7 章）
边界声明
- 出版于 2013 年，方法稳定、几乎不过时；但它只解决"定性访谈取真信号"，不替代定量验证与规模判断
- 适用：需求真伪、痛点强度、B 端线索质量；不适用：可用性测试、界面偏好、市场容量估算
- 它教你"怎么问"，不教你"该问谁/机会怎么排序"——样本与优先级需结合 pm-advisor-torres 的发现结构
- 单次访谈样本小，结论要在多个访谈间交叉验证后才可采信
工作流
收到用户问题后：
- 匹配场景 → 选框架（设计提纲 / 判断信号真假 / 判断承诺）
- 缺核心输入（想验证的具体行为、访谈对象类型）→ 一次性列出需补的信息；需要行业事实时用 WebSearch，不编造
- 按框架步骤执行：帮用户把"坏问题"逐句改写成"好问题"，给出可直接用的提纲
- 用信号过滤清单复核用户已有的访谈记录，逐条标出哪些是 fluff、哪些是真信号
- 结尾声明边界，提示可换视角交叉验证（如"Torres 会帮你把这些访谈挂进机会解决方案树"）
本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Rob Fitzpatrick，仅供个人学习。
