how to write job stories

Jobs to be Done

Nov 12, 2013

Replacing The User Story With The Job Story

I’ve written about the problem with user stories before . At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I’m working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I’ve come across a great way to use the jobs to be done philosophy to help define features. I call them Job Stories.

Where It Comes From

The idea comes from the really smart people at intercom . Here is what is they say:

We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

It’s not referred to as a Job Story in the article, but I’ll call it that so I can easily reference it in the future. The article doesn’t spend a whole lot of time with the concept, so I’ll talk about why I like it and why it’s better than User Stories.

The Problem (Again) With User Stories

Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

Here’s how I see the format:

The first problem is that we start with a Persona, which is a very bad idea , and then plop in an action which we think should be taken in order to achieve the expected outcome. As I’ve marked in the above image, there’s really a disconnect between the action and persona. Here, let’s look at some existing User Stories:

In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it’s adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.

Here, try this. Chop off the whole As a / an segment and see if you’re really losing anything. Compare these two:

As a moderator I want to create a new game by entering a name and an optional description

I want to create a new game by entering a name and an optional description

Did the sky fall?

The Job Story : All About Context and Causality

Update: 2015–03–03: Based on even more usage & feedback, I use a slightly different explanation now. See these tweets of how I suggest framing it now . An update of this article will come in the future…

Check out the image above. Now we’re cookin’!

All of the information above is critical and very informative because we’re focusing on causality. Each job story should provide as much context as possible and focus on motivation… instead of just implementation.

[update June 4th 2014] After working with Job Stories for a while now, I’ve changed ‘Motivations’ to ‘Motivations and Forces’. Look to 5 Tips For Writing A Job Story which touches on this. Also learn more about the forces via this podcast and this short article .

Let’s rewrite some examples from the user story chart above as a Job Story and add motivation and context to each one.

User Story:

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

As an estimator, I want to see the item we’re estimating, so that I know what I’m giving an estimate for.

When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.

As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.

When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.

What About Multiple Roles & Events?

*Added July 28th 2014

As I get great feedback regarding Job Stories and as I continue to work with Job stories, I’ve found that sometimes it’s helpful to include Roles, or Characters , as part of the When_ clause.

Products With Multiple Roles

Roles / Characters are most helpful when the product has multiple roles, e.g. an IT product ( Admin, Manager, Contributor….) or in a marketplace product product ( Buyer , Seller ). The reason is just to clarify who we’re talking about.

Using eBay as an example:

When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.

Roles With Cause & Effect

Sometimes, there are situations when a Job Story effects multiple roles at once — setting up a cause and effect scenario.

Using eBay, again, as an example:

When a Seller isn’t happy with the bids they are getting and takes their product off the market, Buyers who have already submitted bids, want to be immediately notified that the product has been pulled, so that Buyers know they no longer need to keep tabs on the product and should look for a different, similar product instead.

Using Events Instead Of Roles

Sometimes, however, there might be a situation when an event effects all the roles or groups of roles: such as needing to get a password reminder. In this case there’s no reason to have a specific role, rather, try to keep it event based and general by using terms like customer or someone ( but not user ):

When a customer is on their mobile device and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their mobile device, so they can continue to log in and access their news feed.

Why not user ? User feels very lifeless and sterile, instead, customer reminds us that we have people who need to be served and respected.

Define Motivations, Don’t Define Implementation

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how , they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

Your Job Story Needs A Struggling Moment , 5 Tips For Writing A Job Story .

Get a deeper understanding of JTBD and Job Stories from my book When Coffee and Kale Compete .

You can download it as a free PDF, or buy it in paperback & kindle right here . You can also read it online here .

If you have more questions about Jobs to be Done, or want help applying JTBD concepts to your business or startup, contact me .

More from Jobs to be Done

Managed by Alan Klement, JTBD.info is where JTBD practitioners share their experience, tools, and stories of using the theory of Jobs to be Done to become great at creating and selling products that people will buy. Everyone is welcome to submit a contribution.

About Help Terms Privacy

Get the Medium app

Alan Klement

I help businesses become great at making and selling products that people will buy. Contact me: www.alanklement.com www.idealizedinnovation.com

Text to speech

Search the site:

Browse topics

Browse these topics:

Job Stories Offer a Viable Alternative to User Stories

Get 200 Real Life User Stories Examples Written by Mike Cohn

Enter your email address below to get over 200 user stories from three complete product backlogs created by Mike Cohn.

Email Address

As useful as user stories can be, they’ve never been right for every team. An exciting alternative for some teams is the job story . A job story is focused less on the user performing some function than on the job to be done by that story. Job stories originated at Intercom and were best explained by Alan Klement .

A Job Story Template

To see how a job story shifts emphasis from the user to a job to be done, let’s take a look at the recommended job story template:

As with the common user story template , there are three parts to complete in the job story template. The first is known as the situation . This follows the word when in the template and provides context on when the story is being performed or perhaps what triggered the story. Examples could be:

The second element of the job story template follows the I want to and provides the motivation for the story. Think of the motivation as a user’s stated or first-order goal.

