Back to Details

jtbd-framing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Jobs-to-be-Done Framing

Jobs-to-be-Done框架应用

A senior product leader's playbook for the Jobs-to-be-Done framework as applied methodology. Job statements, struggling moments, hire and fire criteria, the difference between feature-thinking and job-thinking. Honest about where JTBD adds clarity and where it becomes performative ritual.
JTBD has become one of the more cited and less practiced frameworks in product. Teams cite it in strategy docs, run job-statement workshops, produce wall-sized artifacts, and continue building from feature requests and persona archetypes the next quarter. The methodology gets the credit; the practice gets skipped.
This skill is JTBD as applied product methodology. The framework's actual contribution: surfacing what users are trying to ACCOMPLISH (the job) rather than treating users as preference-aggregators (feature requests) or demographic archetypes (persona theater). When the framing is grounded in struggling moments and hire/fire criteria, it produces decisions; when it stops at the job-statement worksheet, it produces ritual.
This skill is honest about both modes. JTBD genuinely earns its keep in discovery, prioritization, and positioning when applied with rigor. It becomes ceremony when teams treat job statements as deliverables rather than as analytical tools.
The voice is the senior product leader who has used JTBD well and watched plenty of teams use it badly. Concrete, opinionated about what the framework actually contributes, willing to call out where it gets oversold.
When to use this skill: applying JTBD to a discovery cycle, replacing persona-driven prioritization with job-driven prioritization, reframing positioning around what users hire the product to do, or auditing whether existing JTBD work in the org is driving decisions.
资深产品负责人的Jobs-to-be-Done（JTBD）框架实战手册。涵盖工作陈述、挣扎时刻、雇佣和解雇标准，以及功能思维与工作思维的差异。客观阐述JTBD在哪些场景下能提升清晰度，哪些场景下会沦为形式化流程。
JTBD已成为产品领域被引用最多但实践最少的框架之一。团队在战略文档中提及它，举办工作陈述研讨会，制作大幅墙面成果，但下个季度仍继续基于功能请求和角色原型进行产品构建。方法论获得了认可，实践环节却被跳过。
这个技能聚焦于作为实战产品方法论的JTBD。该框架的实际价值在于：挖掘用户真正想要完成的任务（工作），而非将用户视为偏好集合体（功能请求）或人口统计原型（角色剧场）。当框架基于挣扎时刻和雇佣/解雇标准落地时，它能驱动决策；若仅停留在工作陈述工作表层面，则会沦为形式化流程。
本内容客观呈现了JTBD的两种应用模式。当严谨应用时，JTBD确实能在产品发现、优先级排序和定位环节发挥价值。当团队将工作陈述视为交付成果而非分析工具时，它就会沦为形式化流程。
内容视角来自一位既成功应用过JTBD，也见过众多团队错误使用该框架的资深产品负责人。内容具体务实，明确阐述框架的实际价值，敢于指出其被过度吹捧的地方。
何时使用该技能：将JTBD应用于产品发现周期、用工作驱动的优先级排序替代角色驱动的优先级排序、围绕用户雇佣产品的核心目标重新定位产品、审核组织内现有JTBD工作是否能驱动决策。

What this skill is for

该技能的适用场景

This skill spans JTBD as a framing technique within product work. The PM-skill distinction:
  • discovery-research-synthesis
    is broader synthesis discipline; JTBD is one framing technique within it.
  • jtbd-framing
    (this skill)     is the specific JTBD methodology, its strengths, and its failure modes.
  • pm-spec-writing
    is downstream: specs reference jobs as input.
  • creative-direction
    is positioning territory; JTBD informs positioning but does not replace creative direction.
  • roadmap-planning
    is downstream: roadmap can be organized around jobs rather than features.
