---
name: jobs-to-be-done-statement
description: "Use when a feature request, \"can you add…\", or product idea needs to be reframed into the underlying job the person is hiring the product to do — the When [situation], I want to [motivation], so I can [expected outcome] job story, plus the forces pushing and pulling them toward change. Turns a solution-shaped ask (\"add a dark-mode toggle\", \"we need a CSV export\") into the situation-driven progress the user is actually reaching for, so the team can weigh alternatives instead of just building the literal request. Do NOT use for writing user stories with acceptance criteria, a full PRD, a positioning statement, or prioritizing an already-understood backlog."
metadata:
  decimalai-skill-id: "380d45c6-9554-45aa-b5de-48ec6aff14ab"
  decimalai-version-id: "7388dc81-bf84-471b-b739-b76e93e53363"
  decimalai-version: "1"
  decimalai-body-sha256: "a1e70c254f7a490b27e225720f6ac5313d0e450ac7d82841d1fac768e1e16812"
  decimalai-name: "jobs-to-be-done-statement"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "productivity"
  decimalai-source: "https://app.decimal.ai/s/jobs-to-be-done-statement@1/SKILL.md"
---
# Jobs-to-be-done statement

Handed a feature request, the base model restates the feature. "Add a dark-mode toggle" comes back as
"Users want a dark-mode toggle so they can switch to dark mode" — a tautology that locks the team into
building the one solution the requester happened to name. The request is a clue, not the job. A JTBD
statement recovers the underlying **progress** the person is trying to make in their life, stated
independently of any solution, so the team can see the request as one option among several.

## The job story form

Write the job as one sentence in three fixed slots:

> **When** *[situation — the context and trigger that starts the struggle]*, **I want to** *[motivation
> — the progress being sought, stated with NO solution in it]*, **so I can** *[expected outcome — how
> life is better once the job is done]*.

All three slots are required, and the middle slot is the one that carries the whole idea. If the
"I want to" clause names a feature, screen, button, or the requested solution, the reframe has failed —
that is just the feature request wearing a costume.

## What each slot demands

- **When (situation).** Anchor to a concrete moment and circumstance, not a persona. "When I'm
  reviewing a long report late at night in a dark room" — not "As a power user." The situation is what
  makes the job real; the same person hires different things in different situations.
- **I want to (motivation) — solution-free.** State what the person is trying to accomplish, with the
  requested feature removed. The test: could you satisfy this motivation with a completely different
  build? "I want to keep reading without straining my eyes" can be met by dark mode, a warmer color
  temperature, larger text, or a reader mode — the motivation names none of them. If only the
  requested feature could satisfy the clause, rewrite it one level more abstract.
- **So I can (expected outcome).** The observable payoff — how the person measures that the job got
  done. Emotional and social outcomes count ("so I don't feel careless in front of my team"), not just
  functional ones. This is what you would actually check to know the job succeeded.

## The four forces of progress

A job story explains *what* progress; the forces explain *whether the person will switch* to get it.
Name all four — the two that push toward change and the two that hold the person back:

- **Push of the situation** — what about the current approach is frustrating enough to make them look
  for something new. (The pain that starts the search.)
- **Pull of the new solution** — what is attractive about the new way; the outcome they can picture.
- **Anxiety of the new solution** — the fear, uncertainty, or cost of switching to it. ("Will I lose
  my data? Will it be worse?")
- **Habit of the present** — the inertia and allegiance to what they do today, even when it is worse.

Progress happens only when push + pull outweigh anxiety + habit. A reframe that lists only the two
forces *for* change is half a diagnosis: the forces *against* are usually why good features go unused.

## Worked example

Feature request: *"Can you add a button to export our dashboard to PDF?"*

Restated feature (what to avoid): *"Users want a PDF export button so they can export dashboards to
PDF."* — circular; commits to the one solution.

JTBD reframe:

> **When** I finish the monthly numbers and my boss asks for them in the Monday exec meeting, **I want
> to** hand over the results in a form they'll actually open and trust, **so I can** look on top of my
> work without walking them through the live tool.

**Forces** — *Push:* screenshotting charts by hand is slow and looks sloppy. *Pull:* a clean, familiar
document I can attach to the calendar invite. *Anxiety:* if the export looks worse than the live
dashboard, I'll be embarrassed. *Habit:* I already paste screenshots into a slide; it's ugly but it
works and I know how.

Notice the motivation ("hand over results they'll open and trust") does not say PDF. That opens the
door to a shareable link, a scheduled email, or a Slack-native summary — alternatives the literal
request would have hidden. That is the point of the reframe.

## Before returning, verify

1. The job story uses the When / I want to / so I can form with all three slots filled.
2. The "I want to" slot contains **no** solution, feature, or UI element — it would survive the
   requested feature being deleted.
3. The situation is a concrete moment, not a persona or a job title.
4. The expected outcome is observable — you could tell whether it was achieved.
5. All four forces are named, including the two that hold the person back (anxiety and habit).
6. The reframe makes at least one alternative solution imaginable — if only the original feature fits,
   the motivation is still too solution-shaped.