What is the difference between User story and Job story?

Article 14/34 about #productmanagement with a focus on Hard skills.

Introduction

In product development, understanding user needs and challenges is key. User stories and Job stories are two tools that help teams focus on creating value for the user. Despite the apparent similarities, these approaches have fundamental differences in focus, structure, and application. User story focuses on what the user wants to accomplish, while Job story focuses on a specific task to be accomplished in a specific context. Understanding these differences and knowing how to apply both tools as appropriate can greatly improve the efficiency of the development process and the quality of the final product. In this article, we will take a closer look at the main differences between User stories and Job stories, give case studies and discuss how to choose the right tool for your project.

Key differences

Definition and focus

• A User story describes a feature or product requirement on behalf of the user, usually following the format, “As [type of user], I want [action] to [get a result].” This format helps the team focus on the needs and wants of specific types of users, providing context for developing functionality.
• A Job story, unlike a User story, focuses on the task to be accomplished without being tied to a specific user. The format of a Job story might be: “When [situation], I want [action] to [achieve the result].” This approach emphasizes the situation that triggers the need for the action and the result to be achieved, rather than the user himself.

Structure and key components

The user story typically includes a three-component structure (Role — Action — Purpose), which helps to clearly define who the functionality is being created for, what the functionality should do, and why it is important.

The Job story focuses on the conditions of use and expected outcomes, allowing for a deeper understanding of the context of product use and avoiding assumptions about users, their roles or personalities.

Practical application

• User stories are most effective in projects where it is important to understand and meet the needs of specific user segments. They help to formulate and test hypotheses about how different aspects of the product can meet the wants and needs of users.
• Job stories are preferred in situations where it is important to focus on accomplishing certain tasks without being tied to specific user personas. This approach is particularly useful when developing functionality focused on improving efficiency or usability.

These differences emphasize the importance of selecting the appropriate tool depending on the project goals and the available understanding of the target audience. In the following sections, we will look at case studies and discuss how to properly integrate these tools into the development process.

Example User story

User Story: “As a parent of a young child, I want to be able to track spending on baby products in a mobile app to control the family budget.”

Analysis:

This User story focuses on a specific need of a certain user group (parents of young children) and offers a clear goal (controlling the family budget). It allows the development team to clearly visualize who they are building this feature for and why.

Example Job story

Job Story: “When I do a monthly family budget analysis, I want to easily find all the expenses for children’s goods so I can quickly assess where we can save money.”

Analysis:

• This Job story focuses on a specific situation (monthly budget analysis) and task (evaluating the possibility of saving money on a specific category of expenses). Unlike the User story, no specific user is mentioned here, allowing for a broader approach to the task.

These examples demonstrate how User story and Job story can be used for different purposes: User story helps to focus on the user and their needs, while Job story emphasizes the performance of a specific task in a specific context. The choice between these approaches depends on the specifics of the project and how important it is to consider specific user roles or situations that users are in.

About the User Story problem

In general, the problem with user stories is that they contain too many assumptions and little causality. When a task is posed in a user story format (As [user type], I want [action] to get [result]), there is no room for the question “why?”, you are essentially just limited to a specific sequence taken out of context.

You can show it schematically

Job story in action

Now let’s take a closer look at how to write a job story.

For example, we have a gym where we want to increase sales of monthly passes. First, let’s look at the people (the description is rather conventional, in reality it is much more detailed and elaborate):

• Masha, 30, is a mother of two children. Masha has gained weight after childbirth and wants to get in shape, but she can only work out twice a week. In fact, she works out even less often, often skipping workouts. Masha is a philologist by education, and in her spare time she likes to draw and read art books;\
• 25-year-old athlete Nikita, a regular at our gym. Nikita is a management student with a lot of time on his hands and not much money. Nikita likes cycling and hiking with friends.

In what case will such descriptions be useful to us?

For example, for targeted advertising. If we want to attract more Mashas or Nikitas — please: we set the campaign settings according to certain characteristics of our persons and wait.

Are they suitable for development, especially innovative ones?