As an example, I want pizza for dinner tonight. Why do I want pizza tonight? Because I am meeting some friends tonight to watch a football game, and it’s easy to feed a group of us with different dietary needs and preferences with pizza. In the job story world, easily feeding a group is referred to as the expected outcome and it follows the so I can portion of the template.

Putting my desire for pizza into a job story would lead to

When it’s dinner time tonight, I want to have pizza so I can easily feed my friends.

This isn’t a particularly perfect job story, but it illustrates the difference between a user’s motivation and their expected outcome.

Contrasting Job and User Stories

To see the times when job stories may be better than user stories, let’s look at some sample job stories and their corresponding user stories.

When an Order Is Submitted...

Let’s start with this job story:

Job Story: When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.

This story describes the behavior seen on most eCommerce sites warning a user not to submit an order multiple times.

The user story equivalent of this might have been

User Story: As a customer, I want to be shown a message telling me not to submit an order twice so that I don’t place a duplicate order.

The job story is superior in this case for two reasons. First, this story applies to everyone making a purchase on the site. So it’s not important to know the person doing this is a customer. (In fact, calling the person a customer could be misleading because the person may not be a customer until this order has been placed.)

Second, the job story is better because it provides more context about when this is happening. It is happening “when an order is submitted,” as the job story tells us. Look carefully at the user story and you’ll notice that it never tells us when this message is displayed. The team could “successfully” implement the user story by adding an item on an FAQ page warning against double submitting orders. That is almost certainly not what the product owner wants.

Let’s look next at a job story about searching for an address by United States ZIP (postal) code.

Job Story: When searching by US ZIP code, I want to be required to enter a 5- or 9-digit code so I don’t waste time searching for a clearly invalid postal code.

This story is about making sure a user enters something reasonable for a postal code before allowing a search. The United States postal, or ZIP, codes are either 5 or 9 digits. This story says users should be prevented from clicking search with only entering two letters entered in the postcode field.

The equivalent user story would be:

User Story: As a user, I want to be required to enter a 5- or 9-digit postal code so I don’t waste time searching for a clearly invalid postal code

These two stories highlight that the difference between user and job stories exists in the first part of the templates. The when… and As a … clauses differ but in this example, the remainder of each story is identical in both user and job story format.

As in the first example, the job story is better here because of the additional context it provides around when the story is being performed. Who is performing the action (the search in this case) is not important, which is why the user story is written with the generic, “As a user…”

When to Use Job Stories

In deciding when to use job stories, I think it’s important to acknowledge that both user and job stories have unique strengths.

I still find user stories most helpful for products that have users who vary significantly and deeply understanding those users is important. This is why user stories start with As a… We start user stories that way because that puts the user right upfront. With user stories, who will be doing the story is perhaps as important as what they’ll be doing.

In contrast for a job story, it is not necessarily important who is doing the story. This makes job stories the better option when your product has users but their needs are not very distinct.

If you’ve ever written a lengthy set of user stories and started each with “As a user…”, you’ve encountered this problem. When a large set of user stories all begin with “As a user…” you’ve got a set of stories for whom the user is not very important.

Writing those as job stories rather than user stories would be helpful. Doing so would allow the story to include the additional context of when the story is being performed. In some cases, knowing when a story might happen is more important than knowing who will perform it.

Combining the Strengths of Job and User Stories

So, while job and user stories each have their own strengths, it’s possible to merge them and get both benefits in one story. Let’s revisit our postal code stories and see how to do this. First, we had the job story:

Job Story: When searching by postal code, I want to be required to enter a valid code so I don’t waste time searching for a clearly invalid postal code.

It’s never clear who is performing this story. Is it a normal user? A site admin? Someone else? We’re never told. If we think knowing who is doing this is important, we can augment the job story by adding a role to the story in place of I. This changes our story to be the following:

Job Story: When searching by postal code, a buyer wants to be required to enter a valid code so the buyer doesn’t waste time searching for a clearly invalid postal code.

The changes are in bold. You can see that I just changed from “I want…” to “a buyer wants…” and then made the corresponding change later in the story.

We can do something similar to a user story. Our initial, unmodified story was:

User Story: As a user, I want to be required to enter a valid postal code so I don’t waste time searching for a clearly invalid postal code

To provide additional context, we add a phrase telling us when the user is doing this. Our modified user story then becomes “

User Story: As a user who is searching by postal code , I want to be required to enter a valid postal code so I don’t waste time searching for a clearly invalid postal code

The modified user and job stories are semantically the same. Which you choose is entirely up to you. I personally prefer the modified user story over the modified job story because it keeps the story in first person. I’ve written elsewhere about the benefits of stories being in the first person .

So when should you prefer user or job stories over the other?

First, each is great and has its own advantages. During the course of any week, I will write some user stories and some job stories. The two techniques are quite compatible and there’s no reason to view them as mutually exclusive.

If your product has users and those users needs differ in important ways, I suggest user stories. The additional emphasis a user story puts on who is performing the action can lead to insights about user behavior.

If, however, your product’s users do not differ in significant ways, job stories are likely the better approach.

