Research

Jobs to Be Done statement examples (and the template behind them)

A jobs to be done statement captures the progress a customer is trying to make, in the form: When [situation], I want to [motivation], so I can [expected outcome]. For example: When I face a long, boring commute, I want something filling I can manage one-handed, so I can make the drive bearable. Bob Moesta, who helped create Jobs to Be Done, would tell you the format is the easy part. The real skill is reconstructing that statement from a customer who actually switched, not inventing it at a desk.

Why this matters. Founders write JTBD statements that secretly describe their own product, then build the wrong thing. A good statement is solution-free, so it survives being handed to a competitor, and that portability is exactly what makes it useful.

Ask Gavel, free

No signup for your first answer. See a real cited response before you decide.

The short answer

Jobs to Be Done statement examples

Every statement follows the same shape, When [situation], I want to [motivation], so I can [expected outcome], and names no product or feature. Four across different situations:

1

The commute (the classic)

When I face a long, boring commute, I want something filling I can manage one-handed, so I can make the drive bearable without a mess.
2

Onboarding a new hire

When a new engineer joins mid-sprint, I want them shipping something real in week one, so I can prove the hire is working without slowing the team.
3

Choosing a project tool

When my team keeps missing handoffs across three apps, I want one place we all actually check, so I can stop chasing status in DMs.
4

Switching banks

When my current bank keeps surprising me with fees, I want an account that feels fair and predictable, so I can stop dreading the statement.

Portability is the test. A good statement could be satisfied by several products; if yours only makes sense with your app in the room, you've written a feature, not a job.

The cited playbook

How operators write JTBD statements that hold up

These come from Bob Moesta, who built the switch-interview method, not a persona worksheet. Here is how the statement gets written and pressure-tested, each move linked to its source.

1

State the job as progress, not a feature

People don't buy products because the features are good; they hire a product to make progress in a situation and fire whatever they used before. Write the statement as that progress, free of your UI, so it stays true no matter what solves it. If you can't name the progress someone was making, you don't yet know who the product is for.
Bob Moesta · The Switch Interview
2

Reconstruct the statement from a real switch

Don't write the statement at your desk. Find someone who recently hired something new and fired something old, then walk the timeline: the struggling moment, the trigger, the choice. As Moesta puts it, bitching ain't switching, only the people who actually changed can tell you the real story.
Bob Moesta · The Switch Interview
3

Write the anxiety and habit into the statement

Most JTBD statements capture only the push of the struggle and the pull of the new, and then predict the wrong thing. A switch happens only when push plus pull beats the anxiety of the unknown and the habit of the old, so a complete statement accounts for all four forces. The two you're tempted to skip are usually why the deal stalls.
Bob Moesta · The Switch Interview
4

Sort your statements by the quest behind them

Group your example statements by the quest driving them: needing to get out of a bad situation, to take the next step, to regain control, or to realign. Two customers with identical demographics can be on opposite quests, so one statement rarely covers them all, and a statement written for pull energy will miss a customer who is in push mode.
Bob Moesta · Jobs to Be Done, Four Quests

Where experts disagree

Where researchers disagree: a precise formula or a reconstructed story?

Tony Ulwick

treats the job statement as a precise, quantifiable formula, a desired outcome you can measure, with a direction of improvement, a metric, an object, and a context, stable and testable at scale. The rigor is the point, because a fuzzy statement can't be prioritized.

Bob Moesta

argues you can't write a useful statement from a template in the abstract. You reconstruct it from real switches and the forces around them, emotions and all, because the causal story of one switch teaches more than a tidy outcome metric.

ChatGPT hands you a clean formula and calls it done. Gavel shows both lineages so you know when to quantify the outcome and when to go interview someone who actually switched.

FAQ

JTBD statement questions, answered

What is a jobs to be done statement?

It's a one-sentence description of the progress a customer is trying to make, written as: When [situation], I want to [motivation], so I can [expected outcome]. It names no product and no feature, so it stays true no matter what the customer hires to get the job done.

What's an example of a jobs to be done statement?

The classic one, from the milkshake study: When I face a long, boring commute, I want something filling I can manage one-handed, so I can make the drive bearable. Notice it never mentions a milkshake, and that's exactly what makes it a job rather than a feature request.

What is the jobs to be done statement format?

When [situation], I want to [motivation], so I can [expected outcome]. The situation is the trigger, the motivation is the progress they want, and the outcome is what success looks like. Keep all three free of your product's name.

Jobs to be done statement vs a user story, what's the difference?

A user story is written from a role toward a feature: As a [role], I want [feature] so that [benefit]. A JTBD statement is written from a situation toward progress and names no feature at all. The user story assumes the solution; the job statement is deliberately solution-free so it can outlive any one product.

Can ChatGPT write my jobs to be done statements?

It'll format plausible-looking statements, but it can't run the switch interview with your real customers, which is where the true statement comes from. Moesta's whole point is that you reconstruct the job from someone who actually switched, not from a template. That interview is the context Gavel grounds in.

Bring your actual numbers. Get a cited answer you can defend.

Try Gavel free

Related guides

Research

Jobs to be done templates

The core JTBD templates are the job statement, the four forces of progress, and the switch in...

Strategy

Product strategy framework

Most product strategy is a goals list in disguise. A real one has three parts: diagnosis, gui...

Keep exploring

Experts & frameworks

Every operator Gavel cites, with timestamped sources.

Is ChatGPT good for…

The decision-by-decision take on where generic AI falls short.

Playbooks

Multi-expert guides for pricing, PMF, first customers.