Jobs as Progress: Job Stories and the Forces

Jobs-as-progress reframes a customer's job as the progress they want to make — moving from a struggling current situation to a preferred one — rather than a task or a product. Popularized by Alan Klement in When Coffee and Kale Compete, it captures that progress in job stories: When [situation], I want to [motivation], so I can [expected outcome].

Quick Answer: In the jobs-as-progress school of Jobs to Be Done, a job is the progress a customer makes from a struggling moment to a better situation. You capture it with a job story — When [situation], I want to [motivation], so I can [expected outcome] — which anchors on context, not on a persona.

If you came to founding from product management, you already know the ritual of writing "As a user, I want…" and watching the backlog fill with features nobody asked for. The jobs-as-progress lens is the antidote. It treats demand as a story about progress, gives you a sharper way to write requirements, and tells you who you are actually competing against. This guide walks through the model, its forces, and the job story format — and how a founder validates an idea with it.

Why customers want progress, not products

Customers want progress, not products — they hire a solution to move from a situation they are struggling with to one they prefer. Alan Klement's framing in When Coffee and Kale Compete is that a Job to Be Done is the process a person goes through to transform their current life-situation into a better one. Progress is the unit, not the object they buy.

This is a genuine shift, not a rebranding of "needs." A need is a static gap. Progress has direction and a story: a starting point, a desired end state, and the constraints in between that keep the person stuck. The product is just whatever they hire along the way to close that distance.

The jobs-as-progress school is one branch of JTBD. It is most associated with Klement and Bob Moesta and emphasizes the customer's situation and emotional pull. It sits alongside the more quantitative, outcome-metrics branch — both are valid, and this guide stays in the progress branch. If you want the broader map first, start with the Jobs-to-Be-Done framework for founders and come back here for the progress-specific tools.

The book's title makes the point concrete. Coffee and kale look nothing alike and sit in different aisles, yet they can compete — because a person trying to make the same progress ("start my day feeling healthy and alert") might weigh one against the other. Category does not define the contest. Progress does.

For a founder, three consequences follow:

• Your competitors are defined by the job, not by the industry. Anything a customer might hire for the same progress — including a spreadsheet or doing nothing — is in the set.
• Features are means, not ends. Two products with identical features can serve different jobs, and the same product can serve two jobs at once.
• You can only build for progress you can name. If you cannot state the situation someone is moving away from and toward, you are guessing.

The jobs-as-progress model at a glance

The jobs-as-progress model has a small vocabulary, and the terms build on each other: a struggling moment kicks off demand, the forces of progress decide whether a switch happens, and a job story records the whole arc. Seeing them together prevents the common mistake of treating them as unrelated tips.

The table below maps each element of the model to what it means and why it changes a founder's decisions. It is qualitative by design — this is a lens, not a scorecard.

Takeaway: read down the table and you get the whole method in order. Something makes a customer dissatisfied (struggling moment), forces tip them toward or away from change, and you write the resulting job as a story so your team builds for progress instead of for a feature request. Miss one element and the others lose their meaning.

Struggling moments — the seed of new demand

A struggling moment is the specific instant a person becomes dissatisfied with their situation and starts wanting something better — and it is where demand is born. In the jobs-as-progress view, no struggle means no job. Founders who cannot point to a real struggling moment are usually inventing demand rather than discovering it.

Struggling moments are ordinary and easy to miss because people rarely announce them. They show up as friction, workarounds, and quiet frustration:

• A workaround — someone duct-taping three tools together or maintaining a manual spreadsheet.
• A trigger event — a deadline, a failure, a new responsibility that makes the old way suddenly untenable.
• An emotional tell — annoyance, embarrassment, or anxiety about how the current situation reflects on them.

The reason struggling moments matter so much is that they are causal. They explain why now — why a person who tolerated a problem for months suddenly starts looking for a solution this week. That timing is the difference between a market and a wish.

