- Loading related notes...
Stop Writing User Stories. Start Writing Job Stories.
Most "User Stories" I see in Jira aren't stories at all. They're just features wrapped in a template.
You know the drill: "As a user, I want a dashboard, so that I can see my data."
That’s not a user story. That’s a requirement document trying to look agile. It assumes the solution (a dashboard) before you’ve even agreed on the problem.
This is how teams turn into Feature Factories. You hand developers a solution, and they build it. No questions asked. No innovation allowed.
The Problem with "As a User..."
The standard format (As a... I want... So that...) has a fatal flaw: User Persona.
Personas are often too vague. "As a Sales Manager" covers a thousand different contexts. Are they at their desk? On a train? Stressed? Bored? The persona doesn't tell you why they need the thing right now.
Better PMs focus on the situation, not the person.
Enter the Job Story
Job Stories (popularized by Intercom) flip the script. They focus on the triggering event and the motivation. Here is the structure:
When [Situation], I want to [Motivation], so I can [Outcome].
It sounds subtle, but the difference in output is massive.
The Comparison
Let's look at the difference between the two approaches for the exact same feature request.
❌ The Typical User Story:
"As a salesperson, I want to export my report to PDF, so I can read it later."
The Result: Engineering builds a "Export to PDF" button. It’s clunky on mobile, the formatting breaks, and nobody uses it.
✅ The Job Story:
"When I am rushing to a client meeting in an area with bad signal, I want to have my key metrics accessible instantly, so I can answer their questions without looking incompetent."
The Result: Engineering realizes a PDF might be overkill. Maybe a "Offline Mode" for the mobile app is better. Maybe a text-message summary works best. The solution is open for debate; the problem is clear.
Why This Changes Discovery
When you write Job Stories, you stop arguing about UI widgets and start arguing about human behavior.
- It empowers design & engineering. You give them the context ("rushing," "bad signal") and let them solve the puzzle.
- It kills assumptions. You can't write a Job Story if you don't know the user's context. If you can't fill in the "When," you need to do more research.
- It reduces scope creep. Does adding a chart help the user in the "bad signal" situation? No? Then cut it.
Stop handing your team solutions. Hand them problems with context.
Sources & Further Reading: