The Job Story: Context Is the Whole Point

Most founders and product teams can tell you what their users do.

They can't tell you when, or why, or what was happening in the user's life five minutes before they opened the app. That gap is where the wrong products get built.

And now that we’re in the midst of the AI gold rush, that gap has gotten more expensive. Teams can now generate interfaces, automate workflows, summarize content, and wrap AI around old product ideas faster than ever. But if they don’t understand the user’s situation behind the request, they’re not building actual intelligence into the product.

A team building a recipe app might write: "As a user, I want to save recipes so I can cook them later."

Reasonable. Actionable. Already missing what matters.

Because "cook them later" isn't a moment. It's not a situation. It tells you nothing about where the user is, what they're feeling, what's at stake, or why this particular feature needs to work a particular way.

Now consider: "When I'm standing in the grocery store trying to remember what's in the recipe I picked this morning, I want to find it instantly without scrolling through a long saved list, so I can grab the right ingredients and get out."

Same feature. Completely different product.

The first version gets you a save button. The second version tells you the recipe needs to load fast on mobile, needs to surface ingredients prominently, and probably needs to work offline—because grocery stores sometimes have a terrible signal.

That's the job story format. And the gap between those two versions is the difference between building what users say they want and building what they actually need.

This article shows you how job stories can transform how your team writes requirements. The situation the user is in — not the feature they're requesting, what demographic they belong to, or or what technology your team wants to use  — carries the design constraints, the emotional stakes, and the performance requirements your team needs to build the right thing.

Each article in this category builds on this insight, helping you write Job Stories so grounded in real needs that your team stops fighting about what to build and starts coming together around the moments that will make your users hire your product over and over.

The format

The Intercom product team developed the format in the early 2010s while applying JTBD thinking to software design. Alan Klement — a JTBD practitioner who wrote about the technique on Intercom's blog — gave it the name 'job stories' and popularized the approach."

Intercom's product team was writing user stories and finding they produced generic features. The stories defined the actor ("as a user," "as an admin") but said nothing about what was happening in the user's world when they needed help.

Intercom’s alternative dropped the persona entirely and replaced it with a situation:

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

The weight shifts completely. A user story asks "who is this person?" A job story asks "what's happening right now?" Because the insight isn't in who the person is. It's in what they need and what's going on when they need it.

The "when" is the trigger. The "I want" is the motivation. The "so I can" is the outcome—the progress they're trying to make. Together, they describe a specific moment in someone's life and what they need to get through it.

That matters even more as products become more automated and AI-mediated. A prompt may say, “Help me prepare for tomorrow’s client call,” but the real job is not “summarize my notes.” It might be walking into the room calm, prepared, and ready to defend a recommendation. The words the user types are only the surface. The job story gets underneath them.

The "When": where the insight lives

The situation is the most important part of the format and the part most teams write too loosely.

"When I'm using the app" is not a situation. It's a tautology.

"When I'm trying to collaborate with my team" is a job category, not a situation.

"When I've just finished a difficult client call and I need to document what was agreed before I forget" is a situation. It carries emotional state (rattled, moving fast), time pressure (before memory fades), and stakes (professional accountability).

The situation is where the job gets real.

Here's the same feature—a tagging system in a notes app—written with different situations:

Version 1: "When I'm doing a weekly review and trying to find notes from a project I finished two months ago, I want to filter by tag, so I can pull everything relevant into one view without digging through hundreds of notes."

Version 2: "When I'm in a meeting and someone references a decision we made last quarter, I want to search my notes and find the right one in under ten seconds, so I can answer the question without looking unprepared."

Same feature. Version 1 is an understated, organized desktop moment. Version 2 is a live, high-stakes, mobile moment.

Those are different design problems. Version 1 needs a good filtering interface. Version 2 needs fast search with near-instant results. If you only wrote version 1, you'd build a perfectly functional feature that fails version 2 users every time it counts most.

This is where blindly chasing AI can go wrong fast. See “find notes” and you probably jump to semantic search, auto-summary, or chat. But the situation determines what good actually means. One user may need depth. Another may need speed. Another may need confidence that the answer is accurate enough to say out loud in a meeting. The exact same capability can feel brilliant or useless depending on the situation it was designed for.

When a product Is clearly designed for the situation

You can tell when a team has thought carefully about the "when,” whether or not they literally wrote a job story.

Intercom's own product is the clearest example, which makes sense given where the format was born. Their in-app messenger was designed for a specific situation: a user is confused right now, on this page, in the middle of doing something. Not "a user needs help" generically.

The situation demanded that the messenger appear in context, respond quickly, and not require the user to leave what they were doing. That's why Intercom built the chat widget into the product itself rather than routing people to a separate help center. The situation shaped the form.

Uber's ride-tracking screen works the same way. The situation isn't "the user ordered a ride." It's "the user is standing on a curb, possibly in the cold, wondering if this is actually coming."

That's why the screen shows the car's real-time location, the driver's name and photo, and an estimated arrival time updating every few seconds. Every element on that screen is answering a question the situation creates: Is it coming? How long? Is it the right car?

A product designed for "the user ordered a ride" might just show a confirmation message and a receipt. A product designed for the actual situation shows you a moving dot on a map.

The same logic applies to AI features. A product designed for “the user wants a summary” might produce a neat paragraph. A product designed for “the user is about to send this to their boss and cannot afford to miss the risk” might show sources, flag uncertainty, expose what changed, and make the output easy to verify. The situation shapes the form.

