这本书是我在《小而美：持续盈利的经营法则》里看到的引用，本来没有特别在意。尤其是在没有看副标题之前，其像《穷爸爸富爸爸》那样劝退了我，直到某个机缘巧合的再次推荐，我重新找到了这本书，试看了一下。
这是一个聚焦在很小一点上的书籍，主要是介绍如何与潜在客户（或者用户）通过对话获得关于自己 Business 的真实反馈，与我自己之前做客服的经历也有相通之处，很适合需要经常做市场调研或者用户访谈的人群，比如创业者或者产品设计。
即使我们忽略其中的方法论，只是意识上的改变也是可以的，比如：
- 每个与我们对话的人都在不同程度的欺骗我们，越亲近的人越是如此
- 没有直接送到嘴边的事实，好的事实都是需要在对话里花精力挖掘出来的，也是这本书的价值
- 用户拥有问题，但不一定清楚问题的本质是什么，而我们有义务搞清楚问题是什么，并提供对应的解决方案
- 对话是为了获取具体发生的事实，而不是未来的观点，所以，不能相信用户说"这个我未来会付钱"
- 对话本身就是对人性的挑战，除了对话的人爱撒谎，我们自己也总是比想象中更想要获得认可，这会导致获得很多虚假的恭维
- 拥有很多想法是创业者的日常，但往往急于行动，而不是追寻想法背后的动机和目的
- 很多人不太会处理用户的反馈，可以理解用户的想法，但不要遵从
- 很多用户说的问题，其实都不是问题，因为实际什么都没有尝试，只是口头说一说
- 用户访谈尽量闭嘴，更不要提及自己的想法，我们的目的是获取对方的事实
在意识先行之后，如何执行这套有价值的对话流程呢？
流程图原始地址：how-to-run-the-process
妈妈测试 Mom Test
People say you shouldn’t ask your mom whether your business is a good idea. That’s technically true, but it misses the point. You shouldn’t ask anyone whether your business is a good idea. At least not in those words. Your mom will lie to you the most (just ‘cuz she loves you), but it’s a bad question and invites everyone to lie to you at least a little.
每个人都在或多或少撒谎，你的妈妈撒谎最多，其实越是亲近的人越容易撒谎。（这个地方反向说明了，如何以好的措辞来提问才能有可能不让别人欺骗自己。）
妈妈测试是一套简单的规则，用于制定好问题，即使是你的妈妈也无法对你撒谎。
收集一堆错误的积极结果就像说服一个醉酒的人他清醒一样：没有任何改善。
早期客户对话的有用性的衡量标准是它是否提供了关于客户生活和世界观的具体事实。这些事实反过来又使我们能够改进我们的业务。
这里其实首先说明不要问主观想法，要询问具体发生的事实，任何提炼或者主观的意见都会有曲解甚至撒谎。
The Mom Test（的核心）
- Talk about their life instead of your idea 谈论他们的生活而不是你的想法
- Ask about specifics in the past instead of generics or opinions about the future 询问过去的具体事项，而不是关于未来的概括或意见
- Talk less and listen more 少说多听
被称为"妈妈测试"，因为它会引出一些连你的妈妈都无法对你撒谎的问题。
Rule of thumb: Customer conversations are bad by default. It’s your job to fix them.
经验法则：默认情况下，客户对话是糟糕的。你的工作是修复它们。
获得答案是需要花费很大精力的，而不是直接相信送到眼前的事情。
假设你正在开发一个帮助建筑公司管理供应商的应用程序。你可以要求他们展示他们目前的做法。谈论他们喜欢和讨厌的部分。询问他们在选择这个应用程序之前尝试过哪些其他工具和流程。他们是否正在积极寻找替代品？如果是，是什么让他们犹豫不决？如果不是，为什么不是？他们目前的工具在哪些方面浪费了他们的金钱？是否有预算购买更好的工具？现在，将所有这些信息综合起来，自己决定是否是一个好主意。
Rule of thumb: Anything involving the future is an over-optimistic lie.
经验法则：任何涉及未来的事情都是过于乐观的谎言。
经验法则：人们知道自己的问题是什么，但不知道如何解决这些问题。
很多时候，我都觉得，人们并不知道自己的问题本质是什么，他们只知道问题的表象，我们要知道的是表象和表象的 Context 是什么。
好的故事应该"展示，而不是告诉"。
最好的方式是，站在用户旁边，让用户演示一下，实在不行可以录屏，但是尽量避免用户转述。
Rule of thumb: Watching someone do a task will show you where the problems and inefficiencies really are, not where the customer thinks they are.
经验法则：观察他人执行任务将向你展示问题和低效之处的真正所在，而非顾客认为的所在。
其实就是观察别人做了什么，而不是说了什么
Rule of thumb: If they haven’t looked for ways of solving it already, they’re not going to look for (or buy) yours.
经验法则：如果他们还没有寻找解决办法，那么他们也不会寻找（或购买）你的解决方案。
说明这个问题并不重要。
一如既往地，询问他们目前的做法，而不是他们认为将来可能会做的事情。
要问的问题是关于你的客户的生活：他们的问题、关心的事情、限制和目标。你谦卑而真诚地收集尽可能多的关于他们的信息，然后自己进行有远见的解决方案。一旦你迈出了这一步，你通过承诺和进步来确认它是正确的（并加以完善）
It boils down to this: you aren’t allowed to tell them what their problem is, and in return, they aren’t allowed to tell you what to build. They own the problem, you own the solution.
归根结底就是这样：你不能告诉他们问题是什么，而他们也不能告诉你要建造什么。他们拥有问题，你拥有解决方案。
用户拥有问题，而我们拥有构建方案的能力。
避免坏数据 - Avoiding bad data
Unfortunately, they’re almost certainly lying. Not necessarily intentionally. They might want to be supportive or to protect your feelings. Or your excitement might be rubbing off on them.
很不幸，他们几乎肯定在撒谎。不一定是有意的。他们可能想要支持你或保护你的感受。或者是你的兴奋感影响了他们。
你交谈的人可能为了表达对你的支持而欺骗你。
一旦你开始注意到，通过回避恭维、锚定废话和深入探究思想，重新回到正轨是很容易的。
如果一个会议以赞美结束，那么大概率是恭维，都是 Bad Data，这是书中提到的。
Even if they really do like it, that data is still worthless. For example, venture capitalists (professional judges of the future) are wrong far more than right. If even a VC’s opinion is probably wrong, what weight could that of some random guy’s possibly have?
即使他们真的喜欢它，那些数据仍然毫无价值。例如，风险投资家（未来的专业评判者）往往错误远多于正确。即使风投家的意见可能是错误的，那么一个随机人的意见又能有多大的分量呢？
除了行业专家以外，其他人的意见基本都是毫无价值的。（书里提到的）
你需要的是事实和承诺，而不是恭维。
摆脱恭维的错误信息的最佳方法是完全避免提及你的想法。如果它们仍然发生，你需要转移恭维的注意力，继续收集事实和承诺。
一旦提及自己的想法，对谈的人不太可能去否定你的想法，反过来就只会听到正面的恭维。
为了进行一次良好的对话，你并不需要得到你想要听到的结果。你只需要找到真相。
交谈是为了获取真相，极有可能听到自己不想听到的结果。
Sometimes it’s easier to spot the symptoms than to notice the original compliment.
忽略赞美应该很容易，但事实并非如此。我们非常渴望听到赞美，以至于常常被欺骗，将其视为积极的数据点而非空洞的谎言。有时候，更容易察觉到症状，而不是注意到最初的赞美。
赞美往往很虚空，缺少事实的支撑。
忽略赞美应该很容易，但事实并非如此。我们非常渴望听到赞美，以至于常常被欺骗，将其视为积极的数据点而非空洞的谎言。
对于我们自己，我们比我们想象中更想听到赞美，这也说明，本能的我们会忍不住去提及自己的想法。
当有人开始谈论他们"总是"、“通常”、“从不"或"会"做什么时，他们只是在给你提供一些泛泛而谈的假设性内容。遵循《妈妈的测试》的原则，将他们带回到过去的具体情况中。询问他们上次发生的时间，让他们向你描述一下，他们是如何解决的，还尝试了什么其他方法。
其实也是在避免泛泛而谈
最糟糕的引发废话的问题是：“你会这样做吗？“当然他们可能会。某一天。但这并不意味着他们会这样做。
这句话问的也是未来。
当使用一般性描述时，人们描述的是他们想成为的人，而不是他们实际上是谁。你需要具体说明以突出边缘情况。
你需要具体说明以突出边缘情况。
锚定是以废话为锚点，探索更具体的事实
为了接近这个真相，你只需要拒绝他们的泛泛之论、偶然的抱怨和空洞的承诺。相反，将他们锚定在他们已经过的生活和他们已经采取的行动上。
创业者总是被想法淹没。
把它们写下来，但不要急于把它们添加到你的待办事项列表中。创业公司的重点是专注并执行一个可扩展的想法，而不是追随每一个好主意。
这就是日常最常遇到的问题，不要急于添加到待办，而是先写下来，Review 之后再做定夺，Review 是了解想法背后的动机和目的，急于行动总是反复。
当你听到一个请求时，你的工作是理解背后的动机。你可以通过深入探究问题来找到根本原因。为什么他们要以这种方式做？为什么他们想要这个功能？他们在没有这个功能的情况下是如何应对的？深入挖掘。
即使是自己的请求也是如此，这些都是直觉上的想法。
挖掘功能请求的常见问题，适合给客服和运营同学
Questions to dig into feature requests:
深入了解功能请求的问题：
- “Why do you want that?” 你为什么想要那个？
- “What would that let you do?” 那会让你做什么？
- “How are you coping without it?” 你没有它的话，你怎么应对？
- “Do you think we should push back the launch add that feature, or is it something we could add later?” 你认为我们应该推迟发布并添加这个功能，还是可以稍后再添加？
- How would that fit into your day? 那会如何适应你的一天？
Questions to dig into emotional signals:
深入探讨情绪信号的问题：
- “Tell me more about that.” 告诉我更多关于那个的事情。
- “That seems to really bug you — I bet there’s a story here.” 这似乎真的让你很烦恼 - 我敢打赌这里面肯定有个故事。
- “What makes it so awful?” 是什么让它如此糟糕？
- “Why haven’t you been able to fix this already?” 为什么你还没能解决这个问题？
- “You seem pretty excited about that — it’s a big deal?” 你似乎对此非常兴奋 - 这是一件大事吗？
- “Why so happy?” 为什么这么开心？
- “Go on.” 继续。
任何强烈的情绪都值得探索，它是一种信号
Rule of thumb: Ideas and feature requests should be understood, but not obeyed.
经验法则：理解意见和功能请求，但不必遵从。