Jobs Stories: “As a User” Is Lying to You

You've seen it a thousand times:

"As a user, I want to create playlists, so that I can organize my music."

Clean. Fits on an index card. Gives engineering something to build.

It's also almost useless.

Because "organize my music" isn't a job anyone wakes up wanting to do. Nobody lies in bed thinking "God, I really need to organize my music today." That's not what's happening.

What's actually happening is: Someone's hosting a dinner party on Saturday. They want the music to feel effortless, and not endure awkward silences while they scroll through their phone.  They don’t want a moment where the wrong song kills the vibe. They want to seem like the kind of person whose home just has good music playing, like it's natural.

That's . And "As a user, I want to create playlists" doesn't capture any of it.

Tell the right story

There's a better format. It's called a , and it looks like this:

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

Same three parts, completely different emphasis.

The dinner party version: "When I'm hosting people and want the music to feel effortless, I want to queue up songs that match the vibe ahead of time, so I can stay present with my guests instead of fidgeting with my phone all night."

Now you're getting somewhere. You know the trigger (social pressure, wanting to seem put-together). You know the real motivation (not "organize"—it's “reduce anxiety about looking distracted”). You know what success looks like (being present, not being glued to their phone).

And suddenly, "build a playlist feature" might not even be the answer. Maybe they need a "dinner party mode" that auto-continues similar songs so they never have to touch their phone at all. The user story would never get you there. does.

The magic is in the "when."

  • When I'm rushing to leave for work and realize I forgot to send an important email...*
  • When I'm in a meeting and someone asks for a number I don't have memorized...*
  • When I'm lying in bed and can't sleep because I remembered something I need to do tomorrow...*

These situations carry everything you need: emotional state, physical , stakes. Is this person rushed? Embarrassed? Anxious? At a desk or on mobile? High-pressure moment or low-key browsing?

"As a user, I want to add tasks quickly" tells you none of this.

But "When I remember something important while falling asleep and don't want to lose it by morning, I want to capture it with minimal effort, so I can let go and actually sleep"—now you know exactly what "quickly" means and why it matters.

I'll give you another one.

User story: "As a shopper, I want to save items to a wishlist, so that I can buy them later."

Seems fine. Build a wishlist, ship it, move on.

But there are at least two completely different jobs hiding in there:

#1: "When I find something I want but can't justify buying right now, I want to stash it somewhere I won't forget, so I can come back when I have the budget or when it goes on sale."

This person is managing guilt and financial timing. They want sale alerts. They want reminders. "Won't forget" is doing heavy lifting.

#2: "When I'm researching a big purchase and comparing options across sites, I want to bookmark my top contenders in one place, so I can make a final decision without re-finding everything."

This person wants to compare. They might need notes. Side-by-side views. The ability to track prices across competitors.

Same feature request. Completely different jobs. The user story collapsed them into one. stories pulled them apart and showed you they might need different solutions.

The anxiety matters as much as the task.

Consider this: "When I'm about to present to executives and realize my might be outdated, I want to refresh the dashboard instantly, so I can avoid looking unprepared in front of people who control my career."

That last part—"people who control my career"—changes how you design the refresh button. It needs to be fast. Obvious. Confidence-inspiring. A loading spinner that takes 10 seconds might be technically acceptable but emotionally brutal. tells you the stakes in a way "As a user, I want to refresh " never could.

Writing good job stories isn't hard, but it requires you to start with careful observations instead of assumptions.

Don't invent situations in a conference room. Watch people. Interview them. Ask: "Tell me about the last time you did this. What was going on right before you opened the app? What would have happened if you couldn't do it?"

Get specific about the trigger. "When I need to collaborate with my team" is too vague to be useful. "When I've made changes to a doc and need my manager to approve them before the client sees it, but she's in back-to-back meetings" reveals urgency, bottlenecks, time pressure.

And break big jobs into smaller ones. "Manage my finances" is too abstract. But "When I get paid and want to make sure I don't overspend this month" is a real moment you can design for. So is "When a subscription charge appears that I don't recognize." So is "When I'm whether I can afford a spontaneous trip."

Each of those is a different situation with different stakes and different solutions.

Job stories give you clarity on design decisions.

Where does this button go? Depends—which job is someone in when they need it? Are they rushed? Distracted? On mobile with one hand?

What should the default settings be? What situation are most users in when they first encounter this? What would reduce their anxiety?

What should this error message say? What job just got interrupted? How do you help them recover and still make ?

Spotify's "Made for You" playlists exist because someone understood : *"When I want to listen to music but don't have the energy to choose, I want something that sounds like me without effort, so I can just press play and go." The feature is a direct answer to that situation.

Jobs > Features

User stories simply ask: What does this user want to do?

Job stories dig deeper and ask: What's happening in this person's life that makes them need to make right now?

The first question gets you features. The second gets you products people actually switch to.

When McDonald's asked "What do users want in a milkshake?" they didn’t get very far in their business goals.

But then guru Clayton Christensen famously asked, "When people are buying milkshakes, what job are they hiring the milkshake to do?" The answer—long boring commute, one free hand, need something engaging—changed everything about how they designed the product. Instead of making milkshakes sweeter and more dessert-like, they made them thicker, so they’d last an entire commute.

Job stories are how you ask the right questions for anything you build, from milkshakes to marketing apps.

Was this page helpful?