Job Story

For a long time there was one standard way to write a requirement down: as a user, I want to do something, because of some reason. That format is the user story, and the part that caused trouble was the very first slot. What usually went in there was a persona, a model that compresses a group of users into a single imagined person. Two people could read the same persona name and picture two different humans.

Pagedeck ran into exactly that. Mia brought the line "as a busy team lead, I want to find documents quickly" into a planning meeting. Noa sketched a bigger search box. Theo pictured a list of recently opened files. Neither reading contradicted the sentence. Nothing in it said when the busy team lead was looking for a document or what they were doing right before, so each of them filled the gap with a scene they already knew.

A job story swaps that first slot from a person to a moment. Instead of who, it opens with when and under what circumstances. Once "right after a meeting ends" is fixed in the sentence, the question of where the find-a-document feature belongs is largely settled with it. The bet underneath the format is that the same person behaves differently in different situations, while different people in the same situation behave much alike.

One sentence splits into three parts. The order is fixed and each part answers a different question.

1. Situation — when this happens and what the person was in the middle of. "Right after a meeting ends, before the laptop closes" works because it pins both a time and an activity.
2. Motivation — what they want to get done in that moment. "I want to capture just the decisions, fast." No screen names, no button names, only the intent.
3. Expected outcome — what should be different once that works. "So the next meeting doesn't relitigate the same points from scratch."

Nothing forces the three parts onto one line — plenty of teams keep them as three labeled rows in a ticket — but they travel together, because any one of them alone reads as an opinion.

Strung together: right after a meeting ends, before the laptop closes, I want to capture just the decisions, so the next meeting doesn't relitigate the same points from scratch.

Almost all of the value sits in part one. "When organizing documents" is not a situation, it's a category — it applies at any hour of any day, so it constrains nothing. "Right after a meeting" drags real constraints along with it: two or three minutes of attention left, and nothing in hand but the notes just typed. From those constraints follows a conclusion, which is that the right screen is a meeting-notes template already open, not a blank document waiting to be named.

Part three decides what gets checked afterward. If the outcome is that discussions stop repeating, then the number worth watching after launch is not how many notes get written but how often an old note gets reopened. Leave that part blank and the acceptance criteria — the conditions under which the work counts as done — end up invented later, by someone else, from memory.

A product manager usually writes them, but not from the desk. The moment that belongs in part one can only come from observation, so a switch interview comes first: find people who recently moved from one product to another and walk them back through the day they switched. Scenes from those interviews go straight into the situation slot.

Interviews are also what keeps the sentence honest: a situation nobody described out loud has no business being in part one.

Three groups read the result. Designers read the situation and decide where in the product the feature lands. Engineers read the motivation to know what to build and the expected outcome to know where the work stops. The product manager reads them again at the next prioritization pass — when several job stories turn out to share one situation, that moment is where the product is rubbing hardest.

One sentence carries one functional job, meaning the practical task someone needs finished. The emotional job, what the person wants to feel along the way, either gets its own sentence or rides along in the expected outcome. Cram all of it into a single line and what to build goes blurry again.

"Can you rewrite this as a job story? I can't see what situation it's for."

I understand what to build but not when it gets used, so I can't decide where it goes on screen.

"The situation says 'when organizing documents.' That's too wide."

No moment fails to match that condition, so it puts no constraint on the design at all.

"All four of these came out of the same situation — right after a meeting."

Requests that looked scattered are actually clustered in one moment, so let's treat that moment as the unit of work.

A Monday planning session at Pagedeck. Mia walks in with four job stories written after six switch interviews. Noa reads only the situation lines first. Three of the four point at the minutes right after a meeting ends, so she argues for pulling the meeting-notes entry point forward instead of touching search. Theo points at the expected outcome and asks to start measuring how often people reopen an old note now, before anything ships, because without today's number there's no way to tell later whether it moved.

One sentence settled a layout decision and a measurement decision in the same meeting. Each of the three parts gave a different person something to act on.

The most common mistake is believing that changing the format improves the requirements. It's a visible change, so it feels like progress. What actually changes is the shape of the blanks. The moment that belongs in the situation slot comes from observation, and a team that fills it in a conference room from shared hearsay ends up with a guess wearing the right costume. The worse part is that the guess now looks like evidence. Six months later, when the feature turns out to go unused, nobody can reconstruct who wrote that situation line or what they were looking at.

The other misreading is that dropping the person means user research is optional. Seeing the persona disappear from the opening slot makes that easy to assume. What disappeared is not the user but the habit of naming users as a group. Writing a real situation requires knowing who got stuck, when, and in the middle of what — which demands more specific observation, not less. Left alone, this misreading produces a team that skips the interviews and writes tidy sentences in the correct format.