Job Stories Revisited
Job stories have become a staple in the jobs to be done (JTBD) framework. Many people find that their clear, simple format — akin to a Mad-Libs style — guides problem framing for innovation effectively. A well-crafted job story is self-evident and practical, seamlessly integrating into your next team discussion.
The technique was first pioneered by the product team at Intercom, a leading marketing communications solution. They wanted to avoid leading designers with a preconceived solution to better align development with the company’s vision and strategy. Encapsulating the customer pain point to address in a job story proved to be a useful approach.
Intercom’s product manager, Paul Adams, first articulated the concept of job stories stating: “We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome.” https://www.intercom.com/blog/accidentally-invented-job-stories/
Their job story format has three parts. Rather than concentrating on a generic role, such as a “user” or an “admin,” job stories emphasize the situation and context over the individual. The suggested format is concise and to the point:
When [situation], I want to [motivation], so I can [expected outcome].
However, job stories are notably flexible within the JTBD framework compared to other techniques. Many have adapted the format to their specific needs. Variations abound, and nearly no two applications of job stories are identical. In fact, Maxim van de Keuken’s 2017 study on the use of job stories found a significant degree of variation.
Consequently, several misconceptions have arisen about job stories. Let’s explore some of these:
MISCONCEPTION #1: Job stories replace user stories (not really)
Agile development breaks down efforts into individual units of work, captured as user stories. A typical user story follows a common format:
As a [role], I can [functionality], so that [benefit].
This could look something like:
As a system admin, I can specify files or folders to back up based on file size, date created, and date modified.
User stories, often very granular, might describe the function of a single button but don’t typically articulate why a user would want to take a specific action. That’s where job stories come in: they provide detail about the motivation and unmet need from the individual’s perspective.
Looking at it through the lens of the double diamond, job stories converge on a compact definition of the problem to be solved. I see job stories at the fulcrum of the problem space and solution space, with user stories very much tied to building a solution downstream from that point.
From the outset, job stories were never intended to outright replace user stories, which are integral to developing software functionality. Instead, they were originally thought of as a way to replace personas, not user stories (More on that below).
Bottom line: Job stories complement user stories.
MISCONCEPTION #2: Job stories replace the need for personas (not necessarily)
Personas are archetypal user representations, used across business functions for fostering customer-centric decision-making.
Some JTBD proponents advocate for abandoning personas, citing their often demographic, psychographic, behavioral, or attitudinal-based inaccuracies. While these elements are central to traditional marketing, they might not directly drive innovation and design. JTBD shifts focus from the individual’s psychological traits to the objectives they aim to achieve.
Claiming that JTBD obviates the need for personas is a misconception. Given the variety of actors in any JTBD ecosystem, personas can effectively represent different job performers and their unique circumstances.
For instance, if you are focusing on conference attendees (job performers) who attend a conference (target job), you might find a key distinction between in-person attendees and remote conference attendees. The job may remain the same (i.e., the steps in getting the job done are identical), but how they get the job done is different. They will also likely prioritize different outcomes, emotions, and social factors.
This would warrant personas, in my opinion — one for an in-person attendee and one for a remote attendee. If personas can bring that clarity to your team, by all means, use them.
Bottom line: personas are still a useful tool to communicate different types of job performers
MISCONCEPTION #3: Job stories are a good way to represent the target job (not quite)
Sometimes job stories are mistaken for or used as direct stand-ins for the core “target job.” This simplification overlooks the nuanced range of information and prioritization that should precede a job story. While it’s tempting to encapsulate the answer to the question “what’s the job to be done here?” in a job story format, it can prematurely jump to conclusions.
In contrast, the JTBD Canvas 2.0 lays out the key elements of the JTBD framework for analysis. Once you define the target job, you’re then looking for specific bits of information about that job from your audience, namely:
- Job steps, which go into a job map
- Emotional and social factors
- Outcomes, also known as personal success metrics
- Job differentiators, or the contextual factors that show how the job might get done differently in different situations.
One of the strengths of the JTBD framework is the rigor that goes into first collecting and then prioritizing comprehensive lists of the above elements. You want to get all of the job steps before creating a job map; you need to have a complete list of outcomes before running a quantitative survey; and your research should strive for an exhaustive list of emotional and social factors, as well as the job differentiators.
Jumping directly into job stories without this foundational understanding overlooks the meticulousness integral to the JTBD methodology and might lead to overlooking critical aspects of the job.
Bottom line: Job stories summarize the pain point after analysis is completed
Updated Job Story Format
Not everyone on a team will be intricately involved in JTBD research from start to finish. Typically, only a handful of members conduct interviews, and a small, dedicated team performs the analysis. While it’s possible to communicate findings through reports or presentations, team members often need a clear and compact description of the customer pain point they are addressing.
But what exactly is a pain point? In an article from the folks at Vendbridge, a leading JTBD consultancy, the authors show that a good pain point has three key elements:
- It must express a need, not a solution
- It must be concrete, not abstract
- It must be measured quantitatively, not anecdotal
A job story serves as a consistent format for summarizing and communicating pain points for ongoing reference.
To maintain the structure yet enhance specificity, I recommend this updated three-part job story format:
When I’m [job step] +[job differentiators to show context]
I want [customer imperative/new ability]
So that I can [outcome + emotional/social aspects]
In this format, the prioritized elements from the JTBD neatly converge, offering a cohesive and actionable narrative.
My suggested format departs from Adam’s original, but still has the three-line style. The first and the third lines come right from your JTBD analysis, where the middle element is generated from research but requires a little creativity. Let’s look at each in detail:
First line elements:
- Job step
Not all job steps in your job map hold equal weight. Some are more challenging to accomplish or more pertinent to your current strategy. From your analysis, identify which steps to focus on. Typically 1–2 that surface as prime candidates through team discussions or quantitative prioritization. These selected steps set the stage for the “when” in the first part of your job stories. - Job differentiators
Your research will unearth factors that reflect variation in the execution of the job. Prioritize these differentiators based on their impact on job performers. The latter part of the job story’s first line should spotlight these contextual and situational aspects.
Third line elements:
- Outcomes
Often referred to as “personal success metrics” or “needs,” outcomes articulate how the job performer gauges success. They provide a measure of effectiveness from point A to point B, as found in the job map. Prioritize these outcomes, particularly focusing on the top unmet need, to embed them in the third segment of the job story. - Emotional and/or social aspects
A comprehensive analysis should also yield a list of relevant emotions and social considerations. Prioritize these according to their significance to the job performer, incorporating the most pivotal feelings or social factors into the latter half of the job story’s third line.
The middle element: customer imperative:
That leaves the second line, the middle element in the job story format.
This is where the “customer imperative,” or the capability that an ideal solution would provide, comes into play. This element doesn’t derive directly from JTBD analysis but is informed by your research. It requires a bit of creativity: envision the “superpower” an ideal solution would grant the customer. This is a glimpse into the solution space without dictating a specific solution, placed in the middle of the job story.
Be both specific and aspirational with this element. For instance, if addressing the job of preparing a meal, avoid vague desires like “I want to save time getting ingredients ready.” Opt for a more precise and ambitious goal, such as “I want to seamlessly prepare meals without interruptions to find missing ingredients.” It describes what capability is missing from the job performer’s perspective — insight gathered during your research.
Let’s consider a scenario where the focus is on new home buyers (the job performers) aiming to shop for a new home (the target job). By utilizing the JTBD Canvas 2.0, you’ll derive a job map from the job steps, along with comprehensive lists of outcomes, emotions, social aspects, and job differentiators. Your next step is to synthesize the prioritized elements from each category into a single cohesive job story.
The image below illustrates the relationship between the key elements of the JTBD framework, as outlined on the JTBD Canvas 2.0, and how these elements translate into job stories. Essentially, you’re using the prioritized elements from each category as the foundation for your job stories.
In other words, job stories express customer pain points through careful prioritization and evidence.
It’s important to note that crafting a job story requires a bit of narrative skill. After all, it’s not called a job story by accident. The narrative should be coherent, with all the elements interrelating logically and meaningfully.
Take, for example, the new home shopping scenario. It wouldn’t be logical to pair a job step like “learning about the market” with an outcome like “minimizing lack of knowledge of specific neighborhoods” — they don’t logically flow together. Instead, this outcome might be more relevant when the job performer is comparing potential home options. Job stories require consideration in aligning the prioritized elements in a way that makes sense.
Often, for any given target job, you might find yourself crafting a series of job stories. This is because there could be several job steps and outcomes to address — perhaps the top 2–3 unmet needs. You may then end up with 3–6 primary job stories to align to, depending on your field and the complexity of the job.
This part of the process might feel a bit like piecing together a puzzle. Try to find common themes across your prioritizations. The goal is to ensure that the elements within your job stories work synergistically, creating a clear, comprehensive narrative that anyone can follow.
Qualities of Good Job Stories
What distinguishes an effective job story? Based on my experience, job stories should be:
- Evidence-based
Job stories aren’t concocted out of thin air; they are derived from analysis. Avoid hastily crafting a job story from the first pain point encountered in interviews. Instead, amass a body of comparative evidence to underpin your job stories. Further, validate these stories with job performers to ensure they resonate and accurately reflect real-world challenges. - Specific about the pain point
A job story should delve into the underlying pain point with detailed precision. For instance, instead of a vague notion like “When commuting to work I want to get there quickly so I don’t waste time,” a refined job story might say, “When I’m commuting to work daily at times when there might be heavy traffic and I absolutely cannot be late, I want to know exactly where and when slowdowns might occur so I can adjust my travel plans and avoid long waits and delays, maintaining my productivity and focus.” - Empathy-building
Job stories should contextualize the scenario to foster empathy. Incorporating specific job differentiators or qualifiers in the first line provides a vivid picture of the job performer’s situation, making it easier for the team to understand and empathize with their experience. - Aspirational
The central element of a job story — the customer imperative — should be a goal that propels the solution forward, something ambitious yet achievable. It should encourage the team to push the boundaries of current solutions and inspire innovative thinking. It frames possible solutions at an aspirational level without dictating specific features. - Self-evident
Job stories should be coherent and stand-alone, understandable in various contexts without needing extensive background on the broader JTBD framework. As they are evidence-rooted, they should instill confidence that the team is addressing the right problem.
Here are some hypothetical job stories from different fields to illustrate some of the above points:
Job performer: New home buyer
Target job: Shop for a new home
Job story:
When I‘m comparing available homes and am unfamiliar with neighborhoods of a potential home to buy but value having a strong community feel to my living arrangement,
I want to be able to get an immediate sense of what it might be like to live in a specific area,
So I can reduce any lack of knowledge of the neighborhood and what it might feel like to live there, giving me confidence about integrating that information into my decision-making process.
Job performer: Conference attendee
Target job: Attend a conference
Job story:
When I’m attending conference presentations that are particularly relevant to me as an in-person attendee and am new to the topic at hand,
I want to be able to easily and instantly capture the most relevant points and resources mentioned,
so that I can easily recall the most salient points later and put them into practice, as well as pass on my learnings to teammates, giving a feeling of accomplishment from attending the event.
Job performer: Commuter
Target job: Commute to work
Job story:
When I’m commuting to work daily at times when there might be heavy traffic (either from driving or ridership or foot traffic) and I absolutely cannot be late,
I want to immediately know exactly where and when slowdowns might occur,
so I can adjust my travel plans and avoid unnecessarily long waits and delays to reduce my stress and keep my energy focused on being productive.
Jobs Stories in Action: Practical Approaches
Although the technique originated to help product teams at Intercom design solutions, job stories have applications across the organization — from development to marketing and sales to strategy.
Here are some specific ways to bring job stories into your workflow:
- Generate a “How Might We…” statement for brainstorming
Utilize job stories as a springboard for ideation in brainstorming sessions. Transform your job story into a “how might we” question to guide exploration. For instance, from the commuting example, you might ask: “How might we inform commuters about various slowdowns en route to work so they can adjust to avoid delays?” - Define a design sprint challenge
Use job stories to craft a challenge for design sprints, which are intense multi-day sessions aimed at developing specific solutions. Articulate the job story as a challenge statement to provide a clear focus for the sprint. For example: “We aim to enable commuters to circumvent potential slowdowns by providing timely traffic information and alternative travel suggestions.” - Create a testable hypothesis for an MVP
Leverage job stories to frame hypotheses for testing Minimum Viable Products (MVPs) following Lean approaches. Formulate statements to validate whether the proposed solutions effectively address the job stories. A hypothesis might look like:
We believe that [job performers]
will achieve [desired outcome]
while performing [job step]
using [proposed solution].
Success will be evidenced by [specific measure].
This makes job stories actionable and testable, anchoring the solution to real needs and desired outcomes. - Incorporate into planning and road mapping
Bring job stories into Agile sprint planning to guide the development of solutions. Use them as heuristics to ensure design decisions align with user goals. They can also form the basis for success criteria in usability tests. For example, if reducing traffic surprises is a goal, test whether the solution effectively informs users about potential delays. - Craft go-to-market campaigns
Job stories can inform go-to-market strategies by focusing on the pain points and desired outcomes they encapsulate. Use the language and insights from job stories to shift marketing messages from feature-centric to benefit-centric. This ensures that marketing efforts are closely aligned with the user needs and solutions developed. Sales teams can also align their messages to a common understanding of unmet needs in the marketplace.
In Summary
Job stories synthesize crucial elements from JTBD research, bridging the gap between understanding user needs and developing effective solutions. They complement user stories and personas, offering a versatile, accessible format to capture and communicate customer pain points. Job stories feed into and enhance conceptual and development cycles, serving as benchmarks for success from the user’s perspective.
By adopting job stories, teams within the JTBD framework can more effectively align their efforts, from initial concept to market delivery, ensuring that solutions are deeply rooted in user needs and desired outcomes.
In the end, job stories are a key technique in the JTBD playbook, enabling a human-centered, evidence-based approach to creating value.
— — — — — — — — — — — — — — — — — — —
Further Resources on Job Stories
Paul Adams, “How we accidentally invented Job Stories,” Intercom (2003)
Alan Klement, “Replacing The User Story With The Job Story,” JTBD.info (2013); “5 Tips For Writing A Job Story,” JTBD.info (2013); “Designing Features using Job Stories,” Inside Intercom (2015)
Maxim van de Keuken, “Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering,” Thesis, Utrecht University (2017)
Dhananjoy Roy, “What are Job Stories and How are They Different From User Stories?” Dew Solutions blog (2021)