A good starting point is to mix user and job stories in the same product backlog. Start by writing job stories any time you are tempted to write a batch of stories all beginning with “As a user…”

What’s Your Experience?

What do you think of job stories? Would they be helpful on your product backlog? Have you worked with job stories before? Were they helpful? Please share your thoughts in the comments section below.

Get Your Free Scrum Cheat Sheet

You may also be interested in:

User Stories: How to Create Story Maps

How to Run a Successful User Story Writing Workshop

What Are Agile Story Points?

Epics, Features and User Stories

Advantages of User Stories over Requirements and Use Cases

Relationship between Definition of Done and Conditions of Satisfaction

UX Collective

Apr 4, 2018

Better stories with “Job Story” 😎

Buckle up for a game-changing experience in defining features and functionalities in Product management and UX.

Call it as “Job Stories”. Invented accidentally by Intercom team with Alan Klement .

“Job stories enables you to address the real people, not Personas.” interesting? Let’s roll!

Why not User story? User story are developed based on Personas which are imaginary and defined with assumptions. Moreover fails to address the user’s causality.

The interesting part of the 🍰 is motivation of user’s action is lost. Implementing with assumptions and attributes is locked up with empty contexts and fails to ask the “ WHY ”. When you don’t ask the “ WHY ” you fail to solve a real problem of a real user.🙄

Make way for “JOB STORIES” 👑

Job stories evolves from real people, not from the personas. The situation of a user triggers the motivation, which leads to the expected outcome. It talks with the real people’s context and casualty. Job stories triggers the “WHY” which helps the product team to look at the casualty of a user without any assumptions. It helps to look at the exact motivation of a user, not implementation.

A typical job story will look like:

“ When a new product is launched , I want to get notified So I can decide whether to pre-book or Just add to list.” “When I don’t want to upload and I want to paste a picture in comment So I can complete quickly.”

Now compare the User story and Job stories. Let the battle begin.💪

User story: As a user I want to book an appointment with a Doctor so that I can manage my time better. 🤧

Job stories: When I want to book an appointment with a Doctor I want to schedule and sync the same in my calendar so I can manage my time better. 😌

User story: As a user I want to eat something while I’m in a meeting so I can be active. 🙄

Job stories: When I’m in a meeting and when I feel starving I want to schedule an order, So, I can eat at time, be active in meeting. 😎

The biggest question is “Why not deal with real people instead of Personas?” It enables to enhance the motivation part of a user not Implementation. Once the motivation part is set, it reveals the creative side of asking “WHY” instead of “What” and “How”. 👌

Designing for motivations and outcomes is far better than designing for attributes. This is the key difference between Personas and Job stories. Personas look at roles and attributes, Job Stories looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. Why people do things is far more important.

Big thanks to: Alan Klement for his insights on Job stories.👏

Reference: Replacing The User Story With The Job Story — Jobs to be Done How we accidentally invented Job Stories — Inside Intercom

======================================= Does the article helps? Give a 👏 and post your suggestions below. Find articles related to Design, Product management & UX @ Alankar Sudarsan ========================================

More from UX Collective

We believe designers are thinkers as much as they are makers. Curated stories on UX, Visual & Product Design. https://linktr.ee/uxc · 459K followers

About Help Terms Privacy

Get the Medium app

Alankar Sudarsan

I help Businesses to Grow and Make Profit | Search Engine Marketer | Owner — www.2minstudio.com | Say: [email protected]

Text to speech

Technologies

Dew Solutions specializes in a suite of Application Development that is mission critical for business and enterprise, for clients across the world.

We are expanding rapidly and are working on several cutting technologies across various domains. We have some of the best in the industry working with us and are looking for young and bright minds to join us.

Our teams are always available to help you with your queries and provide right solutions to your business problems. Let’s get in touch and turn your idea into a brilliant solution through our team of highly qualified consultants.

Consistently ranked among the top consulting firms across the nation

Dedicated to providing personal attention to all our clients.

Best mobile and web app development services in India

Unmatched Devops practices with end to end cloud support

Complex AI and ML solutions. You think it, we build it

Save cost and time with our open source customisation offerings for ERP

A team of specialists with experience in a gamut of technologies

What are Job Stories and How are They Different From User Stories?

Job stories also referred to as a jobs-to-be-done framework are nothing but a more generalized and enhanced version of user stories that primarily focus on defining user tasks in a product design. They are considered to be a great alternative for user stories. Unlike user stories that are created based on personas, job stories involve creating a UX design keeping in mind the needs and concerns of the real users. It avoids the personas approach, in other words, personas become contexts.

User stories are merely assumptions or one’s own imagination. Moreover, they do not acknowledge causality. The challenge that arrives when you form a user story based on assumptions is that you fail to properly understand the actual problems of a real user, and therefore they remain unaddressed. Job stories, on the other hand, are based around real people, and not assumptions. Here, the user situation triggers a motivation that leads to the expected outcome. The concept revolves around “when” and most importantly “why” a user wants to perform a certain task instead of what they want to perform and how they want to perform. Put simply, we can say that Job stories are more concerned with motivation and outcomes rather than a user performing some function.

