阅读完本节后，你将会收获：
- 掌握产品验证三步法的核心要点
- 理解真实访谈法的三条原则，区分好问题与坏问题
- 学会用 MVP 思维快速验证假设
- 掌握避免虚假验证信号的方法
序言中提到的产品验证三步法：灵魂三问、MVP 思维、快速验证。
MVP（Minimum Viable Product，最小可行产品）是用最少资源验证核心假设的产品版本。目标不是"完美"，而是"足够验证"。
Product-Market Fit（PMF）指产品与市场的匹配程度。当产品满足了市场需求，用户会主动拉新，留存曲线变平，即为达到 PMF。
在开始任何验证之前，先问自己三个问题。这三个问题看似简单，却是无数创业者在实践中反复跌倒的地方。它们的价值不在于得到答案，而在于迫使你从自我陶醉中清醒过来，用市场的视角重新审视自己的想法。
模糊的回答等于没有回答。"所有人"不是用户，"年轻人"不是用户，"需要这个功能的人"也不是用户。
具体的回答指向可触达的人群：职场人士中每天需要处理 5-10 个任务的人；每周五需要花 2 小时汇总周报的销售团队；只会用微信、不会复杂操作的父母。
为什么具体用户很重要？因为不同用户群体的痛点、使用场景、支付意愿完全不同。为"所有人"设计的产品，最终谁也服务不好。当你说"所有人"时，实际上是在逃避选择。选择意味着放弃，放弃那些不合适的用户，才能为真正合适的用户提供更好的服务。很多创业者害怕这种选择，担心缩小了潜在市场。但事实是，一个试图取悦所有人的产品，往往无法让任何人真正满意。具体用户画像的价值在于，它让你能够想象出一个真实的人，在真实的情境中使用你的产品。这种具象化的想象，是做出正确产品决策的基础。
"我觉得需要"不是真痛点。"应该会有人用"也不是真痛点。真痛点是：用户现在有解决方案，但那个方案很痛苦。
便签纸容易丢、手机备忘录打开太麻烦——这是真痛点，因为用户每天都在经历。"没有这样的工具"不是真痛点，因为用户可能根本不在意这个问题。
如何判断痛点的真实程度？看用户是否已经尝试解决。如果用户没有主动搜索过解决方案，没有花钱或时间尝试过替代方案，那么这个"痛点"可能只是你的想象。
真痛点的另一个特征是用户已经在为此付出代价。这种代价可以是金钱，比如购买昂贵的软件或服务；也可以是时间，比如每天花费大量精力处理繁琐的流程；还可以是情绪上的负担，比如焦虑、沮丧或尴尬。当用户已经在为解决问题付出代价时，说明这个问题对他们来说是真实且重要的。相反，如果用户只是口头上说"这确实是个问题"，但从未采取任何行动去解决，那这个"痛点"的优先级可能很低，不值得你投入资源去开发解决方案。
在定义产品需求时，用户需求其实有三个层次，理解这三个层次能帮你更精准地定位产品价值。
第一层是痛点（Must-have），这是用户不得不解决的问题。比如一个开发者每次部署都要手动执行 10 个命令，容易遗漏步骤导致部署失败，这就是真实的痛点。痛点的特征是：如果不解决，用户会持续痛苦，甚至愿意为解决方案付费。MVP 应该专注于解决痛点，因为只有痛点才能让用户真正愿意使用你的产品。
第二层是痒点（Nice-to-have），这是用户心中的理想状态。比如部署系统能自动检测代码变更并触发部署，这会让开发者的工作更轻松，但不是刚需——手动部署虽然麻烦，但也能接受。痒点的特征是：如果实现会很开心，但不实现也不会阻碍用户使用产品。痒点应该在迭代时逐步加入，而不是在 MVP 阶段就追求。
第三层是爽点（Wow-factor），这是超出用户预期的体验。比如系统不仅能自动部署，还能在部署失败时自动回滚，并在 Slack 通知团队具体的失败原因和建议的修复方案。用户完全没想到你会做到这一步，这种"哇"的感觉就是爽点。爽点是产品的差异化竞争力，是让用户主动推荐你的产品给朋友的关键。
在编写 PRD 时，分别列出这三个层次，能让产品定位更精准。先确保痛点被解决，再逐步加入痒点，最后用爽点打造差异化。
"因为我们技术最好"用户不在乎。"因为界面好看"用户不买账。"因为 AI 做的"这不是卖点。
真实的优势源于三个方面：更好解决痛点（更快、更便宜、更简单）、独特的获客渠道（你能触达而别人不能）、独特的数据或资源（别人没有）。
很多时候，答案不是"为何用你"而是"根本不需要你"。如果能接受这个答案，就节省了后续所有投入。
这个问题之所以重要，是因为它迫使你面对竞争的现实。大多数市场都不是空白，用户已经在用某些方式解决他们的问题。你的竞争对手可能不是另一家创业公司，而是 Excel 表格、纸质笔记本，或者是"什么都不做"这个默认选项。要赢得用户，你必须提供足够大的改进，大到足以让他们愿意改变现有的习惯。这种改变是有成本的——学习新工具的时间、迁移数据的麻烦、适应新流程的不适。如果你的优势不足以抵消这些成本，用户就不会切换。承认"用户不需要我"是痛苦的，但这种痛苦远小于投入大量资源后发现市场不存在的那种痛苦。
好的问题引向具体行为和真实动机，坏的问题引向观点和承诺。
观点类问题：
除了市场本身，没人能预测一个想法是否成功。这类问题得到的只是安慰，不是数据。
假设类问题：
人们对未来行为的预测往往过于乐观。这些数字看起来很具体，但毫无参考价值。
诱导性问题：
这些问题暗示了期待的答案，对方出于礼貌会顺着说。
行为追溯类：
具体行为无法撒谎，它揭示了真实痛点和优先级。
现状挖掘类：
了解现状不仅能验证痛点，还能给出定价锚点。
动机探究类：
动机决定付费意愿。有些问题虽然存在，但影响不大，用户不会为此付费。
MVP 不是"残缺版产品"，而是"能验证假设的最简版本"。
这个定义至关重要，因为它纠正了一个常见的误解。很多人听到 MVP 时，想到的是"先做个简陋的版本上线，以后再完善"。这种理解会导致两个问题：一是"简陋"往往意味着用户体验糟糕，而糟糕的体验会让潜在用户过早地放弃你的产品；二是"以后再完善"往往永远不会到来，因为一旦产品上线，新的需求和 bug 会占据你所有的时间。
正确的理解是，MVP 是一个实验工具，它的目的是以最小的成本验证最核心的假设。如果假设被验证，你可以继续投入；如果假设被证伪，你可以及时止损。MVP 的"最小"不是指功能少到无法使用，而是指只包含验证假设所必需的功能。一个优秀的 MVP 应该能让用户完成核心价值主张所承诺的体验，即使这个体验是手工后台支撑的。
MVP 不一定是代码。验证假设的方法有很多：
| 验证方式 | 适用场景 | 成本 |
|---|---|---|
| 手工服务 | 验证需求是否存在 | 时间 |
| 落地页 | 验证用户兴趣 | 几乎为零 |
| 原型演示 | 验证方案可行性 | 中等 |
| 简化版本 | 验证核心功能 | 开发成本 |
选择 MVP 形式时，问自己：这个假设能否用更简单的方式验证？
假设有多个层次，从"用户存在"到"用户愿意付费"。每层都需要验证，不要跳过。
| 假设层次 | 验证方法 | 通过标准 |
|---|---|---|
| 用户存在 | 与目标用户交谈 | 能找到 5-10 个符合画像的人 |
| 痛点真实 | 了解现状和代价 | 对方已经尝试解决 |
| 方案可行 | 原型或手工服务 | 对方愿意使用或付费 |
| 可持续 | 付费验证 | 有人真的付钱 |
A: 目标是 5-10 次有效访谈，不是几百次。当 3 次连续访谈没有新信息时，基本可以停止。
A: 这是风险信号。如果找不到用户访谈，可能用户群体不存在或无法触达，这两个都是致命问题。
A: 检查是否提到了自己的想法，是否问了未来行为而非过去行为。重新设计问题，聚焦具体行为和真实代价。
A: 验证不是一次性事件。随着产品发展，新的假设需要新的验证。持续保持验证心态。