问题定义

问题定义

何时使用此技能

当你需要：

• 撰写问题陈述或定义问题空间
• 区分「客户问题」与「业务问题」
• 使用 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

"第一件事是，除非我们能从一开始就看到结局，否则我们不会启动任何事情。我们不会拿一个大概念然后说：'这个东西的估算是多少？'"

核心洞察：对最终结果的清晰认知是启动任何开发工作的先决条件。

如何应用：

• 确保团队在投入资源之前能够可视化完成的功能
• 避免从尚未被锐化为具体想法的「模糊」概念开始

常见错误

• 从技术/功能出发，寻找问题
• 接受模糊的问题陈述而不深挖
• 混淆业务问题与客户问题
• 只询问而不观察
• 试图规模化未验证的解决方案

关键战术

相关技能

• [[05-北极星指标-north-star-metrics|北极星指标]]
• [[04-产品愿景-product-vision|产品愿景]]
• [[07-路线图优先级-roadmap-prioritization|路线图优先级]]
• [[06-OKR目标设定-okrs-goals|OKR目标设定]]