The audience: senior PMs, product directors, product strategists, agencies running discovery and positioning work, in-house teams considering or already using JTBD.
What is not in scope: other product strategy frameworks (Wardley mapping, North Star, OKRs); the broader synthesis discipline (
discovery-research-synthesis
covers it); the demographic-persona work that sometimes gets confused with JTBD.
本技能涵盖产品工作中作为框架技术的JTBD。与其他产品经理技能的区别：
  • discovery-research-synthesis
    是更宽泛的综合研究学科；JTBD是其中一种框架技术。
  • **
    jtbd-framing
    （本技能）**是特定的JTBD方法论，包括其优势和失效模式。
  • pm-spec-writing
    属于下游环节：需求文档会将工作作为输入参考。
  • creative-direction
    属于定位领域；JTBD为定位提供信息，但不能替代创意指导。
  • roadmap-planning
    属于下游环节：路线图可以围绕工作而非功能进行组织。
受众：资深产品经理、产品总监、产品策略师、从事产品发现和定位工作的机构、正在考虑或已使用JTBD的内部团队。
不涵盖的内容：其他产品战略框架（Wardley映射、北极星指标、OKRs）；更宽泛的综合研究学科（
discovery-research-synthesis
涵盖该内容）；有时会与JTBD混淆的人口统计角色相关工作。

Feature-request-list vs persona-theater vs job-framing

feature-request-list vs persona-theater vs job-framing

The keystone framing.
Feature-request-list. "Users want X, Y, Z." Treats users as preference-aggregators. The product team builds the most-requested features. Output: a product that satisfies stated preferences but misses what users were actually trying to accomplish. Users do not always know what would solve their problem; they describe symptoms, not solutions. Feature-list-driven products often improve incrementally without becoming meaningfully better.
Persona-theater. Demographic personas with cute names. "Marketing Manager Maria, 35, urban, Pinterest user, drinks oat milk lattes." Decorative, not decision-driving. Persona characteristics rarely correlate with what the user needs from the product; demographic detail substitutes for behavioral insight. Personas in the wild often live as wall posters that nobody references in actual prioritization debates.
Job-framing. Users hire products to do jobs. The job is what the user is trying to accomplish, not who the user is or what features they request. The framing surfaces struggling moments (when do users feel pulled toward an alternative); hire criteria (what makes them adopt a product); fire criteria (what makes them switch away). Output: product decisions grounded in user motivation rather than user description.
The litmus test. Take a product decision the team is debating. Can JTBD ground the decision? "Should we build feature X?" Reframed: "What job would feature X help users do? What job is currently done badly that this addresses?" If the JTBD framing produces clearer arguments on both sides, the framing is earning its keep. If the JTBD framing just adds vocabulary without resolving the debate, the framing is ritual.
核心框架对比。
feature-request-list（功能请求列表）：“用户想要X、Y、Z。”将用户视为偏好集合体。产品团队开发最受追捧的功能。产出：满足用户明确偏好但未触及用户真实需求的产品。用户并不总是知道什么能解决他们的问题；他们描述的是症状，而非解决方案。基于功能列表驱动的产品通常只会有小幅改进，无法实现质的提升。
persona-theater（角色剧场）：带有可爱名字的人口统计角色。“营销经理Maria，35岁，居住在城市，Pinterest用户，喝燕麦奶拿铁。”仅作装饰，无法驱动决策。角色特征很少与用户对产品的需求相关；人口统计细节取代了行为洞察。实际场景中，角色通常只是贴在墙上的海报，没人在实际优先级讨论中参考它们。
job-framing（工作框架）：用户雇佣产品来完成工作。工作指的是用户想要完成的任务，而非用户的身份或他们请求的功能。该框架挖掘挣扎时刻（用户何时会被替代方案吸引）、雇佣标准（促使他们采用产品的因素）、解雇标准（促使他们转用其他产品的因素）。产出：基于用户动机而非用户描述的产品决策。
检验标准：选取团队正在讨论的一个产品决策。JTBD能否为该决策提供依据？“我们应该开发功能X吗？”重新表述为：“功能X能帮助用户完成什么工作？它解决了当前哪个完成得不好的工作？”如果JTBD框架能为辩论双方提供更清晰的论据，那么它就发挥了价值。如果JTBD框架只是增加了词汇却无法解决辩论，那么它就是形式化流程。

The job statement structure

工作陈述结构

The canonical structure: "When [situation], I want to [motivation], so I can [outcome]."
Situation. The context, trigger, or moment when the job becomes active. Not a demographic; a moment.
  • "When my team is rolling out a new feature and I need to communicate it to customers..."
  • "When I am preparing the quarterly board deck..."
  • "When I get a customer escalation outside of business hours..."
