mcpField
M
mom-test

mom-test

github.com/getagentseal营销与增长783694 次安装3 周前更新
代码仓库

关于 mom-test

面向创始人与产品团队的客户访谈 skill,帮助通过讨论客户过往行为而非假设来验证问题与需求。它提供提问、细分受众、记录访谈和识别真实承诺的方法。

主要功能

  1. 01围绕客户生活而非产品提问
  2. 02追问具体的过往行为
  3. 03识别赞美、空泛回答与功能建议
  4. 04通过时间、声誉或金钱判断承诺
  5. 05细分并寻找可触达的客户群

适用场景

  1. 01验证创业想法所针对的问题
  2. 02准备并开展客户访谈
  3. 03从访谈中识别真实购买意愿
  4. 04缩小过于宽泛的目标客群

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/getagentseal/founder-playbook --skill mom-test

安装后在 Claude Code 中输入/mom-test确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

cases.md
examples.md
frameworks.md
integration.md

详细介绍

注意: 此技能提供的是独立分析和评论,并非复述原文。它将书中的核心理念与现代创业实践相结合,指出哪些框架已经过时或不够完善,并融入相关学科的视角。如需了解完整论述和背景,请阅读原书。

The Mom Test

“如何与客户交谈,并在所有人都对你撒谎时判断你的商业点子是否靠谱”——Rob Fitzpatrick

3 条核心规则

  1. 聊他们的生活,而不是你的点子
  2. 询问过去的具体经历,而非泛泛而谈或询问他们对未来的看法
  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 美元)
细分流程
  1. 在这个群体中,谁最想要它?
  2. 他们为什么想要?他们具体遇到了什么问题?
  3. 他们已经在用什么方法解决?
  4. 我们能在哪里找到他们?

良好的细分测试: 只有当你知道去哪里找他们时,一个细分群体才有用。

对话时长指南

时长目标
5 分钟问题是否存在?是否重要?
10-15 分钟工作流细节、他们尝试过什么
1 小时以上与专家深入探讨行业

保持轻松随意

  • 去掉正式感——把“会议”变成“聊天”
  • 一开始就抛出最重要的问题
  • 目标:让他们甚至意识不到自己“开过一场会”
  • 5-10 分钟的轻松交谈,收获不亚于正式会议

流程检查清单

之前
  • 选择聚焦且容易找到的细分群体
  • 与团队确定 3 个重要学习目标
  • 确定理想的后续步骤和承诺
  • 先做基础的案头调研
期间
  • 说明对话的背景
  • 保持轻松随意
  • 提出符合 The Mom Test 的问题
  • 回避赞美,把空话落到实处,深入探究信号背后的内容
  • 做好笔记
  • 推动对方做出承诺并商定后续步骤
之后
  • 与团队回顾笔记和关键引述
  • 更新看法和计划
  • 确定接下来 3 个重要问题

做法不对的迹象

  • 你说得比他们多
  • 他们在夸你或你的想法
  • 你没有做笔记
  • 你得到了意料之外的答案,却什么都没改变
  • 你提出的问题没有一个让你感到害怕
  • 你不知道接下来会发生什么
  • 会议“进行得很顺利”,但没有具体承诺

快速规则

上面的表格和检查清单中尚未提到的规则:

  1. 客户对话默认效果不佳。你的工作就是改善它们。
  2. 人们了解问题,却不了解解决方案。不要问该构建什么。
  3. 你提出的问题里至少有一个应该让你感到害怕(害怕的是答案,而不是提问这件事)。
  4. “嗯……”比“哇!”能提供更可靠的信息。
  5. 只有在你给了对方一个具体的拒绝机会后,对方才算真正的潜在客户。

时间安排

花一周,也许两周。先摸清情况,然后给对方一些可以承诺的事情。不要花几个月空想。

背景:创始人与产品团队

这个框架是为创始人编写的,帮助他们验证一个新想法是否值得继续推进。如果你是在成熟公司工作的产品经理,情况就不同了:你已经知道客户想要这款产品。你的访谈是在现有用户中发现问题(什么出了问题?)或发现功能需求(下一步往哪个方向走?),而不是测试市场是否存在。“推动对方做出承诺”和客户细分部分基本不适用。核心提问技巧(询问过去的行为、避免假设性问题、把空话落到实处)仍然可以直接运用。

不适用的情况

  • 正式的 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