jtbd

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# 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

From Alubiama/awesome-cognitive-skills, MIT.

More from Alubiama/awesome-cognitive-skills