Motivation. What the user is trying to do in that situation.
  • "...I want to write a clear announcement that explains what changed and why it matters..."
  • "...I want to assemble revenue and engagement data into a coherent narrative..."
  • "...I want to triage and respond without disrupting my evening too much..."
Outcome. What success looks like; what the user is trying to achieve by doing the job.
  • "...so I can ship the rollout without flooding support with confusion."
  • "...so I can answer the board's likely questions before they ask them."
  • "...so I can address the customer's concern while still being present at home."
The structure forces specificity at all three levels. Vague situations, vague motivations, or vague outcomes produce job statements that drive nothing.
Detail in 
references/job-statement-structure-patterns.md
.
标准结构：“当[场景]时，我想要[动机]，以便[成果]。”
场景：工作激活的背景、触发因素或时刻。不是人口统计特征，而是某个时刻。
  • “当我的团队推出新功能，需要向客户传达时……”
  • “当我准备季度董事会报告时……”
  • “当我在非工作时间收到客户投诉时……”
动机：用户在该场景下想要完成的事情。
  • “……我想要撰写清晰的公告，解释变更内容及其重要性……”
  • “……我想要将收入和参与度数据整合成连贯的叙事……”
  • “……我想要在不严重打扰自己夜晚的情况下进行分类和回复……”
成果：成功的表现；用户完成该工作想要达成的目标。
  • “……以便顺利完成功能推出，不会让支持团队收到大量困惑咨询。”
  • “……以便在董事会提问前就准备好答案。”
  • “……以便在处理客户问题的同时，还能兼顾家庭。”
该结构要求三个层面都具备明确性。模糊的场景、动机或成果会产生无法驱动任何决策的工作陈述。
详细内容见
references/job-statement-structure-patterns.md
。

Identifying struggling moments

识别挣扎时刻

Jobs become visible at struggling moments: when the user's current solution is failing them, when the alternative tools they have feel inadequate, when they would actively prefer a different way of doing the job.
The signal. Users describe friction in their current approach. They describe workarounds. They describe wishing they had something better. They describe specific moments when the current approach broke down.
The methodology. Discovery interviews surface struggling moments through specific prompts: "Walk me through the last time you did X." "What was hardest about that?" "What would you have done differently if you could?" Specific recent moments produce richer data than abstracted descriptions of "how I usually do this."
The pattern recognition. Across many users, struggling moments cluster. The same kinds of friction recur. The clusters reveal the jobs that are not currently being done well in the market.
The pitfall. Teams that interview without grounding in specific moments produce abstracted job descriptions that cannot drive decisions. "Users want to be more productive" is not a struggling moment; "I lost an hour on Tuesday assembling the board metrics from three different dashboards because none of them had the slice I needed" is.
Detail in 
references/identifying-struggling-moments.md
.
工作在挣扎时刻会显现：用户当前的解决方案失效时，他们现有的替代工具不足时，他们明确想要不同的工作方式时。
信号：用户描述当前方法中的摩擦。他们描述变通方案。他们表达希望拥有更好工具的意愿。他们描述当前方法失效的具体时刻。
方法论：通过特定提问在发现访谈中挖掘挣扎时刻：“带我回顾你最近一次做X的经历。”“最困难的部分是什么？”“如果可以的话，你会怎么做？”具体的近期时刻比“我通常怎么做”这类抽象描述能产生更丰富的数据。
模式识别：在众多用户中，挣扎时刻会形成聚类。相同类型的摩擦反复出现。这些聚类揭示了市场中当前未被很好完成的工作。
陷阱：未基于具体时刻进行访谈的团队会产生无法驱动决策的抽象工作描述。“用户想要提高生产力”不是挣扎时刻；“周二我花了一个小时从三个不同的仪表板整理董事会指标，因为没有一个仪表板包含我需要的细分数据”才是。
详细内容见
references/identifying-struggling-moments.md
。

Hire and fire criteria

雇佣和解雇标准