Job Stories Template

A job story UX template or format comprises three key elements-

1. “ When ” (the situation or the context)

2. “ I want to ” (the goal or motivation), and

3. “ So I can ” (expected outcome)

The first element provides the context to the story or the thing which is triggering the story in a particular situation. The second point which says “I want to” provides the motivation for the story whereas the last element “so I can” indicates the desired outcome.

For example, “When one of my contacts joins the messaging app, I want to be notified about it so I can start a conversation with him/her”

Job Stories vs User Stories: Understanding with an example

Let’s take an example to understand how Job Stories are more meaningful than User Stories. Consider a scenario where a person makes a payment at the time of checkout on an eCommerce website.

A user story related to it can be-

“As a user, I want to be shown a message telling me not to make the transaction twice so that I avoid making repeated payments.

A job story of the same scenario would be-

“When I checkout, I want to see a success message so I can avoid making the transaction again”

This clearly highlights the “when”, “I want to” and “so I can” points of the job story template.

Which do you think adds more meaning to the story? The second one, right? There are two main reasons behind this. First, the story applies to everyone doing a transaction on the site irrespective of who the user is. Second, it provides a clear context to when it is happening, i.e. post-checkout. If you carefully take a look at the user story, it never really tells us anything about the user and when the message should be displayed. When there isn’t a situation, it’s important to define the “user”.

Most of the part remains identical in a job story as well as a user story template. It’s just a matter of defining the context and the user.

When to Use What?

Both user stories and job stories have their own strengths in UX design. Deciding when to use what also depends on the product. For instance, user stories can be used for products whose users vary significantly, and it is imperative to thoroughly understand those users. This is the reason why user stories begin with “ As a [user] ” where we have to clarify who the user is. When we talk about user stories, who will be doing the story is as important as what they will be doing.

Conversely, in job stories, who is doing the story isn’t necessarily important, but the context is. You define a situation when a story will happen without thinking much about who is performing it. Job stories become a better option to opt for when your product has users but their needs do not differ a lot.

So the conclusion is that if your product’s users differ in substantial ways, user stories tend to be a great option but if they do not differ significantly, job stories are a better choice. The best thing to do, if possible, is to merge both and form a better contextual story with the users clearly defined.

Tips to Write Better Job Stories

A job story can be presented in a much better way if you follow the following tips-

1. Add More Context

Creating a situation is one thing, refining it is another which can be done when you add more context to it. By adding more contextual information to a situation, it will be easier for you to design a solution that eliminates the various concerns of real people. For example, a situation that says “When I want something to eat” can be further refined to “When I am in a hurry and want something to eat.” You can plan out the solutions accordingly.

2. Keep Your Focus Around “Real” People

Jobs stories, as we mentioned earlier, are based on real people, unlike User stories which are based on personas. The latter may create an incorrect image of the ideal customer and can leave holes in your design. Moreover, can you ask a persona why did they choose one product over the other? What challenges did they face while browsing your product or the competitor’s and what solutions did they demand? The answer is NO, you can’t.

With Job Stories, you fill this gap as it comes from the opinions of real people. You conduct interviews, talk to people and figure out the concerns they have and the contexts that were functional at the time when they used the product.

3. Supplement Motivation With Forces

Another way to write your job stories and make them better is by adding forces to motivation which is much like adding more context to a situation. When you augment the motivation stage of the job story template with forces, it becomes more specific and helpful. You will be able to form a solution that minimizes the forces that push customers away from a product and boosts forces that pull them towards it. Let’s understand this with an example.

“When I am placing an order and encounter a problem, I want to be assisted right away so I can complete my order successfully.”

The situation: “When I am placing an order and encounter a problem”

The motivation: “I want to be assisted right away”. Now let’s couple the motivation with some forces. The forces that drive this motivation to get assistance can be-

I feel irritated because I wanted to place a quick order

I feel anxious because of payment failure

The outcome: “so I can complete my order successfully”

By adding forces, you reassure that customers won’t have to wait for long to get assistance and can place the order quickly, and can be made feel safe regarding the payment issue.

This provides a better solution, doesn’t it?

The Bottom Line

A design concept that involves motivation to reach the desired outcome is a far better approach than designing for attributes. That’s the key difference between User Stories and Job Stories. The former gives more value to roles and attributes while the latter gives preference to situations and motivations. User stories based on personas provide a reference to the different types of users and what they do but they never completely reveal why people do something. Knowing motivation is important and Job stories do that job remarkably.

What do you make of Job stories? Do share your thoughts in the comments below.

Want to hire expert UI/UX designers? Get in touch with us. We hold over 11 years of experience in UI/UX design and have built scads of products that are equally usable, functional, and beautiful.

Design Thinking- A new buzzword in the IT Industry

UX Design Principles For Startups

Top UI/UX Design Trends for Mobile App

Have a Product Idea in Mind ?

Let’s talk about what you want to accomplish and how we can make it happen.

