jtbd-demand-mining

name	jtbd-demand-mining
description	使用Jobs-to-be-Done (JTBD)框架挖掘用户真实需求。用于验证产品方向、识别真需求与伪需求、找产品-市场契合点。这个skill应该被用于：用户描述了一个产品想法、需要验证某个需求是否真实存在、分析用户为什么不使用某个产品、理解用户雇用或解雇产品的原因。

JTBD 需求挖掘

目的

使用 Jobs-to-be-Done 框架，系统性地探索用户试图完成的功能性、社交性和情感性工作，识别真正的痛点和收益，帮助验证产品方向是否正确。

什么时候用

• 用户提出了一个产品想法，需要验证需求是否真实
• 想深入理解用户"雇用"某个产品的根本原因
• 产品上线后用户量不达预期，需要分析原因
• 重新定位产品或进入新市场时

核心框架

三层用户工作

层级	问法	示例
功能性工作	用户需要完成什么任务？	"整理发票"、"管理团队日程"
社交性工作	用户想在别人眼中呈现什么形象？	"看起来很专业"、"被同事认可"
情感性工作	用户内心想感受到什么？	"减少焦虑"、"获得掌控感"

痛点类型

• 困难/挑战：完成工作过程中遇到障碍
• 成本过高：花费太多时间、金钱、精力
• 常见错误：用户容易犯的错
• 未解决问题：现有解决方案无法满足的需求

收益类型

• 期望收益：用户预期会得到的结果
• 节省收益：省时间、省钱、省力
• 采用因素：让用户决定使用新产品的原因
• 生活改善：情感层面的正向改变

使用流程

步骤1：定义上下文

明确分析目标：

• 目标用户是谁？（越具体越好）
• 用户在什么情境下需要完成这项工作？
• 用户目前用什么替代方案？

步骤2：探索三层工作

按顺序探索，每层都要问"为什么"直到挖到本质：

功能性工作 → 社交性工作 → 情感性工作

步骤3：识别痛点

针对每层工作，问：

• 这方面有什么困难？
• 什么让用户感到沮丧？
• 用户容易犯什么错误？
• 现有解决方案哪里不够好？

步骤4：发现收益

问：

• 用户期望得到什么结果？
• 什么会让用户的工作变得更轻松？
• 什么因素会让用户决定换一个新方案？

步骤5：按强度排序

不是所有痛点都同等重要，按严重程度排序：

• 必须有：没有就别想用户会用
• 重要有：能显著提升用户体验
• 最好有：锦上添花

输出格式

产品/方向：[你的产品方向]

目标用户：[具体描述]

【功能性工作】
1. [用户需要完成的具体任务]

【社交性工作】
1. [用户想呈现的形象/获得的社会认可]

【情感性工作】
1. [用户内心想感受的情绪状态]

【核心痛点】(按严重程度)
1. [最痛的痛点] - 严重程度：高
2. [次要痛点] - 严重程度：中

【期望收益】
1. [用户最想要的收益]

【需求验证结论】
- 真需求？：[是/否/部分]
- 理由：[简述]
- 下一步：[需要做什么验证]

常见陷阱

陷阱	症状	对策
把解决方案当需求	"用户想要一个XX功能"	追问"为什么需要这个功能"
需求定义太宽泛	"用户想要更高效"	具体化：什么场景下、做什么事
只关注功能层	只挖掘任务层面的需求	必须探索社交层和情感层
凭空捏造	没有任何用户数据支撑	进行用户访谈或观察
所有痛点等同视之	眉毛胡子一把抓	必须按严重程度排序

反模式

这个skill不是：

• 功能愿望清单
• 人口统计学特征描述
• 模糊的市场分析
• 只关注单一维度的需求列表

追问技巧

当用户说"用户想要X"时，连续追问5个"为什么"：

用户想要X功能
→ 为什么用户想要这个？（因为Y问题）
→ 为什么会产生Y问题？（因为Z期望）
→ Z期望背后是什么？（更深层的动机）
→ 这个深层动机与什么情感相关？（情感层）

相关资源

如需更深入分析，可结合：

• discovery-interview-prep：设计用户访谈来验证JTBD发现
• pre-mortem-analyst：假设产品失败后验证需求是否真实