Why users adopt a product (hire), why they switch away (fire). The two questions ground the framework in real decisions users make.
Hire criteria.
  • The struggling moment the user is trying to solve.
  • The alternatives they considered or tried first.
  • What made the chosen product the answer (vs the alternatives).
  • The expected job output: what the user expected to accomplish with the product.
Fire criteria.
  • The struggling moment that recurred even with the chosen product.
  • The alternative that started looking better.
  • What tipped the user from "considering switching" to "switching."
  • The job output that the chosen product failed to deliver consistently.
Why hire/fire matters.
  • Hire criteria reveal what the product needs to be excellent at to win adoption.
  • Fire criteria reveal what the product needs to maintain to retain users.
  • The two are often different: features that win adoption are not always the features that prevent churn.
The methodology. Customer interviews surface hire/fire through specific prompts: "What were you doing before you adopted X?" "What made you switch?" "If you switched away from X tomorrow, what would the trigger be?" Recent switch decisions are particularly rich; users remember the specific moment.
Detail in 
references/hire-and-fire-criteria.md
.
用户为何采用产品（雇佣），为何转用其他产品（解雇）。这两个问题将框架与用户做出的真实决策挂钩。
雇佣标准：
  • 用户试图解决的挣扎时刻。
  • 他们考虑或尝试过的替代方案。
  • 为何所选产品是最佳答案（与替代方案相比）。
  • 预期的工作产出：用户期望通过产品完成的目标。
解雇标准：
  • 即使使用所选产品仍反复出现的挣扎时刻。
  • 开始看起来更优的替代方案。
  • 促使用户从“考虑转换”变为“实际转换”的触发因素。
  • 所选产品未能持续交付的工作产出。
雇佣/解雇标准的重要性：
  • 雇佣标准揭示了产品为赢得用户采用必须具备的核心优势。
  • 解雇标准揭示了产品为保留用户必须维持的核心能力。
  • 两者通常不同：赢得用户采用的功能并不总是能防止用户流失的功能。
方法论：通过特定提问在客户访谈中挖掘雇佣/解雇标准：“在采用X之前，你在做什么？”“是什么促使你转换？”“如果你明天放弃X，触发因素会是什么？”近期的转换决策尤其有价值；用户会记得具体时刻。
详细内容见
references/hire-and-fire-criteria.md
。

Functional, emotional, and social dimensions of jobs

工作的功能性、情感性和社会性维度

Jobs have three dimensions. Strong JTBD work surfaces all three; weak work treats jobs as functional only.
Functional dimension. What the user is mechanically trying to accomplish.
  • "Assemble the quarterly board deck."
  • "Track team OKR progress."
  • "Onboard a new engineer to the codebase."
Emotional dimension. How the user feels (or wants to feel) doing the job.
  • "Confident that the deck represents the team's actual progress, not a polished version."
  • "In control of the OKR check-in cadence, not behind on it."
  • "Helpful to the new engineer without becoming their full-time guide."
Social dimension. How the user wants to be perceived doing the job.
  • "Seen by the board as a competent leader who knows the numbers."
  • "Seen by direct reports as someone who follows through on commitments."
  • "Seen by the new engineer as a senior who invested in their onboarding."
Why three dimensions matter.
  • Products that win on functional alone often lose to alternatives that also serve emotional and social.
  • Some product decisions hinge on emotional dimensions ("the user wants to feel in control"); functional analysis alone misses these.
  • Social dimensions inform positioning more than functional descriptions do.
The discipline. For each job statement, ask the three dimensions explicitly. Most early job statements are functional-only; the addition of emotional and social often reveals what the product actually needs to address.
Detail in 
references/functional-emotional-social-dimensions.md
.
工作具备三个维度。优秀的JTBD工作会挖掘所有三个维度；糟糕的工作仅关注功能性维度。
功能性维度：用户机械层面想要完成的事情。
  • “整理季度董事会报告。”
  • “跟踪团队OKR进度。”
  • “引导新工程师熟悉代码库。”
情感性维度：用户在完成工作时的感受（或想要的感受）。
  • “确信报告真实反映了团队的实际进度，而非经过修饰的版本。”
  • “掌控OKR检查节奏，而非落后于进度。”
  • “对新工程师提供帮助，但不会成为他们的全职指导。”