In my opinion, not really. A persona is the end result of research and our labor; it is the audience we already have. By focusing on personas, we artificially limit our product, we don’t develop features for new, potential users. Again, by focusing exclusively on “old people” and improving the product for them, we fall out of the competition. Why? Because we don’t think about other ways to solve our users’ problem. We think about how they see that solution and polish it up — instead of fundamentally changing our approach and going through the solution options.

Conventionally speaking, we can build a super-modern gym with touchscreens and a kids’ corner — and still “give” a portion of users to a mobile workout app or a home exercise bike.

Let’s get back to our Masha. Here’s an example of a job story that could have happened:

When I work out at the gym and I have small children and no one to leave them with, I want them to be supervised so I don’t worry and exercise calmly for an hour.

Does it matter that Masha is 30 years old? That she has two children, not one? What is her educational background? And that it is Masha and not Anya? No, one single characteristic comes to the fore: that our user has young children. In job stories, this is part of the context, not the description of the user — simply because the context can be a completely different user profile. In the example with children, it could be Masha, or it could be Nikita if his older sister is away on a business trip and asks him to babysit and he doesn’t want to miss a training session.

The easiest way to understand this is through the example of Uber. It seems that there are two specific persons: a driver and a passenger. In fact, this characterization is only part of the context: depending on the situation, the driver can be in the passenger’s shoes, and vice versa.

If we’re talking about a candy store, and the context is “I want to treat myself to a sweet once in a while after a hard day or a successful project”, this can include Masha and Nikita, as well as diabetic Misha, vegetarian Alice, and dieting Petya. We think not about what differentiates our users, but what unites them. So the features that we make and release get a bigger reach.

Personas are certainly much better than nothing. Moreover, many successful companies are still working with this framework and are doing just fine. In any case, job stories are just another cool way to look at your product from a different perspective. Personas allow you to look at your users under a magnifying glass, but they don’t answer the question of why they continue to use your product — and why new ones will come after you release the feature. In my picture of the world, it looks something like this:

• In general, it is important to understand what your current audience looks like — this understanding comes after regular user research and work with audience figures;
• But specifically before developing a feature or product strategy, you need a job story.

How to do research for a job story

So, let’s say we’ve gotten into it and want to write a good job story. Where do we start? With research, of course.

Most current research focuses on the moment of product consumption, whereas job story research tries to understand when and under what conditions the customer had the first thought of buying a product (i.e. what happened BEFORE the product was used). The researcher is based on the assumption that there are four forces acting on the customer at the time of the purchase decision:

• dissatisfaction with the current situation (“push”) — “This gym is only open in the morning and I want to work out in the evening”
• the lure of a new solution (“pull”) — “Another gym is open 24 hours a day”.
• anxiety that something could go wrong — “What if the new gym is too crowded?”
• attachment to what we have — “I’ve been going to this gym for a year now and I know all the coaches”.

Why all this and what does it give us?

People are inert by nature. In most cases, they will continue to use a familiar solution than research the market and look for something new — simply because they are already norms. Something out of the ordinary has to happen for me to stop getting coffee at my favorite coffee shop.

And it’s important to realize that users aren’t buying your product, they’re switching to it from something else. Before the new gym, there was the previous gym. Before the previous gym, there was charging on the mat in the morning. Before the mat, there were burgers and ice cream at McDonald’s (that’s indirect competition, more on that next). The price of switching from one product to another is determined by habit and satisfaction, multiplied by the fear of change. And it’s critical for you to catch this moment of internal struggle and push the user in the right direction.

Conclusion

The choice between User stories and Job stories plays an important role in the product planning and development process. Both are powerful tools for focusing the team’s attention on user needs and objectives, but their use depends on the specific goals and context of the project.

User stories are best suited for projects where in-depth understanding and engagement of specific user groups is important, providing the team with clear guidelines for creating functionality that addresses the unique needs and desires of users.

Job stories, on the other hand, offer a more universal approach, focusing on the performance of specific tasks in specific use cases, making them ideal for projects where the context and situations users face are more important than their personal characteristics or membership in specific groups.