问题定义
何时使用此技能
当你需要：
- •撰写问题陈述或定义问题空间
- •区分「客户问题」与「业务问题」
- •使用 JTBD（待办任务）框架分析用户需求
- •验证问题是否值得解决
核心原则
1. 从挣扎时刻出发，而非从解决方案出发
记录用户感到卡住的具体场景，而不是从技术能力开始思考。
2. 区分客户问题与业务问题
「找不到我需要的东西」是客户问题；「需要更多收入」是业务问题。反复问「为什么」来找到底层的客户问题。
3. 观察用户，而非只是询问
观察实际工作流程、屏幕共享、手动变通方案。用户会将痛苦常态化，无法表达隐藏的问题。
4. 用量化的具体性定义问题
明确谁有这个问题、发生频率、严重程度。量化影响（例如：10%用户每天10次 vs 80%用户每月1次）。
5. 先解决，后规模化
抵制过早规模化的冲动。在发现阶段接受混乱；在扩展解决方案之前，专注于找到正确的问题。
专家洞察
Bret Taylor
"这只是之前某个东西的数字版本……为什么要用这个而不是黄页？它只是之前某个东西的数字版本。"
核心洞察：仅仅将模拟前身数字化往往会失败，因为它缺乏在新平台上存在的原生理由。
如何应用：
- •问「为什么客户要关注这个？」，对比非数字替代品
- •避免只是复制现有数字竞争对手的「跟风」产品
Jake Knapp + John Zeratsky
"这个想法是关于打破僵局，把你一直在讨论的抽象想法或概念，变成一个具体的原型——你可以看到、点击、实际尝试的东西。这在很多不同的场景中都有效。"
核心洞察：从抽象概念转向具体原型是定义和解决问题的最快方式。
如何应用：
- •将抽象讨论转化为可点击的原型以获得清晰度
- •在花费数月开发之前，用原型验证方向是否正确
Marily Nika
"有一种叫做'闪亮物体陷阱'的东西，我总是告诉人们：'嘿，不要为了做 AI 而做 AI。' 确保那里存在一个问题。确保有一个需要用智能方式解决的痛点。"
核心洞察：避免「闪亮物体陷阱」——确保 AI 是用来解决特定的、已验证的用户痛点，而不是为了技术本身。
如何应用：
- •在确定实现技术之前，先识别问题和高层解决方案
- •整合 AI 时，先关注「为什么」，再关注「怎么做」
Marty Cagan
"人们不买问题，他们买你的解决方案。显然，如果不能解决他们关心的事情，他们不会买。但有很多产品都在解决他们关心的事情。真正的问题是：你是否比其他所有人都解决得更好，让他们选择你？这才是关键……"
核心洞察：理解问题是必要的，但竞争优势和客户购买决策来自解决方案的质量。
如何应用：
- •如果问题已经被充分理解，限制花在问题验证上的时间
- •将大部分发现时间分配给寻找制胜的解决方案
Ryan Singer
"第一件事是，除非我们能从一开始就看到结局，否则我们不会启动任何事情。我们不会拿一个大概念然后说：'这个东西的估算是多少？'"
核心洞察：对最终结果的清晰认知是启动任何开发工作的先决条件。
如何应用：
- •确保团队在投入资源之前能够可视化完成的功能
- •避免从尚未被锐化为具体想法的「模糊」概念开始
常见错误
- •从技术/功能出发，寻找问题
- •接受模糊的问题陈述而不深挖
- •混淆业务问题与客户问题
- •只询问而不观察
- •试图规模化未验证的解决方案
关键战术
| 战术 | 说明 |
|---|---|
| 摩擦日志 | 系统性记录用户痛点 |
| 屏幕共享 | 观察用户完成工作流程 |
| 问题日记 | 记录日常烦恼，不立即解决 |
| 五个为什么 | 反复问「为什么」以找到根本原因 |
| MECE框架 | 将问题分解为互斥、完全穷尽的类别 |
相关技能
- •[[05-北极星指标-north-star-metrics|北极星指标]]
- •[[04-产品愿景-product-vision|产品愿景]]
- •[[07-路线图优先级-roadmap-prioritization|路线图优先级]]
- •[[06-OKR目标设定-okrs-goals|OKR目标设定]]