社会性维度：用户在完成工作时希望给他人留下的印象。
  • “在董事会眼中是熟悉数据的称职领导者。”
  • “在直属下属眼中是信守承诺的人。”
  • “在新工程师眼中是重视他们入职的资深员工。”
三个维度的重要性：
  • 仅在功能性维度表现出色的产品，往往会输给同时兼顾情感性和社会性维度的替代方案。
  • 一些产品决策取决于情感性维度（“用户想要掌控感”）；仅做功能性分析会忽略这些需求。
  • 社会性维度比功能性描述更能影响产品定位。
实践要求：针对每个工作陈述，明确询问三个维度。大多数早期工作陈述仅关注功能性；添加情感性和社会性维度通常会揭示产品实际需要解决的问题。
详细内容见
references/functional-emotional-social-dimensions.md
。

Where JTBD adds clarity vs where it becomes ritual

JTBD提升清晰度的场景vs沦为形式化流程的场景

The honest framing.
Where JTBD genuinely earns its keep.
  • Discovery. When research is grounded in struggling moments and hire/fire decisions, JTBD surfaces the user motivation that feature-list discovery misses. Discovery interviews structured around jobs produce richer data than ones structured around feature preferences.
  • Prioritization. When the team is debating which work to prioritize, jobs ground the debate in what users are trying to accomplish. "Does this work help users do an important job better?" cuts through the politics of feature-request prioritization.
  • Positioning. When marketing or sales is articulating what the product does, jobs frame the product as a way of accomplishing something the customer cares about, rather than as a feature list.
Where JTBD becomes ritual.
  • Job-statement workshops as deliverables. The team runs a workshop, produces a wall of job statements, and never references the artifacts in subsequent decisions. The workshop became the deliverable; the analytical work did not happen.
  • Job statements substituted for personas without analytical rigor. "We have JTBD now" but the team treats job statements as named characters (Job Bob, Job Alice) instead of as analytical tools.
  • Mandatory JTBD for every product question. Every meeting starts with "what's the job?" Even when the question does not benefit from the framing. The methodology becomes a tax rather than a tool.
  • JTBD as compliance. The org adopts JTBD because a leadership book or conference talk endorsed it; teams produce JTBD artifacts to show they are using the framework; nobody actually uses the framework to decide.
The honest signal. If the team can show how a recent product decision was different because of JTBD analysis, the framework is earning its keep. If the team uses JTBD vocabulary but cannot trace decisions to JTBD analysis, the framework is ritual.
客观的框架应用分析。
JTBD真正发挥价值的场景：
  • 产品发现：当研究基于挣扎时刻和雇佣/解雇决策时，JTBD能挖掘出功能列表式发现无法触及的用户动机。围绕工作构建的发现访谈比围绕功能偏好构建的访谈能产生更丰富的数据。
  • 优先级排序：当团队讨论工作优先级时，工作能将辩论聚焦于用户想要完成的任务。“这项工作能否帮助用户更好地完成重要任务？”能打破功能请求优先级排序中的政治博弈。
  • 产品定位：当营销或销售阐述产品用途时，工作将产品定位为帮助客户完成重要任务的工具，而非功能列表。
JTBD沦为形式化流程的场景：
  • 将工作陈述研讨会视为交付成果：团队举办研讨会，制作一墙的工作陈述，但后续决策从未参考这些成果。研讨会成了交付成果，而分析工作并未开展。
  • 无分析严谨性地用工作陈述替代角色：“我们现在用JTBD了”，但团队将工作陈述视为命名角色（Job Bob、Job Alice）而非分析工具。
  • 对所有产品问题强制使用JTBD：每次会议都以“对应的工作是什么？”开头，即使该问题无法从框架中获益。方法论成了一种负担而非工具。
  • 将JTBD视为合规要求：组织因某本领导力书籍或会议演讲而采用JTBD；团队制作JTBD成果以证明自己在使用框架，但实际上没人用框架做决策。
客观判断信号：如果团队能证明近期某个产品决策因JTBD分析而有所不同，那么框架就发挥了价值。如果团队使用JTBD术语但无法将决策追溯到JTBD分析，那么框架就是形式化流程。

