AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载导读本篇技术指南以 Product-Manager-Skills 仓库中 jobs-to-be-done 示例文档 为骨架系统讲解 JTBDJobs-to-be-Done技能在真实产品场景中的完整用法如何将客户需求拆解为功能型 / 社会型 / 情感型三类 Jobs如何按 Challenges、Costliness、Common Mistakes、Unresolved Problems 四类 Pain 和 Expectations、Savings、Adoption Factors、Life Improvement 四类 Gain 建立结构化分析以及如何避免把要 AI、要看板、要移动 App这类功能愿望清单误当成 JTBD。读完你将掌握一套可直接复制的访谈提问句、质量检查标准和优先级排序方法并能结合仓库内的 SKILL.md、填充模板 与工业场景示例 sample-industrial.md 落地到自己的产品工作中。一、JTBD 框架的骨架三类 Jobs、四类 Pains、四类 Gains在进入示例之前先建立框架的完整结构。根据 jobs-to-be-done 的 SKILL.md 中的 Key Concepts 定义JTBD 受 Clayton Christensen《与运气竞争》/Competing Against Luck和 Osterwalder 的价值主张画布Value Proposition Canvas影响将客户需求划分为三个层次1. Customer Jobs客户要完成的任务Functional Jobs功能型任务客户需要执行的具体事务例如发送一张发票Social Jobs社会型任务客户希望被他人如何看待例如在客户面前显得专业可靠Emotional Jobs情感型任务客户寻求或回避的情绪状态例如对自己的工作感到自信。2. Pains痛点Challenges挑战客户面对的障碍Costliness成本高昂之处在时间、金钱或精力上过于昂贵的事物Common Mistakes常见错误客户经常犯、本可预防的失误Unresolved Problems未解决问题现有解决方案的空白。3. Gains收益Expectations期望超出现有方案水平的表现Savings节省令人惊喜的时间、金钱或精力削减Adoption Factors采纳因素提高客户切换意愿的条件Life Improvement生活改善方案如何让生活更轻松、更愉悦。这一结构之所以有效Why This Structure Works见 SKILL.md在于四点将 Job 与 Solution 分离与团队沟通是 Job发邮件是 Solution揭示底层动机功能 Job 可能是记账情感 Job 却是对财务状况有掌控感暴露看不见的竞争对手客户会雇用纸笔、电子表格等替代方案按强度排序并非所有痛点都同等重要优先解决最尖锐的。二、示例 1 深度拆解项目管理软件的优质 JTBD 分析示例文档 给出了第一个完整示例——项目管理软件场景下的优质分析我们逐层还原并解读其为何有效。2.1 三类 Jobs功能、社会、情感Functional Jobs功能型任务Coordinate tasks across a distributed team协调分布式团队的任务Track project progress against deadlines对照截止日期跟踪项目进度Identify blockers before they derail the project在阻塞点拖垮项目前识别它们Social Jobs社会型任务Be seen as an organized, reliable project leader被视为有条理、可靠的项目负责人Demonstrate transparency to stakeholders向利益相关方展现透明度Emotional Jobs情感型任务Feel confident that nothing is slipping through the cracks对没有遗漏任何事项感到自信Avoid the stress of last-minute surprises避免最后一刻突发状况带来的压力注意这三个层级的递进关系功能 Job 描述做什么社会 Job 描述别人怎么看我情感 Job 描述我自己感觉如何。正如 SKILL.md 强调的功能 Job 可能只是表面情感 Job 才是真正驱动购买决策的力量——这也是只做一维分析只看功能最常见的盲区。2.2 四类 Pains挑战、成本、常见错误、未解决问题Pains - Challenges挑战Team members use different tools (Slack, email, spreadsheets), causing information silos团队成员使用 Slack、邮件、电子表格等不同工具造成信息孤岛No single source of truth for project status项目状态缺乏单一可信来源Pains - Costliness成本高昂之处Manually updating status reports takes 3 hours per week手工更新状态报告每周耗时 3 小时Meetings to sync everyone take 5 hours per week同步会议每周耗 5 小时以上Pains - Common Mistakes常见错误Forgetting to follow up on tasks without clear ownership遗忘跟进没有明确负责人的任务Miscommunicating priorities, leading to wasted effort优先级传达失误导致无效劳动Pains - Unresolved Problems未解决问题Current tools dont surface blockers automatically现有工具不会自动暴露阻塞点Hard to visualize dependencies between tasks任务间的依赖关系难以可视化此处体现了 Pain 分类的实战价值Costliness 给出可量化基准3 小时 / 5 小时Common Mistakes 指向可预防的流程缺陷Unresolved Problems 则直接标记出现有工具的空白地带——这三类信息分别对应产品经理后续做 ROI 计算、流程优化和差异化定位的依据。2.3 四类 Gains期望、节省、采纳因素、生活改善Gains - Expectations期望Automatically updates stakeholders on progress without manual reports无需手工报告即可自动向利益相关方更新进度Suggests task owners based on workload and expertise根据工作量和专长推荐任务负责人Gains - Savings节省Reduce status reporting time from 3 hours to 15 minutes将状态报告时间从 3 小时压缩到 15 分钟Cut sync meetings in half同步会议减半Gains - Adoption Factors采纳因素Easy to onboard ( 30 minutes to set up)上手简单30 分钟内完成设置Integrates with Slack and Google Calendar与 Slack 和 Google Calendar 集成Gains - Life Improvement生活改善Leave work on time instead of staying late to track down updates按时下班而不是加班追赶更新Feel proactive instead of reactive感觉主动而非被动2.4 这个示例为什么有效示例文档在末尾给出了结论Why this worksJobs 具体且与解决方案无关solution-agnostic——识别阻塞点不绑定任何具体工具形态Pains 经过研究验证——3 小时 / 周5 小时 / 周是可量化的研究结果而非拍脑袋Gains 可度量、可排序——从 3 小时到 15 分钟会议减半都是后续可验证的产品指标可直接进入优先级排序对应 SKILL.md 的 Step 5按痛点强度排序、区分必备收益与锦上添花收益。三、示例 2 反面教材功能愿望清单为什么失败示例文档 的第二个示例展示了同一场景下的错误做法——把 JTBD 分析做成了功能愿望清单Functional Jobs功能型任务Use AI用 AIHave dashboards有仪表盘Get mobile app有移动 AppSocial Jobs社会型任务Be seen as innovative被视为有创新力Emotional Jobs情感型任务Feel modern感觉现代Pains痛点Current tools are old现有工具很旧Gains收益Better UX更好的体验Faster performance更快的性能3.1 逐条诊断失败原因Use AI 不是 Job而是 Solution示例文档的批评一针见血——AI 是一种技术方案关键问题是客户想用 AI 完成什么what are they trying to accomplish with AI?。这是 SKILL.md 中Anti-Patterns这绝对不是第一条的直接体现不是功能愿望清单。Have dashboards 是功能不是 Job看板是产品特性客户真正要完成的任务可能是一眼看出项目是否健康。Pains 过于含糊Current tools are old 无法指导任何行动——它不是挑战、成本、错误或未解决问题中的任何一类没有可操作的指向。Gains 过于通用Better UX 是人人都能说的空话不具备可度量性和差异化。3.2 如何修正示例文档给出的修复路径How to fix it简洁而关键去访谈用户。问你想完成什么而不是你想要什么功能Ask What are you trying to do? not What features do you want?并深挖具体任务、障碍和期望结果Dig into specific tasks, obstacles, and outcomes。这与 SKILL.md 的 Pitfall 4未经研究就凭空捏造 JTBD完全一致——只有扎根于真实客户洞察的 JTBD 分析才有价值。四、从示例到实操五步完成一次 JTBD 分析SKILL.md 提供了完整的操作流程可直接配合 填充模板 template.md 使用。模板给出了完整的填表结构Customer JobsFunctional / Social / Emotional 各三条、PainsChallenges / Costliness / Common Mistakes / Unresolved Problems、GainsExpectations / Savings / Adoption Factors / Life Improvement正是示例 1 中各类别的占位版本。Step 1定义上下文——明确目标客户细分可参考 proto-persona 技能、任务出现的场景如当管理项目截止日期时……以及当前使用的方案竞品、变通办法、什么都不做。若缺少上下文进行客户访谈、情境观察contextual inquiries或切换访谈switch interviews追问客户为何从旧方案切换过来。Step 2探索客户 Jobs对应示例 1 的 Jobs 部分功能型问你需要完成什么任务What tasks are you trying to complete?质量检查标准是动词驱动send、analyze、coordinate、与方案无关说与远程队友沟通不说用邮件沟通、足够具体管理财务太宽泛跟踪业务支出用于税务抵扣才具体社会型问你希望被他人如何看待How do you want to be perceived by others?要点是明确观众老板、客户、同事——社会型 Job 往往比功能型更能驱动采纳情感型问你想达到或回避什么情绪状态正负都要覆盖既包含感到掌控也包含避免尴尬且必须扎根研究不要凭空捏造情绪。Step 3识别 Pains对应示例 1 的 Pains 部分——逐类提问什么障碍阻止你完成这项任务什么在时间、金钱、精力上过于昂贵你经常犯哪些本可预防的错误现有方案没有解决什么问题Step 4挖掘 Gains对应示例 1 的 Gains 部分——逐类提问什么会让你爱上这个方案什么节省会让你惊喜什么会让你从现有方案切换过来如果这项任务变简单你的生活会变得怎样Step 5优先级排序与验证——按强度给 Pains 排序尖锐 vs 轻微区分必备收益与锦上添花收益与 persona 交叉比对最后用更大范围的问卷验证访谈洞察JTBD 产生假设数据验证假设见 SKILL.md。五、五大常见陷阱自查清单SKILL.md 归纳了五个高频陷阱配合上面两个示例可以建立完整的自查体系把 Job 当成 Solution我需要 Slack→ 连问五个为什么从需要 Slack追问到避免项目延期Job 过于泛化更高效节省时间→ 具体化把月度报告生成时间从 8 小时降到 1 小时忽略社会 / 情感型 Job→ 访谈中明确追问感知与情绪解决这个问题会让你感觉如何如果你解决了它会是谁注意到不经研究凭空捏造→ 示例 2 就是典型修复方法是做切换访谈、情境观察或问题验证访谈把一切 Pains 同等对待→ 列出 20 条痛点等于没有排序应追问如果只解决一个痛点哪个影响最大。六、进阶场景B2B / 工业场景的双执行者分析仓库在 sample-industrial.md 中还提供了工业场景的进阶示例Northfield Automation 的改造控制系统它揭示了一个示例 1 未覆盖的关键变体执行 Job 的人和为 Job 付费的人是不同的人各自拥有不同的 Jobs。维修技术员的 Job 是让停产的产线恢复运行且不使故障恶化换掉故障部件而不重新调试周围设备而工厂运营经理的 Job 是承诺工厂真正能兑现的交货日期用比轶事更有力的证据为资本支出辩护。若只分析错其中一方就可能造出一个演示惊艳、却在一线被绕过worked around的产品。这个示例还点出三个与示例 1 相通的判断标准情感 Job 往往是最诚实的动机技术员避免打电话给 OEM 带来的无能感解释了为什么他宁愿花 40 分钟用万用表而不是 20 秒打电话社会 Job 能预测采纳阻力成为组里什么都能修的人意味着让技术员显得可被替代的工具必然被抵制应定位为放大其专业能力而非替代管理者的 Job 解释成交停机归因不是技术员的功能需求而是把一线改善变成有资金支持的采购的关键。相对地该场景的错误版本减少停机提升效率暴露了经典错误——减少停机是结果而非 Job没有人早上醒来雇用产品去减少停机他们雇用产品去找出是哪个模块坏了且没有指明执行者、情绪表述空洞对设备有信心是贺卡文案、适用于任何工业产品——这恰恰是 JTBD 分析没说出任何东西的信号。七、JTBD 技能在仓库中的定位与生态jobs-to-be-done是 Product-Manager-Skills 的 component组件型技能在 目录索引 skills-index.yaml 中登记为在澄清未满足需求、重新定位产品或改进 discovery 与 messaging 时使用估计耗时 20–30 分钟见 SKILL.md。在技能生态中它有清晰的上下游关系见 SKILL.md上游 / 前置proto-persona 定义谁拥有这些 Jobs / Pains / Gainsdiscovery-interview-prep 提供 JTBD 访谈的方法论问你想完成什么考虑过哪些替代方案为什么选择 X下游 / 消费方problem-statement 用 JTBD 填充Trying to与But段落positioning-statement 用 JTBD 填充that need陈述epic-hypothesis 用 JTBD 定义目标用户期望达成的结果competitive-analysis-process 甚至以 JTBD 为透镜做能力地图按客户 Job 而非功能名对比竞品。从源码结构看该技能目录下 SKILL.md、template.md、examples/sample.md 与 examples/sample-industrial.md 四份文件构成了框架说明 → 填空模板 → 软件行业正反示例 → 工业行业进阶示例的完整教学链条且其在 skills-by-type.md 中被归类为 discovery-research 主题下的组件技能——这解释了为什么示例 1 强调Pains 由研究验证JTBD 的正确用法永远是先访谈、再结构、后验证而不是先填表、再想象、后美化。赞分享AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载相关推荐Product-Manager-Skills 的 Jobs-to-be-Done 技能实战指南用结构化 JTBD 挖掘客户 Job、Pain 与 GainProduct Manager Skills 的 Jobs to be Done 技能实战指南用结构化 JTBD 挖掘客户 Job、Pain 与 Gain 导AI 技能AI 插件easy-vibe 产品思维指南用 Jobs to Be Done 从功能清单转向可验证的用户需求假设easy vibe 产品思维指南用 Jobs to Be Done 从功能清单转向可验证的用户需求假设 导读 在 easy vibe 的项目制学习中产品方向教程文档browser-use 快速上手5 分钟让 AI 浏览器自动化替你批量下载网页文件browser use 快速上手5 分钟让 AI 浏览器自动化替你批量下载网页文件 你是不是也干过这种活五个供应商后台每个都要把月度报表一个个另存为人工智能AI Agent浏览器控制GUI 自动化MCP 服务上一篇Apache Beam WithKeys 实战用 Python 将 PCollection 元素转换为键值对的 Kata 精讲下一篇Kornia image 模块详解PyTorch 深度学习工作流中的高层图像处理 API 指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 5:13:04 · 阅读 1.2k Product-Manager-Skills 实战：用 Jobs-to-be-Done 框架把客户需求从“功能愿望清单“变成可验证的 Jobs、Pains 与 Gains
AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载导读本篇技术指南以 Product-Manager-Skills 仓库中 jobs-to-be-done 示例文档 为骨架系统讲解 JTBDJobs-to-be-Done技能在真实产品场景中的完整用法如何将客户需求拆解为功能型 / 社会型 / 情感型三类 Jobs如何按 Challenges、Costliness、Common Mistakes、Unresolved Problems 四类 Pain 和 Expectations、Savings、Adoption Factors、Life Improvement 四类 Gain 建立结构化分析以及如何避免把要 AI、要看板、要移动 App这类功能愿望清单误当成 JTBD。读完你将掌握一套可直接复制的访谈提问句、质量检查标准和优先级排序方法并能结合仓库内的 SKILL.md、填充模板 与工业场景示例 sample-industrial.md 落地到自己的产品工作中。一、JTBD 框架的骨架三类 Jobs、四类 Pains、四类 Gains在进入示例之前先建立框架的完整结构。根据 jobs-to-be-done 的 SKILL.md 中的 Key Concepts 定义JTBD 受 Clayton Christensen《与运气竞争》/Competing Against Luck和 Osterwalder 的价值主张画布Value Proposition Canvas影响将客户需求划分为三个层次1. Customer Jobs客户要完成的任务Functional Jobs功能型任务客户需要执行的具体事务例如发送一张发票Social Jobs社会型任务客户希望被他人如何看待例如在客户面前显得专业可靠Emotional Jobs情感型任务客户寻求或回避的情绪状态例如对自己的工作感到自信。2. Pains痛点Challenges挑战客户面对的障碍Costliness成本高昂之处在时间、金钱或精力上过于昂贵的事物Common Mistakes常见错误客户经常犯、本可预防的失误Unresolved Problems未解决问题现有解决方案的空白。3. Gains收益Expectations期望超出现有方案水平的表现Savings节省令人惊喜的时间、金钱或精力削减Adoption Factors采纳因素提高客户切换意愿的条件Life Improvement生活改善方案如何让生活更轻松、更愉悦。这一结构之所以有效Why This Structure Works见 SKILL.md在于四点将 Job 与 Solution 分离与团队沟通是 Job发邮件是 Solution揭示底层动机功能 Job 可能是记账情感 Job 却是对财务状况有掌控感暴露看不见的竞争对手客户会雇用纸笔、电子表格等替代方案按强度排序并非所有痛点都同等重要优先解决最尖锐的。二、示例 1 深度拆解项目管理软件的优质 JTBD 分析示例文档 给出了第一个完整示例——项目管理软件场景下的优质分析我们逐层还原并解读其为何有效。2.1 三类 Jobs功能、社会、情感Functional Jobs功能型任务Coordinate tasks across a distributed team协调分布式团队的任务Track project progress against deadlines对照截止日期跟踪项目进度Identify blockers before they derail the project在阻塞点拖垮项目前识别它们Social Jobs社会型任务Be seen as an organized, reliable project leader被视为有条理、可靠的项目负责人Demonstrate transparency to stakeholders向利益相关方展现透明度Emotional Jobs情感型任务Feel confident that nothing is slipping through the cracks对没有遗漏任何事项感到自信Avoid the stress of last-minute surprises避免最后一刻突发状况带来的压力注意这三个层级的递进关系功能 Job 描述做什么社会 Job 描述别人怎么看我情感 Job 描述我自己感觉如何。正如 SKILL.md 强调的功能 Job 可能只是表面情感 Job 才是真正驱动购买决策的力量——这也是只做一维分析只看功能最常见的盲区。2.2 四类 Pains挑战、成本、常见错误、未解决问题Pains - Challenges挑战Team members use different tools (Slack, email, spreadsheets), causing information silos团队成员使用 Slack、邮件、电子表格等不同工具造成信息孤岛No single source of truth for project status项目状态缺乏单一可信来源Pains - Costliness成本高昂之处Manually updating status reports takes 3 hours per week手工更新状态报告每周耗时 3 小时Meetings to sync everyone take 5 hours per week同步会议每周耗 5 小时以上Pains - Common Mistakes常见错误Forgetting to follow up on tasks without clear ownership遗忘跟进没有明确负责人的任务Miscommunicating priorities, leading to wasted effort优先级传达失误导致无效劳动Pains - Unresolved Problems未解决问题Current tools dont surface blockers automatically现有工具不会自动暴露阻塞点Hard to visualize dependencies between tasks任务间的依赖关系难以可视化此处体现了 Pain 分类的实战价值Costliness 给出可量化基准3 小时 / 5 小时Common Mistakes 指向可预防的流程缺陷Unresolved Problems 则直接标记出现有工具的空白地带——这三类信息分别对应产品经理后续做 ROI 计算、流程优化和差异化定位的依据。2.3 四类 Gains期望、节省、采纳因素、生活改善Gains - Expectations期望Automatically updates stakeholders on progress without manual reports无需手工报告即可自动向利益相关方更新进度Suggests task owners based on workload and expertise根据工作量和专长推荐任务负责人Gains - Savings节省Reduce status reporting time from 3 hours to 15 minutes将状态报告时间从 3 小时压缩到 15 分钟Cut sync meetings in half同步会议减半Gains - Adoption Factors采纳因素Easy to onboard ( 30 minutes to set up)上手简单30 分钟内完成设置Integrates with Slack and Google Calendar与 Slack 和 Google Calendar 集成Gains - Life Improvement生活改善Leave work on time instead of staying late to track down updates按时下班而不是加班追赶更新Feel proactive instead of reactive感觉主动而非被动2.4 这个示例为什么有效示例文档在末尾给出了结论Why this worksJobs 具体且与解决方案无关solution-agnostic——识别阻塞点不绑定任何具体工具形态Pains 经过研究验证——3 小时 / 周5 小时 / 周是可量化的研究结果而非拍脑袋Gains 可度量、可排序——从 3 小时到 15 分钟会议减半都是后续可验证的产品指标可直接进入优先级排序对应 SKILL.md 的 Step 5按痛点强度排序、区分必备收益与锦上添花收益。三、示例 2 反面教材功能愿望清单为什么失败示例文档 的第二个示例展示了同一场景下的错误做法——把 JTBD 分析做成了功能愿望清单Functional Jobs功能型任务Use AI用 AIHave dashboards有仪表盘Get mobile app有移动 AppSocial Jobs社会型任务Be seen as innovative被视为有创新力Emotional Jobs情感型任务Feel modern感觉现代Pains痛点Current tools are old现有工具很旧Gains收益Better UX更好的体验Faster performance更快的性能3.1 逐条诊断失败原因Use AI 不是 Job而是 Solution示例文档的批评一针见血——AI 是一种技术方案关键问题是客户想用 AI 完成什么what are they trying to accomplish with AI?。这是 SKILL.md 中Anti-Patterns这绝对不是第一条的直接体现不是功能愿望清单。Have dashboards 是功能不是 Job看板是产品特性客户真正要完成的任务可能是一眼看出项目是否健康。Pains 过于含糊Current tools are old 无法指导任何行动——它不是挑战、成本、错误或未解决问题中的任何一类没有可操作的指向。Gains 过于通用Better UX 是人人都能说的空话不具备可度量性和差异化。3.2 如何修正示例文档给出的修复路径How to fix it简洁而关键去访谈用户。问你想完成什么而不是你想要什么功能Ask What are you trying to do? not What features do you want?并深挖具体任务、障碍和期望结果Dig into specific tasks, obstacles, and outcomes。这与 SKILL.md 的 Pitfall 4未经研究就凭空捏造 JTBD完全一致——只有扎根于真实客户洞察的 JTBD 分析才有价值。四、从示例到实操五步完成一次 JTBD 分析SKILL.md 提供了完整的操作流程可直接配合 填充模板 template.md 使用。模板给出了完整的填表结构Customer JobsFunctional / Social / Emotional 各三条、PainsChallenges / Costliness / Common Mistakes / Unresolved Problems、GainsExpectations / Savings / Adoption Factors / Life Improvement正是示例 1 中各类别的占位版本。Step 1定义上下文——明确目标客户细分可参考 proto-persona 技能、任务出现的场景如当管理项目截止日期时……以及当前使用的方案竞品、变通办法、什么都不做。若缺少上下文进行客户访谈、情境观察contextual inquiries或切换访谈switch interviews追问客户为何从旧方案切换过来。Step 2探索客户 Jobs对应示例 1 的 Jobs 部分功能型问你需要完成什么任务What tasks are you trying to complete?质量检查标准是动词驱动send、analyze、coordinate、与方案无关说与远程队友沟通不说用邮件沟通、足够具体管理财务太宽泛跟踪业务支出用于税务抵扣才具体社会型问你希望被他人如何看待How do you want to be perceived by others?要点是明确观众老板、客户、同事——社会型 Job 往往比功能型更能驱动采纳情感型问你想达到或回避什么情绪状态正负都要覆盖既包含感到掌控也包含避免尴尬且必须扎根研究不要凭空捏造情绪。Step 3识别 Pains对应示例 1 的 Pains 部分——逐类提问什么障碍阻止你完成这项任务什么在时间、金钱、精力上过于昂贵你经常犯哪些本可预防的错误现有方案没有解决什么问题Step 4挖掘 Gains对应示例 1 的 Gains 部分——逐类提问什么会让你爱上这个方案什么节省会让你惊喜什么会让你从现有方案切换过来如果这项任务变简单你的生活会变得怎样Step 5优先级排序与验证——按强度给 Pains 排序尖锐 vs 轻微区分必备收益与锦上添花收益与 persona 交叉比对最后用更大范围的问卷验证访谈洞察JTBD 产生假设数据验证假设见 SKILL.md。五、五大常见陷阱自查清单SKILL.md 归纳了五个高频陷阱配合上面两个示例可以建立完整的自查体系把 Job 当成 Solution我需要 Slack→ 连问五个为什么从需要 Slack追问到避免项目延期Job 过于泛化更高效节省时间→ 具体化把月度报告生成时间从 8 小时降到 1 小时忽略社会 / 情感型 Job→ 访谈中明确追问感知与情绪解决这个问题会让你感觉如何如果你解决了它会是谁注意到不经研究凭空捏造→ 示例 2 就是典型修复方法是做切换访谈、情境观察或问题验证访谈把一切 Pains 同等对待→ 列出 20 条痛点等于没有排序应追问如果只解决一个痛点哪个影响最大。六、进阶场景B2B / 工业场景的双执行者分析仓库在 sample-industrial.md 中还提供了工业场景的进阶示例Northfield Automation 的改造控制系统它揭示了一个示例 1 未覆盖的关键变体执行 Job 的人和为 Job 付费的人是不同的人各自拥有不同的 Jobs。维修技术员的 Job 是让停产的产线恢复运行且不使故障恶化换掉故障部件而不重新调试周围设备而工厂运营经理的 Job 是承诺工厂真正能兑现的交货日期用比轶事更有力的证据为资本支出辩护。若只分析错其中一方就可能造出一个演示惊艳、却在一线被绕过worked around的产品。这个示例还点出三个与示例 1 相通的判断标准情感 Job 往往是最诚实的动机技术员避免打电话给 OEM 带来的无能感解释了为什么他宁愿花 40 分钟用万用表而不是 20 秒打电话社会 Job 能预测采纳阻力成为组里什么都能修的人意味着让技术员显得可被替代的工具必然被抵制应定位为放大其专业能力而非替代管理者的 Job 解释成交停机归因不是技术员的功能需求而是把一线改善变成有资金支持的采购的关键。相对地该场景的错误版本减少停机提升效率暴露了经典错误——减少停机是结果而非 Job没有人早上醒来雇用产品去减少停机他们雇用产品去找出是哪个模块坏了且没有指明执行者、情绪表述空洞对设备有信心是贺卡文案、适用于任何工业产品——这恰恰是 JTBD 分析没说出任何东西的信号。七、JTBD 技能在仓库中的定位与生态jobs-to-be-done是 Product-Manager-Skills 的 component组件型技能在 目录索引 skills-index.yaml 中登记为在澄清未满足需求、重新定位产品或改进 discovery 与 messaging 时使用估计耗时 20–30 分钟见 SKILL.md。在技能生态中它有清晰的上下游关系见 SKILL.md上游 / 前置proto-persona 定义谁拥有这些 Jobs / Pains / Gainsdiscovery-interview-prep 提供 JTBD 访谈的方法论问你想完成什么考虑过哪些替代方案为什么选择 X下游 / 消费方problem-statement 用 JTBD 填充Trying to与But段落positioning-statement 用 JTBD 填充that need陈述epic-hypothesis 用 JTBD 定义目标用户期望达成的结果competitive-analysis-process 甚至以 JTBD 为透镜做能力地图按客户 Job 而非功能名对比竞品。从源码结构看该技能目录下 SKILL.md、template.md、examples/sample.md 与 examples/sample-industrial.md 四份文件构成了框架说明 → 填空模板 → 软件行业正反示例 → 工业行业进阶示例的完整教学链条且其在 skills-by-type.md 中被归类为 discovery-research 主题下的组件技能——这解释了为什么示例 1 强调Pains 由研究验证JTBD 的正确用法永远是先访谈、再结构、后验证而不是先填表、再想象、后美化。赞分享AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载相关推荐Product-Manager-Skills 的 Jobs-to-be-Done 技能实战指南用结构化 JTBD 挖掘客户 Job、Pain 与 GainProduct Manager Skills 的 Jobs to be Done 技能实战指南用结构化 JTBD 挖掘客户 Job、Pain 与 Gain 导AI 技能AI 插件easy-vibe 产品思维指南用 Jobs to Be Done 从功能清单转向可验证的用户需求假设easy vibe 产品思维指南用 Jobs to Be Done 从功能清单转向可验证的用户需求假设 导读 在 easy vibe 的项目制学习中产品方向教程文档browser-use 快速上手5 分钟让 AI 浏览器自动化替你批量下载网页文件browser use 快速上手5 分钟让 AI 浏览器自动化替你批量下载网页文件 你是不是也干过这种活五个供应商后台每个都要把月度报表一个个另存为人工智能AI Agent浏览器控制GUI 自动化MCP 服务上一篇Apache Beam WithKeys 实战用 Python 将 PCollection 元素转换为键值对的 Kata 精讲下一篇Kornia image 模块详解PyTorch 深度学习工作流中的高层图像处理 API 指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考