第02章 什么是「真需求」
第01章立了三个公式，其中公式二「交付闭环 = 范围 → 实现 → 验证 → 验收」。四环里最容易被跳过、也最容易让全盘归零的，是第一环——范围。范围从哪里来？从需求来。而大多数人手里的"需求"，其实只是想法、是功能、是自己的一厢情愿。本章把"需求"这个词重新定义清楚：什么是真需求、什么是伪需求、怎么在三分钟内判别。第03章会讲你作为编排者，怎么把筛出来的真需求编排成产品。
2.1 结论先行：真需求 = 有人愿为解决某个痛点付出代价
先把结论摊开。"需求"这个词被用得太滥，先给它一个能操作的定义：
真需求 = 痛点（不舒服）+ 愿望（想要更好）+ 付费意愿（愿意掏钱 / 花时间）三者层层递进，只有第三层成立，才是真需求。
Layer 1 痛点 "我每周都要花 2 小时手动整理这份报表，烦"
↓ 不舒服，但未必愿意解决
Layer 2 愿望 "要是有个工具能自动整理就好了"
↓ 想要更好，但未必愿意付出代价
Layer 3 付费意愿 "这工具 ¥99/月我也买，省下的时间值"
↓ 掏钱的实际行动 → 这才是真需求| 层 | 名字 | 信号 | 是真需求吗 |
|---|---|---|---|
| L1 | 痛点 | 抱怨、吐槽、绕路操作 | 必要不充分 |
| L2 | 愿望 | "要是有…就好了" | 必要不充分 |
| L3 | 付费意愿 | 掏钱、留邮箱、愿意花时间学 | 是 |
没有 L3 的需求，都是情绪。 用户说"我想要"的时候，你脑子里要自动翻译成"他此刻有点不爽"。仅此而已。
关于"代价"，要特别强调——代价不只是钱。掏钱是最硬的代价，但以下三种实际行动同样算"付出代价"，强度依次递减：
代价强度阶梯：
1. 已掏钱 — 最硬，已经用真金白银投票
2. 花时间学 / 迁移 — 愿意付出学习成本、改变既有流程
3. 留资（邮箱/手机）— 愿意被联系，付出注意力与隐私
4. 口头说想要 — 几乎不算代价，随时会忘很多独立开发者栽在"用户明明说很想要"上，就是没分清第 4 档和第 1 档。一个判别小动作：让用户先付 ¥1 或留个邮箱再给试用。这一步能过滤掉 80% 的"口头想要"。第06章会把这套最小验证讲透。
举个三层过滤的实例。某高校行政老师抱怨："这些数据每年都要手动汇总，太麻烦了。"
L1 痛点 ✓ "每年手动汇总，烦"（确有不舒服）
L2 愿望 ✓ "要是有个自动工具就好了"（确有想要更好）
L3 代价 ✗ 一年才一次，且问"¥99 愿意吗"→ 犹豫（不愿掏钱）L3 不成立 → 这是 Want，不是真需求。做成产品，获客成本永远摊不平。正确动作：要么换高频场景（比如把"汇总"扩到月报），要么直接砍，不投入开发。
这也是呼应第01章公式二的**「范围」环**——范围不是"我想做什么"，而是"有人愿意为什么付代价"。没有真需求，范围从源头就错了，后面实现 / 验证 / 验收三环做得再漂亮，也是在给一个不存在的东西打补丁，闭环必然烂尾。理解这一点后，本章其余都在回答一个问题：怎么把伪需求在三分钟内筛掉，只留下真需求。
2.2 需求 / 想法 / 功能：定位与边界
日常语境里这三个词被混着用，但它们来自完全不同的地方，验证方式也完全不同。
三者差异
| 维度 | 想法（Idea） | 功能（Feature） | 需求（Need） |
|---|---|---|---|
| 来源 | 你的脑子里 | 解决方案的某个零件 | 用户的痛点 + 付费意愿 |
| 形态 | "做个 X 吧" | "加个导出 PDF 按钮" | "有人愿为 Y 付代价" |
| 验证方式 | 拍脑袋 | 看能不能做出来 | 看有没有人掏钱 / 花时间 |
| 数量 | 无限多 | 无限多 | 极少 |
| 典型陷阱 | 把想法当需求 | 把功能当需求 | —— |
能做什么
- 想法用来发散——Brainstorming 阶段越多越好，但只作为原料，不作决策依据。
- 功能用来实现——它是需求被翻译成产品后的具体形态，是手段不是目的。
- 需求用来决策——它决定你做不做、做给谁、收不收钱。
不能做什么（边界）
- 想法不能直接进排期——它连"是不是有人要"都没回答。
- 功能不能倒推需求——"我加了这个功能，用户应该会喜欢吧"是赌博，不是工程。
- 需求不能凭你一个人定义——你自己不是用户，你的"想要"权重为零（见 2.7 死法二）。
铁律：一句话分清三者——想法问"做什么"，功能问"怎么做"，需求问"为谁、值不值"。先答需求，再谈功能和想法。
一个常见的混淆场景：客户说"我要一个能导出 PDF 的报表系统"。这句话里同时藏着三层——"做个报表系统"是想法，"导出 PDF"是功能，"为什么需要 PDF、给谁看、多久一次"才是需求。错误的反应是立刻评估技术栈、画原型；正确的反应是回到 2.4，先挖出 JTBD。90% 的烂尾项目，都是在这一步把功能听成了需求。
2.3 真需求三判据：高频 × 痛 × 愿付费
把 2.1 的三层定义翻译成三个可操作的判据。一个候选需求，三个都过，才是真需求；任何一个不过，就是伪需求。
候选需求
│
┌──────────┼──────────┐
▼ ▼ ▼
高频？ 痛？ 愿付费？
(多久遇一次)(多想解决) (掏钱的实际行动)
│ │ │
每天/每周 主动抱怨 已付费/留资/愿学
↓ ↓ ↓
过 过 过
└──────────┴──────────┘
│
三项全过 → 真需求
任一不过 → 伪需求（降级或砍掉）2.3.1 高频：多久遇一次
痛点必须反复出现才有商业价值。一生一次的痛点（结婚、买房、换国籍）不是不能做，但不适合一人公司——获客成本太高，复购为零。
- 每天 / 每周：高频，优先级最高。
- 每月：中频，可做但要注意留存。
- 每年一次 / 一生一次：低频，除非客单价极高，否则砍掉。
2.3.2 痛：多想解决
光高频还不够——刷牙是高频，但没人在乎。痛度的判别信号：
- 用户主动抱怨、找替代方案、自己用 Excel / 脚本绕路解决。
- 用户为了解决它愿意改变现有行为（装新软件、学新流程、迁移数据）。
被动忍受、随口一提、听完就忘的，痛度不够。
2.3.3 愿付费：掏钱的实际行动
这是三判据里唯一的硬指标。"我会用"不等于"我会买"。付费意愿的验证梯度：
强 ←──────────────────────────────→ 弱
已掏钱 预付款 留资 愿学 说"想要" 无反应越靠左越真。口头说"想要"位于倒数第二档，几乎不算证据。 第06章会专门讲怎么用最小成本验证付费意愿。
铁律：三判据是 AND 不是 OR。高频但没人付费，是慈善不是生意；愿付费但一年才一次，是项目不是产品；又痛又愿付费但一周才遇到一次，规模天花板很低。
2.4 需求冰山模型：表面诉求 vs 底层任务
用户告诉你的，永远是冰山一角。真需求藏在水面下。
▲
│ "我想要个 XX 功能" ← 表面诉求（Solution-side）
水面 ──┤ ─────────────────────
│ "我想完成 YY 这件事" ← 底层任务（JTBD）
│ "因为 ZZ" ← 动机
▼**JTBD（Jobs To Be Done，待办任务）**理论的核心一句话：用户不是买钻头，是买墙上的洞。 用户提的功能（钻头）是他自己瞎猜的解决方案，你的任务是挖出他想完成的任务（洞），再判断这个任务值不值得做、有没有更好的解法。
把诉求翻译成任务的例子
| 用户原话（诉求） | 翻译成任务（JTBD） | 可能的更好解法 |
|---|---|---|
| "我想要个 Markdown 编辑器" | "我想把笔记快速整理成可分享的文档" | 也许他需要一键导出工具，而不是又一个编辑器 |
| "加个数据导出 Excel" | "我想把这份报表交给老板看" | 也许他需要自动周报邮件，而不是导出按钮 |
| "做个 CLI 工具" | "我想在服务器上批量处理这些文件" | 也许他需要 Web 面板，CLI 他根本不会装 |
翻译的方法只有一个：连问 5 次"为什么"（5 Whys）。每次用户给你一个诉求，问"为什么需要它"，连续 5 次，你会从功能层一路挖到任务层和动机层。
一个完整的 5 Whys 推演实例。用户原话："我想要个支持 Markdown 的笔记 App。"
Q1 为什么想要 Markdown App？
A "因为我想把会议纪要快速整理成可分享的格式"
→ 任务层浮现：整理会议纪要
Q2 为什么是"快速整理"？
A "因为每次会议后都要花半小时排版，领导催得急"
→ 痛点量化：每次 30 分钟、有外部压力
Q3 为什么领导催得急？
A "因为他要拿纪要去对接其他部门，迟了会卡流程"
→ 动机层：纪要是跨部门协作的输入
Q4 为什么不用现有的 Word / 飞书？
A "用了，但格式转换和分发太繁琐，多端同步也卡"
→ 现有解法的具体短板
Q5 如果有个工具能"会议录音 → 自动出可分发纪要"，你愿意付多少？
A "¥30/月愿意，省的时间值"
→ 付费意愿落地 → 真需求确认挖到这一层，你发现用户要的根本不是"又一个 Markdown App"，而是**"会议录音到可分发纪要"的自动闭环**——这是一个完全不同的产品，竞争也少得多。如果你停在 Q1 就去做 Markdown 编辑器，等于跳进红海还不知道为什么淹死。
铁律：用户给你的是答案（功能），你要的是问题（任务）。永远不要在用户给的答案上做产品，要把答案翻译回问题，再重新求解。
2.5 实战：用三判据筛掉伪需求
把 2.3 的三判据做成一张可勾选的筛选清单。任何一个候选需求，先过这张表。
步骤一：把候选需求列成清单
候选需求清单（每行一个，写成任务而非功能）：
1. _____________________________________________
2. _____________________________________________
3. _____________________________________________
4. _____________________________________________
5. _____________________________________________写得越像功能（"做个 XX"）的，越要回头用 2.4 的 5 Whys 翻译成任务再填。
步骤二：逐个过三判据筛选表
┌──────┬────────────┬────────────┬────────────┬─────────┐
│ 编号 │ 高频？ │ 痛？ │ 愿付费？ │ 结论 │
├──────┼────────────┼────────────┼────────────┼─────────┤
│ 1 │ □日 □周 │ □主动抱怨 │ □已付费 │ 真需求 │
│ │ □月 □年 │ □自己绕路 │ □留资 │ / │
│ │ □一生 │ □改变行为 │ □愿学 │ 伪需求 │
│ │ │ □随口一提 │ □仅口头 │ │
└──────┴────────────┴────────────┴────────────┴─────────┘三列都勾到上半区（日 / 周 + 主动抱怨 / 自己绕路 / 改变行为 + 已付费 / 留资 / 愿学）→ 真需求。任意一列落到下半区 → 伪需求，降级处理或砍掉。
下面是一张已填好的实例，演示同一份候选清单筛完的样子：
┌──────┬────────────┬────────────┬────────────┬──────────┐
│ 编号 │ 高频？ │ 痛？ │ 愿付费？ │ 结论 │
├──────┼────────────┼────────────┼────────────┼──────────┤
│ 1 │ ■周 │ ■主动抱怨 │ ■已付费 │ 真需求 │
│ │ (每周对账) │ (自己写脚本)│ (买过同类) │ → 排期 │
├──────┼────────────┼────────────┼────────────┼──────────┤
│ 2 │ ■月 │ ■自己绕路 │ □仅口头 │ 伪需求 │
│ │ (月度报表) │ (用 Excel) │ │ → 砍 │
├──────┼────────────┼────────────┼────────────┼──────────┤
│ 3 │ □一生 │ ■主动抱怨 │ □仅口头 │ 伪需求 │
│ │ (毕业论文) │ │ │ → 砍 │
└──────┴────────────┴────────────┴────────────┴──────────┘注意 2 号——痛和高频都够，但卡在付费意愿。这时不要直接砍，先做一步：把它降级到观察列表，两周后回访那位用户是否还在用 Excel 绕路。绕路行为持续存在 + 付费意愿被激活，再捞回真需求池。3 号"一生一次"即使痛也直接砍，一人公司养不起。
步骤三：对真需求排序
通过筛选的真需求，按 (高频 × 痛 × 愿付费) 综合分排序，只取第一个进入下一章的验证（第06章）和文档化（第07章）。
一人公司一次只做一个需求（呼应第01章 1.5 节"一次只补一块"）。筛出三个真需求，挑一个最痛、最高频、最愿付费的，剩下两个进 backlog，不要并行。
验证：筛完之后，你的候选清单应该至少砍掉 70%。如果一个都没砍掉，说明你不是在筛需求，是在给自己打气——重做步骤二，对"愿付费"一列从严。
失败边界（筛选失真排查）：
| 症状 | 根因 | 处理 |
|---|---|---|
| 一个都没砍 | 自评放水，把"口头想要"当付费意愿 | 强制要求"已付费"或"留资"证据 |
| 全是高频但都不付费 | 你筛的是自己想象的需求 | 回到用户那里做访谈（第05章） |
| 筛完不知道做哪个 | 三判据打分一样 | 加一道排序：哪个痛度最高做哪个 |
2.6「需求」vs「想要」vs「需要」：分工与选型
这三个中文词在产品语境里经常打架，先把它们的分工定死。
| 维度 | 想要（Want） | 需要（Need） | 需求（Demand） |
|---|---|---|---|
| 主语 | 用户的口 | 用户的痛点 | 用户的钱包 × 行动 |
| 信号 | 说出来 | 应该有 | 已掏钱 |
| 来源 | 情绪 / 欲望 | 痛点推导 | 付费验证 |
| 你该不该信 | 信 10% | 信 50% | 信 100% |
| 对应英文 | Want | Need | Effective Demand |
决策树：
用户说"我想要 X"
│
├─ 问他"愿意付多少" → 沉默 / 还价 → 这是 Want，归档观察
│
├─ 他反复遇到、自己绕路 → 这是 Need，候选
│
└─ 他已经为同类方案付过费 → 这是 Demand，立刻排期选型规则：只对 Demand 做产品，把 Need 放进观察列表，把 Want 直接忽略。一人公司资源极其有限，把精力花在 Want 上是最大的浪费。
一个完整的分级实例。你做技术调研，听到三个信号：
信号 A："你这工具看着不错"（点赞，没下文） → Want，归档
信号 B："我们部门每周都被这事卡，自己写脚本绕" → Need，候选
信号 C："之前买过 XX 软件 ¥500/年，太难用退了" → Demand，立刻排期A 是社交礼貌，权重接近零。B 暴露了痛点和绕路行为，但没验证付费，放进观察列表，两周后回访。C 已经用真金白银投过票——他不是"可能需要"，是"已经在付费找方案"，只是现有方案不够好。抢 Demand 用户的成本，远低于教育 Want 用户，因为前者已经完成了"愿付费"的市场教育，你只需要证明"比他现在用的更好"。
分级的核心收益是专注：一人公司最大的敌人不是没有需求，是同时追五个 Want、一个都没做透。
2.7 失败边界：三种最常见的死法
死法一：把功能当需求
症状：需求文档第一句就是"做一个带 XX 功能的 YY 系统"。还没搞清为谁、解决什么痛，就开始画原型。
根因：跳过了 2.4 的冰山翻译，直接在用户给的表面诉求（功能）上开工。等于别人说"我想要个钻头"，你就去造钻头，根本没问他是要在墙上打洞还是在木头上拧螺丝。
对抗：任何需求文档，第一段必须先写 JTBD 句式——"（谁）在（什么场景下）想要完成（什么任务），因为（什么动机）"。写不出这一句，说明你还不知道需求是什么，不许进入实现环节。这是呼应第01章公式二的「范围」环——范围的第一句话必须是任务，不是功能。
死法二：把自己的想要当用户需求
症状：你觉得"这个功能太酷了，用户一定喜欢"，做了三个月上线，无人问津。
根因：你把自己当成了用户。开发者 / 信息化从业者的工具偏好、技术审美、付费习惯，和真实用户几乎不重合。你喜欢 CLI，用户要 GUI；你觉得订阅合理，用户只想一次性买断；你不在乎广告，用户被一个 banner 就劝退。
对抗：在产品决策里，你自己的"想要"权重为零。每个决策点都要问"这是用户的需求，还是我的偏好？"分不清的时候，默认是后者。第05章的用户访谈会给你一套系统方法绕开自己的偏见。
死法三：把低频当高频
症状：痛点确实存在，用户也确实愿付费，但一个人一辈子只遇到一两次。你做出来了，卖了第一波，然后……没有第二波。
根因：三判据的"高频"一列失守。没区分"市场高频"（很多人各遇几次）和"个人高频"（一个人遇很多次）。一生一次的痛点做出来，获客成本永远摊不平。
对抗：用市场总频次而非个人频次评估。判断公式：
市场总频次 = 目标用户数 × 单用户年遇到次数这个数要大到支撑你的获客成本。一人公司的安全线是目标用户至少每年遇到 ≥12 次（约每月一次）。低于这个数，要么换细分市场，要么提高客单价，要么砍掉。
红线边界：不可让渡的决策
- "这是不是真需求"：即便用 AI 帮你跑筛选清单、做访谈摘要，最终的"做 / 不做"判断必须人审。AI 会把"口头想要"误读成 Demand，你必须兜底。
- "做哪一个"：AI 可以给排序建议，但一人公司一次只做一个，这个选择必须你定——它决定你接下来三个月的时间分配。
- "砍掉哪一个"：砍需求比加需求更难，AI 倾向于"都留着看看"，你必须敢于砍。
这三件事，是呼应第01章公式二「范围」环的核心——范围的本质是取舍，取舍的本质是判断真需求。把取舍交给 AI，就是把公司的方向盘交出去。
2.8 小结 / 核心心法
需求 ≠ 想法 ≠ 功能。真需求只有一个判据：有人愿意为解决某个痛点付出代价。其他都是情绪。
- 需求三层定义：痛点（不舒服）→ 愿望（想要更好）→ 付费意愿（愿意掏钱 / 花时间）。只有第三层成立，才是真需求。
- 三判据 AND 关系：高频 × 痛 × 愿付费，任一不过即伪需求。
- 冰山模型：用户给你的是功能（答案），你要挖出任务（问题），用 5 Whys 翻译。
- 想要 / 需要 / 需求分级：只对"已掏钱"的 Demand 做产品，Want 直接忽略。
- 呼应第01章公式二：没有真需求，「范围」环从源头就错了，后面三环做得再好也是烂尾。
执行清单（每个候选需求过一遍）：
- [ ] 我能用 JTBD 句式（谁 / 场景 / 任务 / 动机）写出这个需求吗？
- [ ] 高频：目标用户至少每月遇到一次（市场总频次够大）？
- [ ] 痛：用户主动抱怨 / 自己绕路解决 / 愿改变行为？
- [ ] 愿付费：有"已付费"或"留资"的实际证据（不是口头说想要）？
- [ ] 三判据三项全过？任一项落下半区就降级或砍掉。
- [ ] 这是我（开发者）的想要，还是用户的真需求？分不清默认是前者。
- [ ] 筛完后候选清单至少砍掉 70%？没砍说明自评放水，重筛。
上一章：第01章 三个工程化公式 下一章：第03章 你是编排者，不是执行者