有想法时，最不该做的第一件事是开发

有了一个产品想法，很多人的第一个动作是打开代码编辑器，或者先找人报价。

这个动作很自然。开发会迅速产生页面、按钮和功能，让人感觉项目已经从“想法”变成了“现实”。

但开发最容易制造一种错觉：

产品正在变完整，不等于我们正在接近真实需求。

代码可以证明你有能力把产品做出来，却不能证明谁真的需要它、问题是否足够重要，以及用户是否愿意改变现在的行为。

所以，有想法时最不该做的第一件事，是直接开发完整产品。

第一步应该是找到最危险的假设。

先把“产品想法”拆成假设

一句“我要做一个 AI 学习助手”，听起来像产品，实际上包含很多尚未被证明的判断：

• 哪一类人需要它？
• 他们在什么场景中遇到问题？
• 这个问题现在有多频繁、多严重？
• 他们目前如何解决？
• 现有方法为什么不够好？
• 他们愿意为新的解决方式付出什么？

只要其中一个关键判断不成立，后面的功能设计就可能建立在错误基础上。

因此，不要先问“第一版应该有哪些功能”，先把想法改写成一句可以被证伪的假设：

我相信［某类用户］
在［某个具体场景］中
反复遇到［某个问题］，
并愿意通过［一种真实行动］尝试解决它。

如果这句话里出现了“所有人”“经常”“应该会喜欢”或者“肯定愿意”，就继续把它写得更具体。

什么是最危险的假设

最危险的假设不是最难实现的功能，也不是你最想证明正确的观点。

它是：

一旦不成立，整个产品就没有必要继续的那个判断。

例如，你准备开发一个帮助自由职业者自动生成报价单的工具。

“AI 能不能生成 PDF”可能不是最危险的假设，因为技术上通常可以找到实现办法。更危险的可能是：自由职业者是否真的经常因为制作报价单而耽误成交，以及他们是否愿意把客户资料交给一个新工具。

如果真正的问题并不存在，把 PDF 做得再漂亮也没有意义。

开发前，可以怎样验证

验证不等于发一份问卷问“你会不会使用”。

更有价值的是设计一个能观察真实行动的小实验。

1. 用户访谈

寻找五位符合条件的人，询问最近一次问题发生时的真实经历：当时发生了什么、怎么处理、付出了多少时间，以及最后为什么选择现在的办法。

不要先介绍你的产品，也不要问“如果有这个功能你会买吗”。

2. 人工服务

在没有系统的情况下，先手工替一两位用户完成核心任务。

如果用户连人工完成的结果都不需要，自动化通常也不会自动创造需求。

3. 落地页

用一个页面明确写出目标用户、问题、解决方式和下一步行动，观察目标用户是否愿意留下联系方式、预约体验或提交资料。

4. 可点击原型

当你需要验证流程是否容易理解，可以先使用可点击原型，让用户完成任务，而不是立即建设完整后台。

这些方法都不保证想法成立。它们的价值恰恰是让错误更早暴露。

什么时候应该开始开发

“不要先开发”不等于“永远不写代码”。

当下面至少一种情况成立时，开发就可能成为合理的验证手段：

• 用户问题已经通过真实经历得到初步确认；
• 需要验证的关键假设必须通过交互才能观察；
• 技术可行性本身就是项目最大的风险；
• 人工服务已经出现重复步骤，需要用工具提高效率；
• 已经有人用时间、数据、承诺或付费表达真实兴趣。

这时也不要一次做完整产品，只开发回答当前问题所需的最小部分。

每一段代码都应该对应一个学习目标：我们写它，是为了知道什么？

AI 应该放在什么位置

AI 可以帮助你把模糊想法拆成假设、生成访谈提纲、列出反例、制作原型和落地页初稿。

但 AI 生成的用户回答不是用户证据。

它可以帮助你准备验证，不能替你完成验证。需求是否存在，最终仍要由真实用户的经历和行动回答。

合理的顺序是：

想法 → 假设 → 最小实验 → 真实证据 → 必要的开发

而不是：

想法 → 完整开发 → 上线后等待答案

今天可以完成的一张验证卡

现在拿出你的产品想法，写下四行：

目标用户：
发生场景：
最危险的假设：
不用完整产品的验证动作：

如果第四行只能写出“先把产品做出来看看”，再回到第三行。

你真正需要购买的第一样东西不是代码，而是证据。

先买证据，再买代码。