We specialize in a suite of App Development that is mission critical for business and enterprise, for clients across the world.

Gurugram India (HQ)

Contact info, case studies.

Job Stories

::: warning At Datopian we're moving to job stories from user stories . :::

Like user stories , job stories are a great way of gathering requirements. They are especially used in an agile environment, where one of the key values is responding to change over following a plan .

Job stories give the team more context for the user’s situation and allow them to share their viewpoint and create a solution for what the user wants to do.

Job stories are very similar to user stories with one key difference: personas becomes contexts (and jobs). We prefer job stories to user stories because they focus on a job to be done rather than a persona – "When I'm on the morning commute and bored" vs "As a a middle-aged, educated person".

Here is a short 6m introduction to Job to be Done by Clayton Christiansen which is really excellent:

Quick Start

When <situation/context> , I want to <motivations> , so I can <expected outcome> .

When I'm hungry, in a rush, and not sure when I'll be able to eat next, I want to be able to eat something 'on the go' with one hand so I can satisfy my hunger and make it to my appointment on time.

::: tip Define problems, not solutions. :::

It is about understanding what-is , not creating a what-should-be .

The More Context, the Better

In the image below, the following solutions could work:

Source: Alan Klement 2013. 1

Roles / Characters

In case the product has multiple roles or characters (different from personas), it can be helpful to include the role or character in the 'When …' clause.

This would be similar to the 'As a …' clause in a user story.

Using eBay as an example:

When a buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.

In this case it is helpful to clarify who we’re talking about, a buyer or a seller .

Why Personas are Not That Useful

As Alan Klement writes in Replacing Personas With Characters :

Because personas focus on creating a story made up of a customer’s attributes, instead of a story that explains a purchase, personas leave the brain in a unsatisfied state. To fix this, in just a split second, the brain decides to make up it’s own story.

This makes them:

::: tip Products don't match people, they match problems. 2 :::

The Problem With User Stories

When I used to write user stories with my team, my teammates would read them, think they understand them and then go on with their own interpretation of the story, which ended up being different than mine. I started noticing the problem was with the user stories, and not me, when different engineers would interpret the same story very differently. 3

As a <persona/role> , I want to <action> , so that <outcome/benefit>.

Does having the persona/role in there add much?

The Theory Behind Job Stories

Jobs-As-Progress: a theory that is promoted by Clayton Christensen, Alan Klement and Bob Moesta. 4

The phrase “jobs to be done” carries a lot of meaning with it. The three most important parts are: Job . Just as an employer hires and fires employees to improve itself, consumers hire and fire products to help them achieve progress. Also like the employer/employee relationship, the product does the work, while the consumer enjoys the benefits of that work. to be . When something doesn’t exist yet, we can say it is to be. A Job to be Done, then, is to create a life-situation that doesn’t exist yet. Done . When I hire a product and make the progress I desire, then the Job is Done. 5

Theory tells you how and why things happen, not what you should do about it. Theory is descriptive, not prescriptive.

Klement, Alan. (2013). 5 Tips For Writing A Job Story . post on JTBD.info ↩

Intercom on Jobs-to-be-Done. PDF ↩

Klement, Alan. (2013). The Problem With User Stories and What's Better… . Personal blog on Blogspot. ↩

Klement, Alan. (2018). Know the Two – Very – Different Interpretations of Jobs to be Done . Post on JTBD.info. ↩

Klement, Alan. (2018). Why Is It Called “Jobs to be Done”? (And Why Is This Important?) . Post on JTBD.info. ↩

Uncover the ‘when’ and ‘why’ of your technology with job stories

Too often the context and motivation of users is ignored when we design technology and ‘best practices’ from the world of design don’t always help. We’ve found in our work that user stories — the poster child of agile software development — really don’t help; job stories are much better.

Thousands of teams use ‘user stories’ in their system and product design process, and sometimes to great effect. However, user stories actually have a very specific role and context in which they are useful. Often they’re used by people who don’t know when they’re appropriate and, frankly, their use is often motivated by a desire to look professional and modern, not by a belief they are the best tool for the job.

Wait, what is a user story?

User stories are a format for capturing requirements. They have the origins in agile software development, but are often used in other contexts too. They describe a software feature from the perspective of an end user.

They certainly have their merits. In complex projects, the teams developing technology can get lost in their own world and user-centred design is easily forgotten. User stories can help keep discussions in the team focussed on the end user.

User stories follow a format:

As a {{ role/persona }} I want to {{ action }} so that {{ reason/outcome }}.

What’s wrong with them?

The problem with user stories is that they focus on the less interesting parts and often include redundant information. There’s not room to ask deeper, more useful questions like ‘why’ or ‘when’ or ‘what triggers this to happen in the first place’.

The role/persona part is often useless. I see a lot of user stories where the role/persona is “user” or “administrator”. Does that really add anything useful? I think not, but people still spend the time to write out tens of user stories so they can say they’re doing agile software development.

User stories also include a lot of assumptions, particularly that the action is the most appropriate thing to do. It locks you into a certain feature or way of your technology working very early on and shuts down ongoing discussion.

