三问验真 · 验证需求是不是真的
Three Questions to Validate Whether a Business Need Is Real
Why · Framework · Usage · Case Study · 中文版
Most product ideas die not because they're badly executed, but because the need wasn't real in the first place.
Founders spend months building for a problem nobody has. Teams ship features nobody uses. The root cause is almost always the same: they validated the solution, not the problem.
WhoWhatWhy is a 3-question framework that forces you to check your assumptions in 5 minutes — before you spend 5 months building.
Who (in what situation) → What problem → Why you?
| Step | Question | Purpose |
|---|---|---|
| 1️⃣ Who | Who is in what situation/scenario? | Define real user + real context |
| 2️⃣ What | What problem did they encounter? | Validate pain point: real? urgent? |
| 3️⃣ Why | Why would they pick you? | Confirm your solution actually beats alternatives |
- ❌ "Everybody" / "All users" in Step 1 → scenario is not specific enough = need is fake
- ❌ "If only they could…" in Step 2 → you're creating a need, not discovering one
- ❌ "No competitors" in Step 3 → usually means no market, not a blue ocean
⚠️ Comments say "Just use X instead" → your solution's moat is questionable
- Describe the idea in one sentence
- Ask the three questions — fill each cell honestly
- Check for danger signals
- Decide — green (proceed), yellow (re-evaluate), red (kill)
After the three questions, add one more round:
"If this need isn't real, what's the most likely counter-evidence?"
Most validations only argue for — never against. Hedge analysis catches optimism bias before it costs you.
| Step | Analysis |
|---|---|
| Who in what situation? | Hotel guests — business travelers, vacationers, couples. What scenarios make them want a drink without going to a bar? |
| What problem? | Multiple possible pain points: "don't want to go to a bar alone," "hotel bar is too expensive," "need convenience after hours." Which one is real? |
| Why you? | A vending-machine cocktail vs hotel bar / delivery / bringing your own. Is the advantage convenience (real) or novelty (weak)? |
Signal from real comments: "Just swap it for beer." — This tells you the core need isn't cocktails, it's convenience/price. The commenter is saying the solution is wrong, but the problem (affordable after-hours drinks) might be real. Classic case of validating the right problem through the wrong "who."
验证一个需求是否真实的三步框架。
谁什么情况？→ 碰到了什么问题？→ 为什么选你？
| 步骤 | 问题 | 目的 |
|---|---|---|
| 1️⃣ 谁 | 谁在什么情况/场景下？ | 明确目标用户画像和使用场景 |
| 2️⃣ 问题 | 他碰到了什么问题？ | 验证痛点是否真实、是否迫切 |
| 3️⃣ 方案 | 为什么选你？ | 确认方案是否真的比现有方案好 |
- ❌ Step 1 出现"所有人""所有用户" → 场景不具体 = 需求不真实
- ❌ Step 2 出现"如果他能……就好了" → 需求是被创造出来的，不是被发现的
- ❌ Step 3 出现"没有竞品" → 通常意味着没有市场，不是蓝海
⚠️ 评论区出现"换成XX就可以了" → 方案的不可替代性存疑
| 步骤 | 分析 |
|---|---|
| 谁什么情况？ | 什么样的客人什么场景下需要鸡尾酒？商务出差/度假/情侣？ |
| 碰到了什么问题？ | "不想去酒吧" vs "酒店酒吧太贵" vs "不方便" — 需要区分 |
| 为什么选你？ | 无人鸡尾酒机 vs 酒店酒吧/外卖/自带酒，不可替代优势在哪？ |
评论信号："换成啤酒就可以了" — 核心需求不是鸡尾酒，是方便/便宜。不要在错误的"谁"上验证正确的"问题"。
demand-validation product-market-fit customer-discovery lean-startup startup-tools entrepreneurship product-management business-validation 伪需求 需求验证 创业
MIT