Emotional Job

Requirements documents almost always stop at the work to be finished. Several people have to be able to edit a document at once. Every change has to leave a history. Those are checkable outcomes, easy to write down and easy to count off as built.

The trouble starts when all of it ships and nobody moves over. Pagedeck hit exactly that. Mia laid the product out against competitors in a feature table and found no empty cells, and teams on the free plan still didn't convert. Everyone said it looked great in the demo, and the conversation ended there every time.

The reason surfaced only after a round of interviews. One team lead described sending a meeting-notes link and then reopening the document on his own screen, to check that what he had just edited was really what the other person would see. The feature worked. What he lacked was confidence that it worked. That extra open, every time he sent a link, was the reason he hadn't switched.

Jobs to be done (JTBD) reads demand through the work a customer hires a product to finish, and the emotional job comes from the fact that the work has more than one layer. Editing a document together and removing the nagging doubt about whether this is the current version are two different jobs. Solve only the first and the product is usable, but not a reason to move.

Emotional jobs don't show up in what people say. They show up in what people do. Nobody announces that they feel uneasy; they perform small actions that settle the unease, and finding those actions is the whole task.

The recurring ones look like this.

1. Double-checking — reopening something after sending it, or refreshing a page after saving.
2. Keeping a copy — duplicating a document before editing it, or taking a screenshot.
3. Asking a person — putting a question to a colleague that the screen should have answered. "This saved, right?"
4. Deferring — stalling in front of a button that looks irreversible.

In interviews, don't ask about the feeling directly. "How did that feel?" gets a plausible answer someone constructs on the spot. Ask what they did next instead. "And after you sent the link?" produces the reopening, and following up on why produces the worry underneath it.

Turning that into design means working with signals, wording, and timing rather than features. Removing the reopening doesn't take a new capability; it takes showing, right there, that the work saved and what the other person will see. A save indicator in the corner, the name and time of the last edit, a preview of the recipient's view before sending — those are the mechanisms.

One caution comes with it. Emotional jobs earn no praise when they're solved, because an anxiety that is gone isn't visible. Work of this kind rarely registers in satisfaction surveys, and it reads more accurately in behavior: whether the double-checking clicks went down, whether people stopped duplicating documents before editing them.

Three places use it directly.

1. Interpreting interviews — splitting what you heard into three layers. What were they trying to finish, what made them uneasy, and how did they want to look to others. Without the split, all that survives is a list of feature requests.
2. Writing it down — a job story is written in three parts: situation, motivation, expected outcome. Put the emotional job in the motivation slot and what gets built changes. "Right after a meeting, I want to capture the decisions quickly" and "right after a meeting, I want to trust that what I wrote will still be there at the next one" lead to different screens.
3. Holding on to people — cancellation flows and the first few sessions are where this weighs most. New users worry that adopting the tool will damage material they already have, and while that worry stands, no amount of features gets them to commit.

A method like the switch interview, which walks back through the moment someone changed tools, exposes this layer best. Ask what they liked and you hear about features; ask what made them hesitate and you hear the emotional job. "I put it off for two months because I thought migrating would take three days" appears on no feature list.

"Everything's built and nobody uses it, so I think the emotional job is still open."

What the product finishes is solved; the unease of using it isn't.

"This one line of copy closes the emotional job. No engineering needed."

The fix is a message, not a feature.

"In the interview, skip the feelings question and ask what they did next."

Emotional jobs are found in behavior, not in statements.

At Pagedeck, Mia transfers interview notes into a three-column table: the work they were trying to finish on the left, the anxiety in the middle, how they wanted to appear to others on the right. An empty middle column means the interview didn't go deep enough, and she schedules another. Early on, about half of the hour-long sessions came back with that column blank.

Noa takes the middle column and designs screen states from it — distinguishing saving from saved, showing when someone else has the same document open. None of it is a new feature. It is making an existing feature visibly work, which is usually cheaper than anything on the roadmap and never appears there.

The most common misreading treats emotional jobs as making the interface feel nice. The word emotional pulls the conversation toward color and animation. But the emotions in play here are mostly anxiety and unease, and the remedy is confirming information rather than decoration. Leave the misreading in place and the team spends its time adding motion to buttons while users go on reopening the links they sent.

The other one is assuming users can simply be asked. Adding "what makes you uneasy?" to a survey looks like it should collect the answer, but people are poor at recognizing their own unease and worse at it in a survey. What comes back is a list of feature requests, because a request is the form people can put an unnamed discomfort into. You have to start from behavior and work backward, which is why this layer emerges from interviews and usage records rather than questionnaires.