我想讲一个特别简单、但大多数人每天都做反了的道理：
不要先把事情做完整，再去找用户。先让用户做出一次真实承诺，再决定要不要把事情做完整。
人们通常按照这样的顺序做事：
想法 → 做产品 → 打磨细节 → 做宣传 → 等用户
真正稳妥的顺序应该是：
猜想 → 做一个最小测试 → 看真实行为 → 再投入资源
这里的“真实行为”不是点赞，也不是一句“挺好的”。它应该是付款、交订金、预约、留下联系方式、提交资料，或者真的打开并使用一次。
你以为自己在做产品，其实可能只是在逃避验证
很多人做一个项目，第一步是起名字、做 Logo、买域名、画原型、搭架构、写功能列表。每一步看起来都很努力，也确实能让人获得一种“事情正在推进”的感觉。
但这里藏着一个很不舒服的问题：
如果最后根本没人要，这些努力是不是只是在把错误做得更漂亮？
完整开发还有一个心理好处：你暂时不用面对拒绝。只要产品还没做完，就可以把没有用户解释成“还没上线”“宣传还没开始”“功能还不够多”。
而一个小测试会立刻把问题推到你面前：有没有人愿意现在就行动？
这就是为什么“先验证，再建设”让人不舒服，却经常更接近正确答案。
四个不是靠运气的案例
这些案例不是说“只要照做就一定成功”。它们真正有价值的地方在于：成功者都先把最大的不确定性拆出来，用很小的代价测试，而不是先押上全部资源。
1. Zappos：没有先买库存，先确认网上有人买鞋
Zappos 创始人 Nick Swinmurn 最早想验证的不是“仓库怎么建”，而是一个更基础的问题：
人们愿不愿意在网上买鞋？
他的做法很原始：去实体鞋店拍下鞋子的照片，放到网上。有人下单后，他才去店里按原价把鞋买回来，再寄给客户。
这当然不是长期经营方式，利润也不好看。但它用极低的成本验证了关键事实：网上确实有人愿意买鞋。
等需求被确认之后，库存、供应链和规模化才值得投入。
这里最重要的动作不是“拍照”，而是：
先验证交易，再建设系统。
出处：Eric Ries，《The Lean Startup》，关于 Minimum Viable Product 的 Zappos 案例。Google Books
2. Dropbox：先做演示视频，不先开发完整同步系统
Dropbox 早期面对的是一个解释成本很高的问题：用户能不能理解“文件在多个设备之间自动同步”到底有什么用？
如果按照常规做法，团队可以先花很长时间把同步系统做出来，再等用户评价。但创始人 Drew Houston 先做了一个演示视频，用画面模拟产品如何工作。
视频并不是完整产品，却足以让目标用户理解结果。看完之后，很多人主动加入等待名单。
这一步验证的是“用户想不想要这个结果”，而不是“后台架构是否已经完美”。
先证明用户想要结果，再解决如何稳定地交付结果。
出处：Drew Houston 的早期创业复盘，以及对 Dropbox MVP 的公开案例整理。Startup Lessons Learned：Great Entrepreneurs Ship
3. Buffer：先测试点击和付费意愿，再开发完整工具
Buffer 创始人 Joel Gascoigne 最开始没有直接开发一套完整的社交媒体排程产品。
他先做了一个简单网页，解释产品能做什么。用户点击之后，会看到不同的价格方案。那时产品还没有完整交付能力，但这个页面可以测试两件重要的事：
- 用户是否理解这个问题值得解决；
- 用户是否愿意为解决方案付费。
这比发问卷更接近现实。因为用户面对的不是“你以后会不会买”，而是一次具体的价格选择。
价格页不是营销装饰，它是一张很便宜的需求测试纸。
出处：Buffer 创始人 Joel Gascoigne 对早期验证过程的复盘。How We Got Our First Paying Customers
4. Airbnb：先手工帮几个房东成交，再把手工过程产品化
Airbnb 早期没有先建一个能覆盖全球的住宿平台。创始人面对的是一个很具体的问题：房东有房，但用户看不到，也不愿意预订。
他们亲自去房源现场，帮房东拍更好的照片，手工优化房源，并直接观察用户是否愿意预订。
这看起来很不“互联网”：没有复杂推荐算法，也没有完善的自动化流程。但它先验证了最关键的一点——改善房源展示，确实能增加真实预订。
之后，拍照、展示、匹配和支付这些流程，才逐步被产品化、规模化。
先人工交付价值，再自动化重复动作。
出处：Paul Graham，YC，《Do Things that Don’t Scale》。原文
这套方法不是“做一个半成品糊弄人”
最小验证不等于粗制滥造，更不等于欺骗用户。
它的意思是：只解决当前最重要的不确定性。
如果你还不知道有没有人愿意买，就不要先解决自动化、扩容、品牌和十个边缘功能。
如果你已经确认有人愿意买，下一步才是提高交付质量、降低成本、扩大规模。
顺序错了，结果通常是：
先把规模化的事情做好，却还没有证明有人愿意使用。
顺序对了，结果应该是：
每一次投入，都在回答一个更具体的问题。
一周内可以执行的最小实验
拿你最近想做的一个项目，严格执行下面七天。
第一天：只写一个假设
不要写“我想做一个帮助大家提升效率的工具”。写成下面这样：
我认为，正在用 Excel 管理客户的独立顾问，愿意支付 99 元，换取一套能自动生成跟进提醒的模板。
一个合格的假设必须写清楚：谁、有什么问题、你提供什么结果、他愿意付出什么代价。
第二天：做一个最小可购买版本
只准备一个介绍页、报名表、预约链接或付款链接。也可以是一段展示结果的视频。
不要先做完整网站、Logo、品牌手册和复杂后台。你现在要测试的是“有没有人要”，不是“能不能把公司装修得很漂亮”。
第三到第四天：找十个真实目标用户
不要只发朋友圈等点赞。直接联系十个真正符合条件的人。
可以这样说：
我正在测试一个解决 X 问题的小服务，现在还不是完整产品。我可以先手工帮你完成一次。如果结果有价值，你愿意支付 99 元，或者预约下一次吗？
第五天：要求一次真实行动
至少观察一种结果：
- 有人付款或交订金；
- 有两个人明确预约；
- 有三个人愿意提交资料并配合测试；
- 有五个目标用户愿意留下联系方式并继续沟通。
“挺好的”“以后可能需要”“你做出来我看看”，都不能算验证。
第六天：手工交付一次结果
哪怕要手工整理、手工分析、手工剪辑，也先完成一次交付。
重点观察：用户有没有真正使用、有没有追问、有没有再次付费、有没有主动推荐，以及他最不满意的地方是什么。
第七天：只做一个决定
只允许三个结论：
- 继续：有人采取了真实行动，扩大测试；
- 修改：有人感兴趣，但当前结果还不够有价值；
- 停止：目标用户没有行动，停止继续投入。
不要使用“再准备一下”“大家还没理解”“功能再多一点就好了”这种模糊结论。它们通常只是把拒绝推迟。
最后只记住一句话
在投入一周以上的时间、超过一笔你舍不得浪费的钱之前，先让一个真实用户做出一次真实承诺。
不是先把桥修完，再问有没有人过河。
而是先看有没有人愿意站到河边，愿意付出一点代价，等你把桥接上。
这不是保守，而是把“努力是否值得”提前验证。