Struggling moments also define the boundary of your opportunity. If the struggle is mild, people will keep coping and your product becomes a vitamin nobody renews. If the struggle is acute and recurring, you have the raw material for a job worth building around. Part of validation is simply confirming the struggling moment is real, frequent, and painful enough to move someone.

This is where the progress lens meets fieldwork. You are not asking people what they want; you are reconstructing the moment they got stuck. At Edmired, that means capturing the struggling moments, triggers, and workarounds you hear in discovery in one place, so a pattern across ten conversations is visible instead of scattered across ten sets of notes.

The four forces of progress that drive a switch

The four forces of progress explain why a customer does or does not switch to something new: two forces generate demand for change, and two forces reduce it. A switch only happens when the demand-generating forces outweigh the demand-reducing ones — which is why a "better" product so often fails to win.

The four forces are a staple of the progress-making school, and Klement details how they shape every decision to change. The table summarizes them qualitatively; note that the two blocking forces are not irrational obstacles to bulldoze — they are real feelings your solution has to earn its way past.

Takeaway: most founders pour all their energy into the pull — a slicker product, a bigger promise. But a switch stalls just as often because anxiety and habit were underestimated. Winning the hire means amplifying the push and pull and actively defusing anxiety and loosening the grip of the old habit.

Each force also maps to a concrete lever you control. A free trial or a guarantee reduces anxiety. An import tool or a migration path weakens habit. Vividly naming the customer's current frustration sharpens the push. For a fuller breakdown of applying each one, see the guide to the four forces of progress in JTBD.

The forces are also a diagnostic for churn and stalled deals. A prospect who loves the demo but never signs is usually blocked by anxiety or habit, not by a missing feature — and adding features rarely fixes a force-of-progress problem.

Writing job stories to capture the customer's job

A job story captures a job as a short, context-first sentence: When [situation], I want to [motivation], so I can [expected outcome]. Developed by the team at Intercom — Paul Adams and Alan Klement are the names most associated with it — the format deliberately leads with the situation instead of a persona, so the requirement carries the causal context a builder actually needs.

The job story format: situation, motivation, expected outcome

Each clause does one job, and dropping any one of them loses information:

• When [situation] — the circumstance and trigger. This is the struggling moment, written as context. "When I get a Slack alert that a customer downgraded…"
• I want to [motivation] — what the person wants to do in that moment, stated without prescribing a specific feature. "…I want to see why they downgraded…"
• So I can [expected outcome] — the progress they are after, the reason the motivation matters. "…so I can decide whether to reach out before they cancel."

Written well, a job story is testable and solution-agnostic. It tells you what has to be true for the customer to make progress, but it does not smuggle in a UI, a screen, or a technology. That freedom is the point: several designs could satisfy one job story, and the story lets you compare them against the outcome instead of against each other.

Good job stories also stack. A handful that share the same situation reveal a recurring moment worth designing a whole flow around; a handful that share an outcome reveal a job that several triggers lead into.

Job stories vs. persona-based user stories

The core difference is where each format anchors: a user story starts with who ("As a [persona], I want…"), while a job story starts with when ("When [situation], I want…"). Klement's argument for the switch is that a persona bundles in assumptions — about who has the need and, often, about the solution — whereas a situation stays focused on causality.

Both formats share the same three-part skeleton, so the contrast is easy to see side by side. Here is how each clause differs.

Takeaway: neither format is universally right. User stories are efficient once a team has genuinely agreed on the persona and the direction; job stories shine earlier, when you are still figuring out why anyone would switch and don't want a persona quietly deciding it for you. For a deeper, example-by-example comparison, read job story vs. user story.

The practical warning for a PM-turned-founder is this: a persona is a convenient fiction, and early on it hardens assumptions before you've earned them. Leading with the situation keeps you honest about the moment you're really serving. Job stories, struggling moments, and the forces of progress are three views of the same customer reality — and they fit inside the wider method covered in the complete guide to customer research for founders.

