docs(guide): add new appendix sections for product thinking
add four new appendix sections covering idea sources, double diamond model, jobs to be done, and mom test interview method. includes both zh-cn and en versions with comprehensive content and navigation updates. update introduction.md and stage-0 index files to include new sections in tables of contents. add sidebar navigation entries in config.mjs for all languages. each new appendix provides beginner-friendly explanations, practical frameworks, and AI integration tips for product development and validation.
This commit is contained in:
sanbuphy
@@ -42,6 +42,10 @@
|
||||
| :-------------------------------------------------------------------- | :---------------------------------------- | :--- |
|
||||
| [附录A：产品思维补充](/zh-cn/stage-1/appendix-a-product-thinking/) | 从想法评估到需求拆解与 MVP 的产品思维框架 | ✅ |
|
||||
| [附录B：常见报错及解决方案](/zh-cn/stage-1/appendix-b-common-errors/) | vibe coding 中的常见错误及排查方法 | ✅ |
|
||||
| [附录：从哪里找点子](/zh-cn/stage-1/appendix-idea-sources/) | 从参考应用、趋势和 VC 清单里收出细分方向 | ✅ |
|
||||
| [附录：双钻模型](/zh-cn/stage-1/appendix-double-diamond/) | 理解先定义问题，再展开方案设计的完整节奏 | ✅ |
|
||||
| [附录：Jobs to Be Done](/zh-cn/stage-1/appendix-jobs-to-be-done/) | 用 JTBD 方法看清用户真正想完成的事 | ✅ |
|
||||
| [附录：The Mom Test 用户访谈法](/zh-cn/stage-1/appendix-mom-test/) | 通过用户访谈验证需求的调研方法 | ✅ |
|
||||
|
||||
### 二、初中级开发工程师
|
||||
|
||||
|
||||
@@ -82,6 +82,38 @@
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### 附录：用户研究与需求验证
|
||||
|
||||
**为什么需要**：当你已经有了产品点子，但还不确定它是不是真需求、该如何和用户聊、该优先验证什么时，这组内容能帮你把模糊感觉变成可验证的判断。
|
||||
|
||||
**什么时候看**：
|
||||
- 当你说不清用户到底在“雇用”你的产品完成什么事时
|
||||
- 当你准备做用户访谈，却担心只得到礼貌性反馈时
|
||||
- 当你想把“感觉不错”的点子，变成更扎实的需求假设时
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-idea-sources/"
|
||||
title="从哪里找点子"
|
||||
description="学会从参考应用、行业趋势和 VC 清单里，收出一个更具体的产品方向。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-double-diamond/"
|
||||
title="双钻模型入门"
|
||||
description="理解 Discover、Define、Develop、Deliver 四步，避免还没想清楚问题就急着做原型。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-jobs-to-be-done/"
|
||||
title="Jobs to Be Done 入门"
|
||||
description="用 JTBD 方法看清用户真正想完成的事，判断需求和产品方向。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-mom-test/"
|
||||
title="The Mom Test 用户访谈法"
|
||||
description="学会正确和用户聊天，避免只听到“听起来不错”的假阳性反馈。"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### 附录：技术方案
|
||||
|
||||
**为什么需要**：在开发过程中遇到技术问题或想了解更优工具时，这些技术附录能提供即查即用的解决方案。
|
||||
|
||||
@@ -0,0 +1,544 @@
|
||||
---
|
||||
title: '双钻模型：先做对的事，再把事做对'
|
||||
description: '面向零基础读者的 Double Diamond 入门文章。理解 Discover、Define、Develop、Deliver 四个阶段，避免在问题还没搞清楚时就急着做原型。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 双钻模型：先做对的事，再把事做对
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', '设计思维', '需求分析', '方案设计']"
|
||||
coreOutput="1 个更清楚的问题定义和 1 个更合理的验证切口"
|
||||
expectedOutput="不再一上来就急着画原型，而是知道先想清楚问题，再比较方案"
|
||||
>
|
||||
|
||||
很多人第一次做产品时，最容易踩的坑不是“不够努力”，而是太快进入解决方案。
|
||||
|
||||
脑子里刚冒出一个方向，就开始想页面怎么画、按钮放哪、要不要接 AI、要不要做登录注册、原型用什么工具画。忙了一圈之后，才发现最根本的问题根本没想清楚：用户到底是不是真的有这个痛点？这个问题值不值得现在解决？你以为自己在推进项目，其实只是很努力地在错误方向上加速。
|
||||
|
||||
双钻模型（Double Diamond）就是用来避免这种情况的。
|
||||
|
||||
它最有价值的提醒是：**“做对的事情”和“把事情做对”，是两个完全不同的阶段。** 如果你还没搞清楚问题，就急着冲去做原型，通常只会把错误方向做得更完整。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚做产品时什么时候该先想问题，什么时候才该开始想方案和原型，避免一上来就在错误方向上做得很认真。
|
||||
|
||||
**行动项**：按 `Discover → Define → Develop → Deliver` 四步往下走，每一步只做当前阶段该做的事。
|
||||
|
||||
**结果**：你会得到一个更清楚的问题定义、几种可比较的方案，以及一个可验证的最小版本。
|
||||
|
||||
**关键词跳转**：[双钻模型是什么](#dd-what) · [第一个钻石](#dd-first) · [AI 怎么帮你](#dd-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 双钻模型是什么，为什么它适合零基础做产品时使用
|
||||
2. Discover、Define、Develop、Deliver 四个阶段分别在做什么
|
||||
3. 怎样区分“现在应该继续发散”还是“现在应该开始收敛”
|
||||
4. 如何把双钻模型用在 AI 产品、原型设计和需求验证里
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## 1. 双钻模型到底是什么 [↩ 回到开头](#top-dd)
|
||||
|
||||
双钻模型是英国 **Design Council** 推广的一套经典设计流程框架。它把一个完整的设计与创新过程，画成两个连续的钻石形状。
|
||||
|
||||
之所以是“钻石”，是因为每个钻石都包含两种相反但都很重要的动作：
|
||||
|
||||
- **发散**：先把视野打开，看更多可能性
|
||||
- **收敛**：再把范围缩小，做出判断和取舍
|
||||
|
||||
整个过程一共四步：
|
||||
|
||||
1. **Discover**：广泛了解用户、问题、环境和市场
|
||||
2. **Define**：从大量信息里提炼出真正值得解决的核心问题
|
||||
3. **Develop**：围绕核心问题发散多种解决方案
|
||||
4. **Deliver**：筛选、原型、测试并交付更合适的方案
|
||||
|
||||
如果把这四步压缩成一句最容易记住的话，就是：
|
||||
|
||||
- **第一个钻石**：先搞清楚到底要解决什么问题
|
||||
- **第二个钻石**：再决定用什么方案去解决它
|
||||
|
||||
这也是你刚才说得很准确的那句话：
|
||||
|
||||
- **第一个钻石：做对的事情**
|
||||
- **第二个钻石：把事情做对**
|
||||
|
||||
## 2. 为什么双钻模型特别适合新手
|
||||
|
||||
新手做产品最常见的节奏，往往是这样的：
|
||||
|
||||
- 想到一个点子
|
||||
- 觉得这个方向很酷
|
||||
- 马上开始画原型
|
||||
- 做着做着发现功能越来越多
|
||||
- 最后不知道自己到底在解决什么问题
|
||||
|
||||
双钻模型的价值，不在于让流程变复杂，而在于 **强迫你把“理解问题”和“设计方案”拆开** 。
|
||||
|
||||
这件事听起来很普通，但实际非常重要。因为很多失败的产品，不是执行不认真，而是：
|
||||
|
||||
- 选错了问题
|
||||
- 误解了用户
|
||||
- 过早锁定了解决方案
|
||||
- 把大量时间花在细节打磨上，却没有验证方向
|
||||
|
||||
双钻模型就是在不断提醒你：
|
||||
|
||||
- 不要因为想法顺手，就默认问题已经成立
|
||||
- 不要因为方案能做出来，就默认它值得做
|
||||
- 不要因为原型看起来完整，就默认用户会真的需要
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## 3. 第一个钻石：做对的事情 [↩ 回到开头](#top-dd)
|
||||
|
||||
第一个钻石关注的是 **问题本身** ，而不是解决方案。
|
||||
|
||||
你可以把它理解成一句话：**先别急着做，先搞清楚到底值不值得做。**
|
||||
|
||||
### 3.1 Discover：先把问题空间打开
|
||||
|
||||
Discover 阶段的核心任务，是 **广泛调研，而不是快速下结论。**
|
||||
|
||||
这一步通常会做的事情包括：
|
||||
|
||||
- 看用户在真实场景里怎么做
|
||||
- 访谈潜在用户，了解他们最近一次遇到问题是什么时候
|
||||
- 观察他们现在怎么凑合解决
|
||||
- 看竞品和替代方案都在怎么处理
|
||||
- 收集市场、流程、约束、上下游信息
|
||||
|
||||
很多人会误以为 Discover 就是“多看点资料”。其实更关键的是：**你要理解人和场景，而不只是搜一堆信息。**
|
||||
|
||||
比如你想做一个“AI 帮忙整理会议纪要”的工具，在 Discover 阶段更应该关注的是：
|
||||
|
||||
- 用户开完会后到底哪里最痛苦
|
||||
- 是记录难，还是整理难，还是同步难
|
||||
- 他们现在是自己写、让实习生写、录音回听，还是干脆不整理
|
||||
- 哪些会议场景最需要纪要，哪些根本不需要
|
||||
|
||||
这一步最重要的目标不是得出答案，而是 **别太早以为自己已经知道答案。**
|
||||
|
||||
### 3.2 Define：从一堆信息里提炼出核心问题
|
||||
|
||||
如果 Discover 是打开视野，Define 就是开始收束。
|
||||
|
||||
Define 阶段要做的，不是把所有观察都保留下来，而是问：
|
||||
|
||||
- 真正最值得优先解决的问题是哪一个
|
||||
- 哪个问题最常出现、最痛、最有价值
|
||||
- 我们第一版到底只盯住哪一个场景
|
||||
|
||||
这一步的核心，是把一个宽泛话题，收敛成一个清晰问题定义。
|
||||
|
||||
比如你一开始说：
|
||||
|
||||
> 我想做一个提高开会效率的 AI 工具。
|
||||
|
||||
到了 Define 阶段，更好的表达可能会变成：
|
||||
|
||||
> 我们先解决项目型团队在 30 到 60 分钟协作会议结束后，无法在 10 分钟内输出带待办、责任人和截止时间的纪要这个问题。
|
||||
|
||||
这时候问题就开始变清楚了：
|
||||
|
||||
- 用户是谁
|
||||
- 场景是什么
|
||||
- 卡点是什么
|
||||
- 成功标准是什么
|
||||
|
||||
Define 的本质，就是 **从“问题很多”收敛到“这次先解决哪一个问题”。**
|
||||
|
||||
## 4. 第二个钻石：把事情做对
|
||||
|
||||
当你完成第一个钻石后，才真正适合进入第二个钻石。因为这时你解决的不是一个模糊方向，而是一个被收敛过的具体问题。
|
||||
|
||||
### 4.1 Develop：围绕核心问题发散方案
|
||||
|
||||
Develop 阶段的重点，是 **围绕同一个问题，探索多种可能方案。**
|
||||
|
||||
注意，这里的发散和 Discover 阶段不一样。
|
||||
|
||||
- Discover 的发散，是在探索问题空间
|
||||
- Develop 的发散，是在探索解决方案空间
|
||||
|
||||
比如还是会议纪要这个例子，到了 Develop 阶段，你可以开始想：
|
||||
|
||||
- 是做网页工具，还是会议插件
|
||||
- 是上传录音后处理，还是实时记录
|
||||
- 是只做摘要，还是重点做待办提取
|
||||
- 是强调个人效率，还是强调团队同步
|
||||
- 是给用户自由编辑，还是直接输出结构化模板
|
||||
|
||||
这一步很适合脑暴，也很适合和团队一起把方案拉开。
|
||||
|
||||
但这里有一个前提：**所有方案都必须服务同一个已定义的问题。**
|
||||
如果问题没定义清楚，Develop 很容易又重新变成功能乱飞。
|
||||
|
||||
### 4.2 Deliver：选择方案、做原型、测试和交付
|
||||
|
||||
Deliver 阶段是第二个钻石里的收敛阶段。
|
||||
|
||||
这时你要做的不是继续想更多，而是开始判断：
|
||||
|
||||
- 哪个方案最适合当前阶段
|
||||
- 哪个版本最小但最有用
|
||||
- 哪些功能必须先做，哪些可以以后再说
|
||||
- 怎么做原型、测试和小范围验证
|
||||
|
||||
很多人以为 Deliver 就等于“上线”。其实它更准确的意思是：**把一个方案变成可测试、可验证、可迭代的东西。**
|
||||
|
||||
它可能是：
|
||||
|
||||
- 一张低保真流程图
|
||||
- 一个 Figma 原型
|
||||
- 一个可运行的 MVP
|
||||
- 一次小规模用户测试
|
||||
- 一轮真实反馈后的迭代版本
|
||||
|
||||
Deliver 的重点不是“完美交付”，而是 **尽快把方案放进真实环境里验证。**
|
||||
|
||||
## 5. 一个最容易记住的对照表
|
||||
|
||||
如果你总是分不清四个阶段，可以直接记下面这个版本：
|
||||
|
||||
| 阶段 | 你在做什么 | 关键词 | 常见产出 |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | 理解问题 | 调研、观察、访谈、收集信息 | 用户洞察、场景笔记、问题清单 |
|
||||
| Define | 定义问题 | 提炼、聚焦、取舍、重写问题 | 问题定义、优先级、MVP 切口 |
|
||||
| Develop | 探索方案 | 脑暴、比较、共创、原型设想 | 方案列表、流程草图、原型方向 |
|
||||
| Deliver | 验证方案 | 原型、测试、迭代、交付 | 原型、测试反馈、优化版本 |
|
||||
|
||||
再压缩一点，就是这样：
|
||||
|
||||
- **Discover / Define**：解决“做对的事情”
|
||||
- **Develop / Deliver**：解决“把事情做对”
|
||||
|
||||
## 6. 双钻模型最常见的误区
|
||||
|
||||
### 6.1 还没 Discover，就直接 Deliver
|
||||
|
||||
这是最常见的一种。很多人刚有想法就开画原型、写 PRD、接模型、做页面。
|
||||
|
||||
问题不是你做得不认真，而是你可能根本还没确认问题值不值得解决。
|
||||
|
||||
### 6.2 Discover 很久，但始终不 Define
|
||||
|
||||
另一种极端是一直调研、一直看资料、一直访谈，却迟迟不敢收敛。
|
||||
|
||||
双钻不是让你无限发散，而是提醒你：发散之后必须进入判断和取舍。
|
||||
|
||||
### 6.3 Define 之后，又偷偷改问题
|
||||
|
||||
很多团队会在 Develop 时因为某个方案更容易做，就反过来修改问题定义，让它适配现有方案。
|
||||
|
||||
这很危险。因为你可能不是在解决问题，而是在为自己偏爱的方案找理由。
|
||||
|
||||
### 6.4 把 Deliver 误解成“大而全上线”
|
||||
|
||||
Deliver 不是说必须把完整产品都做完才算结束。很多时候，一个可以测试的原型、一轮真实用户试用，已经是很好的 deliver。
|
||||
|
||||
## 7. 在 AI 产品里，双钻模型怎么用
|
||||
|
||||
AI 产品特别容易掉进“能力先行”的坑里，因为模型能力看起来太诱人了。你会很想直接去想：
|
||||
|
||||
- 要不要接多模态
|
||||
- 要不要做 Agent
|
||||
- 要不要加工作流
|
||||
- 要不要接语音、图像、联网搜索
|
||||
|
||||
但双钻模型会逼你先问：
|
||||
|
||||
- 用户到底在哪个环节真的卡住了
|
||||
- 这个卡点是不是非 AI 不可
|
||||
- 如果不用 AI，现有办法到底哪里最差
|
||||
- AI 加进去之后，最核心的进展是什么
|
||||
|
||||
这能帮你避免一种常见情况：**能力很强，价值很弱。**
|
||||
|
||||
一个实用的顺序是：
|
||||
|
||||
1. 在 Discover 阶段观察用户现在怎么处理任务
|
||||
2. 在 Define 阶段把最痛的一个场景写成一句清晰的问题定义
|
||||
3. 在 Develop 阶段再去比较哪些 AI 能力最适合服务这个问题
|
||||
4. 在 Deliver 阶段做一个最小版本，让真实用户测试
|
||||
|
||||
## 8. 可以直接套用的双钻模板
|
||||
|
||||
如果你正在做自己的产品，可以先按这个顺序往下写：
|
||||
|
||||
### Discover
|
||||
|
||||
- 我观察到的用户是谁？
|
||||
- 他们最近一次遇到这个问题是什么时候？
|
||||
- 他们现在怎么解决？
|
||||
- 他们最烦、最慢、最不放心的地方是什么？
|
||||
|
||||
### Define
|
||||
|
||||
- 这堆问题里，最值得优先解决的是哪一个？
|
||||
- 哪个场景最高频，或者最关键？
|
||||
- 我们第一版先只服务谁、只解决什么？
|
||||
- 成功解决后，用户状态会发生什么变化？
|
||||
|
||||
### Develop
|
||||
|
||||
- 针对这个问题，有哪些可能方案？
|
||||
- 哪些方案最轻、最快、最容易验证？
|
||||
- 哪些是必须做，哪些是以后再说？
|
||||
|
||||
### Deliver
|
||||
|
||||
- 我们最小可以交付什么来验证这个方向？
|
||||
- 是流程图、原型，还是 MVP？
|
||||
- 需要找谁测试？
|
||||
- 测试后怎样判断要继续、修改还是放弃？
|
||||
|
||||
## 9. 一个从零基础也能看懂的例子
|
||||
|
||||
假设你想做一个“帮大学生准备求职简历”的 AI 工具。
|
||||
|
||||
很多人一开始就会直接进入第二个钻石，开始想：
|
||||
|
||||
- 要不要一键美化
|
||||
- 要不要智能改写
|
||||
- 要不要自动匹配 JD
|
||||
- 要不要生成自我介绍
|
||||
|
||||
但按双钻模型，更好的过程会是这样：
|
||||
|
||||
### 第一个钻石
|
||||
|
||||
**Discover**
|
||||
|
||||
- 去聊应届生最近一次改简历是什么时候
|
||||
- 看他们怎么从旧简历改成新版本
|
||||
- 了解他们最困扰的是“不会写”“不会改”，还是“不会判断好不好”
|
||||
|
||||
**Define**
|
||||
|
||||
- 最后收敛出一个更具体的问题：
|
||||
- 不是“大学生不会做简历”
|
||||
- 而是“第一次投递实习的学生，很难把已有经历改写成贴合岗位的表达，因此拖延投递”
|
||||
|
||||
### 第二个钻石
|
||||
|
||||
**Develop**
|
||||
|
||||
- 想几种方案：模板库、AI 改写、岗位对照、简历评分、案例参考
|
||||
|
||||
**Deliver**
|
||||
|
||||
- 第一版只做“根据岗位描述改写经历 bullet points”
|
||||
- 给 5 个学生试用，看他们会不会更快投出第一版简历
|
||||
|
||||
你会发现，一旦第一个钻石做扎实，第二个钻石会清楚很多。
|
||||
|
||||
## 10. 小结
|
||||
|
||||
双钻模型最有力量的地方，是它帮你把一整团混乱拆成了四个更清楚的动作：
|
||||
|
||||
- 先发散理解问题
|
||||
- 再收敛定义问题
|
||||
- 再发散探索方案
|
||||
- 最后收敛交付方案
|
||||
|
||||
它不是让你变慢，而是让你 **少走很多看起来很忙、其实方向不对的弯路。**
|
||||
|
||||
尤其在 AI 时代，做东西变得越来越快，双钻模型反而更重要。因为当“做出来”越来越容易时，真正稀缺的能力会变成：**你有没有在解决一个值得解决的问题，以及你有没有用合适的方式去解决它。**
|
||||
|
||||
记住这一句就够了：
|
||||
|
||||
**先做对的事情，再把事情做对。**
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## 11. 如何利用 AI 帮你跑双钻流程 [↩ 回到开头](#top-dd)
|
||||
|
||||
双钻模型本身不是 AI 工具，但 AI 很适合在四个阶段里充当“加速器”。关键不是让 AI 替你决策，而是让它帮你扩展视野、整理信息、比较方案和生成验证材料。
|
||||
|
||||
### 11.1 在 Discover 阶段，用 AI 先做一轮信息铺垫
|
||||
|
||||
在正式访谈和调研前，你可以先让 AI 帮你做一些轻量级问题扫描，比如：
|
||||
|
||||
- 市面上常见替代方案有哪些
|
||||
- 用户在公开社区里最常抱怨什么
|
||||
- 这个问题常见于哪些场景和人群
|
||||
- 现有产品通常忽略了什么
|
||||
|
||||
这一步不能代替真实调研，但很适合帮你快速搭一个问题地图。
|
||||
|
||||
一个很简单的小白输入可以是：
|
||||
|
||||
```text
|
||||
我想做一个帮大学生改简历的工具。
|
||||
你先别帮我想功能，先帮我看看大家在这个问题上最常遇到什么麻烦。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
初步问题地图：
|
||||
|
||||
1. 不知道该写什么经历
|
||||
2. 不知道怎么针对岗位修改
|
||||
3. 改了很多版还是不确定是否够好
|
||||
4. 需要别人帮看，但不方便总麻烦别人
|
||||
5. 因为不确定，所以一直拖着不投
|
||||
```
|
||||
|
||||
这种输出的作用不是替你下结论，而是让你更快进入 Discover。
|
||||
|
||||
### 11.2 在 Define 阶段，让 AI 帮你收敛问题定义
|
||||
|
||||
很多人收集了一堆资料之后，最难的是把问题收成一句真正清楚的话。你可以把调研笔记交给 AI，让它帮你压缩成几个候选问题定义：
|
||||
|
||||
```text
|
||||
下面是我在 Discover 阶段收集到的用户反馈和调研笔记：
|
||||
[贴上内容]
|
||||
|
||||
请你帮我做三件事：
|
||||
1. 归纳最常出现的问题模式
|
||||
2. 按问题频率、痛感和可验证性，整理出 3 个值得优先解决的问题
|
||||
3. 把每个问题写成一句具体的问题定义
|
||||
```
|
||||
|
||||
这样你会更容易进入 Define，而不是一直停留在“问题好多”的状态里。
|
||||
|
||||
你甚至可以把输入写得非常简单：
|
||||
|
||||
```text
|
||||
我现在收集到的问题有：
|
||||
1. 大家不知道简历写什么
|
||||
2. 大家不知道怎么改
|
||||
3. 大家总觉得没改好，不敢投
|
||||
|
||||
你帮我看看，第一版最适合先解决哪个问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
建议优先解决的问题：
|
||||
|
||||
“第一次投递实习的学生，不确定简历是否已经达到可投递水平，因此会反复修改并拖延投递。”
|
||||
|
||||
原因：
|
||||
1. 这个问题更具体
|
||||
2. 它能解释拖延行为
|
||||
3. 更容易设计一个小版本去验证
|
||||
```
|
||||
|
||||
这类输出很有用，因为它帮你从一堆模糊问题里收出一个更像 MVP 起点的定义。
|
||||
|
||||
### 11.3 在 Develop 阶段，用 AI 发散多个方案
|
||||
|
||||
很多人一定义完问题，就只盯着脑子里第一个想到的方案。AI 在这一步很适合帮你强制发散：
|
||||
|
||||
```text
|
||||
我已经定义了一个核心问题：[你的问题定义]
|
||||
请你不要直接给我一个最终答案，而是从以下角度各提出 2-3 种解决方向：
|
||||
1. 最轻量的 MVP
|
||||
2. 最适合验证需求的方案
|
||||
3. 最适合提高体验的方案
|
||||
4. 不依赖 AI 的方案
|
||||
5. 依赖 AI 的方案
|
||||
最后请对比每种方案的优点、风险和验证成本。
|
||||
```
|
||||
|
||||
这样你就不会太早被单一方案绑住。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
我现在的问题定义是：
|
||||
“大学生不确定简历是否已经可以投，所以一直拖着不投。”
|
||||
|
||||
请你帮我想 4 种不同解决方案，不要只给我一种。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
方案 1：简历可投递检查清单
|
||||
方案 2：根据岗位描述做针对性改写
|
||||
方案 3：让用户上传简历后给出风险提示
|
||||
方案 4：提供优秀案例对照，帮助用户判断差距
|
||||
```
|
||||
|
||||
这时你就更容易进入“比较方案”，而不是一上来只盯着 AI 改写一个方向。
|
||||
|
||||
### 11.4 在 Deliver 阶段，用 AI 帮你生成原型文案和测试材料
|
||||
|
||||
当你进入 Deliver 阶段，AI 非常适合帮你加快这些工作：
|
||||
|
||||
- 生成低保真原型里的页面文案
|
||||
- 整理用户测试脚本
|
||||
- 生成可对比的多个版本标题、按钮、说明语
|
||||
- 整理测试后的反馈和问题列表
|
||||
|
||||
比如你可以让 AI 帮你生成一个 20 分钟用户测试脚本，或者帮你把 5 个用户反馈归纳成“继续做 / 修改方向 / 暂停”的判断依据。
|
||||
|
||||
比如一个最小输入可以是：
|
||||
|
||||
```text
|
||||
我做了一个很简单的原型：
|
||||
用户上传简历，系统告诉他哪些地方还不适合投递。
|
||||
|
||||
请帮我生成一份 15 分钟的用户测试脚本。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
15 分钟测试脚本：
|
||||
|
||||
1. 先请用户描述最近一次投简历经历
|
||||
2. 让用户独立完成上传简历
|
||||
3. 观察他是否看得懂反馈结果
|
||||
4. 询问：这些提示里哪些最有帮助，哪些让你困惑
|
||||
5. 询问：如果下次投递前，你会不会想再用一次
|
||||
```
|
||||
|
||||
这种输出很实用，因为它能帮你从“我做完原型了”走到“我接下来怎么测”。
|
||||
|
||||
### 11.5 让 AI 扮演“阶段守门员”
|
||||
|
||||
双钻模型最常见的问题，是人会跳阶段。你可以直接让 AI 充当一个守门员，提醒你现在到底在哪一步：
|
||||
|
||||
```text
|
||||
请你扮演产品流程教练。
|
||||
下面是我当前的项目状态：[你的描述]
|
||||
请你判断我现在更像处于 Discover、Define、Develop 还是 Deliver。
|
||||
并告诉我：
|
||||
1. 我是不是过早跳到了下一阶段
|
||||
2. 当前阶段最该补的动作是什么
|
||||
3. 哪些事情现在先别做
|
||||
```
|
||||
|
||||
这对新手特别有帮助，因为你很容易在“还没想清楚问题时就开始画原型”。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品点子，写出它的 Discover、Define、Develop、Deliver 四步草稿
|
||||
2. 在 Define 阶段，强迫自己把问题缩成一句具体的话
|
||||
3. 在 Develop 阶段，至少列出 3 种不同方案，而不是只盯着第一个想到的做法
|
||||
4. 在 Deliver 阶段，写出一个一周内能交付的最小验证版本
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
这篇文章主要参考了 Design Council 关于 Double Diamond 的官方资料，适合继续往下看：
|
||||
|
||||
- [Design Council: The Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
|
||||
- [Design Council: Framework for Innovation](https://www.designcouncil.org.uk/our-work/skills-learning/tools-frameworks/framework-for-innovation-design-councils-evolved-double-diamond/)
|
||||
- [Design Council: History of the Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/history-of-the-double-diamond/)
|
||||
@@ -0,0 +1,519 @@
|
||||
---
|
||||
title: '从哪里找点子：3 种最适合新手的参考来源'
|
||||
description: '面向零基础读者的产品点子入门文章。学会从参考应用、行业趋势和投资机构清单里找到更具体的方向，并把“看起来很酷”收成一个能尝试的细分点子。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 从哪里找点子：3 种最适合新手的参考来源
|
||||
|
||||
<a id="top-idea-sources"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['找点子', '产品方向', '需求发现', '行业观察']"
|
||||
coreOutput="1 个更具体、能开始验证的细分产品方向"
|
||||
expectedOutput="不再只会刷一堆灵感链接，而是知道怎么从参考里收出一个自己真能试的点子"
|
||||
>
|
||||
|
||||
很多人卡在做产品的第一步，不是不想做，而是根本不知道该从哪开始想。
|
||||
|
||||
脑子里常见的状态是这样的：
|
||||
|
||||
- 想做点 AI 相关的东西，但一时说不清要做什么
|
||||
- 刷了很多“创业灵感”“2026 大趋势”，看完还是很空
|
||||
- 看见别人做得很酷，觉得厉害，但不知道自己能从中切哪一小块
|
||||
|
||||
这时候，你最需要的往往不是再听一遍“要多观察用户”，而是先有一套更容易执行的起点：**去哪里看，怎么看，怎样把一个大方向收成一个更具体的小方向。**
|
||||
|
||||
这篇文章讲的就是这个起点。它不会让你凭空发明一个完美点子，而是帮你学会从现成的参考里，慢慢收出一个更像真实产品方向的东西。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会知道没灵感的时候，应该先去哪里刷，怎么把“一个看起来不错的方向”收成“一个我能尝试的细分点子”。
|
||||
|
||||
**行动项**：先挑 1 个参考应用，再看 1 组趋势来源，最后看 1 轮 VC / 加速器清单；每看完一轮，都写下“谁在什么场景下，愿意为哪一步效率买单”。
|
||||
|
||||
**结果**：你会得到 1 个更具体的尝试方向，而不是只留下“AI + 某行业”这种很空的想法。
|
||||
|
||||
**关键词跳转**：[先看参考应用](#idea-apps) · [再看行业趋势](#idea-trends) · [最后看 VC 清单](#idea-vc) · [怎么收成细分点子](#idea-narrow) · [AI 怎么帮你](#idea-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 为什么很多人不是没有点子，而是不会把模糊灵感收成可尝试的方向
|
||||
2. 三种最适合新手的参考来源：参考应用、趋势来源、VC / 加速器清单
|
||||
3. 每种来源该看什么，不该只看什么
|
||||
4. 怎样从“大方向”进一步收成一个更具体的细分场景和第一版切口
|
||||
|
||||
## 1. 为什么“刷了很多 idea”还是想不出来
|
||||
|
||||
很多人以为自己缺的是灵感，其实更常见的问题是：**看到了很多方向，但没有把方向继续往下压。**
|
||||
|
||||
比如你看到：
|
||||
|
||||
- AI for education
|
||||
- AI for healthcare
|
||||
- AI for finance
|
||||
- AI agent for business
|
||||
|
||||
这些都不算真正的点子，它们更像大类标签。问题在于，大类标签没法直接指导你做第一步。因为它没有告诉你：
|
||||
|
||||
- 是谁在用
|
||||
- 在什么场景下用
|
||||
- 现在怎么勉强解决
|
||||
- 哪一步最值得先切
|
||||
|
||||
所以找点子的关键，不是“看得更多”，而是学会把看到的东西继续往下问。
|
||||
|
||||
你可以反复问自己这 4 句话：
|
||||
|
||||
1. 这到底是谁的问题？
|
||||
2. 这个问题发生在什么具体场景里？
|
||||
3. 他们现在是怎么凑合解决的？
|
||||
4. 我能不能只切其中一步，先做一个很小但有用的版本？
|
||||
|
||||
下面这三种来源，就是帮助你一步步把方向收窄的。
|
||||
|
||||
<a id="idea-apps"></a>
|
||||
## 2. 第一种：先看别人已经在做什么 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这是最适合新手的起点，因为它最具体。
|
||||
|
||||
如果你现在完全没有方向，那比起先看宏大趋势，更好的方法通常是：**先去看别人已经做了哪些产品、哪些小工具、哪些被真实用户讨论的需求。**
|
||||
|
||||
为什么这一步有用？
|
||||
|
||||
- 因为你不用从零想象
|
||||
- 因为你能直接看到产品是怎么描述自己的
|
||||
- 因为你能更快感受到“一个点子被做成产品之后，大概长什么样”
|
||||
|
||||
比较适合拿来刷的地方有三类：
|
||||
|
||||
### 2.1 直接看“别人希望有人做什么”
|
||||
|
||||
- Reddit 的 `r/SomebodyMakeThis`
|
||||
- Reddit 的 `r/AppIdeas`
|
||||
- Reddit 的 `r/Startup_Ideas`
|
||||
|
||||
这类地方的好处是，帖子通常很直接。很多就是用户在说：
|
||||
|
||||
- 我希望有人做一个……
|
||||
- 有没有工具可以帮我……
|
||||
- 我最烦这个流程的地方是……
|
||||
|
||||
它的价值不在于每个帖子都能直接拿来做，而在于你能快速进入一种更真实的需求语境。
|
||||
|
||||
### 2.2 直接看“别人已经做出来并且可能在赚钱什么”
|
||||
|
||||
- Starter Story
|
||||
- Indie Hackers Products
|
||||
- Product Hunt
|
||||
|
||||
这类来源和前面不一样。前面更像“有人在提需求”，这里更像“已经有人把某个需求做成产品了”。
|
||||
|
||||
你看这类网站时，不要只看最火的大产品，更建议看：
|
||||
|
||||
- 月收入不算夸张、但已经有人付费的小产品
|
||||
- 某个行业里反复出现的一类工具
|
||||
- 看起来不酷，但明显在解决具体麻烦的小工具
|
||||
|
||||
很多适合新手切入的方向，恰恰不是那种“会震惊全场”的大项目，而是：
|
||||
|
||||
- 一个流程里很烦的一步
|
||||
- 一个行业里总有人重复在做的整理工作
|
||||
- 一个已有需求但产品还不顺手的细分角落
|
||||
|
||||
### 2.3 不只看产品本身，也看差评和“代做服务”
|
||||
|
||||
这一步非常重要，因为它会让你从“看产品”转向“看没被解决好的地方”。
|
||||
|
||||
你可以去看：
|
||||
|
||||
- G2
|
||||
- Capterra
|
||||
- 国内外一些 SaaS 点评区
|
||||
- 淘宝、闲鱼、Fiverr、Upwork、猪八戒这类平台上的“代做”“代整理”“代处理”服务
|
||||
|
||||
为什么这些地方特别有价值？
|
||||
|
||||
因为差评往往在说：
|
||||
|
||||
- 现有产品哪里不好用
|
||||
- 哪一步还是得手工做
|
||||
- 为什么用户用了还是嫌麻烦
|
||||
|
||||
而“代做服务”在提醒你：
|
||||
|
||||
- 这个需求已经有人在花钱解决
|
||||
- 但现在主要还是靠人工
|
||||
- 其中可能有一部分流程可以被产品化或自动化
|
||||
|
||||
所以，**先看参考应用，不只是为了模仿，而是为了看清楚“别人已经验证了哪一类问题”和“哪些地方还做得不够好”。**
|
||||
|
||||
<a id="idea-trends"></a>
|
||||
## 3. 第二种：再看哪些方向正在起来 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
如果第一种来源帮你看到“现在已经有人在做什么”，那第二种来源更像是在提醒你：**接下来哪些方向可能会越来越值得看。**
|
||||
|
||||
比较典型的来源有：
|
||||
|
||||
- Google Trends
|
||||
- Exploding Topics
|
||||
- 行业研究摘要
|
||||
- 垂直社区、论坛和行业媒体
|
||||
|
||||
看趋势最大的误区，是只停留在“这个词最近很火”。
|
||||
这对做产品帮助不大。你真正该看的是：
|
||||
|
||||
- 哪个词在变热
|
||||
- 这个词落在哪些具体场景里
|
||||
- 哪些人会最早为它付出时间、切换成本或预算
|
||||
|
||||
比如你看到某个趋势方向在涨，不要停在：
|
||||
|
||||
- AI voice
|
||||
- AI healthcare
|
||||
- AI sales
|
||||
|
||||
而是继续问：
|
||||
|
||||
- 是谁最先会为它买单？
|
||||
- 这个趋势会卡进哪个已有工作流？
|
||||
- 哪个子问题最像“现在就值得做”的切口？
|
||||
|
||||
### 3.1 趋势不是点子，它只是放大镜
|
||||
|
||||
趋势的价值，不是直接给你答案，而是帮你缩小搜索范围。
|
||||
|
||||
比如你原本完全没方向，后来看到：
|
||||
|
||||
- 某类 AI 教育工具在持续增长
|
||||
- 某类行业自动化需求开始变热
|
||||
- 某类内容生产方式在快速普及
|
||||
|
||||
这时候你就知道：至少这个大方向现在不是冷门死角。接下来你应该做的不是停在“那我也做 AI 教育”，而是继续往下压：
|
||||
|
||||
- 是面向学生、老师、家长，还是培训机构？
|
||||
- 是上课前、上课中，还是课后复盘？
|
||||
- 是提高效率、降低错误，还是提升转化率？
|
||||
|
||||
### 3.2 如果你想要“更业务”，就看更接近真实工作流的来源
|
||||
|
||||
有些趋势来源偏投资视角，能帮你看大方向；但如果你想再往“谁在真实花钱、谁在真实抱怨”靠近一点，可以继续看：
|
||||
|
||||
- 政府采购和公开招标信息
|
||||
- 企业采购需求和项目招标平台
|
||||
- 行业论坛、职业社区、Reddit 垂直板块
|
||||
- 行业协会报告、行业年度报告
|
||||
|
||||
这些来源更“业务”的原因在于，它们离真实流程更近。你看到的不只是“未来可能值得做什么”，而是：
|
||||
|
||||
- 现在谁已经愿意花钱
|
||||
- 预算大概在哪个区间
|
||||
- 需求写得有多具体
|
||||
- 哪些流程今天仍然靠 Excel、微信、纸笔、电话在硬撑
|
||||
|
||||
如果你能在一个趋势方向里，再补上这些业务信息，你得到的就不只是一个“看起来挺热”的方向，而是一个更像真实市场机会的方向。
|
||||
|
||||
<a id="idea-vc"></a>
|
||||
## 4. 第三种：最后看 VC / 加速器正在追什么 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这一类来源，最典型的就是：
|
||||
|
||||
- Y Combinator 的 `Requests for Startups`
|
||||
- a16z 的 `Big Ideas`
|
||||
- 其他基金或加速器的年度方向清单、行业判断文章
|
||||
|
||||
这类内容很适合在你已经有一点感觉之后再看。因为它能帮你回答一个问题：
|
||||
|
||||
**接下来两三年里，哪些方向可能会被更多资源、技术和创业团队一起推动？**
|
||||
|
||||
它们的价值主要有三点：
|
||||
|
||||
### 4.1 帮你看见“浪往哪边打”
|
||||
|
||||
VC / 加速器通常会从技术变化、政策变化、产业变化里提炼出一些方向。
|
||||
这会让你知道：
|
||||
|
||||
- 哪些问题不只是你一个人觉得有意思
|
||||
- 哪些方向已经具备了“现在开始更有机会”的外部条件
|
||||
- 哪些赛道未来会吸引更多创业团队和资本进入
|
||||
|
||||
### 4.2 帮你快速进入一个赛道的语境
|
||||
|
||||
像 YC RFS 这种内容，往往不会只说“这个行业值得做”，而会直接给出某种更细的切口，比如：
|
||||
|
||||
- 哪类工作流会被 AI 重做
|
||||
- 哪类行业有明显的流程升级机会
|
||||
- 哪类基础设施还不够成熟
|
||||
|
||||
这对新手很有帮助，因为它相当于替你做了第一轮“方向拆解”。
|
||||
|
||||
### 4.3 但它不等于真实需求本身
|
||||
|
||||
这是最重要的一点。
|
||||
|
||||
VC 清单很容易让人产生一种错觉：
|
||||
|
||||
- 这个方向被大机构提了，所以一定能做
|
||||
- 这个概念很新，所以肯定值得做
|
||||
- 我只要顺着这个大词往下讲，就等于有点子了
|
||||
|
||||
其实不是。
|
||||
|
||||
VC / 加速器更擅长告诉你：
|
||||
|
||||
- 未来大浪可能往哪边打
|
||||
|
||||
但它不一定会告诉你：
|
||||
|
||||
- 具体哪个角色最痛
|
||||
- 哪一步流程最卡
|
||||
- 今天谁已经在为这件事付钱
|
||||
|
||||
所以更好的用法是：
|
||||
|
||||
- 先把它当成大方向灵感来源
|
||||
- 再回到真实应用、真实工作流和真实用户抱怨里做下钻
|
||||
|
||||
换句话说，**VC 清单适合帮你找方向，不适合替你完成验证。**
|
||||
|
||||
<a id="idea-narrow"></a>
|
||||
## 5. 怎样把“大方向”收成“我能试一个”的细分点子 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这一段最重要，因为很多人问题不在于没看过来源，而在于不知道怎么收。
|
||||
|
||||
你可以直接套下面这个顺序：
|
||||
|
||||
### 5.1 先选一个你愿意继续看的方向
|
||||
|
||||
不是最宏大、最性感的方向，而是那个你看完之后会觉得：
|
||||
|
||||
- 我大概能理解这个场景
|
||||
- 我愿意继续查 1 小时
|
||||
- 我身边可能就认识一点相关的人
|
||||
|
||||
这一步不用追求完美，只要能进入下一步就够了。
|
||||
|
||||
### 5.2 把方向写成“谁 + 在什么时候 + 卡在哪一步”
|
||||
|
||||
比如不要只写：
|
||||
|
||||
- AI for education
|
||||
- AI for sales
|
||||
- AI for healthcare
|
||||
|
||||
而要尽量写成：
|
||||
|
||||
- 第一次准备投实习的学生，在改简历这一步特别卡
|
||||
- 小型外贸团队，在把供应商报价整理成客户报价单这一步特别慢
|
||||
- 诊所运营人员，在跟进患者方案确认这一步特别依赖人工催促
|
||||
|
||||
一旦你能写到这个程度，方向就已经开始变具体了。
|
||||
|
||||
### 5.3 再问：今天他们是怎么硬撑的
|
||||
|
||||
这一步很关键，因为它能帮你看见现实世界。
|
||||
|
||||
如果答案是：
|
||||
|
||||
- Excel
|
||||
- 微信
|
||||
- 备忘录
|
||||
- 电话
|
||||
- 手工复制粘贴
|
||||
- 找同事帮忙
|
||||
|
||||
那通常说明这里真的有一个可以继续观察的切口。
|
||||
|
||||
### 5.4 最后只切一小步
|
||||
|
||||
不要一上来就想做整个平台。
|
||||
一个更适合新手的思路通常是：
|
||||
|
||||
- 只做工作流里最烦的一步
|
||||
- 只服务一个更具体的人群
|
||||
- 只在一个小场景里把事情做顺
|
||||
|
||||
比如：
|
||||
|
||||
- 不做“求职平台”，先做“按岗位改写简历 bullet points”
|
||||
- 不做“全链路外贸系统”，先做“供应商报价转客户报价单”
|
||||
- 不做“诊所经营系统”，先做“患者方案讲解后的自动跟进提醒”
|
||||
|
||||
**一个更接地的点子，往往不是更大，而是更具体。**
|
||||
|
||||
## 6. 新手最常见的 5 个误区
|
||||
|
||||
### 6.1 把“行业”当“点子”
|
||||
|
||||
“做教育”“做医疗”“做 AI agent”都还是大类，不是点子。
|
||||
|
||||
### 6.2 只刷趋势，不看真实流程
|
||||
|
||||
趋势能给你方向，但不能替你找到具体卡点。
|
||||
|
||||
### 6.3 看见一个应用就想整套复刻
|
||||
|
||||
更有价值的动作通常不是“复制一个大产品”，而是找到它没覆盖好的一个细分场景。
|
||||
|
||||
### 6.4 只看概念，不看谁在付钱
|
||||
|
||||
如果你完全看不到谁在为这个问题投入时间、人工或预算，这个方向就还太虚。
|
||||
|
||||
### 6.5 一开始就想做很大的平台
|
||||
|
||||
新手更容易成功的起点，通常是一个很小但真有用的切口。
|
||||
|
||||
## 7. 小结
|
||||
|
||||
不会找点子，通常不是因为你不够聪明，而是因为你还没有形成一套稳定的“收方向”方法。
|
||||
|
||||
对新手来说，更实用的顺序通常是：
|
||||
|
||||
1. 先看别人已经在做什么，建立具体感觉
|
||||
2. 再看哪些方向正在起来，缩小搜索范围
|
||||
3. 最后看 VC / 加速器清单，补上更大的赛道视角
|
||||
|
||||
然后别停在“这个方向挺酷”，而是继续往下问：
|
||||
|
||||
- 谁最痛？
|
||||
- 在哪一步最痛？
|
||||
- 今天怎么硬撑？
|
||||
- 我能先切哪一小步？
|
||||
|
||||
当你能把一个方向写成“某类人，在某个场景里，被某一步流程卡住”，你就已经比单纯刷 idea 清单更接近一个真正能尝试的产品方向了。
|
||||
|
||||
<a id="idea-ai"></a>
|
||||
## 8. 如何利用 AI 帮你找参考点子 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
找点子这件事，AI 很适合当你的整理助手、比较助手和下钻助手。关键不是让 AI 凭空替你发明创意，而是让它帮你更快把“刷到的东西”收成一个更具体的方向。
|
||||
|
||||
### 8.1 让 AI 帮你把一批来源整理成方向清单
|
||||
|
||||
如果你已经刷了一些站点，可以直接把你看到的标题、链接描述或帖子原话贴给 AI，让它帮你归类。
|
||||
|
||||
一个很简单的小白输入可以这样写：
|
||||
|
||||
```text
|
||||
我最近刷到这些东西：
|
||||
1. 有人想做一个帮学生改简历的工具
|
||||
2. 有人在做会议纪要自动整理
|
||||
3. 有人说诊所患者跟进很麻烦
|
||||
4. 我看到 AI 销售自动化最近很火
|
||||
|
||||
你先不要帮我想很大的创业项目。
|
||||
请你帮我做三件事：
|
||||
1. 把这些方向按人群和场景分类
|
||||
2. 每个方向帮我写出“谁在什么场景卡在哪一步”
|
||||
3. 挑出 3 个更适合新手先试的方向，并说为什么
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
适合先试的 3 个方向：
|
||||
|
||||
1. 第一次投实习的学生，在“把旧简历改成贴合岗位的版本”这一步卡住
|
||||
原因：场景具体、用户容易找到、第一版可以做得很小
|
||||
|
||||
2. 小团队开完协作会议后，在“整理待办和责任人”这一步卡住
|
||||
原因：痛点高频、现有替代方案多是手工整理、输出结果容易验证
|
||||
|
||||
3. 小型诊所运营人员，在“患者听完方案后的后续跟进”这一步卡住
|
||||
原因：业务动作清晰、流程重复、容易找到人工替代方案
|
||||
```
|
||||
|
||||
这种输出的价值，在于它能帮你从一堆散乱灵感里，先收出几个更像“真实场景”的候选方向。
|
||||
|
||||
### 8.2 让 AI 帮你把“大趋势”往下压成细分场景
|
||||
|
||||
有时候你只有一个很大的方向，比如“AI + 教育”或者“AI + 医疗”，这时 AI 很适合帮你做第一轮收窄。
|
||||
|
||||
```text
|
||||
我现在只想到一个很大的方向：[你的大方向]
|
||||
请不要直接给我 50 个功能。
|
||||
请你帮我把它拆成：
|
||||
1. 这个方向里常见的几类用户
|
||||
2. 每类用户最可能卡住的具体场景
|
||||
3. 哪些场景看起来更适合先做一个小工具
|
||||
4. 每个场景今天可能在用什么笨办法硬撑
|
||||
```
|
||||
|
||||
你甚至可以写得更口语一点：
|
||||
|
||||
```text
|
||||
我现在只觉得 AI + 教育好像可以做点什么，
|
||||
但我完全不知道该做给谁、做哪一步。
|
||||
你帮我往具体场景想一想。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
可继续下钻的场景：
|
||||
|
||||
1. 第一次准备投实习的大学生，不知道怎么针对岗位改简历
|
||||
2. 培训机构老师，上完课后整理学生反馈和后续跟进很慢
|
||||
3. 家长，在孩子课后想快速知道今天学了什么和哪里需要补
|
||||
```
|
||||
|
||||
这时候你就已经从“AI + 教育”走到了几个可以继续验证的方向。
|
||||
|
||||
### 8.3 让 AI 帮你做“值不值得继续查”的第一轮判断
|
||||
|
||||
当你已经有两三个方向时，可以让 AI 帮你做一个很轻量的比较。
|
||||
|
||||
```text
|
||||
我现在有 3 个方向：
|
||||
1. [方向 A]
|
||||
2. [方向 B]
|
||||
3. [方向 C]
|
||||
|
||||
请你从下面几个角度帮我比较：
|
||||
1. 场景是否具体
|
||||
2. 用户是否容易找到
|
||||
3. 现在是否已有替代方案
|
||||
4. 第一版是否能做得很小
|
||||
5. 哪个方向更适合我先做 1 周调研
|
||||
```
|
||||
|
||||
一个很小白的版本也可以：
|
||||
|
||||
```text
|
||||
我现在有 3 个想法，但不知道先查哪个。
|
||||
你别直接替我决定，
|
||||
先帮我看看哪个更具体、哪个更容易做第一版。
|
||||
```
|
||||
|
||||
AI 可能给出这种很有帮助的输出：
|
||||
|
||||
```text
|
||||
建议先查方向 B。
|
||||
|
||||
原因：
|
||||
1. 用户是谁更清楚
|
||||
2. 发生场景更具体
|
||||
3. 当前替代方案明显
|
||||
4. 不需要一开始做很大的系统
|
||||
|
||||
建议你下一步先去找 5 个相关用户，确认他们现在怎么处理这一步。
|
||||
```
|
||||
|
||||
这类输出最有价值的地方，是它能帮新手避免一上来就被“最大、最酷、最像创业故事”的方向吸走。
|
||||
|
||||
## 9. 延伸阅读
|
||||
|
||||
- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
- [Reddit - r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
- [Indie Hackers - Products](https://www.indiehackers.com/products)
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
@@ -0,0 +1,496 @@
|
||||
---
|
||||
title: '用 Jobs to Be Done 找到用户真正想完成的事'
|
||||
description: '面向零基础读者的 Jobs to Be Done 入门文章。理解用户不是在买功能，而是在特定场景里“雇用”你的产品完成进展，并学会用 JTBD 拆解产品方向、访谈问题与 AI 提示词。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 用 Jobs to Be Done 找到用户真正想完成的事
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', '用户需求', '产品思维', '需求洞察']"
|
||||
coreOutput="1 条更像真实需求的 JTBD 句子"
|
||||
expectedOutput="能把模糊点子收成一个更具体的用户场景和 MVP 方向"
|
||||
>
|
||||
|
||||
很多人刚开始做产品时，最容易犯的一个错误是把注意力全部放在“我要做什么功能”上。看别人有智能分类，你也想加；看别人有自动总结，你也想接；看别人做了 Agent、多模态、工作流，你也觉得自己不能少。
|
||||
|
||||
但现实里，用户很少是因为“这个功能名字很酷”才决定用一个产品。他们更多是在某个具体时刻，想把一件事情推进下去，于是临时“雇用”了一个工具、一个服务，甚至一个人，来帮自己完成这一步。
|
||||
|
||||
这正是 **Jobs to Be Done（JTBD）** 这套方法想提醒我们的事情：**用户不是在购买功能本身，而是在雇用某种解决方案，帮助自己完成一个进展。**
|
||||
|
||||
本篇文章会用尽量直白的语言，带你从零理解 JTBD，并把它变成你做 AI 应用时能直接拿来用的分析工具。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚怎样把一个模糊点子，收成一句真正有用户场景的需求，而不是脑子里只有一堆功能名。
|
||||
|
||||
**行动项**：写 1 句模糊点子，找 3 个潜在用户聊“最近一次怎么处理”，再整理成 1 条 JTBD 句子。
|
||||
|
||||
**结果**：你会得到一个更清楚的需求假设，知道第一版该先解决什么。
|
||||
|
||||
**关键词跳转**：[JTBD 是什么](#jtbd-what) · [一句话公式](#jtbd-formula) · [AI 怎么帮你](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 什么是 Jobs to Be Done，为什么它比“功能脑暴”更接近真实需求
|
||||
2. 如何区分“用户说想要的功能”和“用户真正想完成的事”
|
||||
3. 怎样用一套简单模板，把一个模糊点子拆成场景、触发、障碍和成功标准
|
||||
4. 如何把 JTBD 用在 AI 产品、访谈提问和提示词整理里
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## 1. 什么是 Jobs to Be Done [↩ 回到开头](#top-jtbd)
|
||||
|
||||
Jobs to Be Done 常被简称为 **JTBD**。它背后的核心想法，和 Clayton Christensen 团队推广的那句经典表达有关：**用户会“雇用”某个产品来完成一件事。**
|
||||
|
||||
这里的“事”，不是待办清单里那种表面动作，而是用户希望自己状态发生的一种 **进展** 。比如：
|
||||
|
||||
- 不是“我要一个 AI 纪要工具”，而是“我想在会后 10 分钟内把重点、待办和责任人整理清楚，别再靠回忆补笔记”
|
||||
- 不是“我要一个记账 App”，而是“我想知道钱到底花去哪了，好让我月底别再焦虑”
|
||||
- 不是“我要一个简历优化器”，而是“我想更有把握地投出一份像样的简历，不想每次投递都怀疑自己写得太差”
|
||||
|
||||
所以，**JTBD 关注的不是产品长什么样，而是用户为什么在这个时刻需要它。**
|
||||
|
||||
这也是为什么很多看似不同的产品，实际上在竞争同一个 job。用户想“在上班路上不那么无聊”，可雇用的对象可能是短视频、播客、游戏、聊天，甚至打瞌睡。用户想“快速搞懂一份很长的 PDF”，可雇用的对象可能是 AI 摘要工具、实习生、同事、自己硬着头皮看，或者干脆先不看。
|
||||
|
||||
一旦你用这种视角看问题，你会发现自己真正的竞争对手，往往并不只是“另一个长得像你的 App”，而是 **用户当前所有可接受的替代方案** 。
|
||||
|
||||
## 2. JTBD 和用户画像、功能列表有什么不同
|
||||
|
||||
很多新手刚开始做需求分析时，会先写用户画像：25 岁，女生，一线城市，白领，喜欢效率工具，愿意尝试新产品。这样的信息不能说完全没用，但它通常 **不够解释一个人为什么会在此刻采取行动。**
|
||||
|
||||
JTBD 更关心的是下面这些问题：
|
||||
|
||||
- 他是在什么场景下决定找解决方案的
|
||||
- 当时到底卡住了什么
|
||||
- 他想把什么事情推进到下一步
|
||||
- 现在正在用什么笨办法撑着
|
||||
- 如果事情解决得好，什么结果会让他觉得“值了”
|
||||
|
||||
也就是说，**用户画像更像“这个人大概是谁”，JTBD 更像“这个人现在到底想完成什么”。**
|
||||
|
||||
同样地，功能列表也容易把人带偏。用户说“我想要导出 Word”“我想要 AI 改写”“我想要语音输入”，这些都只是表层表达。JTBD 会继续往下追问：
|
||||
|
||||
- 为什么你现在需要导出 Word，而不是 PDF？
|
||||
- 你想改写，是因为文风太差，还是因为需要适配不同对象？
|
||||
- 你想语音输入，是因为懒得打字，还是因为你经常在走路、开车、开会后马上记录？
|
||||
|
||||
很多时候，**功能只是 job 的一种临时翻译** 。如果你只收集功能，很容易把产品做成“用户说什么就堆什么”；如果你能看见背后的 job，才更有机会做出真正顺手、真正有竞争力的方案。
|
||||
|
||||
## 3. 一个零基础也能理解的例子
|
||||
|
||||
先不要急着想复杂的 AI 产品，我们从一个生活例子开始。
|
||||
|
||||
假设有人早上出门前总来不及吃早餐，于是经常在地铁口买一个三明治和咖啡。表面上看，他“购买”的是早餐；但如果用 JTBD 看，他真正想完成的事可能是：
|
||||
|
||||
- 在赶时间的早晨，用最省脑力的方式解决一顿饭
|
||||
- 让自己在到公司前不至于饿得发慌
|
||||
- 不因为吃早餐耽误通勤节奏
|
||||
|
||||
这时候，用户雇用的不是“某个固定品牌的三明治”，而是一个能帮他把早晨顺利推进下去的解决方案。如果隔壁便利店更快、更近、更稳定，他可能立刻换掉原来的选择。
|
||||
|
||||
把这个逻辑搬到 AI 产品里就更明显了。
|
||||
|
||||
比如你想做一个“AI 会议纪要工具”。如果只停在功能层面，你会很容易开始想：
|
||||
|
||||
- 要不要支持上传音频
|
||||
- 要不要接入说话人分离
|
||||
- 要不要导出 Markdown
|
||||
- 要不要自动生成待办
|
||||
|
||||
这些都没错，但还不够。用 JTBD 再问一层，用户真正想完成的可能是：
|
||||
|
||||
- 我想在会后 10 分钟内，把讨论结果同步给没参会的人
|
||||
- 我想把待办、责任人和截止时间提干净，别让团队靠记忆协作
|
||||
- 我想减少重复整理会议内容的时间，把精力留给决策和推进
|
||||
|
||||
一旦 job 被说清楚，很多功能优先级就会自动浮出来。第一版最重要的也许不是“支持 12 种导出格式”，而是：
|
||||
|
||||
- 纪要结构要足够清楚
|
||||
- 待办提取要稳定
|
||||
- 分享链接要方便
|
||||
- 输出结果要让人敢直接转发给团队
|
||||
|
||||
这就是 JTBD 的价值：**它能帮助你从“我要堆哪些能力”回到“我要帮用户推进什么进展”。**
|
||||
|
||||
## 4. 一个好用的 JTBD 模板
|
||||
|
||||
如果你是零基础，可以先不要试图把 JTBD 想得很学术。先抓住最实用的 5 个要素就够了。
|
||||
|
||||
### 4.1 场景
|
||||
|
||||
用户是在什么时刻、什么环境里想起这个产品的？
|
||||
|
||||
- 是开完会以后
|
||||
- 是老板临时要材料的时候
|
||||
- 是晚上准备投简历的时候
|
||||
- 是月底发现钱又不够花的时候
|
||||
|
||||
**没有场景的需求，通常都还不够真实。**
|
||||
|
||||
### 4.2 触发
|
||||
|
||||
是什么让他决定立刻找解决方案？
|
||||
|
||||
- 被长文档压住，不知道从哪开始看
|
||||
- 明天要交材料，今天才发现格式乱七八糟
|
||||
- 刚被领导追问进度，意识到自己没有整理清楚
|
||||
- 想坚持记录，但手写、复制、整理都太麻烦
|
||||
|
||||
触发点往往带着情绪。这个情绪很重要，因为它决定了用户为什么会在这一刻产生行动。
|
||||
|
||||
### 4.3 想完成的进展
|
||||
|
||||
他不只是想“做个动作”，而是想把自己推进到什么新状态？
|
||||
|
||||
- 从混乱到清楚
|
||||
- 从焦虑到安心
|
||||
- 从拖延到启动
|
||||
- 从低效到顺手
|
||||
- 从说不明白到能直接交付
|
||||
|
||||
这一步里，“进展”这个词非常关键。因为很多人真正买的不是工具，而是 **状态变化** 。
|
||||
|
||||
### 4.4 当前替代方案
|
||||
|
||||
现在没有你的产品时，他怎么做？
|
||||
|
||||
- 手工复制粘贴
|
||||
- 用 Excel 或备忘录硬撑
|
||||
- 找同事帮忙
|
||||
- 拖着不做
|
||||
- 在几个工具之间来回切
|
||||
|
||||
谁是替代方案，谁就是你的真实竞争环境。
|
||||
|
||||
### 4.5 成功标准
|
||||
|
||||
事情怎样才算真的被解决？
|
||||
|
||||
- 10 分钟内得到可分享的结果
|
||||
- 不需要二次大改就能发给别人
|
||||
- 不容易漏项、出错、忘事
|
||||
- 第一次用就知道下一步怎么走
|
||||
|
||||
如果你连“用户怎么判断值不值”都说不清，那这个方向大概率还没有收敛好。
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## 5. 直接套用的一句话公式 [↩ 回到开头](#top-jtbd)
|
||||
|
||||
当你想梳理一个产品方向时，可以先套这个非常实用的句式：
|
||||
|
||||
> 当 __________ 的时候，我想要 __________，以便于 __________。
|
||||
> 现在我只能通过 __________ 来勉强完成这件事。
|
||||
|
||||
比如：
|
||||
|
||||
> 当我开完一场信息量很大的项目会时，我想要快速得到一份带待办、责任人和截止时间的纪要，以便于我能马上同步团队并推进执行。
|
||||
> 现在我只能靠自己回忆、翻聊天记录和手工整理来勉强完成这件事。
|
||||
|
||||
再比如：
|
||||
|
||||
> 当我准备投递一个新岗位时，我想要快速把已有经历改写成更贴合岗位的版本，以便于我能更有把握地投出一份像样的简历。
|
||||
> 现在我只能反复复制旧简历、手改措辞，改到最后越来越不确定。
|
||||
|
||||
如果你能把一句话写到这种清晰程度，后面的页面设计、提示词设计、功能优先级判断，都会容易很多。
|
||||
|
||||
## 6. 做 AI 产品时，特别要看的三层 job
|
||||
|
||||
很多 AI 产品在功能演示时看上去很强，但真正上线之后却留不住人，常见原因是只解决了表层动作，没有解决更深的 job。
|
||||
|
||||
你可以把一个 job 粗略分成三层来看：
|
||||
|
||||
### 6.1 功能层
|
||||
|
||||
最表面的任务是什么？
|
||||
|
||||
- 总结文档
|
||||
- 改写文案
|
||||
- 提取待办
|
||||
- 生成图片
|
||||
|
||||
这是用户嘴上最容易说出来的一层。
|
||||
|
||||
### 6.2 情绪层
|
||||
|
||||
用户希望减少什么不舒服，或者获得什么感受？
|
||||
|
||||
- 不想那么慌
|
||||
- 不想显得不专业
|
||||
- 不想每次都从零开始
|
||||
- 想更有掌控感
|
||||
|
||||
很多付费意愿，实际上和情绪层关系很大。
|
||||
|
||||
### 6.3 社会层
|
||||
|
||||
用户希望在别人眼里变成什么样？
|
||||
|
||||
- 看起来更靠谱
|
||||
- 在团队里更有组织能力
|
||||
- 在客户面前更专业
|
||||
- 在社交平台上更会表达
|
||||
|
||||
如果你只做功能层，产品很容易被替代；如果你同时理解了情绪层和社会层，你就更容易找到真正有黏性的价值。
|
||||
|
||||
## 7. 用 JTBD 反过来筛产品方向
|
||||
|
||||
有时候不是你已经有产品，而是你手里有 3 到 5 个点子，不知道做哪个。这时 JTBD 很适合拿来做筛选。
|
||||
|
||||
你可以拿着每个点子，分别问自己 5 个问题：
|
||||
|
||||
1. 这个点子对应的场景是不是足够具体？
|
||||
2. 用户现在是否已经在用某种笨办法解决？
|
||||
3. 这个 job 的痛感是否足够强，或者足够高频？
|
||||
4. 如果我做好了，用户会不会明显感受到“状态变好了”？
|
||||
5. 第一版能不能只围绕这个 job 的关键一步，做出一个很小但有用的版本？
|
||||
|
||||
如果一个方向讲到最后还是只能说“感觉挺有意思”，却说不清触发、替代方案和成功标准，那它大概率还只是一个模糊灵感，不是一个成熟方向。
|
||||
|
||||
## 8. 可以直接拿去访谈用户的问题
|
||||
|
||||
很多人一做调研就问：“你想要什么功能？”这种问法很容易得到表面答案。
|
||||
|
||||
JTBD 更适合问下面这些问题：
|
||||
|
||||
- 最近一次你遇到这个问题是什么时候？
|
||||
- 当时你在做什么，为什么会卡住？
|
||||
- 你最后是怎么解决的？
|
||||
- 这个过程里最烦、最慢、最不放心的地方是什么？
|
||||
- 如果有一个工具能帮你，什么结果会让你觉得真的有用？
|
||||
- 你试过哪些替代方法？为什么它们不够好？
|
||||
|
||||
这种问法有个好处：它会把对话拉回真实经历，而不是停留在想象中的偏好。
|
||||
|
||||
## 9. 用 AI 帮你做 JTBD 拆解
|
||||
|
||||
JTBD 本身不是 AI 发明的，但 AI 很适合帮你整理和提炼 JTBD。
|
||||
|
||||
比如你已经收集了 5 到 10 条用户反馈，就可以把它们丢给模型，让它按以下结构总结：
|
||||
|
||||
```text
|
||||
请你扮演产品研究助手。
|
||||
我会给你一些用户原话，请你不要先给功能建议，
|
||||
而是先按 Jobs to Be Done 的框架整理：
|
||||
|
||||
1. 用户处在什么场景
|
||||
2. 触发他采取行动的事件是什么
|
||||
3. 他真正想完成的进展是什么
|
||||
4. 当前替代方案是什么
|
||||
5. 他最在意的成功标准是什么
|
||||
6. 这些反馈里反复出现的情绪词有哪些
|
||||
|
||||
最后，请把这些内容整理成 3 个最值得优先验证的 JTBD 假设。
|
||||
```
|
||||
|
||||
如果你已经有一个点子，也可以让 AI 帮你做第一轮收敛：
|
||||
|
||||
```text
|
||||
我想做一个 [你的产品想法]。
|
||||
请不要直接给我功能列表，而是用 Jobs to Be Done 方法帮我分析：
|
||||
|
||||
1. 这个产品可能服务哪些具体场景
|
||||
2. 每个场景中用户想完成的核心 job 是什么
|
||||
3. 现有替代方案有哪些
|
||||
4. 哪个 job 最适合作为 MVP 的起点，为什么
|
||||
5. 请把最终推荐的 job 写成一句清晰的 JTBD 句子
|
||||
```
|
||||
|
||||
这样做的好处是，你不会一上来就被 AI 带去“脑暴 50 个功能”，而是先把方向讲清楚。
|
||||
|
||||
## 10. 新手最常见的 4 个误区
|
||||
|
||||
### 10.1 把 job 写成功能名
|
||||
|
||||
“AI 总结”“智能分类”“自动生成”都不是 job，它们只是可能的实现方式。
|
||||
|
||||
### 10.2 把人群写得很宽
|
||||
|
||||
“所有职场人”“所有学生”“所有创业者”通常都太泛。越泛，你越难看见真实场景。
|
||||
|
||||
### 10.3 只听用户说，不看用户怎么做
|
||||
|
||||
用户会描述自己想要什么，但他真正的优先级，常常藏在他现在如何凑合解决问题里。
|
||||
|
||||
### 10.4 一开始就想做完整平台
|
||||
|
||||
JTBD 的正确打开方式，通常不是“我来做一个包打天下的大平台”，而是先盯住一个场景里最关键的一步，把它做到非常顺手。
|
||||
|
||||
## 11. 小结
|
||||
|
||||
Jobs to Be Done 最有价值的地方，不是给你一个新名词，而是帮你换一个观察角度：**不要只盯着产品功能，而要盯着用户想把什么事情推进到下一步。**
|
||||
|
||||
当你开始反复问自己：
|
||||
|
||||
- 用户是在什么场景下雇用这个产品的
|
||||
- 他到底卡在了哪里
|
||||
- 现在正用什么办法硬撑
|
||||
- 事情解决后，状态会发生什么变化
|
||||
|
||||
你会发现，很多原本模糊的点子一下子变清楚了，很多原本很花哨的功能也一下子没那么重要了。
|
||||
|
||||
做产品，尤其是做 AI 产品，最怕的是一开始就沉迷能力展示。JTBD 能帮你把注意力拉回到真正重要的地方：**用户为什么需要你，以及你到底在帮他完成什么进展。**
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## 12. 如何利用 AI 帮你实践 JTBD [↩ 回到开头](#top-jtbd)
|
||||
|
||||
JTBD 不是 AI 发明的，但 AI 很适合在这套方法里当你的研究助手、整理助手和对照助手。关键是：**让 AI 帮你整理和扩展，而不是替你臆测用户。**
|
||||
|
||||
你可以这样用：
|
||||
|
||||
### 12.1 让 AI 帮你把模糊点子改写成 JTBD 假设
|
||||
|
||||
当你脑子里只有一句模糊描述，比如“我想做一个帮大学生找实习的工具”，可以先让 AI 帮你把它拆成几种可能的 job：
|
||||
|
||||
```text
|
||||
我现在有一个模糊产品点子：[你的点子]
|
||||
请不要直接给我功能列表，而是用 Jobs to Be Done 的方式帮我分析：
|
||||
1. 可能对应哪些具体场景
|
||||
2. 每个场景里用户真正想完成的进展是什么
|
||||
3. 当前替代方案可能是什么
|
||||
4. 哪个 job 最适合先做 MVP
|
||||
请最后把每个 job 写成一句清晰的 JTBD 句子。
|
||||
```
|
||||
|
||||
你甚至可以把输入写得很小白：
|
||||
|
||||
```text
|
||||
我想做一个帮大学生找实习的东西。
|
||||
我现在也说不清具体是做什么，你帮我想想用户到底想完成什么事。
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
可能的 JTBD 方向：
|
||||
|
||||
1. 当我第一次准备投实习时，我想快速知道应该先准备哪些材料，
|
||||
以便我不要因为信息混乱一直拖着不投。
|
||||
|
||||
2. 当我看到一个实习岗位时，我想快速判断自己是否值得投，
|
||||
以便我不要在不合适的岗位上浪费太多时间。
|
||||
|
||||
3. 当我开始投递时，我想把现有简历改成更贴合岗位的版本，
|
||||
以便我能更快完成投递并提高通过率。
|
||||
```
|
||||
|
||||
这种输出的价值在于，它会把你原本一句很泛的想法，拆成几个更接近真实场景的方向。
|
||||
|
||||
### 12.2 让 AI 帮你整理访谈原话
|
||||
|
||||
如果你已经做了几次用户访谈，可以把访谈记录交给 AI，让它帮你提炼反复出现的场景、触发点、替代方案和成功标准。
|
||||
|
||||
```text
|
||||
下面是 5 位用户的访谈原话。
|
||||
请不要先给解决方案，而是按 JTBD 框架整理：
|
||||
1. 用户处在什么场景
|
||||
2. 触发他采取行动的事件是什么
|
||||
3. 他真正想完成的进展是什么
|
||||
4. 当前替代方案是什么
|
||||
5. 他最在意的成功标准是什么
|
||||
6. 哪些信息在多位用户中重复出现
|
||||
最后整理成 3 条最值得优先验证的 JTBD 假设。
|
||||
```
|
||||
|
||||
一个很简单的小白输入也可以这样写：
|
||||
|
||||
```text
|
||||
我问了 3 个人，他们大概是这样说的：
|
||||
|
||||
1. 每次要投实习我都得重新改简历，特别烦。
|
||||
2. 我其实最怕的是不知道自己写得对不对。
|
||||
3. 我现在会先找学长学姐帮我看，但每次都不好意思总麻烦别人。
|
||||
|
||||
你帮我整理一下，他们真正想完成的事情是什么。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
整理结果：
|
||||
|
||||
- 共同场景：准备投递实习前，需要处理简历
|
||||
- 共同困难：不知道如何修改到“够好”
|
||||
- 当前替代方案：找学长学姐帮看，自己反复修改
|
||||
- 可能的 JTBD：
|
||||
当我准备投递实习时，我想更快判断简历是否已经达到可投递水平，
|
||||
以便我不要一直卡在“再改一改”而迟迟投不出去。
|
||||
```
|
||||
|
||||
这种输出很有用，因为它帮你从零散原话里提炼出更像“需求”的东西。
|
||||
|
||||
### 12.3 让 AI 帮你做一轮轻量级网络调研
|
||||
|
||||
在你还没开始大规模访谈前，可以先让 AI 帮你做一些很轻的外部信息扫描，比如：
|
||||
|
||||
- 公开论坛或社区里，大家是怎么抱怨这个问题的
|
||||
- 市面上已有产品主要在解决哪一层问题
|
||||
- 用户最常见的替代方案是什么
|
||||
- 常见评价里，大家最满意和最不满意的点是什么
|
||||
|
||||
这种调研不能代替真实用户访谈，但很适合作为 Discover 阶段的热身，帮你先建立问题地图。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
请你帮我查一查：
|
||||
“大学生改简历、投实习时最常见的痛点是什么？”
|
||||
优先看公开论坛、经验帖、求职社区里大家自己说的话。
|
||||
帮我整理成 5 条最常见问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
常见痛点整理：
|
||||
|
||||
1. 不知道简历该写什么，经历太少
|
||||
2. 不知道怎么针对不同岗位修改
|
||||
3. 改了很多版，但始终不确定是否够好
|
||||
4. 找不到可靠的人帮忙看
|
||||
5. 投递流程复杂，容易拖延
|
||||
```
|
||||
|
||||
这类输出不能当最终结论，但很适合帮你先决定要优先访谈哪类问题。
|
||||
|
||||
### 12.4 让 AI 充当“反方”
|
||||
|
||||
很多时候，我们会对自己的想法太有感情。你可以专门让 AI 扮演一个挑刺的人，逼你把问题说得更清楚：
|
||||
|
||||
```text
|
||||
请你扮演一个非常严格的产品研究顾问。
|
||||
下面是我的 JTBD 假设：[你的假设]
|
||||
请从以下角度批判它：
|
||||
1. 这个场景是否过宽
|
||||
2. 这个 job 是否写成了功能而不是真正进展
|
||||
3. 替代方案是否太弱
|
||||
4. 成功标准是否不够清楚
|
||||
5. 这个假设最需要被验证的风险是什么
|
||||
```
|
||||
|
||||
这样做的好处是，你能更快发现自己是在看需求，还是只是在看自己喜欢的方案。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品点子，用一句 JTBD 公式把它写清楚
|
||||
2. 为这个点子补齐 5 个要素：场景、触发、进展、替代方案、成功标准
|
||||
3. 找 3 个潜在用户，至少问出一次“最近一次你遇到这个问题是什么时候”
|
||||
4. 把访谈原话交给 AI，整理成 3 条最值得优先验证的 JTBD 假设
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- [Christensen Institute: Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/)
|
||||
- [Harvard Business School Online: What Is Jobs to Be Done?](https://online.hbs.edu/blog/post/jobs-to-be-done)
|
||||
- [Intercom: Jobs-to-be-Done: A framework for customer needs](https://www.intercom.com/blog/jobs-to-be-done-framework/)
|
||||
- [Mural: Jobs to Be Done framework guide](https://www.mural.co/blog/jobs-to-be-done-framework)
|
||||
@@ -0,0 +1,589 @@
|
||||
---
|
||||
title: 'The Mom Test：如何通过用户访谈验证需求'
|
||||
description: '面向零基础读者的 The Mom Test 入门文章。学会避免礼貌性反馈，围绕真实行为、具体事实和已有问题做用户访谈，把“听起来不错”变成更可靠的需求判断。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# The Mom Test：如何通过用户访谈验证需求
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['用户访谈', '需求验证', '用户研究', '产品调研']"
|
||||
coreOutput="1 组更能问出真实信息的访谈问题"
|
||||
expectedOutput="不再把用户的礼貌性鼓励当成验证，而能用真实行为判断方向"
|
||||
>
|
||||
|
||||
很多人第一次做产品调研时，以为最重要的是“找人聊聊”。于是他们去问朋友、同事，甚至家人：
|
||||
|
||||
- 你觉得我这个想法怎么样？
|
||||
- 如果有这样一个产品，你会不会用？
|
||||
- 这个功能听起来是不是还不错？
|
||||
|
||||
对方往往也会给出非常鼓舞人的反馈：
|
||||
|
||||
- 挺好的啊
|
||||
- 听起来很有用
|
||||
- 我觉得你可以试试
|
||||
|
||||
问题在于，这些回答通常并不能帮你做判断。它们更像是礼貌、支持，或者一种不想当场扫你兴的自然反应。你以为自己得到了“市场验证”，其实只是收集了一堆很难用来决策的安慰。
|
||||
|
||||
The Mom Test 这套方法，就是专门用来解决这个问题的。它提醒我们：**不是用户在故意骗你，而是你问问题的方式，天然会把对方引向好听但没用的回答。**
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚怎么和用户聊天，才不会只听到“听起来不错”，而是真的问出能帮你判断方向的信息。
|
||||
|
||||
**行动项**：把你原本想问的 5 个问题改掉，优先问“最近一次发生在什么时候”“你当时怎么处理”。
|
||||
|
||||
**结果**：你会更容易分清哪些是意见，哪些才是真正能支撑判断的证据。
|
||||
|
||||
**关键词跳转**：[The Mom Test 是什么](#mom-what) · [三个核心原则](#mom-principles) · [AI 怎么帮你](#mom-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. The Mom Test 到底在解决什么问题，为什么很多“用户调研”其实没有调研到真实信息
|
||||
2. 这套方法最核心的几个原则：少问意见，多问行为；少问假设，多问事实
|
||||
3. 怎样把一个容易得到假阳性反馈的问题，改成更有价值的访谈问题
|
||||
4. 如何把 The Mom Test 和 JTBD、需求验证、MVP 判断连起来使用
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## 1. The Mom Test 到底是什么 [↩ 回到开头](#top-mom)
|
||||
|
||||
The Mom Test 来自 Rob Fitzpatrick 的同名书籍。它的名字听起来有点像玩笑，但点得非常准：
|
||||
|
||||
**就算是你妈妈，也很难直接告诉你“这是个烂想法”。**
|
||||
|
||||
原因不是她不诚实，而是：
|
||||
|
||||
- 她不想伤害你
|
||||
- 她会下意识鼓励你
|
||||
- 她很容易顺着你的表达方式回答
|
||||
|
||||
其实不只是妈妈，朋友、同事、前同学，甚至很多陌生人，在面对你的产品想法时，也常常会给出类似的“正向反馈”。这不代表需求真的存在，只代表你把问题问成了一个很容易得到好听答案的形式。
|
||||
|
||||
所以，The Mom Test 的重点从来不是“别问妈妈”，而是：
|
||||
|
||||
**别把问题问成任何人都会顺着你回答的样子。**
|
||||
|
||||
这套方法真正想教你的，是如何通过对话，拿到更接近真实需求的信息，而不是收集一堆让自己感觉良好的评论。
|
||||
|
||||
## 2. 它解决的核心问题是什么
|
||||
|
||||
The Mom Test 主要解决的是一种非常常见的认知错觉：
|
||||
|
||||
**把礼貌性的积极反馈，当成真实需求。**
|
||||
|
||||
比如你问：
|
||||
|
||||
- 你觉得这个 App 想法怎么样？
|
||||
- 如果我做一个 AI 帮你写简历的工具，你会用吗？
|
||||
- 这个功能是不是很有价值？
|
||||
|
||||
这些问题的共同特点是：
|
||||
|
||||
- 它们都在问“意见”
|
||||
- 它们都带着一点暗示
|
||||
- 它们都在谈一个还没发生的未来
|
||||
|
||||
而人对“意见”和“未来假设”的回答，通常都不稳定。很多人会高估自己的兴趣、高估自己的执行力，也会高估自己未来的购买意愿。
|
||||
|
||||
所以 The Mom Test 提醒你：
|
||||
|
||||
- 不要太相信别人对你点子的评价
|
||||
- 不要太相信别人对未来行为的预测
|
||||
- 要尽量回到用户已经发生过的真实行为里
|
||||
|
||||
因为和“你会不会用”相比，“你上次怎么处理这件事的”往往更接近真相。
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## 3. 三个最核心的原则 [↩ 回到开头](#top-mom)
|
||||
|
||||
如果你只想先记住最重要的部分，可以先记下面这三个原则。
|
||||
|
||||
### 3.1 少谈你的点子，多谈用户过去的真实经历
|
||||
|
||||
很多无效访谈一开场就讲自己的方案，讲自己多么兴奋，讲自己准备做什么产品。问题是，一旦你讲得太多，对方就很容易切换到“配合你”“鼓励你”的状态。
|
||||
|
||||
相比之下，更好的方式是把重点放在对方的经历上：
|
||||
|
||||
- 最近一次遇到这个问题是什么时候？
|
||||
- 当时你在做什么？
|
||||
- 你最后是怎么处理的？
|
||||
- 哪一步最麻烦？
|
||||
|
||||
你会发现，这类问题能更自然地把对话带回现实，而不是停留在想象中的偏好。
|
||||
|
||||
### 3.2 少问抽象意见，多问具体事实
|
||||
|
||||
“我觉得这个功能挺好”“听起来不错”“好像有点用”，这些表达都太抽象了，很难指导产品决策。
|
||||
|
||||
更有价值的信息通常长这样：
|
||||
|
||||
- 我上周刚为了这件事折腾了 2 小时
|
||||
- 我现在是用 Excel 加微信硬撑
|
||||
- 我上个月已经为类似工具花过钱
|
||||
- 我最怕的是做错，不是做慢
|
||||
|
||||
这些才是真正能帮你判断问题强度、频率和付费可能性的信息。
|
||||
|
||||
### 3.3 少问用户想要什么方案，多看他现在怎么解决问题
|
||||
|
||||
用户很擅长描述自己的困扰，但不一定擅长设计解决方案。
|
||||
|
||||
如果你问：
|
||||
|
||||
- 你想不想要一个 AI 帮你自动做这个？
|
||||
- 你觉得加个智能功能有没有帮助？
|
||||
|
||||
你得到的，通常只是对某个方案的模糊态度，而不是需求本身。
|
||||
|
||||
更好的问题是：
|
||||
|
||||
- 你现在用什么方法处理这个问题？
|
||||
- 为什么你会选择这种方式？
|
||||
- 它哪里不够好？
|
||||
|
||||
看清现有替代方案，往往比直接问“你想要什么”更重要。
|
||||
|
||||
## 4. 为什么人们总会给你好听但没用的回答
|
||||
|
||||
如果你能理解这件事，做访谈时就会少很多误判。
|
||||
|
||||
### 4.1 人会下意识地保持礼貌
|
||||
|
||||
尤其当对话对象和你有关系时，对方很难直接说：
|
||||
|
||||
- 这个方向听起来不太行
|
||||
- 我根本不会用
|
||||
- 这个问题对我没那么重要
|
||||
|
||||
他更可能说“挺好的”“有机会可以做做看”。
|
||||
|
||||
### 4.2 人会高估未来的自己
|
||||
|
||||
很多人真心相信自己未来会：
|
||||
|
||||
- 更自律
|
||||
- 更愿意学习
|
||||
- 更愿意付费
|
||||
- 更愿意尝试新工具
|
||||
|
||||
所以“如果有的话我应该会用”这句话，常常并不等于未来真的会用。
|
||||
|
||||
### 4.3 你的提问方式本身就在引导答案
|
||||
|
||||
当你问：
|
||||
|
||||
- 我这个想法是不是挺好？
|
||||
- 这个功能对你来说是不是很有帮助？
|
||||
|
||||
你其实已经偷偷把“正确答案”塞进问题里了。
|
||||
|
||||
这也是为什么 The Mom Test 特别强调：**不要把访谈做成你在寻找认可。**
|
||||
|
||||
## 5. 直接对比：什么问题容易问废，什么问题更有价值
|
||||
|
||||
下面这些对照，几乎是每个新手都会用到的。
|
||||
|
||||
| 容易问废的问题 | 更有价值的问题 |
|
||||
| --- | --- |
|
||||
| 你觉得我这个想法怎么样？ | 你最近一次遇到这个问题是什么时候？ |
|
||||
| 如果有这个产品你会用吗？ | 你现在是怎么处理这件事的？ |
|
||||
| 你愿意为这个功能付费吗？ | 你上次为了这个问题花过钱吗？花在什么上？ |
|
||||
| 你觉得这个功能重要吗？ | 这个流程里最烦、最慢、最不放心的是哪一步？ |
|
||||
| 你想不想要一个 AI 帮你自动做？ | 你现在为什么还没有找到更顺手的解决办法？ |
|
||||
|
||||
这张表最重要的不是具体句子，而是背后的方向：
|
||||
|
||||
- 从意见走向事实
|
||||
- 从未来走向过去
|
||||
- 从你的方案走向用户的问题
|
||||
|
||||
## 6. 一个零基础也能立刻用的访谈节奏
|
||||
|
||||
如果你现在就想去找人聊，可以直接按下面这个顺序来。
|
||||
|
||||
### 6.1 开场：说明你在学习，不是在推销
|
||||
|
||||
比如：
|
||||
|
||||
> 我最近在研究大家怎么处理这类问题，想先了解真实情况，不是来卖东西的。
|
||||
|
||||
这种表达会让对方更容易放下“我要给你积极反馈”的心理负担。
|
||||
|
||||
### 6.2 从最近一次真实经历开始问
|
||||
|
||||
可以先从这类问题开始：
|
||||
|
||||
- 最近一次遇到这个问题是什么时候？
|
||||
- 当时发生了什么？
|
||||
- 你第一反应是怎么处理的？
|
||||
|
||||
一旦对话进入具体事件，信息质量通常会明显提升。
|
||||
|
||||
### 6.3 往下追问行为、成本和替代方案
|
||||
|
||||
继续问：
|
||||
|
||||
- 你现在用什么办法解决？
|
||||
- 这个办法最不舒服的地方是什么？
|
||||
- 你为此花过多少时间、钱或者精力？
|
||||
- 你试过别的方法吗？为什么没继续用？
|
||||
|
||||
### 6.4 最后再判断痛感和优先级
|
||||
|
||||
你不需要直接问“痛不痛”，可以从细节里判断：
|
||||
|
||||
- 他是不是经常遇到
|
||||
- 他是不是已经在主动补救
|
||||
- 他是不是已经愿意为此付出成本
|
||||
- 他在讲这件事时是不是带着明显情绪
|
||||
|
||||
这些都比一句“这是不是你的痛点”更有用。
|
||||
|
||||
## 7. 一个更完整的例子
|
||||
|
||||
假设你想做一个“AI 帮大学生改简历”的产品。
|
||||
|
||||
### 错误问法
|
||||
|
||||
你去问同学：
|
||||
|
||||
> 我想做一个 AI 简历优化工具，你觉得怎么样？
|
||||
> 如果它能根据岗位自动改简历，你会不会用？
|
||||
|
||||
这时候，对方很可能会说：
|
||||
|
||||
- 听起来挺好
|
||||
- 我觉得应该有用
|
||||
- 如果免费我会试试
|
||||
|
||||
这些回答几乎没有办法帮你判断需求到底强不强。
|
||||
|
||||
### 更好的问法
|
||||
|
||||
你可以改成：
|
||||
|
||||
> 你最近一次改简历是什么时候？
|
||||
> 当时为什么要改？
|
||||
> 你是怎么改的？
|
||||
> 哪一步最卡？
|
||||
> 你有没有找过别人帮你看？
|
||||
> 你以前为简历这件事花过钱或者花过很多时间吗？
|
||||
|
||||
通过这些问题，你可能得到的信息会是：
|
||||
|
||||
- 很多人不是不会写，而是不知道怎么针对不同岗位改写
|
||||
- 他们最痛的不是排版，而是“不知道哪些经历值得写”
|
||||
- 他们会拖延，不是因为懒，而是因为每次改简历都很消耗
|
||||
- 他们已经在用学长建议、模板网站、AI 工具和朋友帮看来勉强解决
|
||||
|
||||
这时候，你离真实问题就近得多了。
|
||||
|
||||
## 8. The Mom Test 和 JTBD 怎么配合用
|
||||
|
||||
如果说 JTBD 帮你看清“用户想完成什么进展”，那么 The Mom Test 更像是在教你：
|
||||
|
||||
**怎么通过访谈，确认这个 job 是不是真的存在。**
|
||||
|
||||
你完全可以把两者接起来使用：
|
||||
|
||||
1. 先用 JTBD 假设一个 job
|
||||
2. 再用 The Mom Test 的方式，去问用户最近一次真实经历
|
||||
3. 看看这个 job 是否真的高频、真实、值得优先做
|
||||
|
||||
比如你的 JTBD 假设是：
|
||||
|
||||
> 当我准备投递实习时，我想快速把旧简历改成贴合岗位的版本，以便尽快完成投递。
|
||||
|
||||
那你就可以用 The Mom Test 风格的问题去验证：
|
||||
|
||||
- 你最近一次投递是什么时候？
|
||||
- 当时你是怎么改简历的？
|
||||
- 哪一段最难写？
|
||||
- 你改完之后怎么判断它够不够好？
|
||||
|
||||
这样，方法就连起来了：
|
||||
|
||||
- JTBD 帮你定义需求假设
|
||||
- The Mom Test 帮你访谈验证假设
|
||||
|
||||
## 9. 新手做用户访谈时最常见的误区
|
||||
|
||||
### 9.1 把访谈做成产品介绍会
|
||||
|
||||
你一讲太多自己的想法，对方就容易开始配合你，而不是告诉你真实情况。
|
||||
|
||||
### 9.2 访谈对象全是熟人
|
||||
|
||||
熟人不是不能聊，但熟人更容易鼓励你。你至少需要混合一些更接近真实用户的人，而不是只找支持你的人。
|
||||
|
||||
### 9.3 过早追着问功能
|
||||
|
||||
如果你还没搞清楚问题，就开始追问按钮、界面、功能细节，通常是在太早进入解决方案。
|
||||
|
||||
### 9.4 把一句“我会用”当成验证结果
|
||||
|
||||
访谈最多帮你判断方向，不等于已经完成验证。真正的验证，最终还是要看用户是否愿意付出真实成本，比如时间、切换成本、试用行为，甚至付费。
|
||||
|
||||
### 9.5 访谈结束后不整理
|
||||
|
||||
如果你聊完就放着，信息很快会变成模糊印象。最好尽快整理：
|
||||
|
||||
- 出现频率高的问题
|
||||
- 用户原话里的情绪词
|
||||
- 当前替代方案
|
||||
- 已经付出的成本
|
||||
- 你自己的新判断
|
||||
|
||||
## 10. 可以直接复制去用的问题清单
|
||||
|
||||
如果你想尽快开始，这里有一组足够通用的问题。
|
||||
|
||||
### 开场问题
|
||||
|
||||
- 最近一次你遇到这个问题是什么时候？
|
||||
- 当时具体发生了什么？
|
||||
|
||||
### 行为问题
|
||||
|
||||
- 你当时是怎么处理的？
|
||||
- 你为什么会选择这种方式？
|
||||
|
||||
### 成本问题
|
||||
|
||||
- 这件事一般会花掉你多少时间或精力？
|
||||
- 你有没有为了解决它花过钱？
|
||||
|
||||
### 替代方案问题
|
||||
|
||||
- 你试过别的工具或办法吗？
|
||||
- 为什么最后没有继续用？
|
||||
|
||||
### 收尾问题
|
||||
|
||||
- 如果以后还遇到同样的问题，你觉得最理想的解决方式应该是什么样？
|
||||
|
||||
注意，这个收尾问题可以问，但最好放在后面。因为前面你更需要拿到事实，而不是愿望。
|
||||
|
||||
## 11. 小结
|
||||
|
||||
The Mom Test 最重要的贡献，不是给你一套“更会聊天”的技巧，而是帮你建立一种更清醒的判断方式：
|
||||
|
||||
- 不要太快相信别人对你点子的夸奖
|
||||
- 不要把“如果有我会用”当成真实需求
|
||||
- 不要让访谈变成你在寻找认可
|
||||
|
||||
真正有价值的访谈，应该尽量回到这些东西上：
|
||||
|
||||
- 用户最近一次真实经历
|
||||
- 他现在怎么处理
|
||||
- 他已经付出了什么成本
|
||||
- 他在哪些地方明显不舒服
|
||||
|
||||
当你开始这样问，你得到的信息虽然有时没那么好听，但通常更有用。
|
||||
而做产品时，**有用的真相，永远比好听的鼓励更重要。**
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## 12. 如何利用 AI 帮你做用户访谈 [↩ 回到开头](#top-mom)
|
||||
|
||||
The Mom Test 本质上还是一套“和真人聊”的方法，所以 AI 不能替代真实访谈。但 AI 非常适合在访谈前、中、后给你打辅助，尤其适合帮新手降低门槛。
|
||||
|
||||
### 12.1 让 AI 帮你把“容易问废”的问题改写掉
|
||||
|
||||
很多人知道自己不该问“你觉得我这个想法怎么样”，但一开口还是会回到这种句子。你可以先把自己准备问的问题交给 AI，让它帮你改写：
|
||||
|
||||
```text
|
||||
下面是我准备做用户访谈时想问的问题：
|
||||
[贴上你的问题]
|
||||
|
||||
请你用 The Mom Test 的原则帮我改写：
|
||||
1. 删掉意见型问题
|
||||
2. 删掉假设未来的问题
|
||||
3. 尽量改成围绕过去真实行为、已有替代方案和已付成本的提问
|
||||
4. 最后整理成一套 8-10 个可以直接访谈的问题清单
|
||||
```
|
||||
|
||||
一个很小白的输入也完全可以：
|
||||
|
||||
```text
|
||||
我想问用户：
|
||||
1. 你觉得我做一个 AI 改简历工具怎么样？
|
||||
2. 你会不会用？
|
||||
3. 你愿不愿意付费？
|
||||
|
||||
请帮我改成更好的问法。
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
改写后的问题：
|
||||
|
||||
1. 你最近一次改简历是什么时候？
|
||||
2. 当时为什么要改？
|
||||
3. 你是怎么改的？
|
||||
4. 哪一步最花时间？
|
||||
5. 你有没有找别人帮你看？
|
||||
6. 你以前有没有为简历修改花过钱或花过很多时间？
|
||||
```
|
||||
|
||||
这种输出很有帮助，因为它直接把你原本“在问意见”的问题，改成了“在问真实行为”的问题。
|
||||
|
||||
### 12.2 让 AI 帮你生成不同对象的访谈提纲
|
||||
|
||||
同一个方向，面对不同人群，访谈重点会不一样。比如学生、HR、自由职业者，关心点完全不同。你可以让 AI 帮你针对不同对象各出一版提纲：
|
||||
|
||||
- 面向新手用户，重点了解最近一次真实经历
|
||||
- 面向重度用户，重点了解替代方案和痛感
|
||||
- 面向付费用户，重点了解是否已经为此付过成本
|
||||
|
||||
这样你在真正聊天时会更有节奏，而不会每个人都问同一套问题。
|
||||
|
||||
比如你可以直接这样输入：
|
||||
|
||||
```text
|
||||
我要聊两类人：
|
||||
1. 第一次找实习的大学生
|
||||
2. 已经帮别人看过很多简历的学长学姐
|
||||
|
||||
请分别给我一套访谈提纲，每套 6 个问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
对大学生：
|
||||
1. 最近一次投实习是什么时候？
|
||||
2. 当时最卡的是哪一步？
|
||||
3. 你怎么知道自己的简历能不能投？
|
||||
...
|
||||
|
||||
对学长学姐：
|
||||
1. 你最近一次帮别人看简历是什么时候？
|
||||
2. 你最常看到哪些明显问题？
|
||||
3. 学弟学妹最容易卡在哪一步？
|
||||
...
|
||||
```
|
||||
|
||||
这样一来，你不用自己从零编问题，访谈准备会轻松很多。
|
||||
|
||||
### 12.3 让 AI 帮你整理访谈记录
|
||||
|
||||
访谈做完之后，最容易出现的问题不是“没信息”，而是“信息太散”。AI 很适合帮你把碎片化对话整理成结构化笔记：
|
||||
|
||||
```text
|
||||
下面是我和 3 位用户的访谈记录。
|
||||
请按 The Mom Test 的角度整理：
|
||||
1. 哪些内容是事实，哪些只是意见
|
||||
2. 用户最近一次真实行为是什么
|
||||
3. 当前替代方案是什么
|
||||
4. 用户已经付出的时间、金钱或精力成本是什么
|
||||
5. 哪些问题被反复提到
|
||||
6. 哪些说法听起来积极，但证据不足
|
||||
```
|
||||
|
||||
这一步尤其有价值，因为它能帮你把“听起来不错”的内容和“真的能支撑判断”的内容分开。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
这是我和一个用户聊完后的记录：
|
||||
|
||||
- 她说如果有个工具应该会试试
|
||||
- 她上周为了改简历花了一个晚上
|
||||
- 她现在主要靠朋友帮看
|
||||
- 她说最难的是不知道改到什么程度算可以投
|
||||
|
||||
请你帮我分一下，哪些是意见，哪些是事实。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
意见：
|
||||
- 如果有个工具应该会试试
|
||||
|
||||
事实：
|
||||
- 上周为了改简历花了一个晚上
|
||||
- 当前替代方案是找朋友帮看
|
||||
- 最难点是不知道什么时候算“可以投”
|
||||
|
||||
可用于判断需求的重点：
|
||||
- 这个问题最近刚发生过
|
||||
- 用户已经投入了明显时间成本
|
||||
- 当前方案依赖他人，不稳定
|
||||
```
|
||||
|
||||
这个输出就能很直观地告诉新手：哪些话能拿来做判断，哪些话只能听听。
|
||||
|
||||
### 12.4 让 AI 先做一轮轻量级网络搜索
|
||||
|
||||
如果你还没开始访谈，可以先让 AI 帮你做一些很轻的外部调研，比如：
|
||||
|
||||
- 公开社区里，大家最近是怎么抱怨这个问题的
|
||||
- 现有工具被吐槽最多的是什么
|
||||
- 用户是不是已经为相似问题花过钱
|
||||
- 市场上有哪些替代方案已经存在
|
||||
|
||||
这类信息不能替代真人访谈，但能帮你更快进入状态，知道该从哪里切入问题。
|
||||
|
||||
比如一个简单输入可以是：
|
||||
|
||||
```text
|
||||
请你帮我搜一下：
|
||||
“大学生改简历时最常吐槽什么”
|
||||
帮我整理出 5 条最常见抱怨，用很白话的话写出来。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
常见抱怨：
|
||||
|
||||
1. 不知道简历上到底该写什么
|
||||
2. 每投一个岗位都要改，太累
|
||||
3. 改了很多版还是不确定好不好
|
||||
4. 没人能给靠谱反馈
|
||||
5. 总觉得还没准备好，所以一直拖
|
||||
```
|
||||
|
||||
这种结果的价值在于，它会让你更容易找到访谈切入口。
|
||||
|
||||
### 12.5 让 AI 扮演“访谈复盘教练”
|
||||
|
||||
你还可以把自己刚做完的一场访谈记录丢给 AI，让它帮你挑刺：
|
||||
|
||||
```text
|
||||
下面是我的一段用户访谈记录。
|
||||
请从 The Mom Test 的角度帮我复盘：
|
||||
1. 我哪些问题问得太像在找认可
|
||||
2. 哪些问题带有明显引导
|
||||
3. 哪些地方本来可以继续追问事实
|
||||
4. 如果再来一次，这段对话可以怎么问得更好
|
||||
```
|
||||
|
||||
这对新手特别有帮助，因为你会更快建立一种“我到底是在收集证据，还是在收集鼓励”的敏感度。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品方向，先写出 5 个你原本会问的“容易问废”的问题
|
||||
2. 把这 5 个问题改写成更符合 The Mom Test 风格的提问
|
||||
3. 找 3 个潜在用户，至少问出一次“最近一次你遇到这个问题是什么时候”
|
||||
4. 访谈结束后整理 4 类信息：真实行为、替代方案、已付成本、反复出现的困难
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- [The Mom Test 官方网站](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
Reference in New Issue
Block a user