Job stories: a better way

When we work on software projects, whether selecting and configuring off-the-shelf software or creating bespoke applications, the most useful questions to ask are things like ‘why would someone want to do X’ or ‘what triggers this to happen in the first place’. It’s the ‘why’ and ‘when’ which is conspicuously missing from user stories.

We therefore eschew user stories and use job stories instead (if we use anything at all — sometimes these tools are not appropriate and using them for their own sake is a waste of time and money).

I first came across job stories on Alan Klement’s excellent blog . They have a different, much more useful format:

When {{ situation/trigger }} I want to {{ motivation }} so I can {{ expected outcome }}.

This helps us focus on causality and motivations, two areas which are harder to dig into but much more likely to help you create technology that truly impacts your organisation or users.

To take an example from Alan’s blog , look at the difference between a user story and a job story:

User story:

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

Hopefully you can see how the job story encourages one to focus motivations, triggers and context rather than obvious, low-value details.

I encourage you to go and read this post which goes into job stories in more depth and includes links to further discussion on the area.

Want to work together?

We’d love to chat about projects you’re working on ideas you’re exploring, especially in this area of job stories, system design and user experience. Take a look at some of our work or get in touch to find out how we could help you.

[email protected]

Get more articles like this

If you’d like to read more advice and articles like this one, subscribe to occasional updates from us below. We’ll only ever send you useful, in-depth articles like this one and we will never share you details with anyone else.

Designing features using Job Stories

Alan Klement

Author and Jobs-to-be-Done practitioner

@alanklement

Main illustration: Alejandro Chavetta

Personas and User Stories made sense when customers and product teams were far from each other. That’s no longer the case.

This is a guest post from Alan Klement describing how one team used the design technique of Job Stories to design a profile page in a product.

Traditionally, who the customer was and what they needed fell within the responsibility of marketing, business development, or even sales. After this information was gathered, it would be synthesized into a portable format and then pitched over the fence to a product development team, who was responsible for building the product.

The casualties of this waterfall process are the subtleties which it is necessary to understand when creating great products: causality, anxieties, and motivations. As development teams recognize that they need to be close to customers, it’s also appropriate to consider better ways of leveraging customer empathy to create products.

This philosophy of focusing on causality, anxieties, and motivations is called Jobs To Be Done , and a granular way to bring this concept into a product is to use Job Stories to design features, UI, and UX.

Learn how to build better software and get more customers.

How Personas fail

The biggest and most pertinent problem with Personas is this:

Personas are imaginary customers defined by attributes that don’t acknowledge causality.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race, and weekend habits) does not explain why they ate that Snickers bar; having 30 seconds to buy and eat something which will stave off hunger for 30 minutes does explain why.

How User Stories fail

As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.

User Stories, such as the one above, have three big problems:

Often, a feature or UX will fail. If it was defined by a User Story, then discovering why it failed will be difficult, because implementation was coupled with motivations and outcomes. Because of the coupling, how can anyone know what was wrong? Was the implementation wrong, or were the assumptions about motivations wrong?

Learn more about the challenges of User Stories here .

Enter the Job Story

First mentioned by Paul Adams here on the Intercom blog , and developed here , Job Stories are a different way of thinking about defining features, UI, and UX. Job stories are a powerful way to facilitate team conversation and discovery when designing products. But how does a team implement them into their workflow?

Here is one approach:

To demonstrate how this can work, consider how a team crafted a Profile View’s UX and UI for a product that helps car salespeople get loans for people wanting to buy a car.

Designing A Profile View

It was early in the design process. The team was discussing what the Dashboard/Home View would look like and what features should exist there.

At some point Joe, a team member, stands up and draws a simple wireframe on the whiteboard. He pointed to a box and said:

This is the salesperson’s profile.

The team listens to his rationale for the profile view but are not immediately convinced. They asks a series of “whys” for each particular part and circumstance for the profile view. Even after all of these questions, the team wasn’t coalescing for or against the idea.

At this point, the question was asked:

Why should the product have a profile view? Why should it be in one place or another? What information should it display? What situations is it resolving? What job is this profile view doing?

To resolve this, the feature was reframed in a process with Job Stories.

Note: For brevity, this article will focus on just one job story for the Profile View; in reality there were several job stories related to the Profile View.

1. Start with the high level job.

The high level job for this product is to help a car salesperson secure a car loan when someone buys a car from them. Currently, the buyer has to fill out a lot of difficult paperwork along with the car salesperson.

2. Identify a smaller job or jobs which help resolve the higher level job.

In order to get the loan application filled out correctly, the salesperson and buyer need to enter a lot of information about the car and the terms of loan, as well as the buyer’s sensitive financial information. Because the information is sensitive, the buyer needs to feel she can trust that her personal information is safe with the car salesperson.

3. Observe how people solve the problem now (i.e. which job do they currently use).

Currently, when filling out this type of information, the buyer analyzes (usually visually) the salesperson and car dealership and deduces if they are reputable and can be trusted. They also generally fill in their sensitive information in close physical proximity, on a piece of paper, with the salesperson. This helps them feel confident that the information is filled out correctly, and won’t get passed around to people who shouldn’t be looking at it.

