当前位置：首页 > news >正文

如何区分真问题还是伪需求

news 2026/6/4 2:06:43

我见过太多这样的项目：一个工程师团队闷头干了四个月，技术栈选得漂亮，架构图画得能裱起来挂墙上，CI/CD 一键发布，单元测试覆盖率 85%。然后上线，DAU 个位数。复盘会上没人敢说出那句真相——这个东西，根本没人需要。

这不是个别现象。被广泛引用的 CB Insights 创业失败原因分析里，排在最前面的从来不是"技术不行"，而是"没有市场需求"（no market need）——这一条常年占到失败案例的约 35%，是头号杀手。换句话说，干掉创业公司的，不是写不出代码，而是写出了没人要的代码。

问题来了：在动手之前，你怎么知道自己面对的是一个"真问题"，还是一个被自己脑补出来的"想象中的问题"？

一、伪需求是怎么长出来的

伪需求几乎从不长得像伪需求。它通常以一句无比顺理成章的话开场：

“用户肯定希望……”
“我要是用户，我一定会想要……”
“这个功能这么明显，怎么可能没人用？”

注意这些句子的主语——全是"我"，没有一个是真实用户用真实行为给出的反馈。这就是伪需求的基因：它诞生于开发者的同理心想象，而非用户的真实付出。

工程师尤其容易掉进这个坑，因为我们手里握着锤子（写代码的能力），于是满世界都是钉子。一个想法冒出来，最舒服的动作就是打开编辑器开始写——写代码是我们的舒适区，而"去问、去验证、去面对可能被打脸"是我们的恐惧区。于是我们用四个月的勤奋，掩盖了四个小时本可以完成的验证。

判断真伪，有一个粗暴但有效的试金石：用户愿意为这个问题付出代价吗？这里的代价不一定是钱，可以是时间、是留下邮箱、是点一次"我要预约"、是把一本书寄出去。只要不需要付出任何东西就能"表示喜欢"，那种喜欢基本不作数。

上图这张四象限里，最危险的不是右下角"已证伪的伪需求"——那是好结果，你用低成本知道了真相。最危险的是左下角：一个伪需求，却从未被验证，于是你带着满腔热情，把它当真问题做了半年。

二、Buffer：一个落地页，验证了一百万用户的需求

2010 年，Joel Gascoigne 想做一个社交媒体定时发帖工具。这在技术上不复杂，但他没有立刻开始写代码。

他先做了一个极简的落地页：两段文字描述了产品的价值主张（“轻松把内容排成队列，按计划自动发到 Twitter”），然后放了一个"计划与定价"按钮。注意，这时产品根本还不存在——按钮背后只是一个"感谢，我们会通知你"的页面。

落地页上线后，他只做了一件事：观察有没有人真的点那个按钮、留下邮箱。

结果是有人点了。于是他才加了一步：展示三种假想的定价套餐，按钮变成了"我要选这个计划"。又有人点了。至此，Gascoigne 才确认：这个问题是真实的，有人真的愿意为解决它付出代价。接下来他才开始写代码，七周后产品上线，后来 Buffer 发展成拥有超过百万用户的成熟产品。

这一步的精妙之处在于：他验证的不是"我能不能做出来"，而是"做出来到底有没有人要"。留邮箱、选定价，就是用户付出的那个"代价"。愿意点击的人，构成了一份比任何问卷都可信的答案——因为这是行为，不是嘴上说说。

那个落地页不是产品，它是一个验证假设的道具。它存在的唯一目的，是把"用户会不会想要"这个不确定性，用最小的成本变成一个可观测的数字。

三、饿了么：用电话和腿，跑通了外卖配送模式

如果说 Buffer 的落地页是"需求验证最轻量的打法"，那么饿了么则给出了一个更"土"也更动人的国内版本——它的第一步，甚至比建网站还要原始。

2008 年，张旭豪和几个同学在交大宿舍里饿了想点外卖，却发现没有合适的平台。他们想做外卖配送，但没有立刻去开发 App 或网站。他们做的是：先打印了一批传单，贴在校园周边餐馆，手机号码写上，用户打电话来下单，他们自己骑车去餐厅取餐、送上门。整个业务流程，全是手工、全靠人肉。

外卖配送的链条一点不简单：餐厅接入、菜单管理、在线支付、配送调度、位置追踪……如果一开始就按技术范式来，应该先开发 App，再做后端系统，再接各家餐厅 API——几个月、大量资金。而张旭豪想先验证的，只是最朴素的一个问题：有没有人真的想点外卖、等配送？餐厅愿不愿意合作？这个模式，从收到订单到把饭送到手，走不走得通？

骑车跑腿的那段时间，就是饿了么的"Concierge MVP"。当订单越来越多、送不过来时——验证完成了。需求是真的，链路是通的。这时候，团队才开始开发网站，才开始考虑规模化和自动化。

这里有个值得每个工程师刻进脑子里的反直觉结论：最初最该被砍掉的，恰恰是写代码这一步。电话和自行车很低技术含量，但它在验证阶段比任何优雅的系统都更优秀——因为它能在一周内、几乎零成本地告诉你真相。

四、把验证变成一套可复用的动作

Buffer 和饿了么不是靠运气，它们走的是同一套方法论的两种形态。把它拆成可操作的步骤，你也能用：

第一步，把"想法"翻译成"可证伪的假设"。
不要写"用户需要一个更好的笔记工具"，这无法被验证。要写成：“有 [谁]，因为 [什么场景下的什么痛点]，愿意 [付出什么代价] 来解决它。” 一个无法被证伪的假设，就是一句正确的废话。

第二步，设计成本最低的验证物。优先级从低到高：

落地页 + 一个按钮：描述价值主张，放一个"立即预约/我要试用"的按钮，看转化率。点击就是代价。
落地页 / 演示视频 / 原型（Buffer 路线）：当产品还不存在，先用最简单的方式传达价值主张，观察有没有人愿意留邮箱、预约、或选定价计划。
人肉服务 / 手工后台（饿了么路线，业内也叫 Concierge MVP 或"绿野仙踪"法）：前台让用户感觉是个产品，后台其实是你自己用电话、用人工跑。专治那些"流程能不能跑通"的疑问。

第三步，盯住行为，而不是表态。问卷里 90% 的人说"会用"，远不如 10 个人真的留邮箱、真的点定价按钮。意见会撒谎，行为不会。设定一个验证前就定好的成败线（比如"落地页转化率低于 2% 就放弃"），免得事后自我安慰、把噪音当信号。

第四步，根据数据决定放大还是掉头。证实，就投入工程资源做正式版；证伪，恭喜你——你刚用一周和几乎零成本，省下了四个月。证伪从来不是失败，它是验证回路里同等宝贵的一种成功。