Applying JTBD to discovery, prioritization, positioning

将JTBD应用于产品发现、优先级排序和定位

The three modes where JTBD genuinely contributes.
Discovery. Structure interviews around recent struggling moments, hire decisions, and fire decisions. Gather job statements after the interviews from the data, not before. Cluster jobs across users. Name jobs from the clusters. Pair with 
discovery-research-synthesis
for the broader synthesis discipline.
Detail in 
references/applying-jtbd-to-discovery.md
.
Prioritization. When evaluating roadmap candidates, frame each candidate by the job(s) it addresses. Ask: which jobs is the product currently doing badly? Which candidates address those jobs vs adjacent or unrelated work? Pair with 
roadmap-planning
for the broader prioritization discipline.
Detail in 
references/applying-jtbd-to-prioritization.md
.
Positioning. When articulating what the product is for, lead with the job rather than the features. "Help product teams synthesize discovery research into decisions" is a job framing; "AI-powered research synthesis with collaboration tools" is a feature framing. Pair with 
creative-direction
and 
brand-discovery
for the broader positioning work.
Detail in 
references/applying-jtbd-to-positioning.md
.
JTBD真正能发挥作用的三个场景。
产品发现：围绕近期的挣扎时刻、雇佣决策和解雇决策构建访谈结构。从访谈数据中提炼工作陈述，而非提前预设。对用户的工作进行聚类。从聚类中为工作命名。结合
discovery-research-synthesis
进行更宽泛的综合研究。
详细内容见
references/applying-jtbd-to-discovery.md
。
优先级排序：评估路线图候选项时，围绕其解决的工作进行阐述。提问：产品当前哪些工作完成得不好？哪些候选项解决这些工作，哪些解决的是相关或无关工作？结合
roadmap-planning
进行更宽泛的优先级排序。
详细内容见
references/applying-jtbd-to-prioritization.md
。
产品定位：阐述产品用途时，以工作而非功能为核心。“帮助产品团队将发现研究转化为决策”是工作导向的定位；“具备协作工具的AI驱动研究综合平台”是功能导向的定位。结合
creative-direction
和
brand-discovery
进行更宽泛的定位工作。
详细内容见
references/applying-jtbd-to-positioning.md
。

Common failure modes

常见失效模式

Rapid-fire. Diagnoses in 
references/common-jtbd-failures.md
.
  • "We did the JTBD workshop but nothing changed in our roadmap." Job-statement workshop as deliverable; no analytical work after the workshop.
  • "Our job statements all sound the same." Generic job statements; not grounded in specific struggling moments. Re-ground in interview data.
  • "Our jobs read like feature requests." "When I am using product X, I want feature Y" is not a job; the job is what the user was trying to accomplish, independent of the product.
  • "We have personas and jobs and they contradict each other." Personas are demographic; jobs are situational. They do not have to align; if they conflict, jobs usually carry more decision weight.
  • "JTBD says we should build everything." Without prioritization across jobs, JTBD identifies many opportunities and does not pick. Pair with prioritization discipline.
  • "We dropped JTBD because it became theater." Common; the recovery is JTBD as analytical tool, not JTBD as ritual. Use the framework where it earns its keep; do not force it everywhere.
  • "Our job statements are functional only." Add emotional and social dimensions; many product decisions hinge on the latter two.
  • "We cannot agree on the job." Often signals different segments with different jobs. Surface the segment differences.
  • "Our marketing copy uses JTBD vocabulary but our product does not." Positioning-product gap; the marketing claim is not load-bearing in product decisions.
