Jobs to Be Done skill for Codex

JTBD work is done well when the job is stated without reference to any product, the forces behind real switching decisions are backed by interview evidence, and the resulting job stories describe a situation and motivation precise enough to design for, so that a solution can be judged by whether it helps the customer make progress.

Core vocabulary

Term	Meaning	Example
Job	Progress a person wants in a circumstance	Get the team aligned on this week’s priorities without a meeting
Circumstance	The situation that makes the job arise	Monday, team is remote, two people were out last week
Functional / emotional / social dimensions	What must get done, how they want to feel, how they want to be seen	Done; in control; seen as organized by their boss
Hire / fire	Choosing or dropping a solution for the job	Fired the weekly sync meeting, hired an async update doc
Competition	Anything hired for the same job, including doing nothing	Spreadsheets, Slack threads, a meeting, a person

Test a job statement: if it mentions your product, a feature, or a technology, it is a solution, not a job. Rewrite it.

Switch interviews

Interview people who switched recently (ideally within 90 days), toward or away from your product. Rebuild the timeline:

First thought -> Passive looking -> Event -> Active looking -> Deciding -> First use -> Ongoing use

Ask for concrete moments on each step: “When did you first think the old way was not working? Where were you? What happened that day?” Dates, places and people make memories reliable; generalities do not. Use $customer-interviews for logistics, consent and general question rules; this skill adds the timeline and forces lens.

Four forces

For each interview, record evidence for each force:

Force	Direction	Listen for
Push of the situation	Toward change	“We missed a deadline because…”, “my boss asked why…”
Pull of the new solution	Toward change	“I saw that it could…”, “a friend showed me…”
Anxiety of the new	Against change	“What if the team won’t use it?”, migration fears, price risk
Habit of the present	Against change	“We’ve always done it in spreadsheets”, sunk setup effort

Switching happens when push + pull exceed anxiety + habit. Product and marketing levers differ by force: onboarding and migration tools reduce anxiety; templates and imports fight habit; messaging should name the push the customer already feels.

Job map and outcome statements

When the job is understood, map its steps (a universal job map: define, locate, prepare, confirm, execute, monitor, modify, conclude). For each step write desired-outcome statements in a consistent form so they can later be rated for importance and satisfaction in a survey:

Minimize the time it takes to confirm everyone has seen the priorities
Minimize the likelihood that a dependency between two people is missed

Format: direction (minimize / increase) + metric (time, likelihood, number) + object + context. Keep them solution-free. Opportunity scoring needs a quantitative survey ($survey-design); do not fabricate importance or satisfaction numbers.

Job stories

Use job stories when the situation matters more than the persona:

When <situation with specific trigger and context>,
I want to <motivation / what I'm trying to do>,
so I can <expected outcome>.

Example rewrite:

• User story: “As a team lead, I want a weekly summary so that I know what happened.”
• Job story: “When I start Monday after a week away, I want to see which commitments changed and who changed them, so I can re-plan before the 10:00 stand-up without pinging everyone.”

The job story tells a designer what information, timing and level of detail matter. Keep user stories ($user-stories) for sprint-sized delivery slices; job stories frame what those slices should achieve.

Workflow

- [ ] 1. State the decision this JTBD work informs
- [ ] 2. Recruit recent switchers (both directions) and non-adopters
- [ ] 3. Run 8-12 switch interviews; capture timeline and forces per person
- [ ] 4. Cluster interviews by circumstance and push, not by demographic
- [ ] 5. Write 1-3 job statements per cluster, solution-free
- [ ] 6. Map job steps; write desired-outcome statements per step
- [ ] 7. Write job stories for the circumstances the product will target
- [ ] 8. List competing solutions per job, including non-consumption

Output template

## JTBD findings: <scope>
Interviews: 11 (6 switched to us, 3 switched away, 2 evaluated and stayed put)

### Job 1: <solution-free statement>
Circumstances: <when it arises>
Dimensions: functional <...>; emotional <...>; social <...>
Forces (count of interviews with evidence):
- Push (9): <summary + 1 quote>
- Pull (7): ...
- Anxiety (6): ...
- Habit (8): ...
Competing solutions: spreadsheets (5), weekly meeting (4), nothing (2)
Job stories:
- When ..., I want to ..., so I can ...
Implications: <product, onboarding, messaging, pricing>

Gotchas

• Jobs stated too broadly (“be productive”) cannot guide design; too narrowly (“export to CSV”) they are features. Aim for a statement a competitor outside your category could also serve.
• Personas and jobs are not the same; two very different personas often share a job, and one persona has many jobs.
• Do not interview people about switches that happened years ago; memories become rationalizations.
• Firing evidence is as valuable as hiring evidence. Always include people who left.
• Counting forces across interviews indicates prevalence in the sample, not the market; say so.

Verification

Check every job statement contains no product, feature or technology words; every force summary cites at least one interview; every job story has a concrete trigger in its When clause (a time, event or state, not “when I use the app”); and the competing solutions list includes non-consumption or a manual workaround.