Out on the streets of Mumbai you’ll find peanut sellers peddling their wares on the side of the road to drivers stuck in the thick traffic. Instead of hawking “peanuts”, however, they hawk “timepass.”
These timepass sellers realize that what drivers crave isn’t peanuts, but rather a way to pass the time while idling. Peanuts are merely one solution to the Job of “being stuck in a car and bored out of your mind,” and a pretty decent one at that—popping handfuls of peanuts in your mouth not only gives you something to do, but also reduces road rage incidents from hangry drivers.
The key insight realized by the timepass sellers here is that purchasing decisions are not made in a vacuum — context matters. The fact that someone is sitting in traffic is more impactful than whether or not they like peanuts.
Let’s make up a close-to-home example to further explore how context matters. Say you’ve been hired by this fine dollar pizza store in the East Village of NYC:
They’ve tasked you as a consultant with a simple prompt: While sales of dollar pizza are doing well, 2 Bros wants to expand their product mix to maximize single-store revenue. What should they do?
So, being the lean and user-centric consultant you are, you do some interviews and draft up a representative persona of John, the young dollar pizza consumer:
And you do some competitive research to get some traditional alternatives to pizza:
And you even look at some national competitors like Pizza Hut and note what they’re selling in addition to pizza:
And so you start to brainstorm possible solutions, such as:
- John likes tasty food, should we improve ingredient quality?
- John tries to be health conscious, should we make it healthier? Sell salads?
- John orders from Domino’s delivery, should we deliver?
- What else is tasty, cheap, and on-the-go… candy?
- Can we expand to traditional pizza competitors, such as subs or burgers?
- Pizza Hut is doing pasta! Shouldn’t we?
However, all of these options ignore the most important factor…
There’s a good chance John is wasted when he chooses dollar pizza.
Based on my own experience with NYC dollar pizza, here’s a likely graph of 2 Bros sales by hour:
John’s context matters more than anything else. While at lunch during work, John might think “dollar pizza sounds gross, I’m going to go for something healthier, like a salad.” However, at 4am, having last eaten at dinner at 7pm and consuming 12 beers in the meantime, John might think “I’m starving and if I don’t get something greasy and delicious in my stomach immediately, I’m going to regret it in the morning.”
The way to think about this context switch is that John hires dollar pizza for the Job of “filling me up and preventing a hangover when I’m wasted.” John’s context is more important than who John is, and consequently understanding John’s Jobs and needs is more important than understanding his persona.
In truth, whether someone purchases dollar pizza at 4am has almost nothing to do with who they are. Simply put, if you’re drunk and in the East Village when the bars let out at 4am, there’s a really good chance you’re heading towards dollar pizza.
To take this a step further, note how different types of pizza shops fill different Jobs held by the same person. While John might hire dollar pizza to prevent his hangover when he’s wasted, he may hire Lombardi’s (fancy) pizza to impress relatives in town, and he may hire Domino’s for delivery when he has his friends over for the game. It all depends on his context.
So, going back to the assignment at hand — John may have considered these other foods to fill his Job:
However, given John’s context and the Job at hand, I would recommend that 2 Bros installs a small rack of these items:
Bringing context into your backlog with Job stories
So how do we use this lesson to improve our backlog? Let’s deconstruct and then amplify a traditional user story to see how we can reflect context in our stories. A traditional user story has the following components:
As [user description or persona],
I want [to accomplish something],
So that [expected outcome]
Let’s take this framework and make a (weak) user story for John:
As John the 24-year old NYC resident,
I want to purchase pizza,
So that I can fill my stomach on the go with something delicious and cheap
Now — Ask yourself WHY? To answer that, move up the “So that” to the “I want” to get a deeper reason:
As John the 24-year old NYC resident,
I want to fill my stomach on the go with something delicious and cheap,
So that I can satiate my hunger before bed
Once again — Ask yourself WHY? To answer that, dig into the “So that” and contextualize with a “When” statement:
When John is winding down a heavy night of drinking,
He wants to fill his stomach on the go with something delicious and cheap,
So that he doesn’t want up hungover and starving
(Note that you lose the anchoring to a persona with the “As” statement — but remember, context is more important than the persona. The “As” is training wheels anyways, it’s mostly helpful for organizations without a culture centered on user value.)
The Job story follows this general story format:
Let’s break this down to see how the Job story provides better structure:
The Situation (When) gives the context of the motivation, the external trigger that causes the behavior. This reflects the truth that we, as humans, don’t act in a vacuum — we don’t decide to hire a cleaning person “just because”; we’re triggered by something like an imminent visit by a parent, or a friend’s “yuck” face when they enter the house. Figure out what happened in the lead-up to the user behavior. What did the user experience that nudged them to decide to purchase something or change their behavior?
A few caveats and tips about the When:
- When should not be about the user’s wants. Lines such as “When John wants pizza” shortcut the context enough to make it meaningless. Careful you don’t include “weasel want” words, such as “When John is thinking about…” or “When John likes…” or “When John feels…” If you find yourself with a want in the When, ask “why” and bring it back to the concrete event that triggered John to want the thing in the first place.
- Oftentimes the When is another person doing something, which is totally valid. Think platforms and marketplaces: “When someone clicks like on my photo…” or “When the seller confirms the shipment was mailed, the buyer wants…” Embrace this — humans are social creatures, and often the actions of others is what triggers us to do things ourselves.
The Motivation (X wants) should talk about the need of the user, not the solution you have in mind. A classic example here is the old marketing adage “users don’t want a quarter-inch drill, they want a quarter-inch hole.” However, this is actually not the full picture… users don’t want a quarter-inch hole, they want to hang their family photos on the wall. When you think of it this way, handheld drills actually compete with 3M sticky wall hooks in the user’s mind.
Make sure you dig into the motivation enough to understand the user’s need, but stop before it gets too esoteric. Asking “why do users want to hang pictures on their wall” might give you a somewhat actionable, if very emotional, motivation (make my house feel like a home), but further asking “why” to that will probably lead to some sort of deep yet extremely general and completely unactionable human need.
The Expected Outcome (So That) tends to be a deeper reason if you follow the guidelines for the previous two lines. Generally speaking this will end up being what the user expects their benefit to be, and can be either immediate and practical (“So that I know my package is going to arrive in time for my party”) or deeper and emotional (“So that I feel appreciated”), depending on your product.
Converting User stories into Job stories
Let’s wrap this up with a few examples of Job stories extracted from User stories. First, let’s go back to the example at the beginning of this article, timepass. While a user story might look like this:
Title: Mumbai resident should be able to get peanuts
As a resident of Mumbai,
I want to buy peanuts,
So that I can have a snack to fill my hunger
Ask yourself “why” a few times and you may end up with this:
Title: Mumbai drivers should feel their commute shorten
When they are stuck in traffic for what seems like forever
Mumbai drivers want a way to pass the time
So that they don’t lapse into boredom or succumb to road rage while waiting
Another example, using Facebook:
Title: Facebook user should see a notification when a friend tags them in a photo
As a Facebook user
I want to be notified when my friend tags me in a photo
So that I can like, reply to, or delete the tag
Ask “why” a few times, and you end up with a Job story that can help you think of a much more elegant and relevant solution to the user’s needs, (Timeline Review):
Title: Facebook user should be able to hide photo tags
When my friend tags me in an unflattering photo
I want my Facebook work colleagues to not see me in that photo
So that I can maintain my professional reputation
One more example, from my own experience. We realized there were multiple types of IDs floating around in our system, so we wanted to separate them visually with a prefix:
Title: Analyst should see case IDs prefixed with “CASE-”
As an analyst
I want cases to be prefixed with “CASE-”
So that I can determine at a glance what the ID refers to
However, after doing some user research, we learned that multiple systems had ambiguously-titled IDs, creating lots of confusion over email. This led us to refactor the story and create much more unique prefixes for all objects:
Title: Analyst should see a company-wide unique identifier prefix for cases
When an analyst is talking to someone about a case in our system
They want a regular pattern to reference for the case’s identifier
So that there is no ambiguity between IDs in different systems
Hopefully this gives you enough inspiration to try to make the switch in your own organization — I promise Job stories will make your stories feel far more relevant to the user, the product, and the company mission. And if I could leave you with one last parting Job story example:
Title: Blog post writer should be able to receive acclamation
When the reader finishes a particularly fascinating and useful blog post
The writer wants the reader to give applause on Medium and share the post with all their friends
So that they feel appreciated!