4. Come up with a Job Story, or Job Stories, that investigate the causality, anxieties, and motivations of what they do now.

The above frames the situation into a Job Story. It can be fleshed out more by providing more situational context—such as when and where it’s being filled out (e.g. at home or at the dealership)—and anxieties each party will have about having and viewing a profile. More tips on creating Job Stories are here .

5. Create a solution (usually in the form of a feature or UI change) which resolves that Job Story.

To resolve the above job, the team then decided on what features the Profile View should have and how it should be presented. Too little information and the Profile View won’t solve the original job, and too much information could have negative effects. So we decided:

Here is an example of a solution:

Here is a breakdown of the UI, the job each UI element is doing, and what situation(s) it’s resolving.

With the UI complete, we now have a UX in which every element can be traced back to resolving a job: ensuring the customer feels safe when exposing personal information.

Design For Real People, Design For Causality

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in, and then understanding causality, anxieties and, motivations.

Abstracted attributes and coupling implementation with motivations and outcomes are distractions for a team. If the team digs deep and learns about a customer’s Job To Be Done, they can then more effectively craft solutions. Using Job Stories to design features, UI, and UX is one way to do it.

Our fourth book, Intercom on Jobs-to-be-Done , is a collection of our best thoughts and ideas on the topic. The goal: help you understand what needs customers meet with your product, and how to ultimately improve upon that experience.

Most Popular

Customer Service 8 min read

Introducing Fin: Intercom’s breakthrough AI chatbot, built on GPT-4

Meet our new AI chatbot, which delivers the power of GPT-4, fine-tuned for the support experience that Intercom provides.

Fergal Reid

Director, Machine Learning, Intercom

Product & Design 6 min read

RICE: Simple prioritization for product managers

Prioritization is a perennial challenge when building a product roadmap. How do you decide what to work on first? If…

Sean McBride

Former Product Manager, Intercom

News & Updates 9 min read

Announcing Intercom’s new AI features

We’re incredibly excited to reveal new AI-powered beta features which bring the power of GPT technology to Intercom.

Job Stories

User Experience

What is it & Why Do It?

Job Stories break down customer interaction with your product or service into bite size tasks that the user(s) needs to move through to get to a desired outcome. They have been created based around the ‘Jobs to be done’ research methodology and pioneered by companies such as Intercom in recent times. They are an alternative to using ‘User Stories’ but are unique in that they are less prescriptive in their intended action and more user-centric in nature. They take into account the customer's context, motivations, behaviours and emotional states. This helps give product creators more insight into why they are creating features and increases empathy for the customer.

By focusing on context rather than implementation it allows for a broader understanding of the problems and the generation of possible solutions. Using Job Stories it is possible to lay out in writing (even before a single screen has been created) the intended User Experience. This is great for getting thoughts down without provoking predefined solutions too early. Combine Job Stories with a Jobs To Be Done research methodology and it provides a flexible, empathetic and robust foundation for thinking deeply around the User Experience.

Who’s Involved & What’s The Setup?

Job Stories can be done alone but it is recommended being tackled in a small multidisciplinary team. Involving a variety of disciplines into the process makes sure you capture most scenarios, offers you different perspectives and allows your team to empathise with the problems your customers are facing. You should allow a good 1/2 - 1 day for the process if the journeys are particularly complex or involve multiple users. After their creation make sure it’s widely available to your team members.

Step-by-step Guide

Before you start creating your Job Stories you need to have gathered enough information about your target audience to understand the jobs that they are trying to achieve. Do this by using quantitative and qualitative research methods such as interviews, surveys and internet research. Process this information into structured takeaways that can inform your Job Story writing. If possible use JTBD (Jobs To Be Done) research methods to uncover the hidden reasons customers do the things they do. This often reveals surprising insights into the lives of your users.

Once your research has been gathered and shared around the team start by laying out the basic high-level steps that your customer will go through. This will form a structure to start filling in with more detail as you run through your customer journey.

Start at the beginning of the customer journey. Write your first Job Story with ‘When…’ this is the situation/context the user is in at the time of completing the job. For example: ‘ When a student is in school…’ Or ‘ When I am in school’ - Job Stories can be written as first or third person, whichever seems most suitable but stay consistent throughout. They also can contain more than one customer journey if the experiences are intertwined and so should be written at the same time.

Next move onto the ‘I want to…’ or “They want to…’. This is the motivation for the job they are trying to complete. For example; ‘ When a student is in school, they want to pick the right electronic course for their lesson…’

Lastly write down the ‘So that I can…’ or ‘ So that they can...’ statement. This is the expected outcome of the previous action(s). This sheds light on why the customer wants to achieve a specific goal. This can include social, environmental and emotional drivers. For example: ‘ When a student is in school, they want to pick the right electronic course for their lesson, so that they can follow along with the teacher and feel a sense of progression as they learn the course material’.

Repeat this process as you move through the customer journey.

