One of the most important skills in product is the ability to think and communicate in terms of user problems, rather than solutions. The benefits are multifold: your engineering and design colleagues will ideate better solutions when aligned on clearly defined problems; business colleagues can only provide useful input if they understand the “Why are we building this?” question. So while it’s often tempting, immediately ideating solutions generally leads to chaos and, ultimately, lesser products.
This blog post is an introduction to user and job stories, how they differ, and how to use them as a product manager. While many style themselves as acolytes of one theory over another, I find that both are valuable if used in the appropriate scenario.
Definitions
A user story is generally structured as:
“As a PERSONA, I want to ACTION so that OUTCOME.”
A job story has a bit more to it:
PERSONA: “When SITUATION, I want to MOTIVATION so I can OUTCOME.”
The main difference is that job stories include the user’s SITUATION as context for why your persona has a desired outcome.¹ A user story has inherent assumptions about your persona’s intent; a job story spells out those assumptions.²
Let’s look at an example for someone buying Whole Foods delivery on Amazon.com:
User Story
As a grocery shopper, I want to see items I’ve previously purchased so that I can add add them to my cart.
Job Story
Grocery Shopper: When I’m ready to check out my weekly grocery cart, I want to be reminded of items purchased in past grocery orders so that I never forget to buy the staples I need for my kitchen.
The job story in this example tells us a lot more about the grocery shopper’s motivations: she tends to buy groceries every week; there are items she repeatedly buys that are often not top of mind for her; the best time to be reminded of those items is right before checking out. Note that an ideal world “Grocery Shopper” is a fully fleshed out persona used across all your product development, ex. “Anna” is a 35 y/o college-educated woman with $100k income, her grocery needs are…etc.
Job stories are derived from Jobs-To-Be-Done (JTBD), a product marketing framework that argues for customers wanting to buy an outcome, or “leveling up”, in their life, rather than a series of features. In their words: “A Job to be Done is the process a consumer goes through whenever she aims to change her existing life-situation into a preferred one, but cannot because there are constraints that stop her.
How to use in Product
My rule of thumb is to use job stories pre-solution design and user stories post-solution design. Said another way, job stories are important when working with your team to define what the problem is (without prescribing a solution). But once you’ve been through a design process, user stories are more efficient at describing the solution.
For example, let’s go through a quick product development process. Your team starts with an empty Product Requirements Document template. The first step is to define the job stories and success criteria (ex. metrics or KPIs) for the product. This should involve all your stakeholders: you, design, engineering, QA, business colleagues, etc. The process ensures that everyone is on the same page about what you’re trying to accomplish for the business and for your end-user(s).
Once these stories are set, you can move into the design phase. That phase should involve lots of user research, ideation, mockups, design workshops, etc. with all your stakeholders. As your team iterates to final designs you should use those job stories as guideposts along the way.
Now you have your final designs.³ They are an efficient, effective solution to the job stories. To start development your team needs to break those designs into manageable, prioritized chunks (i.e. tickets). You might have dozens of tickets for a single project! The right level of abstraction for tickets is a user story. While a job story is meant to be understood and consumed by all your stakeholders, just your engineers (and designer supporting the development process) need to grok the user stories.
A user story ensures that each chunk of work shipped has a user-defined outcome, while trusting your engineering team to figure out how best to design the solution in code. At the same time, engineers don’t need to re-read the user’s motivations for every single ticket. Many tickets will be granular and highly specific to the product implementation: “As a grocery shopper, when I click the Check Out button I am redirected to an interstitial page that shows me cards of previous items purchased so that I can add them to my cart before continuing to the Payment page.”
That’s it! You’re now a master of how and when to use job and user stories throughout the product development process.
¹ We can roughly equate the ACTION and MOTIVATION terms.
² Note that my formulation of a job story requires an upfront PERSONA. An alternative way would be to replace the “I” with the PERSONA — however I feel that this loses the benefit of the first person angle that puts yourself “in the user’s shoes.”
³ As a general caveat, I’ve greatly simplified the above story. User research may suggest changes to the initial job stories. I also glossed over where those job stories come from in the first place (hopefully a combination of user research, product strategy, and business-level OKRs).