快速诊断。详细诊断见
references/common-jtbd-failures.md
。
  • “我们举办了JTBD研讨会，但路线图没有任何变化。” 将工作陈述研讨会视为交付成果；研讨会后未开展分析工作。
  • “我们的工作陈述听起来都一样。” 通用化的工作陈述；未基于具体的挣扎时刻。重新基于访谈数据构建。
  • “我们的工作读起来像功能请求。” “当我使用产品X时，我想要功能Y”不是工作；工作是用户想要完成的任务，与产品无关。
  • “我们有角色和工作，它们相互矛盾。” 角色基于人口统计特征；工作基于场景。它们不需要一致；若存在冲突，工作通常更具决策权重。
  • “JTBD说我们应该开发所有功能。” 未对工作进行优先级排序，JTBD识别出很多机会但无法筛选。结合优先级排序方法。
  • “我们放弃JTBD了，因为它变成了形式化流程。” 常见情况；解决方法是将JTBD作为分析工具而非形式化流程。在能发挥价值的场景使用框架；不要强制应用于所有场景。
  • “我们的工作陈述仅关注功能性。” 添加情感性和社会性维度；很多产品决策取决于后两者。
  • “我们无法就工作达成一致。” 通常意味着不同细分群体有不同的工作。挖掘细分群体的差异。
  • “我们的营销文案使用JTBD术语，但产品并未落地。” 定位与产品脱节；营销主张未在产品决策中得到支撑。

The framework: 12 considerations for JTBD framing

框架：JTBD应用的12项考量

When applying JTBD or auditing JTBD work, walk these 12 considerations.
  1. Job-framing, not feature-list or persona-theater. Users hire products to accomplish jobs.
  2. Job statement structure: situation, motivation, outcome. Specific at all three levels.
  3. Struggling moments ground the jobs. Specific recent moments, not abstractions.
  4. Hire criteria identified. What makes users adopt the product over alternatives.
  5. Fire criteria identified. What makes users switch away (or would).
  6. Functional, emotional, social dimensions surfaced. All three; not functional only.
  7. Jobs derived from data, not workshop output. Job statements emerge from interview data, not from whiteboard sessions.
  8. JTBD applied where it earns its keep. Discovery, prioritization, positioning. Not as ritual.
  9. Segment differences in jobs surfaced. When the same product is hired for different jobs by different segments.
  10. Decisions traceable to JTBD analysis. Each major decision can be explained through the job framing.
  11. JTBD vocabulary not substituted for analytical work. Vocabulary without analysis is ritual.
  12. Honest assessment of where JTBD does not help. Some questions do not benefit from the framing; force-fitting produces ritual.
The output of the framework is product decisions grounded in user motivation rather than user description, with the framing applied where it adds clarity and held back where it would become ritual.
应用JTBD或审核JTBD工作时，需遵循以下12项考量。
  1. 采用工作框架，而非功能请求列表或角色剧场。用户雇佣产品来完成工作。
  2. 工作陈述结构：场景、动机、成果。三个层面均需明确具体。
  3. 以挣扎时刻为工作基础。具体的近期时刻，而非抽象描述。
  4. 明确雇佣标准。用户为何选择该产品而非替代方案。
  5. 明确解雇标准。用户为何转用其他产品（或可能转用的原因）。
  6. 挖掘功能性、情感性和社会性维度。三个维度均需覆盖；不能仅关注功能性。
  7. 从数据中提炼工作，而非从研讨会产出中获取。工作陈述来自访谈数据，而非白板会议。
  8. 在能发挥价值的场景应用JTBD。产品发现、优先级排序、定位。不要将其作为形式化流程。
  9. 挖掘不同细分群体的工作差异。当同一产品被不同细分群体用于完成不同工作时。
  10. 决策可追溯到JTBD分析。每个重大决策都能通过工作框架进行解释。
  11. 不要用JTBD术语替代分析工作。仅有术语而无分析就是形式化流程。
  12. 客观评估JTBD无效的场景。有些问题无法从框架中获益；强行套用会导致形式化流程。
该框架的产出是基于用户动机而非用户描述的产品决策，框架仅在能提升清晰度的场景应用，避免沦为形式化流程。

Reference files