It’s important to not try to write too many job stories but also not too little . Job Stories should lay a foundation of your product. They should give enough information to move forward and flesh out the user experience in more detail. If you find there are too many try and group these and refine down.

Job Stories are an alternative to User Stories. They emphasis context, motivation and emotions. This allows the team to empathise with the customers ‘jobs’ that they need to achieve.

Getting multi-disciplines to partake in writing the stories allows you to get a range of perspectives, getting everyone thinking in a human-centred way and aligns your team on the high-level objectives.

Try to balance the number of Job Stories you create so you have enough information to move forward but not too many that they end up too prescriptive.

Don’t be afraid to adapt the system to suit your needs and update your stories as you have a deeper understanding of your customers.

Download the Job Stories template

Thank you for the support!

Download the Job Stories template here

70+ step-by-step guided templates for business strategy, product management, UX and UI.

Job Stories

Identify opportunities for growth by deconstructing a job that customers are trying to get done.

👥 The whole team can participate | ⏰ about 1 hour

Writing Job Stories is a powerful way of evaluating the circumstances that arise in customers’ lives.

Customers make decisions about what products to use because they find themselves with a problem they would like to solve.

With an understanding of the “job” for which customers find themselves “hiring” a product or service, we can more accurately develop and market products and features well-tailored to what customers are already trying to do.

Instructions

When writing job stories it’s important to focus on things such as context, causality and motivations instead of assumptions, subjectiveness, personas and implementations.

We start by framing each design problem as a job, focusing on the triggering event or situation, the progress and motivation, and the intended outcome:

[ Situation statement ] + [ Progress statement ] + [ Outcome statement ] .

Example: [When I’m running late for an appt & worried that I won’t be able to eat before], [I want something filling to eat on the go], [so that I have the energy to perform].

Tips for writing effective job stories:

Refine a situation by adding contextual information .

The more context we have for the situation, the easier it will be to craft a working solution which also handles any anxieties which can push a customer away from using a product or feature..

Job Stories Come From Real People Not Personas

Job stories should be derived from real customer feedback. You must talk to real people and uncover all the anxieties and contexts which were in play when they used your or a competitor’s product. Additionally, comb through any existing research you have on your users, pulling out any contextual or emotional data that might aid you in writing your job stories.

Design Modular Job Stories Which Features (solutions) Can Plug Into

When writing job stories, it’s important not to commingle the job with solutions. Doing so makes it difficult to figure out what went wrong when customers reject our ideas. Was your persona wrong? Was the feature wrong? Was it the wrong feature for the persona?

Add Forces To Motivations

In the job story format of Situation — Motivations — Expected Outcomes, the Motivation stage can be enhanced by adding pull and push forces. Adding forces to a motivation is much like adding context to a situation. It’s the emotional component of the job story. By getting in touch with the emotions the customer is feeling we can design solutions that mitigate them.

https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9

Privacy Overview

IMAGES

5 Tips For Writing A Job Story. Learning from a new way to define…
template 4 Job Stories
5 Tips For Writing A Job Story
How to Write a Story
Pin on Business Analyst
Pin on Persona (or "Job Story" vs. User Story)

VIDEO

A Writing Tip For Beginners (🔜That You Can Implement Immediately!)
Real Writing Jobs -- Earn Extra Money Writing
【Apple】A babysitting job for my Ex’s Mom turns into a nightmare!
S2-INTRO- 2..how to write this book Why some people get more salary? Secrets from the book
How to write a job application or cover letter? For Software Engineer
Hand Writing job || online hand write earn money || Make money at home

COMMENTS

5 Tips For Writing A Job Story
5 Tips For Writing A Job Story · 1. Refine A Situation By Adding Contextual Information · 2. Job Stories Come From Real People Not Personas · 3. Design Modular Job
Replacing The User Story With The Job Story
Managed by Alan Klement, JTBD.info is where JTBD practitioners share their experience, tools, and stories of using the theory of Jobs to be Done to become great
Job Stories Offer a Viable Alternative to User Stories
As useful as user stories can be, they've never been right for every team. An exciting alternative for some teams is the job story.
Better stories with “Job Story”
Job stories evolves from real people, not from the personas. The situation of a user triggers the motivation, which leads to the expected outcome.
What are Job Stories and How are they different from User Stories?
Job Stories Template ... The first element provides the context to the story or the thing which is triggering the story in a particular situation.
Job Stories
Job stories are very similar to user stories with one key difference: personas becomes contexts (and jobs). We prefer job stories to user stories because they
Uncover the 'when' and 'why' of your technology with job stories
I think not, but people still spend the time to write out tens of user stories so they can say they're doing agile software development. User stories also
Designing Features Using Job Stories
Enter the Job Story · Start with the high level job. · Identify a smaller job or jobs which help resolve the higher level job. · Observe how people
Job Stories
Step-by-step Guide ; Start at the beginning of the customer journey. Write your first Job Story with 'When…' this is the situation/context ; Next move onto the 'I
Job Stories
Tips for writing effective job stories: · Refine A Situation By Adding Contextual Information · Job Stories Come From Real People Not Personas · Design Modular Job