Defining your real market by the job to be done

Your real market is everyone hiring anything to make the same progress — not everyone who buys a product like yours. This is the strategic payoff of the jobs-as-progress lens, and the reason When Coffee and Kale Compete is named the way it is: when you define the market by the job, the competitive set stops matching the category and starts matching the situation.

Return to the title. If the progress is "feel healthy and get going in the morning," then a green smoothie, a black coffee, a handful of kale, and skipping breakfast entirely are all candidates a person weighs in the same struggling moment. They compete for the same hire despite living in different aisles. Category comparison would never surface that; job comparison does immediately.

Most founders scope their market too narrowly and miss the two competitors that actually cost them the deal:

• Nonconsumption — the customer does nothing and keeps tolerating the problem. For a new product this is frequently the largest competitor of all, because inaction is free and familiar.
• The workaround — a spreadsheet, a manual process, or several tools stitched together. It already "works" in the customer's mind, which makes it harder to unseat than a named rival.
• The good-enough substitute — a product built for a different job that someone is stretching to cover this one.

To map your real market, start from the progress rather than the product. Write down the job, then list everything a person could plausibly hire for it — direct rivals, adjacent tools, manual workarounds, and doing nothing. That full set is what your solution has to beat.

The reframe changes strategy, not just vocabulary. If your true competitor is nonconsumption, the fight is about proving the progress is worth any effort at all, and a price war with a named incumbent is beside the point. If your true competitor is a beloved workaround, the fight is about overcoming habit. Naming the job tells you which battle you are actually in.

Key Takeaways

• A job is progress, not a product — customers hire a solution to move from a struggling situation to a preferred one, so define your market by the progress, not by the category.
• Struggling moments are where demand begins — if you cannot point to a real, recurring moment of dissatisfaction, you are inventing demand rather than discovering it.
• The four forces decide every switch — push and pull generate demand while anxiety and habit reduce it, and a "better" product loses whenever the blocking forces win.
• Defuse anxiety and habit, don't just add pull — trials and guarantees ease anxiety, migration tools weaken habit, and each force maps to a lever you actually control.
• A job story leads with the situation — When [situation], I want to [motivation], so I can [expected outcome] records context, motivation, and outcome without prescribing a solution.
• Job stories anchor on "when," user stories on "who" — leading with a persona bakes in assumptions early, while leading with the circumstance keeps the focus on causality.
• Coffee can compete with kale — anything a customer might hire for the same progress is a competitor, including workarounds and doing nothing at all.

Frequently Asked Questions

What does "jobs as progress" mean?

Jobs as progress means treating a customer's job as the progress they want to make — moving from a current, struggling situation to a preferred one — rather than as a task or a product they buy. It is the branch of Jobs to Be Done, popularized by Alan Klement, that emphasizes situation, emotion, and demand.

What is a job story and how do you write one?

A job story is a requirement written as When [situation], I want to [motivation], so I can [expected outcome]. You write one by starting with a real struggling moment as the situation, stating the motivation without naming a feature, and ending with the progress the customer is after. It keeps the requirement solution-agnostic.

How is a job story different from a user story?

A user story opens with a persona ("As a [role], I want…"), while a job story opens with a situation ("When [situation], I want to…"). The job story deliberately drops the persona to avoid bundling in assumptions about who has the need or how it should be solved, keeping the focus on the causal circumstance.

What are the four forces of progress?

The four forces are the push of the situation and the pull of the new solution, which generate demand for change, plus the anxiety of the new solution and the habit of the present, which reduce it. A customer only switches when the two demand-generating forces outweigh the two that hold them back.

What is When Coffee and Kale Compete about?

When Coffee and Kale Compete is Alan Klement's book on the jobs-as-progress view of Jobs to Be Done. Its title illustrates the core idea: two unrelated products can compete when customers might hire either to make the same progress, so you should define your market by the job, not the category.