The "I Want": motivation, not feature

The middle section trips up teams because they fill it with features instead of motivations.

"I want to filter my results" is a feature request.

"I want to narrow down my options quickly without having to evaluate each one" is a motivation.

The motivation is the why underneath the what.

Here's the difference in practice:

Feature request version: "When I'm shopping online, I want to filter by price range, so I can see cheaper options."

Motivation version: "When I'm shopping for a gift and I have a firm budget, I want to eliminate everything above my limit immediately, so I can stop second-guessing myself and just choose."

The first version tells you to build price filters.

The second tells you the emotional job (reduce decision anxiety) and the real outcome (reach a decision, stop deliberating). That might lead to a price filter. It might also lead to a "gifts under $50" landing page, a "best value" sort order, or a streamlined checkout that removes the final hesitation when someone's already chosen.

Keep "I want" at the level of motivation. If it sounds like a Jira ticket, it's too specific.

This is especially important when you write AI requirements. “I want AI to summarize this,” “I want AI to write this,” or “I want AI to automate this” may describe the feature, but it does not explain the motivation. The real motivation might be “I want to know what changed before I approve it,” “I want to sound prepared without spending my whole evening rewriting,” or “I want to move faster without feeling reckless.” That difference changes whether the product should automate, augment, explain, warn, ask, cite, or stay out of the way.

The "So I Can": progress, not feature confirmation

The final part is where teams default to restating the feature.

"When I want to find a file, I want to search, so I can find my file."

That's circular. It tells you nothing.

The "so I can" should describe the outcome—the progress the person is trying to make. What gets better in their life when this works? What do they get to do, stop doing, or stop worrying about?

"So I can find my file" is a task.

"So I can send the proposal before the client's end of day" is the job.

That distinction changes everything about what "search" means in that context. Speed matters. Confidence in the result matters. The ability to preview before opening matters.

Google Maps' "gas stations near me" feature is a small but clean example of how a real outcome shapes design. The "so I can" isn't "see gas stations on a map." It's "get fuel before my tank runs out while I'm already driving."

That outcome is why the results are sorted by distance from your current location, why navigation starts with one tap, and why the price is shown inline. Every design choice follows from the real progress the person needs to make — not from the task of "searching for gas stations."

AI makes this distinction even easier to miss because the output can look finished while the Job is still unfinished. The product may write the draft, summarize the contract, or generate the plan, but if the user still feels unsure, exposed, stuck, or unable to act, then real progress hasn’t happened. The task may be complete. The job may not be.

The same feature has multiple job stories

One of the most useful things about job stories is that they reveal how many different jobs one feature is actually being hired to do.

Consider a "share" button in a document tool.

Job story 1: "When I've finished a first draft and need feedback before I keep going, I want to share the doc with one person and see their comments, so I can decide whether the direction is right before I invest more time."

Job story 2: "When I'm handing off a completed project to a client, I want to share the final version as a read-only link they can forward to their team, so I can avoid back-and-forth over email attachments."

Job story 3: "When I'm in a meeting and someone asks for the document we discussed last week, I want to share a link immediately from my phone, so I can look prepared and keep the meeting moving."

Three wildly different jobs. Three different design implications. Job 1 needs inline commenting and easy collaboration controls. Job 2 needs permission settings and link-only sharing. Job 3 needs the share action to be fast, accessible, and mobile-friendly.

A team that wrote a single user story ("As a user, I want to share documents with others") would build one generic share function and wonder why different user segments were dissatisfied.

How to write job stories that are actually useful

Start with observation, not imagination. Job stories written in conference rooms produce generic situations. Job stories written from real observation produce specific ones. Watch people using your product or their current workaround. Ask: "Walk me through what you were doing right before you needed to do this."

The answers give you real situations. Not "when I need to collaborate" but "when my manager asks for a status update at 8am on Monday before I've had time to pull things together."

Make the situation uncomfortable. Generic situations feel safe and produce generic products. Specific situations — where there's time pressure, emotional stakes, or real consequences — force you to design for what actually matters.

"When I'm rushing to catch a train and I need to check something quickly" is more useful than "when I'm on the go." The first one implies phone, one hand, under thirty seconds. The second could mean anything.

This is one reason so much AI slop feels impressive in a demo and weak in real use. The demo prompt is clean. The real situation is not. Real users are tired, rushed, anxious, distracted, or trying not to look foolish in front of someone else. Job stories force that context back into the product conversation.

One situation per story. The temptation is to write job stories that cover multiple scenarios. Resist it. "When I'm either planning a project or reviewing one in progress" is two different situations with different motivations and different outcomes. Write two stories. The precision is the point.

Break big jobs into smaller ones. "Manage my finances" is too large to design for. But "when I realize I haven't checked my spending this month and payday is in three days" is a real moment. So is "when a charge appears on my statement that I don't recognize." Each of those is a different situation. Each produces a different design problem.

If your team is writing user stories, try this: take five of them and rewrite them as job stories. Force yourself to describe a specific triggering situation. Not "when I'm using the product." A real moment.

Then compare the two versions.

The user story version probably tells you what to build. The job story version tells you who to build it for, when they need it, and what "good" actually looks like.

That's the difference between shipping features and doing a Job people will keep hiring you for.