Showdown: User Stories vs. Job Stories

In the late 1990s, a software engineer named Kent Beck was trying to solve a real problem.

Beck was one of the founders of Extreme Programming—a development methodology built around the idea that software teams should work in short cycles, respond to change quickly, and stay in constant contact with the people they were building for.

His teams were drowning in requirements documents: long, formal specifications that took months to produce, locked teams into decisions made before they'd written a line of code, and usually described what engineers thought users needed rather than what users actually wanted.

Beck's solution was the user story. Short, human-readable, written on index cards. Something a developer and a business owner could discuss in plain language.

"As a user, I want to reset my password, so that I can log back in."

It was a genuine improvement. The industry adopted it almost universally.

And then eventually teams stopped asking questions and started filling in the template. The format that was supposed to start a conversation became a way to avoid having one.

What user stories were meant to be

The "As a / I want / So that" format wasn't invented by Kent Beck. A company called Connextra formalized that specific template later. Ron Jeffries, one of the founders of Extreme Programming, described user stories as needing three things: a card (the written sentence), a conversation (the actual discussion about what was meant), and a confirmation (criteria for knowing when it was done).

The card was never meant to contain all the information. It was meant to be a placeholder for a richer conversation.

That part got lost.

Teams started treating the sentence as the requirement. The conversation stopped happening. The format became the product.

What gets lost in the template

"As a user, I want to filter search results, so that I can find what I'm looking for."

This looks reasonable. It has a subject, an action, and a rationale.

But look at what it doesn't contain. When does the user need to filter? Are they browsing casually or hunting for something specific? What's the emotional state? What's at stake — a quick lookup or a decision that matters? What does "find what I'm looking for" actually mean?

The user story is a skeleton. It describes what someone wants to do but not the moment in which they need to do it. And the moment is where design decisions get made.

A filter for a casual browser is a different thing than a filter for someone who's been through twenty pages of results and is losing patience. Same feature. Different problems. Different design.

The template flattens them into one sentence.

What job stories do differently

The job story format offers a different structure:

"When [situation], I want to [motivation], so I can [outcome]."

Three parts. Almost the same shape as a user story. But the user type is gone — replaced by a situation.

That's not cosmetic. "As a manager" tells you almost nothing useful about what someone needs in a given moment. A manager checking on team progress at 9 a.m. on Monday is in a completely different situation than a manager presenting results to the board at 2 p.m. on Friday. The role is the same. The job, the context, the stakes, and the design implications are completely different.

Job stories drop the label and keep the moment.

The same feature, two different framings

Here's what this looks like in practice. Take expense reporting.

User story: "As an employee, I want to submit expense reports, so that I can get reimbursed."

Job stories:

"When I've just returned from a business trip and I'm sitting at my desk with a pile of receipts, I want to log everything before I lose track of what was what, so I can submit a complete report without having to dig through my email for the hotel confirmation."

"When I'm still travelling and I've just paid for a client dinner, I want to capture the receipt immediately on my phone, so I can avoid the pile-up at the end of the trip."

"When my expense report has been pending for three weeks and I haven't heard anything, I want to check where it is in the approval process, so I can follow up with the right person and know when I'll actually be reimbursed."

Three different jobs. Three different people, even if they share the same role. Three different products.

The user story produced one expense form. The job stories show you that you need a quick-capture mobile flow, a desktop reconciliation view, and a status-tracking system — and that treating them as one feature will make all of them worse.

Why "as a user" is the real problem

The user story format asks you to define a type of user first.

That sounds sensible. In practice, it causes two problems.

The first: user types become proxies for assumptions. "As a power user" means whoever wrote the story imagined a power user. "As a new user" means whoever wrote the story imagined someone new. There's no mechanism in the template to test whether those imagined users bear any resemblance to real people.

This is how teams end up designing for users they've invented. The user type gives everyone a shared label, but nobody's actually checked whether the label maps to a real person with a real situation.

The second: the same user type contains multitudes. A product manager in the morning, reviewing yesterday's metrics at their desk, is in a different job than the same product manager in an afternoon meeting, being asked to explain a drop in conversions in real time.

They're the same person. The same "user type." But the job is different, the emotional state is different, the tolerance for complexity is different, and the design requirements are completely different.

Labelling them both "product manager" collapses that distinction into nothing.

The practical shift

Teams that make the switch describe a consistent change in how design conversations go.

With user stories, the discussion tends to center on scope: "Does this story cover this case? Should we add acceptance criteria for that?" The conversation is about the story itself.

With job stories, the discussion centers on the moment: "When exactly does this happen? What was the user doing before? What are they trying to get to? What would make this go wrong?" The conversation is about the user's reality.

That's a different kind of meeting. It produces different work.

Here's the same product area — a notification system — written both ways.

User story: "As a user, I want to receive notifications, so that I stay informed about updates."

Job stories:

"When a task I'm waiting on gets completed by a teammate, I want to be notified immediately, so I can move to the next step without having to check manually."

"When I'm in a focused work session, I want notifications to batch until I'm ready, so I can stay concentrated without missing anything important."

"When I haven't logged in for a few days, I want a summary of what I've missed, so I can get back up to speed in one pass instead of digging through activity feeds."

The user story produces a notification toggle. The job stories produce a system with real-time alerts, do-not-disturb batching, and a digest format — because three genuinely different jobs are being done, by the same person, at different times.

The user story format was a good idea at the right moment in software history. It pushed teams toward human-readable requirements and shortened the distance between engineers and users.

Job stories don't improve on them by adding complexity. They improve on them by changing the question. Not "what does this user want to do?" but "what is happening in this person's life, right now, that makes them need this?"

The situation is where it starts.