用户「雇用」产品来完成特定任务。Jobs Scoping 精确定义你的产品将服务哪些任务、拒绝哪些任务——划定战略边界，防止功能蔓延与范围盲区同时发生。
产品团队面临两种相反的失败模式，往往同时存在。第一种是功能蔓延（Scope Creep）：每个季度都在加功能，每个功能都有合理理由，但产品的核心价值却越来越难被用户感知。第二种是范围盲区（Scope Blindness）：用户其实在你的产品旁边完成另一个相关任务，而你完全没有意识到那也是一个机会。
这两种失败的根源相同：团队没有清晰定义「我们的产品被用户雇用来做什么」。Jobs Scoping 从 JTBD（Jobs-to-be-Done）理论出发，通过绘制完整的任务地图（Job Map），让团队看清任务的全貌，然后做出明确的覆盖决策——而不是让功能优先级在每次需求会议上被重新谈判。
好的 Scoping 不只是说「我们不做 X」——它要说清楚「我们不做 X，因为用户雇用我们是为了 Y，而 X 属于另一个不同的任务」。这个区别至关重要：它让拒绝变成战略选择，而不是资源限制。
无论什么任务，用户完成一个「工作」都遵循相同的八个阶段序列。这是 Bob Moesta 和 Chris Spiek 在研究数百个消费者行为后归纳的普遍结构。下表以 Spotify 完成「听到我会喜欢的音乐」这个任务为例，展示每个阶段的用户需求，以及 Spotify 的覆盖决策。
Jobs Scoping 是战略校准工具，在任何需要定义「我们是谁、不是谁」的关键时刻都能发挥作用。
2016 年，Bob Moesta 与 Intercom 团队合作进行了一次 Jobs Scoping 练习。当时 Intercom 面临一个战略迷局：他们的产品覆盖「实时客户消息」，但也有 CRM（客户关系管理）功能。两者听起来相近，但任务地图完全不同。
Jobs Scoping 是一个团队工作坊，通常需要产品负责人、设计师和研究员共同参与。完整流程约 3 小时，包含准备、绘图、决策和验证四个阶段。
任务界定法（Jobs Scoping）是待完成任务（JTBD）理论在产品定义阶段的延伸应用，聚焦于如何精确界定产品所要解决的"任务"范围——既不过宽导致资源分散，也不过窄导致用户价值受限。这一方法综合了克里斯滕森JTBD框架的任务层次模型与敏捷产品管理中的用户故事映射实践，帮助产品团队在立项阶段建立共同的问题边界认知。