关于 mom-test
面向创始人与产品团队的客户访谈 skill,帮助通过讨论客户过往行为而非假设来验证问题与需求。它提供提问、细分受众、记录访谈和识别真实承诺的方法。
主要功能
- 01围绕客户生活而非产品提问
- 02追问具体的过往行为
- 03识别赞美、空泛回答与功能建议
- 04通过时间、声誉或金钱判断承诺
- 05细分并寻找可触达的客户群
适用场景
- 01验证创业想法所针对的问题
- 02准备并开展客户访谈
- 03从访谈中识别真实购买意愿
- 04缩小过于宽泛的目标客群
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ getagentseal/ founder-playbook --skill mom-test安装后在 Claude Code 中输入/mom-test确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
cases.mdexamples.mdframeworks.mdintegration.md详细介绍
注意: 此技能提供的是独立分析和评论,并非复述原文。它将书中的核心理念与现代创业实践相结合,指出哪些框架已经过时或不够完善,并融入相关学科的视角。如需了解完整论述和背景,请阅读原书。
The Mom Test
“如何与客户交谈,并在所有人都对你撒谎时判断你的商业点子是否靠谱”——Rob Fitzpatrick
3 条核心规则
- 聊他们的生活,而不是你的点子
- 询问过去的具体经历,而非泛泛而谈或询问他们对未来的看法
- 少说多听
决策树
Need customer feedback?
├─ Pre-product, no idea what to build → Mom Test (this skill)
├─ Have validated market, packaging product → 100m-offers
├─ Have offer, need traffic → 100m-leads
└─ Selling enterprise → spin-selling
In a customer conversation?
├─ They're complimenting you → DEFLECT to current behavior
├─ They're speaking in generics ("usually", "always") → ANCHOR to last specific instance
├─ They're requesting features → DIG to underlying motivation
└─ They're committing nothing → PRESS for time/reputation/money
糟糕的问题(千万别问)
| 问题 | 为什么不行 |
|---|---|
| “你觉得这是个好点子吗?” | 只有市场才能给出答案。看法毫无价值。 |
| “如果有款产品能做到 X,你会买吗?” | 所有人都会说会。假设性问题都是谎言。 |
| “你愿意为 X 支付多少钱?” | 数字看起来严谨,但仍然是谎言。 |
| “你有没有……”/“你会不会……” | 只会引出空话和对未来的承诺。 |
好的问题(可以这样问)
| 问题 | 能揭示什么 |
|---|---|
| “你为什么要费这个劲?” | 对方认为的问题背后真正的动机 |
| “这会带来什么影响?” | 是必须解决的问题,还是锦上添花 |
| “跟我说说上次发生这种情况时的经过。” | 具体的过往行为 |
| “你还尝试过什么?” | 对方是否在意到愿意寻找解决办法 |
| “你现在是怎么处理的?” | 现有解决方案及价格锚点 |
| “这笔钱从哪里来?” | 预算和采购流程 |
| “我还应该和谁聊聊?” | 测试对方是否在意到愿意帮忙引荐 |
| “还有什么是我应该问但没问的吗?” | 找出遗漏的要点 |
3 类糟糕数据及应对方式
| 糟糕的数据 | 示例 | 应对方式 |
|---|---|---|
| 恭维 | “这真不错,我很喜欢。” | “谢谢——不过你现在是怎么处理这类问题的?” |
| 空话 | “我通常会……”/“我肯定会买。” | “上次发生是什么时候?跟我说说当时的经过。” |
| 点子/功能 | “能加上 X 功能吗?” | “你为什么想要这个?有了它你能做什么?没有它时你是怎么应对的?” |
承诺筹码
真正的兴趣意味着愿意付出有价值的东西。恭维不需要付出任何代价。
| 筹码 | 示例 |
|---|---|
| 时间 | 明确约定下次会面、实际使用试用版、坐下来提供反馈 |
| 声誉 | 引荐同行、引荐给老板、公开评价 |
| 金钱 | 意向书、预购、订金 |
良好的会面收尾方式
- “接下来要做什么?”
- “我们什么时候可以开始试用?”
- “我可以买下原型吗?”
- “你什么时候能回来和团队其他成员聊聊?”
礼貌的拒绝(糟糕的收尾方式)
- “这太棒了,我很喜欢!”
- “上线时告诉我。”
- “我肯定会买。”
关键原则
问题由他们定义,解决方案由你掌握。
你不能告诉他们问题是什么。他们也不能告诉你该做什么。
过滤测试
如果他们连解决方案都没搜过,那他们其实并不在意到愿意为你的方案付费。
客户细分
细分群体过于宽泛的迹象
- 谈了 10 多个人,反馈各不相同
- 每样东西“多少有点用”,但没有任何东西能脱颖而出
- 无法证明自己是对是错
- 每项功能都是某个人的最爱
- 价格差异巨大(10 美元对 10,000 美元)
细分流程
- 在这个群体中,谁最想要它?
- 他们为什么想要?他们具体遇到了什么问题?
- 他们已经在用什么方法解决?
- 我们能在哪里找到他们?
良好的细分测试: 只有当你知道去哪里找他们时,一个细分群体才有用。
对话时长指南
| 时长 | 目标 |
|---|---|
| 5 分钟 | 问题是否存在?是否重要? |
| 10-15 分钟 | 工作流细节、他们尝试过什么 |
| 1 小时以上 | 与专家深入探讨行业 |
保持轻松随意
- 去掉正式感——把“会议”变成“聊天”
- 一开始就抛出最重要的问题
- 目标:让他们甚至意识不到自己“开过一场会”
- 5-10 分钟的轻松交谈,收获不亚于正式会议
流程检查清单
之前
- 选择聚焦且容易找到的细分群体
- 与团队确定 3 个重要学习目标
- 确定理想的后续步骤和承诺
- 先做基础的案头调研
期间
- 说明对话的背景
- 保持轻松随意
- 提出符合 The Mom Test 的问题
- 回避赞美,把空话落到实处,深入探究信号背后的内容
- 做好笔记
- 推动对方做出承诺并商定后续步骤
之后
- 与团队回顾笔记和关键引述
- 更新看法和计划
- 确定接下来 3 个重要问题
做法不对的迹象
- 你说得比他们多
- 他们在夸你或你的想法
- 你没有做笔记
- 你得到了意料之外的答案,却什么都没改变
- 你提出的问题没有一个让你感到害怕
- 你不知道接下来会发生什么
- 会议“进行得很顺利”,但没有具体承诺
快速规则
上面的表格和检查清单中尚未提到的规则:
- 客户对话默认效果不佳。你的工作就是改善它们。
- 人们了解问题,却不了解解决方案。不要问该构建什么。
- 你提出的问题里至少有一个应该让你感到害怕(害怕的是答案,而不是提问这件事)。
- “嗯……”比“哇!”能提供更可靠的信息。
- 只有在你给了对方一个具体的拒绝机会后,对方才算真正的潜在客户。
时间安排
花一周,也许两周。先摸清情况,然后给对方一些可以承诺的事情。不要花几个月空想。
背景:创始人与产品团队
这个框架是为创始人编写的,帮助他们验证一个新想法是否值得继续推进。如果你是在成熟公司工作的产品经理,情况就不同了:你已经知道客户想要这款产品。你的访谈是在现有用户中发现问题(什么出了问题?)或发现功能需求(下一步往哪个方向走?),而不是测试市场是否存在。“推动对方做出承诺”和客户细分部分基本不适用。核心提问技巧(询问过去的行为、避免假设性问题、把空话落到实处)仍然可以直接运用。
不适用的情况
- 正式的 B2B/企业场景: 某些场景需要正式的流程
- 受监管行业: 医疗保健、金融领域可能需要采用不同的方法
- 真正新颖的创新: 客户在看到之前,无法想象自己想要什么
- 文化背景: 日本、德国和正式的企业文化期待不同的流程
- 领域专家: 专家对其自身领域的看法很有分量(这条规则针对的是他们对“你的想法”的看法)
危险信号(应避免的客户)
即便客户热情十足、愿意付费,也可能让你偏离方向:
- 需求过于特殊,会让你偏离方向
- 要求无法推广到其他客户的定制工作
- 想要的东西与你的愿景完全不同的“远见者”
- 只有先构建他们特别想要的功能才愿意承诺
配套文件
- frameworks.md - VFWPA 邮件模板、ACA 框架、更深入的问题层级、寻找对话对象的实用指南
- cases.md - Earlyvangelist 概念(Steve Blank 提出的术语,由 Fitzpatrick 使用)、案例式示例
- examples.md - 笔记符号、完整邮件脚本、对话流程示例
- integration.md - The Mom Test 如何与 100m-offers、100m-leads、spin-selling、obviously-awesome 结合;与假设检验方法的冲突
细微之处
- “少说”是指不要推销你的解决方案,而不是完全不说话。提出有策略的问题并引导对话,也是交流。
- “对一个问题感到恐惧”是指害怕答案(它可能会推翻你的想法),而不是要咄咄逼人地提问。
- “争取对方作出承诺”不代表咄咄逼人。知道何时该退让。得罪联系人比没有争取到承诺更糟。
- “他们不能告诉你该构建什么”不代表要忽视领域专家。经验丰富的用户可能比你更了解实现方式——要弄清楚 WHY。
评论
支持 Markdown