jtbd-framing

Jobs-to-be-Done Framing

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.

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.

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.

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](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 switchi