6个月写出的产品0人问津：开发者最疼的教训藏在代码之前

2023年Stack Overflow调研显示，52%的开发者承认曾在未验证需求的情况下启动项目，其中78%最终因用户流失而终止。这不是技术债的问题——是研究债。

每个写过 side project 的人都经历过这种沉默：周末熬出来的架构，精心选的框架，干净的代码。上线后没有差评，没有功能请求，只有七个 Product Hunt 赞——六个来自朋友。这种失败模式与代码质量无关，它发生在第一行代码之前。

假设堆叠：你在用未验证的赌注盖楼

没和用户聊过就动手，开发者并非从零开始。他们是从假设开始——而且是一堆叠在一起的假设。

问题存在吗？够痛吗？你想象的解决方案和用户脑中的问题匹配吗？他们愿意付多少、怎么发现这个产品、会拿什么做对比？这些假设单独看都合理，但大多数从未被测试。

换个说法：每个假设都是一笔赌注。有些赌注很小，错了代价低；有些是承重墙，错了的话执行再漂亮也白搭。用户研究就是找出哪些是承重墙，在 all in 之前验证它们。

「用户研究」这个词包袱太重。它让人联想到研究员、招募预算、测试实验室、六页方法论 PPT。那种版本存在，也有价值，但不是起步时需要的。

对验证想法的开发者来说，用户研究简单得多：在构建解决方案之前，和有你正在解决的问题的人聊天。就这一步。

三个必问：别推销，要偷听

早期产品访谈跑偏，通常因为开发者在推销想法而非学习。你会问引导性问题，得到社交层面的礼貌回答，离开时自我感觉良好——其实毫无验证。

预构建研究的目标是理解对方现有行为，而非测试他们是否喜欢你的方案。五个能挖出有效信息的问题：

「能给我讲一次你上次遇到这个问题的具体场景吗？」

这逼出具体性。关于问题的泛泛陈述几乎总是错的。你要听的是时间、地点、他们尝试了什么、卡在哪里。

「你当时怎么解决的？」

人们为问题付费，但为解决方案掏更多。如果他们在用 Excel、邮件模板或请实习生手动处理，这就是你的竞品——不是另一家 SaaS。

「为此花了多少钱？包括时间、人力、工具。」

数字不会撒谎。如果他们说「这很痛」但成本核算后是零，要么不够痛，要么他们不是你想象的用户。

「如果魔法解决它，你的一天会有什么不同？」

这暴露他们真正在乎的结果。你可能在优化流程，但他们想要的是「老板不再周五下午发飙」——完全不同的价值锚点。

「你会怎么搜索解决方案？」

这决定你的获客策略。如果他们说是「问同事」，那 SEO 和付费广告都是错的渠道。

48小时验证：没有 UX 团队的实操法

不需要六周。找到 5 个符合你假设用户画像的人，每人聊 30 分钟。LinkedIn 冷消息、Reddit 私信、Twitter 回复、行业 Slack 群组——渠道不重要，重要的是对方真的有这个问题。

录音（征得同意），事后回听。不是记笔记时的那种听，是捕捉语气变化、停顿、「其实……」之后的转折。这些才是信号。

48 小时后你会有：问题是否真实存在的证据、现有解决方案的清单、用户愿意付的隐性价格、以及——往往最关键的——你完全理解错了的地方。

一位连续创业者告诉我他的转折点：「第三次访谈时对方说『哦我们早就不操心这个了』，我才意识到我解决的是两年前的痛点。六个月代码，建在过期需求上。」

承重墙检测：哪些假设必须对

不是每个假设都值得验证。用这两个标准筛选：

如果错了，产品是否直接崩塌？（承重墙）如果错了，是否只是调整路线的问题？（可承受）

典型承重墙假设：用户会为这个付费（商业模式）、用户知道这个问题存在（需求意识）、用户会改变现有习惯来用你的方案（切换成本）。

可承受假设：具体定价点、UI 偏好、功能优先级。这些可以边做边调。

把资源砸在承重墙上。一个未验证的付费意愿假设，能让最优雅的架构变成沉没成本。

YC 合伙人 Michael Seibel 有个粗暴的检验标准：「如果你不能在一周内找到 10 个愿意付定金的人，要么问题不存在，要么你不是解决它的人。」

不是让你真的收定金——是逼自己面对「愿意付费」和「礼貌性感兴趣」之间的鸿沟。

那位连续创业者的项目最终没有复活。但他说那次沉默的上线教会他一件事：代码是便宜的，确定性是贵的。而确定性只能从对话中来，不能从编译器里来。

你的上一个 side project，最后一次和用户聊需求是什么时候——是在写第一行代码之前，还是之后？