把“我想做一个什么产品”改写成“谁在什么时候遇到什么问题”，再用最小的实验检验它。
- 学习结果
- 写出一条可以被检验的问题假设，设计一个提前定好判断标准的最小实验，并知道怎样根据结果继续、缩小或停止。
- 时长
- 60-90 分钟
- 难度
- 入门必修
- 核验
- 未核验
正文
独立开发者很少缺想法，缺的是能被检验的想法。“做一个 AI 资讯站”“做一个更好用的记账 App”，这些是产品形态，不是需求。它们没法验证：你找谁去问？问什么？对方说“挺好的”算不算成立？
这篇讲一个思路上的转换：从“我想做什么产品”转到“谁在什么时候遇到什么问题”，然后用尽可能小的代价去检验它。
把产品名改写成问题假设
一条好的问题假设，至少要写清四件事：谁、在什么时刻、现在怎么做、付出什么代价。
改写前：“做一个 AI 资讯站，帮大家高效获取信息。”
改写后：“负责给客户写每周行业简报的咨询顾问，每周五要从十几个来源里找出和客户相关的变化，现在靠收藏夹和手动复制，每次要花两个小时左右，还常漏掉重要更新。”
改写后的每一部分都能去问、去观察：找几位写简报的顾问，问上一次是怎么做的，花了多久，漏过什么。而“所有人都想高效获取信息”没有边界，问谁都会说“是”，也就什么都证明不了。
现有的替代方案，是最好的信息
用户遇到问题时，通常已经有办法在应付：表格、收藏夹、群消息、找助理、花钱外包，或者干脆忍着。这些替代方案告诉你三件事：问题是否真的存在（有人在花时间或花钱应付它），用户能接受什么程度的麻烦，以及你的产品要比什么更好。
如果一个人说这件事很痛苦，却从来没为它做过任何事，没花时间也没花钱，那这个“痛苦”可能没有他说的那么重。另外，不要把“不喜欢某个软件的界面”解读成“愿意换掉整套工作方法”。换工具的成本，常常比你想象的高。
问题和方案要分开验证
验证可以分三层，按顺序来：
- 问题存在且有代价：这件事经常发生，而且让人付出了时间、金钱或风险。
- 你的方案被接受：给用户看一个样例或原型，他能理解，并且觉得能用。
- 用户愿意投入：他愿意给出时间、真实材料，或者付钱。
很多人跳过第一层，直接做原型给人看，得到一堆客气的夸奖。顺序很重要：问题不成立，方案再好也没有意义。了解问题的具体方法，见用户访谈：怎么问出真实需求。
什么才算信号
判断验证结果，看的是行为，不是言语。按信号强弱大致可以排成这样：
| 信号 | 强度 | 说明 |
|---|---|---|
| “这个想法不错”“做出来告诉我” | 很弱 | 礼貌的回应，几乎没有成本 |
| 留下邮箱、加入候补名单 | 弱 | 有一点兴趣，但成本很低 |
| 提供真实的工作材料、约下一次试用时间 | 较强 | 愿意为此花时间，也愿意让你看到真实情况 |
| 预付、签意向书、讨论预算和审批流程 | 强 | 开始承担实际成本 |
点赞和夸奖不能代替这些行为。设计验证时，就要想清楚你希望看到哪一层信号。
提前写好判断标准
最小实验的关键，是在开始之前写下什么结果算通过。否则结果出来后，人总会找理由说“其实还不错”。
接着上面的例子：联系 10 位确实负责写简报的人；如果至少 3 位愿意提供下周真实要跟踪的主题，并且至少 2 位在下一周真的用了你整理的报告，就进入下一步。
这些数字只是这一次实验的门槛，不是普适的公式。没有达到标准时，先检查是不是找错了人、邀请写得不清楚、时机不对，再决定要不要换方向。不要因为一次没人回应，就断定整个市场不存在。
先用手工交付验证结果
验证“结果有没有价值”，不需要先把产品做出来。你可以先手工交付：自己从公开来源整理一份简报，注明原文链接和日期，发给用户用。Paul Graham 在《Do Things That Don't Scale》里讲的，就是早期用不可规模化的手工方式服务好第一批用户。
手工交付时要诚实：告诉用户现在是人工整理，不要假装已经有自动化产品；也不要为了得到“有人付钱”的信号，收取你交付不了的费用。观察的重点是：哪些内容被用上了，哪些还需要他自己加工，下次他还要不要。
结论要写清楚证据和未知
一次小样本实验，只能说明这群人、这个场景下的情况，不能证明市场有多大。记录结论时，把三类东西分开：用户的原话、观察到的行为、你自己的推断。
最后从三种决定里选一个，并写下理由：继续（信号达到标准，进入下一层验证）、缩小（某一类人反应明显更强，就聚焦到他们身上）、停止（问题不够频繁或代价不够高）。停止不是失败，它省下了你接下来几个月的时间。如果手上有好几个候选想法，可以用Idea 打分：哪些想法值得先做来安排先验证哪个。
保存访谈记录和用户材料时，先征得对方同意，并去掉不必要的个人信息。
学习步骤
- 选一个你想做的产品，用“谁、什么时刻、现在怎么做、付出什么代价”改写成问题假设。
- 列出目标用户现在使用的三种替代方案，包括“不解决”。
- 确定你这次要验证的是哪一层：问题、方案，还是投入意愿。
- 写下实验对象、联系人数和通过标准，在开始之前定下来。
- 用手工交付或样例代替开发，执行实验并记录原话和行为。
- 根据结果在继续、缩小、停止中选一个，写下证据和仍不确定的部分。
场景拆解
验证“周报整理”这个想法
小吴是一名程序员，发现做咨询的朋友每周都要花时间整理行业动态给客户，想做一个自动整理行业简报的工具。
- 改写假设：“给中小客户提供咨询服务的顾问，每周要为每个客户整理一份行业动态，现在靠收藏夹和手动复制，每份要花一到两个小时。”
- 了解替代方案：他问了 6 位顾问，4 位自己手动整理，1 位让助理做，1 位干脆不做了，改成在会上口头讲。
- 定标准：接下来找 10 位顾问，如果至少 3 位愿意提供下周的真实主题，2 位真的把他整理的报告发给了客户，就继续。
- 手工交付：他连续两周手工整理报告，每条都附原文链接和日期，并说明是人工整理的。
- 结果：10 位里有 4 位提供了主题，3 位用了报告。但他发现顾问们最在意的不是“收集信息”，而是“哪些变化和这个客户有关”的判断。
实验通过了，但方向需要调整：价值主要在“筛选和解读”，不在“收集”。他把下一步实验的重点放到了按客户行业筛选上，而不是做更多信息源。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
写出可检验的假设
- 谁：具体的角色
- 什么时刻：触发条件
- 现在怎么做：替代方案
- 代价：时间、金钱或风险
三层验证
- 问题存在且有代价
- 方案被理解和接受
- 用户愿意投入时间、材料或钱
实验与决定
- 开始前写好通过标准
- 先用手工交付验证结果
- 看行为，不看夸奖
- 继续、缩小或停止
02 实践练习
根据文章内容记录自己的判断与依据。
把一个想法变成可检验的实验
用你自己的一个想法，完成从改写假设到定下实验标准的全过程。这个练习不需要写代码。
准备材料
- 一个你想做的产品想法。
- 三到五位可能是目标用户的人的联系方式。
练习步骤
01 / 改写假设
时间： 20 分钟
操作：
- 用一句话写下产品想法。
- 按四要素改写成问题假设。
产出： 一条问题假设。
检查： 读完这句话，你能马上想到具体该去找谁、问什么。
02 / 列出替代方案
时间： 20 分钟
操作：
- 列出目标用户现在可能在用的三种办法。
- 为每种办法写下它的代价：时间、金钱或风险。
产出： 一张替代方案表。
检查： 至少包含一种“不解决，忍着”的情况。
03 / 设计最小实验
时间： 30 分钟
操作：
- 选定要验证的层次和想看到的信号。
- 写下实验对象、人数、交付方式和通过标准。
产出： 一份实验计划。
检查： 通过标准写在实验开始之前，并且是可以观察到的行为。
完成检查
- 假设包含谁、什么时刻、现在怎么做、付出什么代价。
- 实验计划里的信号是行为，不是夸奖。
- 想好了三种结果分别对应什么决定。
03 清单、模板和关键词
用于项目记录和自查。
问题假设模板
【谁】在【什么时刻 / 触发条件】需要【完成什么事】，
现在用【什么办法】，每次付出【多少时间 / 金钱 / 风险】，
最让他困扰的是【具体的哪一步】。
实验计划模板
要验证的层次：问题 / 方案 / 投入意愿
实验对象（具体到角色）：
联系人数：
交付方式：访谈 / 样例 / 手工交付 / 预售
通过标准（开始前写好）：
不通过时先检查：对象 / 邀请方式 / 时机
结论：继续 / 缩小 / 停止，理由：
关键概念
- 问题假设：写清谁、什么时刻、现在怎么做、代价
- 替代方案：用户现在应付问题的办法，包括不解决
- 三层验证：问题存在、方案被接受、愿意投入
- 行为信号：比言语可靠的证据
- 通过标准：实验开始前定下的判断依据
- 手工交付：先人工提供结果，验证价值
容易误判
- 用产品形态代替问题描述
- 把夸奖和点赞当成需求成立
- 跳过问题验证，直接做原型
- 实验结束后才决定什么算通过
- 一次小样本就推断整个市场
- 手工交付时假装已经有自动化产品
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Notion
- 飞书多维表格
- Tally
- Google Forms