参考文件

  • references/job-statement-structure-patterns.md
     - The situation/motivation/outcome structure with worked examples. Common structural failures (vague situations, motivation as feature request, outcome as feature output).
  • references/identifying-struggling-moments.md
     - Discovery prompts that surface struggling moments. Pattern recognition across users. The specific-moment vs abstraction distinction.
  • references/hire-and-fire-criteria.md
     - Methodology for surfacing hire and fire criteria. Why the two are often different. Recent-switch interview discipline.
  • references/functional-emotional-social-dimensions.md
     - Three dimensions per job. Why functional-only fails. Worked examples per dimension. Positioning implications of social dimension.
  • references/applying-jtbd-to-discovery.md
     - Discovery interview structure around jobs. Job clustering. Naming jobs from data. Pair with discovery-research-synthesis.
  • references/applying-jtbd-to-prioritization.md
     - Prioritizing roadmap candidates by jobs. Identifying which jobs are done badly. Pair with roadmap-planning.
  • references/applying-jtbd-to-positioning.md
     - Job-led positioning vs feature-led positioning. Lead with what the product helps users accomplish. Pair with creative-direction.
  • references/common-jtbd-failures.md
     - 9+ failure patterns with diagnoses and cures. The cross-cutting pattern: JTBD as ritual vs JTBD as analytical tool.
  • references/job-statement-structure-patterns.md
     - 场景/动机/成果结构及实例。常见结构缺陷（模糊场景、动机为功能请求、成果为功能输出）。
  • references/identifying-struggling-moments.md
     - 挖掘挣扎时刻的发现提问方式。跨用户的模式识别。具体时刻与抽象描述的区别。
  • references/hire-and-fire-criteria.md
     - 挖掘雇佣和解雇标准的方法论。两者为何通常不同。近期转换决策的访谈原则。
  • references/functional-emotional-social-dimensions.md
     - 每项工作的三个维度。仅关注功能性为何失效。各维度实例。社会性维度对定位的影响。
  • references/applying-jtbd-to-discovery.md
     - 围绕工作构建的发现访谈结构。工作聚类。从数据中为工作命名。结合discovery-research-synthesis。
  • references/applying-jtbd-to-prioritization.md
     - 按工作优先级排序路线图候选项。识别完成得不好的工作。结合roadmap-planning。
  • references/applying-jtbd-to-positioning.md
     - 工作导向定位vs功能导向定位。以产品帮助用户完成的任务为核心。结合creative-direction。
  • references/common-jtbd-failures.md
     - 9种以上失效模式及诊断和解决方法。核心模式：JTBD作为形式化流程vs JTBD作为分析工具。

Closing: jobs over features

结语：工作优先于功能

The Jobs-to-be-Done framework is one of the most useful product methodologies available when applied with rigor, and one of the most performative when applied as ritual. The difference is in whether the framework drives decisions or decorates documentation.
Jobs over features is a real shift in product thinking. Feature-list discovery treats users as preference-aggregators; persona archetypes treat users as demographic categories; job-framing treats users as people trying to accomplish things, where the product is one tool they hire (or fire) for the job.
The teams that benefit from JTBD are the ones that take the analytical work seriously: grounding jobs in struggling moments, identifying hire and fire criteria, surfacing functional-emotional-social dimensions, deriving jobs from data, and applying the framing where it earns its keep. The teams that adopt JTBD vocabulary without the analytical work produce ritual.
When in doubt about whether a JTBD application is real or ritual, ask: can a recent product decision be traced to the JTBD analysis, or did the JTBD work happen in parallel with decisions that were made on other grounds? If the former, JTBD is doing its work. If the latter, the framework is decoration.
当严谨应用时，Jobs-to-be-Done框架是产品领域最实用的方法论之一；当作为形式化流程应用时，它也是最具表演性的框架之一。区别在于框架是驱动决策还是仅装饰文档。
工作优先于功能是产品思维的真正转变。功能列表式发现将用户视为偏好集合体；角色原型将用户视为人口统计类别；工作框架将用户视为想要完成任务的个体，产品是他们为完成任务而雇佣（或解雇）的工具之一。
能从JTBD中获益的团队是那些认真对待分析工作的团队：以挣扎时刻为工作基础、明确雇佣和解雇标准、挖掘功能性-情感性-社会性维度、从数据中提炼工作、在能发挥价值的场景应用框架。仅采用JTBD术语而不开展分析工作的团队，只会产生形式化流程。
若不确定JTBD应用是真实有效还是形式化流程，可提问：近期某个产品决策能否追溯到JTBD分析？还是JTBD工作与基于其他依据做出的决策并行开展？如果是前者，JTBD就发挥了作用。如果是后者，框架只是装饰。