01 · 用户洞察：把"用户"从抽象概念变成可讨论的具体人
"在此之前，我一直认为保持好成绩最重要，而好成绩主要靠理论课程。但十字路口坐三个小时才是真正的设计思维——通过观察和思考去发现问题。"
—— 李泽湘，回忆 1979 年卡耐基梅隆大学的一份作业
99% 的创业失败，不是死于"产品做得不好"，而是死于**"做出来的东西根本没人要"**。Paul Graham 把这种情况浓缩成一句格言：
"Don't make something people don't want."
用户洞察的全部目的，就是在你写第一行代码、画第一张图纸之前，先验证"是否有人在乎这件事"。
本模块覆盖 6 个核心工具，从"找 idea"到"理解用户的任务"依次展开：
| 顺序 | 工具 | 颗粒度 | 何时用 |
|---|---|---|---|
| 1 | 怎么找到创业 idea | 一个待解决的问题 | 最先用——还没 idea 或想验证 idea 方向时 |
| 2 | 用户画像 Persona | 一群人 | 项目启动时，对齐团队对"用户是谁"的认知 |
| 3 | 同理心地图 Empathy Map | 一个人 × 一个时刻 | 30 分钟快速对齐某个具体场景 |
| 4 | 用户访谈 5 问法 | 一个人 × 深度 | 想挖掘真实痛点时 |
| 5 | 用户旅程地图 Journey Map | 一个人 × 一段时间 | 想找痛点峰值、优化体验时 |
| 6 | JTBD | 一个人 × 一个任务 | 想理解"为什么雇佣这个产品"时 |
工具一：怎么找到创业 idea
"The way to get startup ideas is not to try to think of startup ideas. It's to look for problems."
—— Paul Graham, How to Get Startup Ideas (2012)
"通过观察和思考去发现问题。"
—— 李泽湘，1979 年卡耐基梅隆大学作业后的领悟
是什么
"找 idea"本身就是一个工具——不是坐在房间里 brainstorm，而是一套系统的问题发现与筛选方法。
两种找 idea 的核心范式：
| 范式 | 来源 | 核心操作 | 适合 |
|---|---|---|---|
| 从自身不满出发 | PG "live in the future, build what's missing" | 审视自己生活中"为什么这东西这么难用"的时刻 | 软件/SaaS 创业 |
| 从场景观察出发 | 李泽湘"十字路口观察法""场景驱动创新" | 到真实场景中观察人的行为，发现"不合理" | 硬件/硬科技创业 |
两种范式底层逻辑一致：idea 不是"想"出来的，是"看到"的。 区别只在观察对象——是观察自己，还是观察别人。
为什么用
创业者最常犯的两个错误：
- "sitcom idea"（PG 术语）：想一个听起来像创业 idea 的 idea——"Uber for X""Airbnb for Y"——但没有真实问题支撑
- "技术找问题"：先有了一个技术/能力，然后去找能用它的场景——李泽湘反复警告的"自嗨式创新"
PG："Why do so many founders build things no one wants? Because they start by trying to think of startup ideas."
李泽湘："大多数工程师都认为自己能做出更好的 iPhone，但他们从没问过用户：你还需要一个更好的 iPhone 吗？"
用这套方法的直接收益：
- 不做 sitcom idea——每个 idea 都有真实问题锚点
- 不做自嗨——场景驱动迫使你面对真实世界的约束
- 筛掉 90% 的伪 idea——用筛选框架在动手前淘汰
怎么用
阶段一：收集问题（两种路径，选一个开始）
路径 A：从自身不满出发（PG 法）
- 列"不满清单"：过去一个月里，什么东西让你觉得"这破玩意怎么这么难用"？写出 20 条。
- 问"为什么还没人解决"：是技术不成熟？是市场太小？是被大公司忽略？还是所有人都忍了？（第三个答案往往是机会）
- 识别"schlep"：有没有什么事是你觉得"太麻烦所以不想碰"的？——那很可能是你的创业 idea（见 04 模块 Schlep Blindness）
路径 B：从场景观察出发（李泽湘法）
- 选一个场景：医院 ICU、工厂产线、菜鸟驿站、学校食堂——任何有密集人类行为的地方
- 坐三个小时（十字路口观察法）：不带预设，只记录"什么人在做什么事、遇到了什么阻碍"
- 标出"不合理"：哪些行为看起来低效、痛苦、荒谬？哪些流程明显可以被科技改善？
- 追问"为什么还在这样"：是惯性？是法规？是成本？是没有人想过可以不一样？
软件创业偏向路径 A；硬件创业偏向路径 B。但两者都需要——PG 也说要"look for things that seem broken in the world"，李泽湘也要求学生"先把自己的生活当作观察对象"。
阶段二：筛选 idea（PG + YC 4 问）
收集到 10-20 个问题后，用 4 个问题筛：
| 问题 | 好 idea 的特征 | 坏 idea 的信号 | 来源 |
|---|---|---|---|
| 1. Founder/Market Fit | 你是解决这个问题的最佳人选——你有独特的 insight | "这个市场很大，我找个 co-founder 就能做" | PG |
| 2. 这个问题有多痛？ | 用户已经在用拙劣的办法自己解决了（手工 Excel、微信群、3D 打印的土装置） | 用户说"有点烦"但不会为解决方案付费 | YC |
| 3. 市场是新的吗？ | 一个新平台/新技术刚出现，还没人想过怎么用 | "这是一个成熟的 $50B 市场"（你没机会） | PG |
| 4. 你能描述一个具体用户吗？ | 能说出"Sarah 在 XX 场景下被这个问题折磨" | 只能说"目标用户群 25-35 岁" | 李泽湘 |
关键原则：好的 idea 在初期往往看起来像玩具或太小。 PG："The best startup ideas tend to do something that seems minor or trivial at first, but turns out to be important."
Airbnb 的 idea 在 2008 年看起来像"给沙发客用的 Craigslist"；大疆的 idea 在 2006 年看起来像"极客玩具"；Stripe 的 idea 在 2010 年看起来像"几行代码就能搞定的事"。
补充：YC 的五种不公平优势（5 Unfair Advantages）
通过 4 问筛选后，还有一个 YC 内部的评估维度——你的 idea 有没有至少一种"不公平优势"？
YC 合伙人 Kevin Hale 在 Startup School 中提出，能成为 $1B 公司的 idea，至少要占以下五种不公平优势之一：
| # | 不公平优势 | 含义 | 例子 | 如何判断你有没有 |
|---|---|---|---|---|
| 1 | 创始人独特优势 | 你是全球能解决这个问题的前 10 人之一 | Patrick Collison 兄弟自己就是支付开发者，被支付接口折磨过 | "为什么是你而不是别人？"——能不能说出一个别人说不出的 insight |
| 2 | 市场自然增长 20%+ | 你在一个高速增长的市场上——水涨船高 | AI 应用 2024-2025 年本身就是暴涨的市场 | 最弱的不公平优势——因为谁都能进入 |
| 3 | 产品 10 倍更好 | 你做的产品不是"好 20%"，而是"好 10 倍"——让用户无法拒绝 | Stripe：几行代码 vs. 几周银行对接 | 2-3 倍好不够——"slam dunk"需要 10 倍 |
| 4 | 获客模式独特 | 你有零成本、可持续、病毒式的获客方式 | Dropbox 的 referral program（双倍空间） | "用户会不会主动推荐给别人？" |
| 5 | 垄断动力学 | 你的模式有网络效应、或者 winner-takes-all 特征 | Airbnb：房源越多→租客越多→更多房东加入 | "规模变大后，产品会不会变得更好？" |
怎么用这个框架：把你筛出来的 idea 对着这五种优势各打一个分（有/模糊/没有）。如果一个都没有——这个 idea 可能是一个好生意，但不太可能成为 VC-backed 的 $1B 公司。
YC 在审申请书时的核心心态不是"找这个 idea 有什么问题"，而是"想象这个 idea 怎么才能变成一个 $1B 公司"——五种不公平优势就是他们的想象框架。
阶段三：轻量验证（决定要不要进下一步）
筛选出 1-3 个候选 idea 后，用最小的代价验证问题是否真实：
软件路径：
- 找 5 个目标用户聊（用本模块的用户访谈 5 问法）
- 核心问题："你现在怎么解决这个问题的？"
- 如果大部分人说"其实还好，不太困扰"——毙掉
硬件路径：
- 到目标场景实地观察 3 次以上
- 核心观察：用户现在的土办法是什么样的？他们为此花了多少钱/多少时间？
- 如果"土办法"看起来已经够用了——重新考虑
案例：YC 历史上最好的 idea 都"不像正经 idea"
PG 在 2012 年 essay 中举的例子：
| 公司 | 当时的想法 | 为什么"不像正经 idea" | 结果 |
|---|---|---|---|
| Airbnb | 陌生人睡你家气垫床 | 不安全、不专业、没人会用 | $100B+ |
| Stripe | 几行支付代码 | "支付已经是 solved problem" | $70B+ |
| Dropbox | 又一个网盘 | "已经有 20 个网盘产品了" | $10B（被收购） |
| Flexport | 货代软件 | "货运？那不是打电话就行？" | $8B |
这些 idea 的共同点：创始人有独特的 insight（Airbnb 的 Chesky 自己当过气垫床房东，Stripe 的 Collison 兄弟自己写支付代码被折磨过），而且目标市场在当时看起来"太小"。
案例：李泽湘体系的"场景驱动"idea
李泽湘体系孵化的公司，idea 几乎全部来自场景观察，而非技术想象：
| 公司 | 观察到的场景 | 发现的"不合理" | idea |
|---|---|---|---|
| 云鲸 | 用户拖地要先扫后拖，拖布要手洗 | "为什么扫地机器人不能自己洗拖布？" | 自清洁扫拖机器人 |
| 海柔创新 | 仓库工人每天走 20 公里取货 | "为什么是'人找货'而不是'货到人'？" | 箱式仓储机器人 |
| 正浩创新 | 户外露营发电机噪音大、加油烦 | "为什么户外用电一定要燃油发电机？" | 便携储能电源 |
| 希迪智驾 | 矿区司机招不到、事故率高 | "年轻人不愿下矿，为什么不让车自己开？" | 矿山自动驾驶 |
这些 idea 的共同逻辑：创始人不是"想了一个好点子"，而是在一个真实场景里看到了"这种不合理居然还在发生"。
软件 vs 硬件：找 idea 的关键区别
| 维度 | 软件创业 | 硬件创业 |
|---|---|---|
| 观察对象 | 你自己的行为、"为什么这软件这么难用" | 别人的行为、"为什么这个场景还长这样" |
| 问题来源 | 自身的痛（dogfooding） | 场景的痛（沉浸式观察） |
| 验证方式 | 找人聊（5 个访谈就能判断） | 实地看（至少 3 次现场观察） |
| 假阳性风险 | "我自己觉得需要"→ 只代表程序员 | "我觉得他们需要"→ 自我投射 |
| 假阴性风险 | "好像已经有人做了"→ 放弃太早 | "这个太难做了"→ schlep blindness |
| 好 idea 的信号 | 你已经在用手动 workaround 了 | 用户在用自己的"土办法"解决了 |
| 代表案例 | Stripe、Notion、Linear | 大疆、云鲸、海柔创新 |
共同点：如果用户不为当前解决方案感到痛苦，你的产品就没人买单。 两者都必须在"阶段三：轻量验证"里确认痛的真实性。
常见误区
| 误区 | 表现 | 为什么错 |
|---|---|---|
| 等一个"伟大的 idea" | 焦虑："我还没想出那个改变世界的 idea" | 伟大的 idea 一开始都不像——先从小问题开始 |
| 技术驱动 | "我会 NLP/RL/大模型，我该做什么产品？" | 拿着锤子找钉子——李泽湘：这是最危险的创业路径 |
| 市场报告驱动 | "Gartner 说 XX 市场到 2030 年有 $500B" | 大市场 = 大竞争。新市场小 market 才是你的机会 |
| 怕别人偷 idea | 不肯跟人聊自己的 idea | PG："你最大的风险不是被人偷 idea，是做出来没人要" |
| 只观察自己 | 一个软件工程师以为所有人的问题都是软件问题 | 你的体验可能只代表极少数人 |
| 攒太多 idea 不行动 | 记了 50 个 idea 但一个都没验证 | idea 不值钱——筛完就要动手验证 |
与其他工具的关系
- 直接下游：本模块的用户访谈 5 问法——用 5 问验证 idea 的阶段三问题
- 间接下游：02 · 精益画布——把筛选后的 idea 拆成 9 个假设
- 思维工具关联：Schlep Blindness——识别被你心理性回避的问题
- 相反视角：第一性原理——当你有了 idea 后，用它重新推演一遍"这事到底值不值得做"
一句话：idea 不是想出来的——是看出来的（李泽湘）、是活出来的（PG）、是筛出来的（YC 4 问）。然后在 5 个访谈里验证它值不值得继续。
工具二：用户画像（Persona）
是什么
用户画像（Persona） 是一个虚构的具体用户——有名字、有年龄、有职业、有照片、有偏好、有恐惧。它不是"25-35 岁都市白领女性"这种统计描述，而是"Sarah，32 岁，在一家广告公司做客户总监，每天通勤 1.5 小时，最近在备孕……"。
为什么用
核心问题：团队里 5 个人讨论"用户要什么"时，每个人脑子里的"用户"是不同的人。
| 没有画像 | 有画像 |
|---|---|
| 产品经理说"用户要简洁" | 产品经理说"Sarah 这种通勤 1.5 小时的人要简洁" |
| 工程师说"用户要功能" | 工程师说"Sarah 不会用这个功能" |
| 设计师说"用户要美观" | 设计师说"Sarah 会在地铁单手操作，按钮要够大" |
画像的作用是把"用户"从一个抽象名词，变成一个可以指名道姓讨论的具体人。
怎么用
步骤 1：基于真实访谈，不要凭空捏造
画像不是写小说。先做 5-10 个真实用户访谈，再从访谈中抽象出 1-3 个画像。
Alan Cooper（"Persona"概念的提出者）在 1999 年《The Inmates Are Running the Asylum》中强调：画像是基于真实数据的合成人物，不是想象。
步骤 2：填这个模板
## Persona：[名字]
**照片**：（贴一张代表性照片，不要用明星照，用 unsplash 上的普通人）
### 基本信息
- 年龄：__
- 职业：__
- 地理位置：__
- 收入区间：__
- 家庭状况：__
### 一天的生活（典型工作日）
（用 5-8 句话描述她一天的关键场景）
### 与本产品相关的痛点
1. __（最痛的那个）
2. __
3. __
### 当前解决方案
（她现在怎么解决这个问题？为什么不够好？）
### 目标与动机
（她想达成什么？为什么这件事对她重要？）
### 恐惧与障碍
（她害怕什么？什么会让她放弃使用？）
### 关键引言
"__"（一句她在访谈中说的原话，最能代表她的状态）
步骤 3：团队对齐
把画像打印出来贴在办公室墙上。所有产品决策都要回答："这对 Sarah 有什么用？"
案例：李泽湘体系的"偏执学生"
李泽湘在描述他筛选创业者的标准时，反复强调"激情 + 热爱"——这本质上就是一个 Persona：
汪滔（大疆创始人）的 Persona 简化版：
- 年龄：24 岁（2006 年创业时）
- 背景：港科大电子工程本科生，毕业设计只拿了 C
- 痛点：市面上的直升机飞控系统都是欧美进口，价格贵、不开放、不适合二次开发
- 当前解决方案：自己用开源代码改，但缺乏硬件供应链支持
- 目标：做出中国人自己的、能让极客玩的飞控
- 关键特质：偏执——"李泽湘说他是我学生里最偏执的一个"
- 关键引言：（汪滔 2006 年给李泽湘的邮件）"教授，我想做直升机飞控，能不能借我一点钱？"
李泽湘的所有后续决策——招他读研、提供启动资金、对接深圳供应链、任董事长——都是基于这个 Persona 的延伸。
案例：YC 的"反 Persona"原则
注意 YC 在申请表中不收推荐信、不看学历，看似与 Persona 矛盾。其实 YC 的逻辑是：
不要在筛选前预设 Persona，要在筛选后从行为中识别 Persona。
YC 的"反精英主义精英主义"——能在 10 分钟内 demo 一个原型的人，本身就是一种 Persona（"hacker 型创始人"）。
常见误区
| 误区 | 表现 | 后果 |
|---|---|---|
| 统计型画像 | "25-35 岁女性" | 没用——这是市场细分，不是画像 |
| 明星画像 | "高净值白领女性" | 团队无法具象讨论 |
| 太多画像 | 一次画 8 个 | 注意力分散，无法对齐 |
| 不基于访谈 | 在房间里凭空写 | 纯属自我投射 |
| 画像写完就忘 | 放进 PPT 不再回顾 | 丧失对齐功能 |
正确数量：1-3 个。早期创业公司最多服务 3 类用户，多了就是没聚焦。
与其他工具的关系
- 上游：用户访谈（画像的输入）
- 下游：同理心地图（把 Persona 的某个场景放大）、用户旅程地图（基于 Persona 画时间线）、VPC（Persona 是 VPC 右半边的"客户画像"）
工具三：同理心地图（Empathy Map）
是什么
同理心地图是 XPLANE 的 Dave Gray 发明的工具，被 Stanford d.school 纳入设计思维核心工具箱。它用一张 2×2 的方格，画出某个用户在某个具体时刻的 6 个维度。
┌──────────────────────┬──────────────────────┐
│ │ │
│ 1. 在想什么？ │ 2. 在听什么？ │
│ (THINK) │ (HEAR) │
│ │ │
├──────────────────────┼──────────────────────┤
│ │ │
│ 3. 在看什么？ │ 4. 在说什么/做 │
│ (SEE) │ 什么？ │
│ │ (SAY / DO) │
│ │ │
├──────────────────────┴──────────────────────┤
│ │
│ 5. 痛点（PAIN） 6. 收益（GAIN） │
│ │
└────────────────────────────────────────────┘
为什么用
Persona 是"她是谁"，Empathy Map 是"她在某个时刻经历了什么"。
Persona 颗粒度太粗，无法回答"Sarah 第一次打开我们的 App 时，她在想什么？"——这种具体问题需要 Empathy Map。
Empathy Map 是设计思维的"30 分钟 MVP"——它不需要访谈、不需要数据，只需要团队 30 分钟讨论，就能产生惊人的洞察。
怎么用
步骤 1：选一个具体场景
不是"Sarah 用我们的产品"，而是"Sarah 在地铁里、单手、用 4G 网络、第一次打开我们的 App"——具体到时刻、地点、设备、状态。
步骤 2：填 6 个格子
1. THINK / FEEL（在想什么 / 在感受什么）
- 她内心真正在想什么？
- 她有什么没说出口的担忧？
- 对她来说什么最重要？
示例：Sarah 打开 App 时可能在想"这玩意儿能不能帮我搞定明天交的广告提案"、"别又是另一个没用的工具"。
2. HEAR（在听什么）
- 她身边的人在说什么？
- 影响她的人（老板、同事、朋友、KOL）在说什么？
- 她接触的媒体在说什么？
3. SEE（在看什么）
- 她的环境是什么样的？
- 她看到的市场上有什么替代品？
- 朋友/同事在用什么？
4. SAY / DO（在说什么、做什么）
- 她公开说的话（可能和内心想的相反）
- 她的实际行为
- 她的态度、外表
5. PAIN（痛点）
- 她最大的恐惧/挫败/障碍是什么？
- 什么会让她失眠？
6. GAIN（收益）
- 她真正想要什么？
- 成功对她来说长什么样？
- 她用什么标准判断"这个东西有用"？
步骤 3：找洞察
填完后问 3 个问题：
- 冲突点：她"想的"和"说的/做的"有没有矛盾？（最有价值的洞察通常在这里）
- 未满足的需求：GAIN 和 PAIN 之间有没有 gap？
- 决策时刻：什么瞬间决定她用还是不用？
案例：Dropbox 的 Empathy Map
Dropbox 创始人 Drew Houston 2007 年在 YC S07 batch。他最初的 Empathy Map（事后回溯）大致是：
| 维度 | 内容 |
|---|---|
| THINK | "我电脑里的文件太多了，每次换设备都丢东西" |
| HEAR | 同事说"用 U 盘啊"、朋友说"用 Google Docs 啊"——但都不解决"同步整个文件夹" |
| SEE | U 盘、邮件附件、FTP、各种云盘雏形 |
| SAY/DO | 反复用 U 盘、给自己发邮件、用 SVN 同步 |
| PAIN | 文件丢失、版本混乱、跨设备切换 |
| GAIN | 一个"装了就忘"的同步——所有文件在所有设备上自动保持最新 |
这个 Empathy Map 直接催生了 Dropbox 的"魔法文件夹"叙事——也解释了为什么 Drew Houston 在 Demo Day 上没有 demo 功能，而是放了一段 3 分钟的"假装在用 Dropbox"的视频。
这就是著名的 Dropbox MVP 视频——用 Empathy Map 找到的洞察，让 Drew 知道用户最在乎的是"自动同步"这个 GAIN，不是"功能丰富"这个表象。
常见误区
| 误区 | 修正 |
|---|---|
| 把 Empathy Map 当 Persona | Persona 是"她是谁"，Empathy Map 是"她在某时刻经历了什么"——必须选具体场景 |
| 团队成员各自填各自的 | 必须一起填——价值在于讨论分歧 |
| 只填 1-2 格 | 6 格都要填，PAIN/GAIN 尤其关键 |
| 填完就归档 | 填完后必须产出 1-2 个"洞察卡片"——作为后续 VPC/Journey Map 的输入 |
与其他工具的关系
- 上游：Persona（确定"哪个用户"）
- 下游：Journey Map（基于 Empathy Map 找到的痛点峰值，画时间线）、VPC（Empathy Map 的 PAIN/GAIN 直接对应 VPC 的 Customer Jobs/Pains/Gains）
工具四：用户访谈 5 问法
是什么
用户访谈 5 问法 是 YC Office Hour 标准问题清单 + 李泽湘"十字路口观察法"的融合。YC 的合作伙伴在面对每个创始人时会问 5 个问题，每天重复 10-20 遍，21 年下来问了几十万遍：
- What：你在干嘛？
- Why：你做这个的逻辑是什么？
- Who cares：谁在乎这个东西？
- Advantage：你的优势在哪？
- Numbers：给我看数据。
李泽湘的方法论补了一个"反向版本"——不要问用户，去看用户（1979 年十字路口观察法）。
为什么用
用户访谈是用户洞察的"基础设施"——Persona、Empathy Map、Journey Map、JTBD、VPC 全部依赖访谈数据。访谈质量决定了所有下游工具的质量。
但 99% 的创业者不会访谈。他们犯的核心错误是：问用户"你想要什么"。
Henry Ford（常被误引但观点成立）："如果我问人们想要什么，他们会说想要一匹更快的马。"
Steve Jobs："人们不知道自己想要什么，直到你展示给他们看。"
Paul Graham："不要问用户想要什么——观察他们在做什么。"
怎么用
步骤 1：确定访谈目的
不是"了解用户"。每次访谈都要有一个具体的假设要验证：
| 错误的访谈目的 | 正确的访谈目的 |
|---|---|
| "了解一下 Sarah 的需求" | "验证 Sarah 是否真的会为'每天节省 30 分钟'付费" |
| "听听用户怎么想" | "找出 Sarah 当前用什么解决这个问题、为什么不够好" |
| "收集反馈" | "测试 Sarah 在看到我们的 landing page 后，能不能在 10 秒内说出我们是干嘛的" |
步骤 2：用 YC 5 问作为骨架
把 YC 问创始人的 5 问反过来——问用户：
| YC 问创始人 | 反过来问用户 |
|---|---|
| What are you doing? | "你最近一次遇到 [问题] 是什么场景？能详细说说吗？" |
| Why? | "你当时为什么选这个方案？考虑过哪些其他方案？" |
| Who cares? | "你身边还有谁也遇到这个问题？他们怎么解决的？" |
| What's your advantage? | "现有方案让你最不满意的是什么？" |
| Show me your numbers. | "你上次为这个问题花了多少时间/钱？" |
这 5 个问题的精髓：
- 不问未来（"你会用我的产品吗？"）——用户对未来的预测都是错的
- 只问过去（"你上次怎么解决的？"）——过去的真实行为才是数据
步骤 3：叠加李泽湘"十字路口观察法"
李泽湘 1979 年在卡耐基梅隆大学的作业——去十字路口坐 3 个小时——本质上是说：
访谈的尽头是观察。
具体做法：
- 不要只听用户怎么说，要看用户怎么做——去用户的真实工作场景（如果是 B2B，去她办公室；如果是 C 端，去她生活的场景）
- 记录工具/工作流：她用了哪些软件？哪些 Excel？哪些微信群？
- 记录环境的"噪音"：她在被打断几次？什么会让她分心？
李泽湘体系的硬件创业尤其重视场景体验——深圳科创学院的训练营第一课，就是要求学员去目标用户的真实场景待一整天。
步骤 4：5 个反偏差技巧
访谈中常见的认知偏差，必须主动对抗：
| 偏差 | 表现 | 对抗方法 |
|---|---|---|
| 社会期望偏差 | 用户说"听起来不错" | 问"上次你为类似产品付费是什么时候" |
| 引导性提问 | "你觉得这个功能好不好？" | 改为"你会怎么用这个功能？" |
| 共识偏差 | 用户附和你的判断 | 故意说错一个观点，看她会不会纠正 |
| 过度自信 | 用户对未来过度乐观 | 问"如果你不用这个，你会失去什么？" |
| 样本偏差 | 只访谈朋友圈的人 | 强制访谈 3 个"反对方"——明确表示不会用的人 |
步骤 5：访谈后的 24 小时内
- 24 小时内整理：记忆会快速衰减
- 找"原话卡片"：每个访谈挑 3-5 句最有价值的原话，单独成卡
- 找"行为证据"：用户做了什么（不是说了什么）——付过费、推荐过、卸载过
案例：Airbnb 早期的"线下扫楼"
Paul Graham 反复讲的经典案例——Airbnb 早期在纽约的房东访谈：
Airbnb 早期房源的照片都是手机随便拍的，质量很差。Brian Chesky 和 Joe Gebbia 听了 PG 的话——"Do things that don't scale"——亲自飞到纽约，挨家挨户敲房东门，用一台价值 $5000 的相机帮房东拍专业照片。
这次"线下扫楼"的本质就是用户访谈 + 场景观察：
- 借拍照的名义进入房东真实场景
- 观察房东如何布置房间（环境数据）
- 听房东抱怨 Airbnb 的哪些功能不好用（访谈数据）
- 看房东的相机/手机型号、网络速度（行为数据）
结果：纽约的房源预订率提升了 2.5 倍。这不是因为照片好看，是因为 Brian 和 Joe 终于"看见"了用户。
案例：李泽湘为什么招汪滔读研
汪滔在港科大的本科毕业设计——无人机飞控系统——演示时出了问题，只拿了 C。按传统标准，这个学生不该被招进研究生。
但李泽湘在汪滔选修的 Robocon 机器人比赛课上观察了他两年：
- 第一年：汪滔拿下香港冠军
- 第二年：汪滔拿下亚太区并列第三名
李泽湘的访谈+观察数据：汪滔在比赛中表现出的偏执、对细节的执着、愿意为一个小问题熬通宵——这些都是成绩单上看不到的"行为证据"。
"他是我学生里最偏执的一个。"——李泽湘
这个判断后来催生了大疆（2025 年市值 1500 亿人民币）。
常见误区
| 误区 | 修正 |
|---|---|
| 一次访谈 10 个人 | 一次访谈 1 个人，深度 1 小时 > 浅度 10 分钟 |
| 访谈团队老大 | 访谈的不是决策者，是实际使用者——决策者说的和实际用的往往是两回事 |
| 只访谈"喜欢我们的人" | 至少 30% 访谈量给"明确拒绝的人"——他们的反馈最值钱 |
| 用问卷替代访谈 | 问卷是验证假设的工具，不是发现洞察的工具——访谈先于问卷 |
| 访谈完不整理 | 24 小时内整理，1 周后访谈数据基本作废 |
与其他工具的关系
- 下游：Persona（基于访谈抽象）、Empathy Map（基于访谈填 6 格）、Journey Map（基于访谈画时间线）、JTBD（基于访谈找 Job）、VPC（基于访谈填右半边）
工具五：用户旅程地图（Customer Journey Map）
是什么
用户旅程地图是一张时间线——把用户与产品/服务的所有触点按时间顺序串起来，标注每个触点的：
- 用户行为（在做什么）
- 用户情绪（高兴/沮丧）
- 痛点峰值（最不爽的瞬间）
- 机会点（可以优化的地方）
时间 →
│ │ │ │ │ │
行为 │认知→│比较→│购买→│使用→│复购→│推荐│
情绪 │😄 │😐 │😡 │😄 │😄 │😍 │
痛点 │ │ │ ▲ │ │ │ │
│ │ │ │ │ │
为什么用
核心问题：你以为是"产品体验问题"的，往往是"用户旅程中的某个触点问题"。
举个例子：用户说"这个 App 不好用"——可能不是 App 本身的问题，而是注册环节让她在 App Store 搜到 → 下载 → 打开 → 注册 → 验证邮件 → 设置密码 这条链路上某个环节断了。
Journey Map 把整条链路摊开，让团队看见全貌。
怎么用
步骤 1：定义旅程的范围
不是"用户和我们的全部关系"——太大。选一个具体旅程：
| 错误的范围 | 正确的范围 |
|---|---|
| "用户和我们产品的关系" | "新用户从首次下载到完成第一次购买的旅程" |
| "用户生命周期" | "现有用户从续费决策到完成支付的旅程" |
步骤 2：列出所有触点
触点 = 用户与产品/品牌接触的任何瞬间。包括：
- 线上：广告、SEO、社交媒体、App Store、官网、注册页、App 内功能、客服、邮件、推送
- 线下：实体店、快递包装、客服电话、口碑推荐
常见错误：只画 App 内的触点。真正的旅程从用户第一次听说你开始——可能在朋友圈看到一条分享，可能在地铁看到广告。
步骤 3：标注每个触点的情绪曲线
情绪
+5 │ 😍 😍
+3 │ 😄 😄 😄
0 │─────────────────────────────
-3 │ 😡
-5 │
└──────────────────────────→ 时间
认知 比较 购买 使用 复购 推荐
情绪曲线的低点（红色区域）就是痛点峰值——这是优化机会最大的地方。
步骤 4：标注机会点
对每个痛点峰值，问 4 个问题：
- 这个痛点的根因是什么？（技术限制？流程设计？信息缺失？）
- 解决这个痛点的成本是多少？
- 解决后能带来多少收益？（提升转化率？降低流失率？）
- 优先级：高/中/低
案例：Slack 的"邀请旅程"
Slack 早期增长最大的瓶颈不是"用过的人不喜欢"，而是**"团队的管理员没有发出邀请"**。
Slack 团队画的旅程地图大致是：
| 阶段 | 用户行为 | 情绪 | 痛点 |
|---|---|---|---|
| 1. 听说 Slack | 朋友推荐 / 阅读 | 😄 好奇 | 不知道和 HipChat 区别 |
| 2. 注册 | 创建 workspace | 😐 顺利 | —— |
| 3. 第一次邀请同事 | 填写邮箱 | 😡 卡住 | "我不知道同事的邮箱"、"为什么要我一个人邀请" |
| 4. 第一次发消息 | 找频道 | 😐 困惑 | 没人回我，不知道发哪里 |
| 5. 第一个 Aha Moment | 收到第一条回复 | 😍 | —— |
| 6. 邀请更多人 | 团队规模扩大 | 😄 | —— |
痛点峰值在第 3 步——邀请同事。Slack 团队基于这个洞察做了大量优化：
- 支持 Google Workspace 一键导入联系人
- 邀请链接生成（不用一个个填邮箱）
- 邀请页面的引导文案改为"Slack 没有同事就不好玩，邀请 3 个以上同事解锁全部功能"
这就是为什么 Slack 的 Aha Moment 是"发够 2000 条消息"——这个数字背后是邀请旅程优化后，团队能真正用起来的临界点。
案例：李泽湘体系的硬件 Journey Map
硬件创业的 Journey Map 与软件不同——必须包括购买前的"研究旅程"和购买后的"售后旅程"，因为硬件的试错成本高、决策周期长。
云鲸扫地机器人的 Journey Map（简化版）：
| 阶段 | 用户行为 | 关键触点 |
|---|---|---|
| 1. 认知 | 抖音/小红书种草 | KOL 真实测评 |
| 2. 研究 | 对比石头、追觅、iRobot | B 站深度评测、京东评论 |
| 3. 决策 | 看到核心差异化（自动洗抹布） | 抖音直播/电商详情页 |
| 4. 购买 | 京东/天猫下单 | 限时折扣、赠品 |
| 5. 收货 | 开箱体验 | 包装设计、说明书 |
| 6. 首次使用 | 安装、配网、第一次扫 | 痛点峰值——配网失败、卡在沙发下 |
| 7. 日常使用 | 自动清洁、定期维护 | 耗材补充、APP 远程控制 |
| 8. 推荐 | 朋友圈/小红书晒单 | UGC 内容 |
云鲸的核心差异化（自动洗抹布）是 Journey Map 第 7 阶段的痛点——传统扫地机器人需要用户手动洗抹布，这是日常使用中的最大摩擦。云鲸把这个摩擦消除后，整个旅程的情绪曲线被拉高了。
常见误区
| 误区 | 修正 |
|---|---|
| 只画软件触点 | 必须包括"听说你"的环节——广告/口碑/SEO |
| 平均用户旅程 | 不同 Persona 有不同旅程——一张图一个 Persona |
| 不标情绪 | 没有情绪曲线的 Journey Map 只是流程图——价值减半 |
| 画完就归档 | Journey Map 是活的——每次大版本更新都要重画 |
与其他工具的关系
- 上游：Persona（确定是谁的旅程）、用户访谈（提供每个触点的数据）
- 下游：痛点峰值 → VPC 的 Pains / 痛点 → 优先级 → 产品路线图
工具六：JTBD（Jobs-to-be-Done）
是什么
JTBD（Jobs-to-be-Done） 是哈佛商学院 Clayton Christensen（《创新者的窘境》作者）在《与运气竞争》（2016）中系统化的理论。
核心观点：用户不是"买产品"，是"雇佣产品来完成某个任务"。
"人们其实不想买一个 1/4 英寸的钻头。他们想要一个 1/4 英寸的洞。"
—— Theodore Levitt（营销学经典名言，JTBD 的思想源头）
为什么用
JTBD 解决的核心问题：竞争定义。
如果你用"产品属性"定义竞争，你的对手是同类产品：
- "我们的扫地机器人对手是石头、追觅、iRobot"
如果你用 JTBD 定义竞争，你的对手是所有完成同一 Job 的方案：
- "我们的 Job 是'让用户每天回家看到干净的地板'——对手包括：扫地机器人、保洁阿姨、吸尘器、甚至'我决定不打扫了'"
JTBD 让你看见更大的市场，也看见更大的威胁。
怎么用
步骤 1：写出 Job Statement
Job Statement 的标准格式：
当 [情境]，我想要 [动作]，以便 [结果]。
关键约束：
- 不要写产品功能（"用 App 扫地"）
- 要写任务目标（"让客厅看起来干净"）
- 要包括情境（"当家里有客人要来"）
| 错误的 Job Statement | 正确的 Job Statement |
|---|---|
| 用 Spotify 听歌 | 当我加班时，我想要听不会让我分心的背景音乐，以便能保持专注 |
| 用滴滴打车 | 当下雨天在郊区，我想要在 5 分钟内坐上车，以便不耽误会议 |
| 用 Slack 沟通 | 当我和远程团队协作，我想要异步沟通不被打断，以便我能专注写代码 |
步骤 2：找"功能性 / 情感性 / 社会性"三层 Job
Christensen 强调 Job 有三层：
| 层次 | 例子（买 LV 包） |
|---|---|
| 功能性 Job | 装东西 |
| 情感性 Job | 让自己感觉成功、被认可 |
| 社会性 Job | 让别人觉得我"有品位"、"有钱" |
只看功能性 Job 会严重低估市场——LV 的市场从来不是"装东西"。
步骤 3：用 Job 重定义竞争
写下你的 Job Statement 后，问：
"用户还能用什么来完成这个 Job？包括非产品方案"
例子——快餐奶昔（Christensen 经典案例）：
某快餐连锁想提升奶昔销量。他们一开始做 Persona 分析——"买奶昔的人是谁？"——没用。
Christensen 团队换了个问题："用户雇佣奶昔来完成什么 Job？"
观察发现：奶昔主要在早上 8 点前被卖给独处的男性，他们开车带走。
Job Statement："当我早上独自开长途车去上班，我想要一些能让漫长通勤不那么无聊、能撑到中午不饿的东西，以便我能保持工作状态。"
竞争对手不是其他奶昔——是 香蕉、甜甜圈、贝果、咖啡、甚至"什么也不吃"。
为什么奶昔赢？因为它一只手能拿、不会弄脏西装、喝完不需要、能撑 4 小时——这些 Job 维度上完胜香蕉和甜甜圈。
步骤 4：基于 Job 创新而不是基于产品
当你知道 Job 后，创新的方向不再是"做一个更好的奶昔"，而是"更好地完成这个 Job"：
- 加稠奶昔 → 撑更久（更接近 Job）
- 加果粒 → 让通勤更有趣（更接近 Job）
- 加 prepaid 卡 → 路过刷一下就走，节省排队时间（更接近 Job）
案例：大疆的 JTBD
汪滔 2006 年创业时的 Job Statement 不是"做无人机"——
当我是航模爱好者，我想要一个我能改的、便宜的、开放代码的直升机飞控，以便我能专注于飞行本身而不是从头造飞控。
大疆最初的客户是全球的航模爱好者——这群人的 Job 是"飞 + 改 + 玩"。
2013 年大疆推出 Phantom（精灵），Job 转变了：
当我不是技术极客，我想要一个开箱即飞、能拍出好看照片的飞行相机，以便我能记录我的生活。
这个 Job 的转变定义了大疆从"极客品牌"到"消费电子巨头"的跨越。2013 年之前，大疆的对手是开源飞控社区；2013 年之后，大疆的对手是 GoPro、Parrot、3DR。
如果汪滔只盯着"飞控"这个功能性 Job，大疆永远不会做出 Phantom。他看到了社会性 Job——"我想要被朋友羡慕的照片"——这才是消费级无人机的真正市场。
案例：YC 的 "Make something people want" 就是 JTBD
PG 的格言 "Make something people want" 本质上就是 JTBD 哲学：
- "something people want" = "something people would hire to do a Job"
- PG 反复说 "Don't make something people don't want"——这是 JTBD 失败的定义
YC 申请表的第一个问题"What are you doing?"——这就是在问"你完成什么 Job？"
常见误区
| 误区 | 修正 |
|---|---|
| Job = 产品功能 | Job 是任务目标，不是功能 |
| 只看功能性 Job | 必须看情感性 + 社会性 Job——这是溢价的来源 |
| 写一个 Job 就够 | 一个产品通常服务多个 Job——大疆的极客 Job + 消费 Job |
| Job 写完不再回顾 | Job 会随市场变化——定期重新审视 |
与其他工具的关系
- 上游：用户访谈（Job 从访谈中浮现）
- 下游：VPC（Job 是 VPC 右半边的"Customer Job"）、竞争分析（基于 Job 重新定义对手）、PMF 测试（PMF 的本质是 Job 被很好地完成）
6 个工具的整体关系图
这 6 个工具的本质：从"零 idea"到"清晰的、可验证的用户洞察"的 6 步——先找到值得解决的问题，再逐层放大用户颗粒度，直到你能画出一张"用户痛点-收益-任务"的清晰地图。——每一步都把用户的颗粒度变得更细，直到你能画出一张"用户痛点-收益-任务"的清晰地图。
而这张地图，就是下一模块《02 · 价值与商业模式》中**价值主张画布（VPC）**的右半边——也就是你产品要服务的对象。
关联文档
本模块内：本页是 01 模块的唯一文档。
本模块其他章节：
- 02 · 价值与商业模式——把用户洞察翻译成价值主张和商业模式
- 03 · 验证与增长——用 MVP 和 PMF 验证你的假设
- 04 · 融资与战略——验证通过后，融资和战略工具
关联模块：
- Y Combinator 深度分析——YC Office Hour 5 问的源头
- 深圳科创学院深度分析——设计思维和场景体验的源头
- 产品伪需求的基本特征和验证模型——与用户洞察的"反偏差"互补
- 2 万字干货：如何从 0 到 1 搭建用户会员体系——用户洞察实操案例
- 跨部门沟通方法论——把用户洞察传达给团队的技巧
参考资源
- Paul Graham "How to Get Startup Ideas"(2012)——原文——不是 brainstorm，而是"live in the future, build what's missing"
- Paul Graham "Schlep Blindness"(2011)——原文——为什么人们回避真正值得解决的问题
- YC Startup School / Kevin Hale——5 种不公平优势框架（创始人独特优势、市场增长、10x 产品、获客模式、垄断动力学）
- 李泽湘 "十字路口观察法"(1979)——卡耐基梅隆大学的设计思维启蒙作业
- 李泽湘 "场景驱动创新"——不会先想技术再找应用，而是从真实场景中的"不合理"出发
- Alan Cooper《The Inmates Are Running the Asylum》(1999)——Persona 概念的起源
- Alex Osterwalder《价值主张设计》(2014)——Empathy Map 与 VPC 的整合
- Clayton Christensen《与运气竞争》(Competing Against Luck, 2016)——JTBD 系统化
- Paul Graham "Do Things That Don't Scale"(2013)——Airbnb 纽约案例的原始 essay
- Steve Blank《The Four Steps to the Epiphany》(2005)——Customer Development 方法论
- Eric Ries《The Lean Startup》(2011)——MVP 与 Build-Measure-Learn
- Jan Chipchase《Hidden in Plain Sight》(2013)——田野观察方法论