Jtbd

JTBD

Goal

Turn a vague request, feature idea, or proposed solution into a clearer statement of the real job, desired progress, and hiring logic behind it.

The job of this skill is not to brainstorm features. The job is to reveal what the user is trying to get done, why current options are insufficient, and what success must feel like from the user's point of view.

This skill reframes the problem. It does not claim validated demand unless evidence is explicitly provided.

Default Posture

• reframe before ideating
• progress over personas
• circumstances over demographics
• forces over opinions
• outcomes before features

When To Use

Run this skill when:

• the user proposes a feature before naming the need
• the problem statement sounds like a solution statement
• demand is unclear or contradictory
• several ideas exist but it is unclear which one matters
• product, offer, workflow, or strategy decisions need better problem framing

This is a strong first step before:

• scamper
• triz
• broader product ideation
• roadmap prioritization

Scope Boundaries

In scope:

• identify the underlying job
• clarify desired progress and context
• surface switching forces
• name hiring and firing criteria
• produce a sharper framing for downstream methods

Out of scope by default:

• generating the final feature set
• validating market size
• writing full user stories or product requirements
• pretending one interview quote or one anecdote proves the job

Escalation Conditions

Pause and keep open_unknowns prominent when:

• the user and trigger context are both unclear
• no current alternative or workaround can be named
• the proposed job is too broad to guide decisions
• the framing depends on evidence that is not yet available

If framing remains weak after one pass, recommend validation or return to upstream method selection.

JTBD Workflow

1. Restate the proposed solution in neutral terms.
2. Extract the suspected user, context, and trigger moment.
3. Rewrite the problem as progress the user is trying to make.
4. Name the functional, emotional, and social dimensions if they matter.
5. Identify current alternatives, workarounds, or non-consumption.
6. Surface the four switching forces:
   • push of the current situation
   • pull of the new solution
   • anxiety about change
   • habit of the present
7. Define what "good progress" looks like.
8. Return a tighter JTBD framing for downstream use.

Core Questions

Use the minimum set needed:

• What is the user trying to get done?
• What happened that made this matter now?
• What progress is blocked today?
• What does the user use instead right now?
• What makes switching hard?
• What would make the user say "this solved it"?

Output Contract

Always return:

1. proposed_solution
2. job_executor
3. job_to_be_done
4. trigger_context
5. desired_progress
6. current_alternatives
7. switching_forces
8. hiring_criteria
9. evidence_status (provided, inferred, mixed)
10. open_unknowns
11. next_action

Good JTBD Signals

Strong signals:

• a clear before/after state
• a real triggering circumstance
• observable workarounds or alternatives
• concrete progress language
• decision criteria the user would actually use

Weak signals:

• generic demographics instead of context
• feature wishlists with no job
• abstract motivation without a triggering moment
• claims about "users" with no evidence source

Guardrails

• Do not confuse the job with the product category.
• Do not reduce JTBD to "the user wants feature X".
• Do not invent emotional or social dimensions if they do not matter.
• Do not force novelty; sometimes the right answer is better execution of an old job.
• Distinguish evidence from inference.
• If the job remains unclear, say so and keep open_unknowns explicit.
• If the framing is too weak for confident JTBD output, recommend validation instead of pretending certainty.

Anti-Patterns

Watch for these failure modes:

• turning JTBD into persona theater
• answering with feature ideas instead of a job statement
• using demographics as the main explanatory model
• ignoring the current workaround
• treating one solution concept as if it were already validated demand
• collapsing push, pull, anxiety, and habit into one vague paragraph

Example

User request:

We should build an AI meal planner for busy parents.

Expected shape of response:

1. proposed_solution: AI meal planner
2. job_executor: busy parent responsible for weeknight meals
3. job_to_be_done: help me decide and prepare acceptable weeknight meals fast enough that feeding my family does not drain my time and attention after work
4. trigger_context: repeated evening decision fatigue, low time, conflicting family preferences
5. desired_progress: move from stressful last-minute meal decisions to a repeatable low-friction dinner routine
6. current_alternatives: takeout, repeating familiar meals, ad hoc grocery runs, generic recipe apps
7. switching_forces: push from meal stress, pull from easier planning, anxiety about complexity and family rejection, habit of existing routines
8. hiring_criteria: fast planning, low mental load, family acceptance, realistic ingredients
9. evidence_status: inferred
10. open_unknowns: who plans meals, what "acceptable" means, how often planning fails today
11. next_action: validate the job and switching forces before ideating features