名称：待完成任务 描述：系统性地探索客户试图完成的功能性、社交性、情感性任务，他们经历的痛点，以及他们寻求的增益。使用此框架来发现未满足的需求，验证产品想法，并确保您的解决方案解决真正的动机—而不仅仅是表面级别的功能请求。 类型：组件
目的
系统性地探索客户试图完成的功能性、社交性、情感性任务，他们经历的痛点，以及他们寻求的增益。使用此框架来发现未满足的需求，验证产品想法，并确保您的解决方案解决真实的动机—而不是仅仅表面级别的功能请求。
这不是一项调查—它是一个结构化的视角，用于理解为什么客户“雇用”您的产品以及什么会使他们“解雇”它。
关键概念
待完成任务框架
受克莱顿·克里斯坦森和价值主张画布（奥斯特瓦尔德）的影响，JTBD将客户需求分为三类：
1. 客户任务：
- 功能性任务： 客户需要执行的任务（例如，“发送发票”）
- 社交性任务： 客户希望如何被感知（例如，“在客户面前显得专业”）
- 情感性任务： 客户寻求或避免的情感状态（例如，“在工作中感到自信”）
2. 痛点：
- 挑战： 客户面临的障碍
- 成本高昂： 在时间、金钱或努力上过于昂贵的事物
- 常见错误： 客户可能犯的、可以预防的错误
- 未解决问题： 当前解决方案中的差距
3. 增益点：
- 期望： 什么会超越当前解决方案
- 节省： 时间、金钱或努力的减少，令人愉悦
- 采用因素： 什么会增加转换的可能性
- 生活改善： 解决方案如何让生活更轻松或更愉快
为什么这种结构有效
- 分离任务与解决方案： “与我的团队沟通”（任务） ≠ “电子邮件”（解决方案）
- 揭示底层动机： 功能性任务可能是“跟踪支出”，但情感性任务是“感觉对财务有掌控感”
- 浮现您未见的竞争： 客户“雇用”非明显的替代方案（纸笔、电子表格、变通方法）
- 按强度优先排序： 并非所有痛点都相等—关注最尖锐的
反模式（这是什么不）
- 不是功能愿望清单： “我想要AI、自动化和仪表板”不是任务
- 不是人口统计学： “千禧一代想要移动优先”是人物特征，不是任务
- 不是泛泛的： “更高效”太模糊—深入探讨哪些任务和为什么
- 不是一维的： 仅关注功能性任务会错过社交/情感动机
何时使用此框架
- 早期阶段发现（在知道解决方案之前）
- 验证产品-市场契合（您的解决方案是否解决正确的任务？）
- 优先排序路线图（哪些任务最痛苦/重要？）
- 竞争分析（客户为什么“雇用”竞争对手？）
- 营销信息传达（针对任务，而非功能）
何时不使用此框架
- 在您已经构建产品之后（太晚用于发现）
- 对于琐碎功能（不要过度分析小调整）
- 作为定量验证的替代品（JTBD告知假设；数据验证它们）
应用
使用 template.md 获取完整的填写结构。
步骤1：定义上下文
在探索JTBD之前，澄清：
- 目标客户细分： 您在研究谁？（参考
skills/proto-persona/SKILL.md） - 情境： 任务在什么情境下出现？（例如，“当管理项目截止日期时…”）
- 当前解决方案： 他们今天使用什么？（竞争对手、变通方法、什么也不做）
如果缺少上下文： 进行客户访谈、情境查询或“切换访谈”（为什么他们从之前的解决方案切换）。
步骤2：探索客户任务
功能性任务
问：“您试图完成哪些任务？”
### 功能性任务：
- [客户需要执行的任务1]
- [客户需要执行的任务2]
- [客户需要执行的任务3]
示例：
- “为税务申报核对月度支出”
- “在2小时内入职新团队成员”
- “无停机时间将代码部署到生产环境”
质量检查：
- 动词驱动： 任务是行动（“发送”、“分析”、“协调”）
- 解决方案无关： 不要说“使用电子邮件沟通”—说“与远程团队成员沟通”
- 具体： “管理财务”太宽泛；“为税务抵扣跟踪业务支出”是具体的
社交性任务
问：“您希望如何被他人感知？”
### 社交性任务：
- [客户希望被社交感知的方式1]
- [客户希望被社交感知的方式2]
- [客户希望被社交感知的方式3]
示例：
- “被我的执行团队视为战略思想家”
- “向客户显得响应迅速和可靠”
- “向我的年轻同事显得技术娴熟”
质量检查：
- 受众特定： 客户试图给谁留下印象？（老板、客户、同事等）
- 情感权重： 社交性任务通常比功能性任务更能驱动采用
情感性任务
问：“您希望实现或避免哪种情感状态？”
### 情感性任务：
- [客户寻求或避免的情感状态1]
- [客户寻求或避免的情感状态2]
- [客户寻求或避免的情感状态3]
示例：
- “感觉自信我没有遗漏重要细节”
- “避免手动数据输入错误的焦虑”
- “在一天结束时感觉成就感”
质量检查：
- 正面和负面： 包括他们寻求的（“感觉有掌控感”）和避免的（“避免尴尬”）
- 基于研究： 不要捏造情感—使用客户引述
步骤3：识别痛点
挑战
问：“什么障碍阻止您完成这项任务？”
### 挑战：
- [客户面临的障碍1]
- [客户面临的障碍2]
- [客户面临的障碍3]
示例：
- “工具不集成，迫使手动数据输入”
- “对队友的工作内容没有可见性”
- “审批流程需要3天以上，阻碍进展”
成本高昂
问：“什么在时间、金钱或努力上花费过多？”
### 成本高昂：
- [在时间、金钱或努力上太昂贵的事物1]
- [在时间、金钱或努力上太昂贵的事物2]
示例：
- “生成月度报告需要8小时的手工工作”
- “雇用专家花费1万美元，我们无法负担”
- “学习当前工具需要20小时以上的培训”
常见错误
问：“您经常犯什么错误，可以预防？”
### 常见错误：
- [频繁错误1]
- [频繁错误2]
示例：
- “忘记在关键邮件上抄送利益相关者”
- “由于缺少收据而误算税务抵扣”
- “在共享文件中意外覆盖他人的工作”
未解决问题
问：“当前解决方案未能解决什么问题？”
### 未解决问题：
- [当前解决方案未解决的问题1]
- [当前解决方案未解决的问题2]
示例：
- “当前CRM不跟踪客户健康分数”
- “电子邮件在添加人员到线程时不保留对话上下文”
- “现有工具需要我们没有的技术专长”
步骤4：发现增益点
期望
问：“什么会让您喜欢一个解决方案？”
### 期望：
- [什么可能超越期望1]
- [什么可能超越期望2]
示例：
- “自动分类支出，无需手动标记”
- “基于项目状态建议下一步”
- “无缝与我们已使用的工具集成”
节省
问：“什么时间、金钱或努力的节省会让您愉悦？”
### 节省：
- [节省时间、金钱或努力的方式1]
- [节省时间、金钱或努力的方式2]
示例：
- “将报告生成从8小时减少到10分钟”
- “消除对全职管理员的需求”
- “将入职时间从2周缩短到2天”
采用因素
问：“什么会使您从当前解决方案切换？”
### 采用因素：
- [增加采用可能性的因素1]
- [增加采用可能性的因素2]
示例：
- “无需信用卡的免费试用”
- “导入现有数据的迁移支持”
- “来自类似公司的推荐”
生活改善
问：“如果这项任务更轻松，您的生活会如何改善？”
### 生活改善：
- [解决方案如何让生活更轻松或更愉快1]
- [解决方案如何让生活更轻松或更愉快2]
示例：
- “我可以准时下班，而不是熬夜完成报告”
- “我会感觉不那么紧张，不会错过重要截止日期”
- “我可以专注于战略工作，而不是繁琐工作”
步骤5：优先排序和验证
- 按强度排序痛点： 哪些痛点尖锐vs轻微烦恼？
- 识别必需vs可有可无的增益点： 什么会驱动采用vs只是额外奖励？
- 交叉参考人物： 不同人物是否有不同任务/痛点/增益点？（参考
skills/proto-persona/SKILL.md） - 用数据验证： 调查更广泛受众以确认来自访谈的JTBD洞察
示例
参见 examples/sample.md 获取完整JTBD示例。
迷你示例摘录：
**功能性任务：** 协调分布式团队的任务
**痛点 - 挑战：** 团队成员使用不同工具，造成孤岛
**增益点 - 节省：** 将状态报告时间从3小时减少到15分钟
常见陷阱
陷阱1：混淆任务与解决方案
症状： “我需要使用Slack”或“我需要AI驱动的分析”
后果： 您已锚定在解决方案上，而不是底层任务。
修复： 问“为什么？”5次。“我需要Slack” → “为什么？” → “与我的团队沟通” → “为什么？” → “获得快速答案” → “为什么？” → “避免项目延迟。”
陷阱2：泛泛的任务
症状： “更高效”或“节省时间”
后果： 太模糊，无法通知产品决策。
修复： 具体化。“节省时间” → “将月度报告生成时间从8小时减少到1小时。”
陷阱3：忽视社交/情感性任务
症状： 仅记录功能性任务
后果： 您错过了强大的动机因素。人们通常基于情感/社交需求购买，而不仅仅是功能性需求。
修复： 在访谈中明确询问感知和情感。“解决这会如何让您感觉？” “谁会在您解决时注意到？”
陷阱4：无研究捏造JTBD
症状： 基于假设填写模板
后果： 您在猜测。JTBD分析仅在基于真实客户洞察时才有价值。
修复： 进行“切换访谈”（询问为什么从之前的解决方案切换）、情境查询或问题验证访谈。
陷阱5：将所有痛点视为同等
症状： 列出20个痛点而无优先排序
后果： 没有清楚应先解决什么。
修复： 按强度排序痛点（尖锐vs轻微）。问“如果我们只解决一个痛点，哪个影响最大？”
参考文献
相关技能
skills/proto-persona/SKILL.md— 定义谁有这些任务/痛点/增益点skills/problem-statement/SKILL.md— JTBD通知“试图”和“但”部分skills/positioning-statement/SKILL.md— JTBD通知“需要”陈述
外部框架
- 克莱顿·克里斯坦森，《与运气竞争》（2016） — Jobs-to-be-Done理论的起源
- 托尼·乌尔维克，《结果驱动创新》（2016） — 量化任务和结果
- 亚历山大·奥斯特瓦尔德，《价值主张画布》（2014） — 客户任务/痛点/增益点框架
迪安的工作
- [如果适用，链接到迪安·彼得斯的相关Substack文章]
来源
- 改编自
prompts/jobs-to-be-done.md在https://github.com/deanpeters/product-manager-prompts仓库中。
技能类型： 组件
建议文件名： jobs-to-be-done.md
建议放置位置： /skills/components/
依赖： 参考 skills/proto-persona/SKILL.md
使用于： skills/positioning-statement/SKILL.md, skills/problem-statement/SKILL.md, skills/epic-hypothesis/SKILL.md