有商业点子还没动手时：用「先售卖…

当有人提出一个商业点子、想在写第一行代码或花一分钱之前，判断它是否值得投入时使用。

适用场景

解决思路

1. 先讲清核心原则：验证靠售卖、不靠构建；大多数创始人花几个月做出了没人要的产品，正确做法是先把解决方案的「手工版」卖出去。
2. 定义问题而不是解决方案：追问「谁具体有这个问题」（要精确到「为开发票发愁的自由职业平面设计师」，而不是「企业」）；他们今天是怎么解决的（现有的变通办法就是你真正的竞争对手）；这个问题有多痛（轻微烦恼还是火烧眉毛）；他们愿不愿意花钱让这个问题消失。
3. 判断能否先手工解决：在构建任何东西之前，先确认你能靠人工手把手替用户解决这个问题；Sahil 把这叫作「processizing」，即做一个手工但有价值的流程。
4. 自己先做一遍：先雇你自己，把每一步都写在一张纸上。
5. 再做可自动化验证：如果你能为少数几个人手工解决，最终就能把它自动化（例：Gumroad 最初就是 Sahil 手工收集 PayPal 信息、一个个给创作者打款）。
6. 检验付费意愿——终极验证是一笔真实交易：问自己现在能不能对这个手工服务收费；有没有和至少 10 位潜在客户谈过；其中至少 3 位说过愿意付费（或已经付了）；什么价位感觉自然。
7. 动手构建前问自己四个问题：1）我能不能在一个周末内把它交付出去？（第一版原型应在 2-3 天内做出来）2）它有没有让客户的生活好一点点？（这就是最小可行产品）3）有没有客户愿意为它付费？（从第一天起就盈利）4）我能不能快速拿到反馈？（反馈闭环越快，越快做出值得付费的东西）。
8. 检查危险信号，出现就不要构建：没人在试图解决这个问题（没有任何现成的变通办法）；你说不出 10 个具体有这个问题的人；唯一的验证是「我朋友觉得这主意很酷」；你需要教育人们他们存在这个问题；你在为一个自己并不属于的社群做产品。
9. 检查积极信号：人们已经在为更差的解决方案付费；你已经手工为少数人解决过且他们很喜欢；社群正在积极抱怨这个问题；你能用一句话描述你的客户及其痛点；你是在挠自己的痒处。
10. 最后给出明确结论：Validated（已验证——信号强，进入 MVP）；Needs more validation（需要更多验证——给出收集证据的具体下一步）；Pivot（转向——想法需要根本性改变，并给出建议方向）。

适用边界 · 注意事项

• 目标客户是你接触不到的群体（你不属于那个社群）时，手工售卖式验证很难执行。
• 问题属于需要教育市场的新品类、用户尚不自知时，这套「现有变通办法即为竞争对手」的验证逻辑不成立。
• 只想验证技术可行性、而非商业模式是否值得投入时，不适用这套流程。