01 · 用户洞察：把"用户"从抽象概念变成可讨论的具体人
"在此之前，我一直认为保持好成绩最重要，而好成绩主要靠理论课程。但十字路口坐三个小时才是真正的设计思维——通过观察和思考去发现问题。"
—— 李泽湘，回忆 1979 年卡耐基梅隆大学的一份作业
99% 的创业失败，不是死于"产品做得不好"，而是死于**"做出来的东西根本没人要"**。Paul Graham 把这种情况浓缩成一句格言：
"Don't make something people don't want."
用户洞察的全部目的，就是在你写第一行代码、画第一张图纸之前，先验证"是否有人在乎这件事"。
本模块覆盖 11 个核心工具——9 个操作工具按"找 idea → 理解用户任务"顺序展开，2 个元方法论（设计思维 + 批判性思维）贯穿全部工具：
| 顺序 | 工具 | 颗粒度 | 何时用 |
|---|---|---|---|
| 1 | 怎么找到创业 idea | 一个待解决的问题 | 最先用——还没 idea 或想验证 idea 方向时 |
| 2 | Schlep Blindness（麻烦盲区） | 一个心理性盲区 | 识别你本能回避的麻烦领域——机会藏在那里 |
| 3 | 用户访谈 5 问法 | 一个人 × 深度 | 所有用户洞察工具的基础设施——Persona/Empathy Map/Journey Map/JTBD 全部依赖访谈数据 |
| 4 | 用户画像 Persona | 一类人 | 把多个真实用户的相似特征刻意归类成一个典型虚拟人，对齐团队认知——「一类」强调合成物的本质，不是统计意义上随机的一群 |
| 5 | 同理心地图 Empathy Map | 一个人 × 一个时刻 | 30 分钟快速对齐某个具体场景 |
| 6 | 用户旅程地图 Journey Map | 一个人 × 一段时间 | 想找痛点峰值、优化体验时 |
| 7 | JTBD | 一个人 × 一个任务 | 想理解"为什么雇佣这个产品"时 |
| 8 | 第一性原理 | 一个判断 | 验证 idea 是否经得起本质推演 |
| 9 | Make something users LOVE | 一群死忠用户 | 不只是 want，是 love——retention 的源头 |
| 10 | 设计思维（Design Thinking） | 一套方法论 | 把工具 1-7 串成 IDEO 5 步法的 Empathize + Define 操作化——李泽湘"科创新工科四大件"之首 |
| 11 | 批判性思维（Critical Thinking） | 一个元校验 | 反思自己的思考过程——避免用户洞察全流程的认知偏差（确认/可得性/锚定/幸存者/投射） |
工具一：怎么找到创业 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"（2012） | 审视自己生活中"为什么这东西这么难用"的时刻 | 软件/SaaS 创业 |
| 从场景观察出发 | 李泽湘"十字路口观察法"（1979）"场景驱动创新" | 到真实场景中观察人的行为，发现"不合理" | 硬件/硬科技创业 |
两种范式底层逻辑一致：idea 不是"想"出来的，是"看到"的。 区别只在观察对象——是观察自己，还是观察别人。
为什么用
创业者最常犯的两个错误：
- "sitcom idea"（PG 术语）：想一个听起来像创业 idea 的 idea——"Uber for X""Airbnb for Y"——但没有真实问题支撑
- "技术找问题"：先有了一个技术/能力，然后去找能用它的场景——李泽湘反复警告的"自嗨式创新"
PG 2012："Why do so many founders build things no one wants? Because they start by trying to think of startup ideas."
李泽湘 2024："大多数工程师都认为自己能做出更好的 iPhone，但他们从没问过用户：你还需要一个更好的 iPhone 吗？"
用这套方法的直接收益：
- 不做 sitcom idea——每个 idea 都有真实问题锚点
- 不做自嗨——场景驱动迫使你面对真实世界的约束
- 筛掉 90% 的伪 idea——用筛选框架在动手前淘汰
怎么用
阶段一：收集问题（两种路径，选一个开始）
路径 A：从自身不满出发（PG 法）
- 列"不满清单"：过去一个月里，什么东西让你觉得"这破玩意怎么这么难用"？写出 20 条。
- 问"为什么还没人解决"：是技术不成熟？是市场太小？是被大公司忽略？还是所有人都忍了？（第三个答案往往是机会）
- 识别"schlep"：有没有什么事是你觉得"太麻烦所以不想碰"的？——那很可能是你的创业 idea（见 工具二 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 2012 |
| 2. 这个问题有多痛？ | 用户已经在用拙劣的办法自己解决了（手工 Excel、微信群、3D 打印的土装置） | 用户说"有点烦"但不会为解决方案付费 | YC |
| 3. 市场是新的吗？ | 一个新平台/新技术刚出现，还没人想过怎么用 | "这是一个成熟的 $50B 市场"（你没机会） | PG 2012 |
| 4. 你能描述一个具体用户吗？ | 能说出"Sarah 在 XX 场景下被这个问题折磨" | 只能说"目标用户群 25-35 岁" | 李泽湘 |
关键原则：好的 idea 在初期往往看起来像玩具或太小。 PG 2012："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 中提出（2020 年代公开版本），能成为 $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（双倍空间，2008） | "用户会不会主动推荐给别人？" |
| 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 2012："你最大的风险不是被人偷 idea，是做出来没人要" |
| 只观察自己 | 一个软件工程师以为所有人的问题都是软件问题 | 你的体验可能只代表极少数人 |
| 攒太多 idea 不行动 | 记了 50 个 idea 但一个都没验证 | idea 不值钱——筛完就要动手验证 |
与其他工具的关系
- 直接下游：工具二 Schlep Blindness——识别被你心理性回避的问题；本模块的用户访谈 5 问法——用 5 问验证 idea 的阶段三问题
- 间接下游：02 · 精益画布——把筛选后的 idea 拆成 9 个假设
- 验证工具：工具八 第一性原理——当你有了 idea 后，用它重新推演一遍"这事到底值不值得做"
- 零号前提：00 · 合伙人选择——开始找 idea 之前，先解决合伙人问题
一句话：idea 不是想出来的——是看出来的（李泽湘）、是活出来的（PG）、是筛出来的（YC 4 问）。然后在 5 个访谈里验证它值不值得继续。
工具二：Schlep Blindness（麻烦盲区）
"The most powerful motivator may be the desire to avoid schlep."
—— Paul Graham, Schlep Blindness (2011)
是什么
Schlep Blindness 是 Paul Graham 2011 年同名 essay 提出的概念。"Schlep"是意第绪语，意思是"麻烦的、不愿意做的事"。PG 观察到：创业者会本能地回避真正麻烦的问题——而机会正藏在其中。
例子：
- 创业者扎堆做"另一个社交媒体 App"——因为简单
- 没人做"重新设计医疗账单系统"——因为太麻烦（监管、医院关系、保险）
结果：简单的赛道竞争激烈，麻烦的赛道无人问津。
PG 2011："The most powerful motivator may be the desire to avoid schlep."
为什么用
核心问题：找 idea 阶段最大的盲区不是"想不到 idea"，而是"想到了但本能回避"。
Schlep Blindness 让你在工具一 idea 生成的"不满清单"和"场景观察"里，刻意把视线投向那些让你本能皱眉的领域。
PG 在 essay 里列了为什么创业者会回避 schlep：
- 心理防御：麻烦的事意味着辛苦，大脑自动规避辛苦的想象
- 风险规避：麻烦的事通常涉及监管/政治/人际关系——看起来风险大
- 想象力失败：麻烦的事难以在脑子里模拟"做完了是什么样"
但 PG 的数据观察：YC 历史上回报最高的投资，几乎全部是 schlep 公司。
怎么用
应用 Schlep Blindness：刻意找麻烦
每周问自己：
"我们行业里有什么问题是大家都不愿意碰的？"
经典"schlep"领域：
| 领域 | 为什么是 schlep | 谁在 schlep 里赚到了 |
|---|---|---|
| 医疗 | 监管复杂、销售周期长、利益方多 | Oscar Health、Glen Tullman（Livongo） |
| 教育 | 决策周期长、效果难衡量 | Duolingo、Course Hero |
| 政府 | 采购流程慢、政策风险 | Palantir（IPO $40B） |
| B2B 工具 | 客户分散、定制需求多 | Rippling（估值 $16.8B） |
| 制造业 | 供应链复杂、资本密集 | 大疆、李泽湘体系全部 |
| 金融监管 | 牌照、合规、审计 | Stripe（估值 14B） |
YC 反复说：这些领域恰恰是 YC 体系的甜蜜点。
识别自己的 Schlep Blindness
三个自检问题：
- "我脑子里曾经闪过'这事太麻烦了'的创业方向吗？"——列出来
- "我身边的朋友抱怨最多、但没人愿意去解决的问题是什么？"
- "如果有人给我 $10M 让我做一件'最不愿意做'的事，那是什么？"
第三个问题的答案，往往是你的 schlep blind spot。
案例：李泽湘体系就是"反 Schlep Blindness"
硬件创业是最大的 schlep：
- 开模要钱
- 量产要供应链
- 售后要服务体系
- 库存要现金流
99% 的创业者回避硬件——但李泽湘体系主动扎进硬件：
李泽湘 2024："中国不缺优秀的工科人才，不缺全球最完备的制造业产业链，缺的是一套能将人才、技术、市场、产业有效衔接的完整体系。"
李泽湘体系用 30 年解决了硬件 schlep——结果：265+ 家硬科技企业，4 家上市公司，13 家独角兽。
大疆、云鲸、希迪、卧安——全是在别人不愿意碰的硬件 schlep 中长出来的。
案例：YC 的反例——错过 WhatsApp（2009）
YC 2009 年拒绝了 Brian Acton 的 WhatsApp 申请——理由是"没有 hacker 特质"。
PG 后来反思：
"我们低估了那些没有明显'hacker'特质的创始人——这是 Schlep Blindness 的另一种表现。"
WhatsApp 2014 年被 Facebook 以 10B+ 潜在回报。
常见误区
| 误区 | 修正 |
|---|---|
| Schlep = 难做 | Schlep 是"麻烦"——有些麻烦的事其实简单 |
| Schlep 是技术难 | 技术难不一定是 schlep——schlep 是"涉及人际/监管/物流等让你皱眉的事" |
| 只认 schlep 不验证 | Schlep 是 idea 来源，但还是要走工具一阶段三轻量验证 |
与其他工具的关系
- 上游：工具一 idea 生成——Schlep 是 idea 的特殊来源（你心理性回避的问题）
- 下游：工具三 用户访谈 5 问法——验证 schlep 问题是否真实
- 关联：03 模块 Do Things That Don't Scale——schlep 的早期阶段必须手工做不可规模化的事
- 哲学：YC 的 "Make something people want"——schlep 往往就是 "people want but no one wants to do" 的领域
工具三：用户访谈 5 问法
是什么
用户访谈 5 问法 是 YC Office Hour 标准问题清单（2005 至今）+ 李泽湘"十字路口观察法"（1979）的融合。YC 的合作伙伴在面对每个创始人时会问 5 个问题，每天重复 10-20 遍，21 年下来问了几十万遍：
- What：你在干嘛？
- Why：你做这个的逻辑是什么？
- Who cares：谁在乎这个东西？
- Advantage：你的优势在哪？
- Numbers：给我看数据。
李泽湘的方法论补了一个"反向版本"——不要问用户，去看用户（1979 年十字路口观察法）。
为什么用
用户访谈是用户洞察的"基础设施"——Persona、Empathy Map、Journey Map、JTBD、VPC 全部依赖访谈数据。访谈质量决定了所有下游工具的质量。
这就是为什么本工具排在 Persona/Empathy Map 之前——先学访谈，再学从访谈数据抽象出来的工具。
但 99% 的创业者不会访谈。他们犯的核心错误是：问用户"你想要什么"。
Henry Ford（常被误引但观点成立）："如果我问人们想要什么，他们会说想要一匹更快的马。"
Steve Jobs 1998："人们不知道自己想要什么，直到你展示给他们看。"
Paul Graham 2013："不要问用户想要什么——观察他们在做什么。"
怎么用
步骤 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 早期的"线下扫楼"（2009）
Paul Graham 反复讲的经典案例——Airbnb 早期在纽约的房东访谈：
Airbnb 早期房源的照片都是手机随便拍的，质量很差。Brian Chesky 和 Joe Gebbia 听了 PG 的话——"Do things that don't scale"（2013 essay 才写出，但 2009 年就在 YC 内部讲）——亲自飞到纽约，挨家挨户敲房东门，用一台价值 $5000 的相机帮房东拍专业照片。
这次"线下扫楼"的本质就是用户访谈 + 场景观察：
- 借拍照的名义进入房东真实场景
- 观察房东如何布置房间（环境数据）
- 听房东抱怨 Airbnb 的哪些功能不好用（访谈数据）
- 看房东的相机/手机型号、网络速度（行为数据）
结果：纽约的房源预订率提升了 2.5 倍。这不是因为照片好看，是因为 Brian 和 Joe 终于"看见"了用户。
案例：李泽湘为什么招汪滔读研（2003-2006）
汪滔在港科大的本科毕业设计——无人机飞控系统——演示时出了问题，只拿了 C。按传统标准，这个学生不该被招进研究生。
但李泽湘在汪滔选修的 Robocon 机器人比赛课上观察了他两年：
- 第一年：汪滔拿下香港冠军
- 第二年：汪滔拿下亚太区并列第三名
李泽湘的访谈+观察数据：汪滔在比赛中表现出的偏执、对细节的执着、愿意为一个小问题熬通宵——这些都是成绩单上看不到的"行为证据"。
李泽湘："他是我学生里最偏执的一个。"
这个判断后来催生了大疆（2025 年市值 1500 亿人民币）。
常见误区
| 误区 | 修正 |
|---|---|
| 一次访谈 10 个人 | 一次访谈 1 个人，深度 1 小时 > 浅度 10 分钟 |
| 访谈团队老大 | 访谈的不是决策者，是实际使用者——决策者说的和实际用的往往是两回事 |
| 只访谈"喜欢我们的人" | 至少 30% 访谈量给"明确拒绝的人"——他们的反馈最值钱 |
| 用问卷替代访谈 | 问卷是验证假设的工具，不是发现洞察的工具——访谈先于问卷 |
| 访谈完不整理 | 24 小时内整理，1 周后访谈数据基本作废 |
与其他工具的关系
- 下游：工具四 Persona（基于访谈抽象）、工具五 Empathy Map（基于访谈填 6 格）、工具六 Journey Map（基于访谈画时间线）、工具七 JTBD（基于访谈找 Job）、02 VPC（基于访谈填右半边）
工具四：用户画像（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 类用户，多了就是没聚焦。
与其他工具的关系
- 上游：工具三 用户访谈（画像的输入）
- 下游：工具五 Empathy Map（把 Persona 的某个场景放大）、工具六 Journey Map（基于 Persona 画时间线）、02 VPC（Persona 是 VPC 右半边的"客户画像"）
工具五：同理心地图（Empathy Map）
是什么
同理心地图是 XPLANE 的 Dave Gray 发明的工具（2008 公开版本），被 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（2007）
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 找到的痛点峰值，画时间线）、02 VPC（Empathy Map 的 PAIN/GAIN 直接对应 VPC 的 Customer Jobs/Pains/Gains）
工具六：用户旅程地图（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 的"邀请旅程"（2014-2015）
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（确定是谁的旅程）、工具三 用户访谈（提供每个触点的数据）
- 下游：痛点峰值 → 02 VPC 的 Pains / 痛点 → 优先级 → 产品路线图
工具七：JTBD（Jobs-to-be-Done）
是什么
JTBD（Jobs-to-be-Done） 是哈佛商学院 Clayton Christensen（《创新者的窘境》1997 作者）在《与运气竞争》（Competing Against Luck, 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 2016 强调 Job 有三层：
| 层次 | 例子（买 LV 包） |
|---|---|
| 功能性 Job | 装东西 |
| 情感性 Job | 让自己感觉成功、被认可 |
| 社会性 Job | 让别人觉得我"有品位"、"有钱" |
只看功能性 Job 会严重低估市场——LV 的市场从来不是"装东西"。
步骤 3：用 Job 重定义竞争
写下你的 Job Statement 后，问：
"用户还能用什么来完成这个 Job？包括非产品方案"
例子——快餐奶昔（Christensen 2016 经典案例）：
某快餐连锁想提升奶昔销量。他们一开始做 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"（YC 2005 至今）本质上就是 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 从访谈中浮现）
- 下游：02 VPC（Job 是 VPC 右半边的"Customer Job"）、竞争分析（基于 Job 重新定义对手）、03 PMF 测试（PMF 的本质是 Job 被很好地完成）
工具八：第一性原理
是什么
第一性原理（First Principles Thinking） 是回归最基础的物理/数学/经济事实，重新推导结论的思维方式。
对立面：类比思维（"别人这么做，我也这么做"）。
Elon Musk 的经典案例（SpaceX，2002 创立后）：
- 类比思维：火箭很贵（历史上每次发射 $65M），所以发射就是贵
- 第一性原理：火箭的材料是什么？铝、钛、铜、碳纤维——这些材料的市场成本只占火箭售价的 2%。所以火箭理论上可以便宜 50 倍。
结果：SpaceX 把单次发射成本降到 30M）。
为什么用
核心问题：99% 的战略决策是"类比思维"——看竞品怎么做，跟着做。
类比思维的问题：
- 别人可能也是错的（盲从）
- 场景不同（别人的市场 ≠ 你的市场）
- 创新被锁死（永远赶超，永远落后）
第一性原理的价值：让你看到"被共识掩盖的机会"。
Elon Musk 2012 TED："I think it's important to reason from first principles rather than by analogy."
为什么放在 01 模块的最后：第一性原理是横切工具——任何时候都可以用——但它在 工具一 idea 生成 之后第一次最有价值：你有了候选 idea，用第一性原理验证它经不经得起本质推演。
怎么用
步骤 1：识别"假设"
写下你当前的判断，问"这是基于什么假设？"
例子：
- 判断："我们的 SaaS 应该定价 $50/月"
- 假设："因为竞品都是 $50/月"
步骤 2：把假设拆到"第一性"
追问 5 次"为什么"：
- "竞品为什么定 $50？" → "因为行业惯例"
- "行业惯例怎么来的？" → "SaaS 早期的标准定价"
- "SaaS 早期为什么定这个价？" → "对标的 Oracle/Salesforce 价格"
- "Oracle 为什么定那个价？" → "基于企业预算阈值"
- "企业预算阈值是什么？" → "每年每人 $600 是企业工具的舒适阈值"
到了第 5 层，你发现**$50/月是基于"企业工具舒适阈值"**——这是 B2B 的情况。但如果你是 B2C 呢？阈值完全不同。
步骤 3：基于第一性重新计算
例：你的 B2C SaaS——
- 第一年目标：1 万付费用户
- 单用户每年愿意为"节省 30 小时"付多少？→ 调研发现 $20
- 所以年定价 1.99 比竞品的 $50 更合理
重新定价后：你的 TAM 比竞品大 10 倍（因为价格门槛低）。
案例：李泽湘的"第一性"创业观（2014 至今）
李泽湘的所有方法论都是第一性原理推导的：
李泽湘 2024："中国不缺优秀的工科人才，不缺全球最完备的制造业产业链，缺的是一套能将人才、技术、市场、产业有效衔接的完整体系。"
这个判断是第一性的——他不参考"硅谷加速器模式"（类比），而是看中国的根本条件（第一性）。
由此推导出：
- 不做 YC 的纯软件模式（中国软件创业门槛低、VC 不缺项目）
- 做"硬件 + 供应链"模式（中国独有的优势）
- 用 30 年时间建体系（短期不可复制）
这就是为什么深圳科创学院无法被国外复制——它是基于中国第一性条件的产物。
案例：YC 的"反第一性"案例（2009 错过 Uber）
YC 历史上也有"反第一性"的失败：
YC 拒绝 Uber（2009）：
- 类比判断："监管风险大"
- 第一性应该问："出行市场的真实需求多大？监管能否被需求推动改变？"
- 结果：Uber 改变了全球监管——YC 错过 $100B+ 机会
PG 自己反思：
"我们低估了那些没有明显'hacker'特质的创始人。"
这就是第一性原理的反面教材——用类比（"Uber 没有 hacker 特质"）替代第一性（"出行市场需求"）。
常见误区
| 误区 | 修正 |
|---|---|
| 第一性 ≠ 反共识 | 第一性推导可能得出共识结论——重点是过程不是结论 |
| 过度使用 | 不是每个决策都要第一性——日常决策用类比更快 |
| "我觉得"代替第一性 | 第一性必须有客观事实支撑 |
| 推导完不验证 | 第一性结论要用 03 MVP 验证 |
与其他工具的关系
- 上游：工具一 idea 生成——第一性原理用于验证 idea 是否经得起本质推演
- 横切：所有模块都可用第一性原理重新审视
- 特别关联：02 Lean Canvas 的"现有替代方案"、02 BMC 的"价值主张"
- 平行：工具二 Schlep Blindness——两者都是挑战默认假设的思维工具
工具九：Make something users LOVE（不只是 want）
"It's better to have 100 people love you than a million people kind of like you."
—— Paul Graham, 2013 反复强调
"Startups do not die from lack of firepower. They die from lack of love."
—— Garry Tan, 2024 YC Office Hour
是什么
Make something users LOVE 是 PG 在 2013 年《Do Things That Don't Scale》及之后的多次演讲中反复讲的哲学——做出 100 个死忠用户，比 100 万个"还行"的用户更值钱。
它是 [YC 官方格言 "Make something people want"] 的进阶版——want 是入门，love 是壁垒。
| 维度 | Want（想要） | LOVE（爱） |
|---|---|---|
| 用户行为 | 注册、试用 | 每天主动打开、推荐给朋友、为你辩护 |
| NPS | 30-40 | 60+ |
| "非常失望"测试 | 30-40% | 50%+ |
| 留存曲线 | 缓慢下降 | 水平 |
| 商业意义 | CAC 可控 | LTV 极高，自然增长 |
为什么用
核心问题：99% 的创业者满足于"用户喜欢"——但"喜欢"无法形成壁垒。
PG 的反例：很多 YC 公司在 Demo Day 后获得大量早期用户，但 6 个月后留存低于 10%。原因不是产品差，而是产品只让人"喜欢"，不让人"love"。
love 的真正价值：
- 自然增长：100 个 love 你的用户会主动带来下 1000 个；100 万个 kind-of-like-you 的用户不会带来任何
- 溢价能力：love 你的用户愿意付 3 倍价格——Apple 用户、Tesla 用户、Linear 用户的共同点
- 抗竞争：竞品复制功能容易，复制"love"几乎不可能——因为 love 来自细节、来自信任、来自"这个产品懂我"
Brian Chesky 2014："如果你让 100 个人 love 你，他们会帮你做 marketing、客户支持、招聘——他们就是你的免费员工。"
怎么用
步骤 1：识别 love 的 5 个信号
不要靠"感觉"——用数据识别：
| 信号 | 量化指标 | love 阈值 |
|---|---|---|
| 每天主动打开 | DAU/MAU 比 | > 50% |
| 未付费主动推荐 | K 因子（无奖励） | > 0.5 |
| 流失后回归 | 流失用户 30 天内回归率 | > 20% |
| 为你辩护 | Twitter/Reddit/HackerNews 正面提及比例 | > 70% |
| "非常失望"测试 | Sean Ellis 40% 测试（2009） | > 50% |
5 个信号里至少 3 个达到阈值，才算"love"。
步骤 2：从"喜欢"到"love"的 3 个杠杆
PG 在 2013 essay 中给了 3 个具体操作：
杠杆 1：极致的早期用户体验
- 给前 100 个用户 CEO 的私人手机号
- 24 小时内回复所有反馈
- 上门服务——Stripe 兄弟 2010 年飞到每个用户办公室帮装 SDK
- 不是"努力做好"——是"超出他们想象 10 倍"
杠杆 2：让用户参与产品的塑造
- 邀请前 100 个用户进 Slack 群
- 每周和 5 个用户 1:1 聊天
- 把他们的反馈直接变成下个版本的功能
- 让他们感觉"这是我们的产品"
杠杆 3：制造"信仰感"
- 不要做"通用产品"——做"为某一类人量身定制的产品"
- Apple 给设计师、Tesla 给极客、Notion 给深度思考者——每个 love 品牌都有清晰的"信徒画像"
- 敢于 alienate（疏远）非目标用户——这是定位的代价
步骤 3：量化 love 的产出
love 不是抽象的——可以算出 ROI：
100 个 love 用户 × 平均带来 5 个新用户 = 500 个用户（自然增长）
100 个 love 用户 × LTV $1000 = $100,000（生命周期价值）
100 个 love 用户 × 推荐带来的口碑价值 = 不可量化但巨大
对比：100 万个 kind-of-like 用户 × 流失率 90% × CAC 10M，6 个月后剩 10 万。
案例：Slack 的 "2000 条消息" 是 love 的临界点（2014-2015）
Slack 团队发现：团队发够 2000 条消息后，95% 不会换工具——这就是 love 的临界点。
为什么是 2000 条？因为：
- 团队已把工作流迁移过来（切换成本高）
- 已建立频道文化和内部梗（情感连接）
- 已邀请所有同事（社交绑定）
Slack 的早期策略——全力让每个新团队达到 2000 条消息：
- 新团队 onboarding 时 Slack 团队亲自帮设置频道
- 给达到 2000 条的团队送礼物
- 在 Dashboard 上显示"离 2000 条还差 X 条"
Stewart Butterfield 2015："我们不在乎用户数——我们在乎'多少团队达到了 2000 条消息'。"
案例：Linear 的"设计师的爱"（2019-2024）
Linear（项目管理工具）从 day 1 就只追求"设计师/工程师的爱"：
- 创始人 Karri Saarinen 亲自回复每一条 Twitter 提及
- 每个 release notes 用精心设计的视觉呈现
- 拒绝添加"通用 PM 功能"——保持极简
- 结果：5 年内从 0 做到 $50M+ ARR，几乎没花钱 marketing
Karri Saarinen 2023："我们不做'让所有人满意的产品'——我们做'让 1000 个深度用户离不开的产品'。"
案例：李泽湘体系的"硬件 love"——大疆 Phantom（2013）
大疆 Phantom 之所以能定义消费级无人机市场，不是因为"功能多"——而是因为它让航模爱好者 love 它：
- 开箱即飞（不需要 6 个月调飞控）
- 摔了不会失控（GPS 返航）
- 配套 App 极简
汪滔 2014："Phantom 之前，全球航模爱好者不到 10 万人。Phantom 之后，全球航拍爱好者超过 1000 万人——我做的不是抢市场，是创造一批 love 飞行的人。"
硬件 love 的特殊难度：硬件的 Aha Moment 不可逆——用户第一次用如果失望，几乎不会再买。所以硬件 love 的关键是"首次使用体验"。
常见误区
| 误区 | 修正 |
|---|---|
| "用户喜欢 = love" | 喜欢是 NPS 30，love 是 NPS 60+——天差地别 |
| 追求用户数而非 love 数 | 100 万 kind-of-like < 100 love |
| love 是奢侈品，早期做不到 | 恰恰相反——早期必须靠 love 增长，因为没钱做 marketing |
| love 来自功能 | love 来自细节 + 信任 + "懂我"——功能只是载体 |
| 所有人都会 love 你 | 100 个 love 用户意味着 1 万个 hate 你——这是定位的代价 |
与其他工具的关系
- 上游：工具三 用户访谈 5 问法——必须先深度访谈才能识别 love 信号
- 下游：03 PMF + 40% 测试（PMF 是"非常失望"测试 ≥ 40%；love 是 ≥ 50%）、03 Aha Moment（love 是 Aha 的进阶版）
- 哲学源头：YC 格言 "Make something people want" 的进阶——want 是入门，love 是壁垒
工具十：设计思维（Design Thinking）
"设计思维不是'想出好点子'，而是'在动手之前先把用户的真实行为摸清楚'。"
—— David Kelley，IDEO 创始人，Stanford d.school 联合创办者（2005）
是什么
总览 §4 设计思维：双钻背后的哲学 讲了 5 步法（Empathize / Define / Ideate / Prototype / Test）的全局。本工具页聚焦用户洞察模块内的两步——Empathize（同理）+ Define（定义）——的具体执行。
Empathize 不是"问用户想要什么"——这是几乎所有产品经理的默认操作，也是几乎所有自嗨式创新的起点。真正的 Empathize 是"看用户怎么做、想用户怎么想"。 Define 不是"总结访谈"——这是用户研究员的默认产出，也是几乎所有 PRD 的垃圾输入。真正的 Define 是"从 100 条观察里提炼 1 个核心痛点"。
| 步骤 | 错误做法 | 正确做法 |
|---|---|---|
| Empathize | "Sarah，你想要什么？" | 在 Sarah 用产品的现场，看她卡在哪里、用什么土办法解决、最后骂了什么 |
| Define | "用户说想要更快的马"（Henry Ford 名言） | "用户雇佣马来完成'从 A 到 B'的任务——马车不是终点，是任务" |
完整方法论见 —— Stanford d.school, Design Thinking Bootleg, 2018（d.school 官方 5 步法操作手册）
为什么用
用户洞察的两个典型失败模式，根源都在于跳过了 Empathize + Define：
- "自嗨式创新"（李泽湘反复警告）：工程师在屋里 brainstorm 想出一个"更牛的功能"，但用户从来没说过需要。李泽湘 2024："大多数工程师都认为自己能做出更好的 iPhone，但他们从没问过用户：你还需要一个更好的 iPhone 吗？"——这句话的本质是：缺了 Empathize 这一步，所有产品决策都是工程师的自我投射。
- "妈觉得你冷式"投射：把自己的需求当成用户的需求——"我自己觉得这破玩意难用，那 Sarah 肯定也觉得"。这是确认偏差的极端版本（详见 工具十一 批判性思维），但在早期创业者中普遍率高达 70%+——YC 在 2018-2024 的 Startup School 数据中反复提到这一现象。
设计思维的 Empathize + Define 强制你先放下自己的判断，到用户场景里看 3 小时——这是李泽湘"十字路口观察法"（1979）的现代化版本，比 Stanford d.school 的成立（2005）早 26 年。
怎么用：Empathize 阶段（深度同理）
三层同理：看 / 问 / 体验
| 层次 | 动作 | 时长 | 输出 |
|---|---|---|---|
| 看（Observe） | 不打扰用户，到他真实使用场景观察——只记录"他做了什么动作、卡在哪里、表情是什么"。关键：不解读动机，只描述行为 | 30-60 分钟 | 时间轴 + 关键动作 |
| 问（Interview） | 用 5 问法做深度访谈——开放式问题、追问"为什么"、记录原话 | 30-60 分钟 | 5-10 条原话 + 痛点 |
| 体验（Immerse） | 自己当一天用户——用他的土办法走完整个流程，记下你自己的痛苦峰值 | 1 个完整周期 | 第一人称体验日记 |
李泽湘 1979 十字路口观察法就是"看"层次的极致——3 小时纯观察、零干扰、零预设。这一步被很多人认为是"浪费时间"，但 IDEO 在过去 30 年的所有标志性项目（Apple 第一只鼠标、PillPack 药物管理、Bank of America "Keep the Change"）全部始于这种沉浸式观察。
Empathize 阶段的反偏差
参见 工具十一 批判性思维：观察记录时只描述行为，不解读动机——把"Sarah 在填表时皱眉"如实记录，不要写"Sarah 觉得这个表很烦"。前者是事实，后者是解读——解读会污染你后续的 Define。
怎么用：Define 阶段（提炼核心问题）
用 POV 句式把观察转成洞察
POV（Point of View）是 Stanford d.school 的标准模板：
[用户] 在 [场景] 中 试图 [任务/目标]，
但是 [障碍/痛点]，
这意味着 [更深的洞察/机会]。
例子：
| 错误的 POV | 正确的 POV |
|---|---|
| "25-35 岁女性想减肥" | "职场妈妈 Sarah 在加班到 22 点后 试图保持健身习惯，但是 家庭负担 + 没时间做饭 让她无法坚持，这意味着 她需要'10 分钟无装备训练'而不是另一个健身 App" |
| "用户想要更好的扫地机器人" | "养宠物的家庭用户在每周拖地时 试图避免宠毛发臭，但是 现有扫地机器人需要手动清理滚刷上的毛发，这意味着 自清洁拖布是核心需求"（云鲸的 POV） |
POV 的检验：好的 POV 让你能立刻想象出一个具体的人在具体场景里——如果只能想出"目标用户群"，POV 太宽，需要回到 Empathize 重新观察。
用"How Might We"（HMW）把 POV 拆成可发想的问题
HMW 句式："我们可能如何 ___？"——这个句式源自 P&G 1970s 的产品设计流程，被 IDEO 在 1990s 推广。
| POV 的洞察 | 转成的 HMW |
|---|---|
| "Sarah 需要 10 分钟无装备训练" | "HMW 让职场妈妈在 10 分钟内完成有效训练？" |
| "养宠用户需要自清洁拖布" | "HMW 让扫地机器人 30 天不手动清理？" |
HMW 是连接 Define 和 Ideate 的桥梁——好的 HMW 既不太宽（"HMW 让世界更好"）也不太窄（"HMW 把滚刷直径减少 2mm"）。
HMW 的检验：给一个不了解你项目的同事看——如果他能立刻说出 3-5 个完全不同的解决方案，HMW 是好的；如果他只能想到你的现有方案，HMW 太窄了。
案例：云鲸的 Empathize → Define → HMW（2014-2016）
云鲸创始人张峻彬在李泽湘指导下做的设计思维过程：
| 阶段 | 动作 | 输出 |
|---|---|---|
| Empathize（看 + 问 + 体验） | 到 30+ 个家庭观察拖地流程；访谈 50+ 用户；自己每周拖地 2 次共 6 个月 | "拖布要手洗"是高频痛点——用户为此每周多花 30 分钟 |
| Define（POV） | "养宠物的家庭用户在每周拖地时 试图避免毛发缠绕，但是 拖布要手洗这件事让他们抓狂，这意味着 '自清洁'是核心需求" | 1 个核心 POV |
| HMW | "HMW 让拖地机器人 自动清洗拖布？" | 转化为产品命题 |
这就是云鲸 J1（2019 年发布）的 idea 源头——整个产品的工程目标就是回答这个 HMW。云鲸 J1 上线第一年销售额破 ¥10 亿，本质上是 5 年前那场 Empathize 阶段的胜利。
30 分钟动手模板：Empathize + Define 闭环
| 时间 | 步骤 | 动作 | 输出 |
|---|---|---|---|
| 0-15 min | Empathize（看） | 回忆你最近一次与目标用户的对话/观察，按时间轴记录他的 5 个关键动作 + 3 句原话 | 时间轴 + 原话清单 |
| 15-22 min | Empathize（体验） | 自己当用户走一遍流程——记录 3 个最痛的瞬间 | 第一人称痛点清单 |
| 22-28 min | Define（POV） | 把观察填进 POV 句式 | 1 个 POV |
| 28-30 min | Define（HMW） | 把 POV 转成 1 个 HMW 问题 | 1 个 HMW |
常见误区
| 误区 | 修正 |
|---|---|
| 跳过 Empathize 直接 Define | 没有真实观察的 POV = 纯投射 |
| Empathize 只"问"不"看/体验" | 用户说的话 ≠ 用户做的事——三者必须并行 |
| POV 写得太宽 | "用户想要更好的 X" = 没说任何事 |
| HMW 写得太窄 | "HMW 把 X 减小 2mm" = 已经预设答案了 |
| Define 之后不再 Empathize | Define 出来的 POV 必须回到 Empathize 验证——设计思维是非线性的 |
与其他工具的关系
- 元框架：§4 设计思维：双钻背后的哲学——5 步法全局视角
- 上游：工具三 用户访谈 5 问法——Empathize 阶段的核心工具
- 下游：工具四 Persona、工具五 Empathy Map、工具六 Journey Map、工具七 JTBD——都是 Define 阶段的不同表达
- 配套：工具十一 批判性思维——Empathize + Define 的反偏差校验
- 下游模块：02 模块 Ideate 阶段工具（VPC/Lean Canvas/BMC）
工具十一：批判性思维（Critical Thinking）
"The first principle is that you must not fool yourself — and you are the easiest person to fool."
—— Richard Feynman，1974 Caltech 毕业典礼演讲 "Cargo Cult Science"
是什么
批判性思维不是"批评别人的想法"，是反思自己的思考过程——识别并修正自己脑子里的认知偏差。
这个词的现代化定义来自 Karl Popper 1934 年《研究的逻辑》（The Logic of Scientific Discovery）的"可证伪性"原则——一个判断如果不能被反驳，就不是科学判断。Richard Feynman 1974 年在 Caltech 毕业典礼上把这个原则传播到工程与教育领域，留下了开篇那句"the easiest person to fool"——这句话后来被硅谷无数创业者反复引用。
为什么放在用户洞察模块的最后：因为用户洞察是全模块最容易自我欺骗的阶段——你"看到"的是你想看到的，你"听到"的是你想听的，你"问的"是你预设答案的。没有批判性思维，前面 10 个工具的输出全是带着偏差的"伪洞察"。
李泽湘把批判性思维列为「科创新工科四大件」之一——它不是"附加技能"，是用户洞察的元校验。
为什么用
用户洞察中最容易踩的 5 个认知陷阱——这 5 个偏差在 Daniel Kahneman《思考，快与慢》（2011，诺贝尔经济学奖作品）里有系统的心理学机制说明：
| 陷阱 | 心理学名称 | 表现 | 后果 |
|---|---|---|---|
| 确认偏差 | Confirmation Bias | 只记得支持你 idea 的访谈，忽略反对的 | "我访谈了 10 个用户，8 个都说要"——其实你删掉了 2 个反对的访谈笔记 |
| 可得性偏差 | Availability Bias | 把最容易想到的案例当成普遍规律 | "我表姐就遇到过这个问题，所以这是普遍需求" |
| 锚定 | Anchoring | 第一个用户说的痛点主导了你后续所有判断 | "第一个用户说太贵"——后面 9 个用户都没说贵，但你只记住了"贵" |
| 幸存者偏差 | Survivorship Bias | 只访谈还在用你产品的用户 | "留存用户都说喜欢"——但流失用户（80%）没人访谈，他们才是真问题 |
| 投射 | Projection | 把自己的需求当成用户的需求 | "我自己觉得这破玩意难用"——你不是用户 |
这 5 个陷阱不可能完全避免——它们是人脑的硬件缺陷，Kahneman 用了 40 年实验证明这一点。批判性思维的目的不是消除偏差，是识别偏差 + 修正判断。
怎么用：4 个具体工具
工具 A：5 Whys（追问根本原因）
丰田生产方式（TPS）的核心工具，由大野耐一在 1950s 推广——对任何"现象"连续问 5 次"为什么"，直到挖到根本原因。丰田内部文档明确说："丰田科学方法的基石就是 5 Whys——我们不相信任何在 3 层之内停下来的根因分析。"
例子：
| 层级 | 问 | 答 |
|---|---|---|
| 现象 | 为什么用户弃用了 App？ | "因为推送太多" |
| Why 1 | 为什么推送多导致弃用？ | "因为推送内容跟他无关" |
| Why 2 | 为什么推送内容跟他无关？ | "因为我们不知道他在 App 里做了什么" |
| Why 3 | 为什么不知道他在 App 里做了什么？ | "因为我们没有埋点用户的核心路径" |
| Why 4 | 为什么没埋点核心路径？ | "因为没人定义过'核心路径'是什么" |
| Why 5 | 为什么没人定义核心路径？ | "因为我们没做过 JTBD 分析" |
根因：缺 JTBD 分析——回到 工具七 JTBD。
5 Whys 的反模式：问到第 3 层就停下来——根因没找到，对策只能治标。
工具 B：认知偏差清单（每访谈完 1 个用户后必用）
每次访谈结束后，用以下清单自检 5 分钟。这份清单是 YC Startup School 2018 版用户访谈工作表的简化版：
□ 我是不是只记住了支持我假设的原话？（确认偏差）
□ 我是不是被第一个用户的观点"锚定"了？（锚定）
□ 我引用的案例是不是"最容易想起来的"而非"最普遍的"？（可得性偏差）
□ 我访谈的用户是不是都是"还愿意跟我聊的"？（幸存者偏差）
□ 我是不是把我自己的痛点当成他的？（投射）
5 分钟 / 5 个问题 / 5 倍洞察质量——这是用户洞察模块性价比最高的工具。如果你每访谈一个用户只花 5 分钟做这件事，比再多访谈 50 个用户都有用。
工具 C：Red Team 反方推演
军事/情报领域的标准工具（最早来自苏联 1960s 总参谋部情报局，后被 CIA 和五角大楼采纳）——刻意指派一个人扮演"反方"，故意挑战你的核心假设。
怎么用：
- 在团队中指派一个"魔鬼代言人"（Devil's Advocate）——明确告诉他："你的任务是说服大家这个 idea 是错的"
- 给他 30 分钟准备反方论据——必须基于事实，不能只是"我感觉不行"
- 让他用 5 分钟陈述反方观点
- 团队评估：反方论据中哪些是真实风险？
为什么有效：人脑默认"证实"，强制指派"证伪"角色才能打破默认。这一方法在 a16z、Sequoia 的投资决策会议中是标准流程。
工具 D：反向证据搜索（Disconfirming Evidence Search）
哲学家 Karl Popper 的"可证伪性"原则——一个假设如果不能被反驳，就不是科学假设。
应用到用户洞察：
| 你的假设 | 反向证据搜索 |
|---|---|
| "用户需要 X" | 主动搜索"用户不需要 X"的证据——找 3 个明确的反例 |
| "市场有 100 亿" | 主动找"市场只有 10 亿"的论据——用什么数据可以反驳你 |
| "竞品做不到 Y" | 主动假设"竞品 6 个月内能做出来"——他们差什么 |
关键问题："如果我的判断是错的，最可能是哪种证据让我错？"——然后主动去找这种证据。
案例：Juicero 的失败 = 缺乏批判性思维（2016-2017）
Juicero 是硅谷 2016 年最火的硬件创业之一——founder Doug Evans（曾创办有机食品连锁 Juicero 前身）坚信"用户需要一个 120M（Sequoia Capital、Kleiner Perkins、Google Ventures 都投了）。
他们：
- 不做 Empathize：从未到用户家庭观察真实榨汁场景
- 不做 Define：核心 POV 是"硅谷精英需要高科技健康生活"——纯投射
- 不做批判性思维：投资人 Doug Leone（Sequoia）私下质疑过"用户真的需要 $400 榨汁机吗"，但团队用"市场会教育用户"驳回
2017 年 4 月，Bloomberg 做了一个 5 分钟的视频——用手挤 Juicero 的果蔬包，比机器榨得还快。3 个月内公司倒闭，烧光 $120M。
核心教训：Juicero 团队没有任何人做"反向证据搜索"——如果他们做一次，会立刻发现"用户其实可以徒手挤"。这是批判性思维缺失的经典案例。
案例：李泽湘体系的"批判性思维训练"
李泽湘在深圳科创学院训练营中要求每个学员项目都要经历：
- 导师挑战：3-5 位导师轮番质疑项目假设——不是质疑技术，是质疑"你为什么相信用户需要这个"
- 同行挑战：其他学员用 Red Team 反方推演
- 场景挑战：到真实场景验证，遇到反例立刻记录
李泽湘 2024："创业最大的危险不是失败，是'自以为成功'——你以为你在做 PMF，其实你在做自我感动。"
30 分钟动手模板：用批判性思维重新审视你的访谈笔记
| 时间 | 步骤 | 动作 |
|---|---|---|
| 0-10 min | 5 Whys | 选 1 个用户弃用 / 抱怨的现象，连续问 5 个为什么 |
| 10-15 min | 偏差清单 | 用 5 个偏差问题自检你的最近 5 次访谈 |
| 15-22 min | Red Team | 找一个同事 / 朋友，给他 5 分钟质疑你的核心假设 |
| 22-28 min | 反向证据 | 写下 3 个"可能让你判断错的证据"——然后去搜索它们 |
| 28-30 min | 修正 | 在原始判断上加一句"但是……"——任何不加"但是"的洞察都是危险的 |
输出：1 个修正后的核心假设 + 3 个反向证据清单。
常见误区
| 误区 | 修正 |
|---|---|
| 批判性思维 = 批评别人 | 不是——是反思自己的思考过程 |
| 批判性思维会拖慢决策 | 恰恰相反——避免做错决策后 10 倍返工 |
| 认知偏差可以完全消除 | 不可能——只能识别 + 修正 |
| "我没偏差" | 这是最大的偏差（Dunning-Kruger） |
| 批判性思维 = 悲观主义 | 不是——是"乐观地搜索反方证据" |
与其他工具的关系
- 元位置：批判性思维是 01 用户洞察 全部工具的元校验——每个工具用完后都要回头做一次
- 特别相关：工具二 Schlep Blindness（识别心理性回避 = 批判性思维应用在自己身上）、工具三 用户访谈 5 问法的反偏差技巧
- 配套：工具十 设计思维——设计思维 + 批判性思维是用户洞察的"两根支柱"
- 下游模块：04 反向推演 Pre-Mortem——批判性思维的"战略级版本"
11 个工具的整体关系图
这 11 个工具的本质：从"零 idea"到"清晰的、可验证的用户洞察 + 100 个 love 用户"的 9 步操作 + 2 个贯穿全程的元方法论——
主流程 9 步（操作工具）：
- 怎么找到 idea：从场景观察/自身不满发现值得解决的问题
- Schlep Blindness：刻意识别你心理性回避的麻烦领域——机会藏在 schlep 里
- 用户访谈 5 问法：所有洞察工具的基础设施——访谈质量决定下游工具质量
- Persona：从访谈数据抽象出 1-3 个可讨论的具体人
- Empathy Map：把 Persona 放到具体场景，画出她"在想/听/看/说/做/PAIN/GAIN"
- Journey Map：基于 Persona 画时间线，找痛点峰值
- JTBD：理解"用户雇佣产品是为了完成什么任务"——重定义竞争
- 第一性原理：用本质推演验证你的 idea 经不经得起拷问
- Make something users LOVE：不只是 want——做出 100 个死忠用户，是 retention 的源头
横切 2 个（元方法论）：
- 设计思维（Design Thinking）：把工具 1-7 串成 IDEO 5 步法的 Empathize + Define 操作化——李泽湘"科创新工科四大件"之首，回答"用户洞察具体怎么做"
- 批判性思维（Critical Thinking）：反思整个思考过程——避免确认偏差/可得性/锚定/幸存者偏差/投射，是用户洞察全流程的元校验
而这张地图，就是下一模块《02 · 价值与商业模式》中**价值主张画布（VPC）**的右半边——也就是你产品要服务的对象。
关联文档
本模块内：本页是 01 模块的唯一文档。
本模块其他章节：
- 00 · 开始之前：合伙人选择——本模块的零号前提
- 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(2020 至今)——5 种不公平优势框架（创始人独特优势、市场增长、10x 产品、获客模式、垄断动力学）
- 李泽湘 "十字路口观察法"(1979)——卡耐基梅隆大学的设计思维启蒙作业
- 李泽湘 "场景驱动创新"(2024 公开演讲)——不会先想技术再找应用，而是从真实场景中的"不合理"出发
- 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)——田野观察方法论
- Elon Musk "First Principles"(2012 TED)——第一性原理的经典案例