See also: Empathy Mapping, Future Press Release, How Might We, Hypothesis Statement, Journey Mapping, Objectives and Key Results, Problem Statement, User Story Mapping, Assumption Mapping, Design Thinking, Core Tenets of Jobs-to-be-Done (JTBD), Jobs-To-Be-Done Framework (JTBD)
Relevant metrics: Time to complete the task, Accuracy of the completed task, Customer satisfaction ratings, Cost savings or revenue generated, and Employee engagement and satisfaction levels
What are Job Stories?
The Jobs-to-be-Done (JTBD) framework provides an innovative approach to understanding customer needs. At the heart of this methodology is the concept of a “job story,” which offers a unique perspective on customer motivation.
A job story is a narrative framework for describing a specific customer goal or task. Rather than focusing on the product or service being used, the job story centers on the customer’s desired outcome and the context in which they are seeking to achieve it. By framing customer needs in this way, job stories allow product teams to understand the underlying motivation behind customer behavior and design products that better meet those needs.
A typical job story follows a specific structure, with a simple sentence that outlines the customer’s goal, and additional details that provide context and depth. For example, a job story might read, “When I’m feeling hungry in the morning, I want a quick and easy breakfast option that will keep me full until lunchtime so that I can start my day feeling energized and focused.” This narrative provides a clear sense of the customer’s desired outcome, as well as the specific situation in which they are seeking to achieve it.
By focusing on customer needs rather than product features, job stories enable product managers and designers to better understand the underlying motivation behind customer behavior. This, in turn, can help teams build products that more effectively solve customer problems and create lasting value.
Job stories offer a unique and powerful perspective on customer needs within the Jobs-to-be-Done framework. By providing a structured narrative that focuses on customer goals and context, job stories can help product teams create more effective and customer-centric solutions.
Where did Job Stories originate from?
The term “job story” was coined by Alan Klement, a product designer and Jobs-to-be-Done (JTBD) practitioner. Klement first introduced the concept of job stories in his 2014 book “When Coffee and Kale Compete,” in which he explores how JTBD can be used to create better products.
Klement developed the concept of job stories as a way to help product teams better understand customer needs and motivation. By framing customer needs in the context of a specific job or task, job stories provide a structured narrative that enables product teams to create solutions that more effectively address those needs.
Since its introduction, the concept of job stories has become a widely used tool within the JTBD framework. Today, job stories are a key element of JTBD methodology and are used by product teams around the world to create customer-centric solutions that meet real-world needs.
Why should product teams use job stories?
Product teams should use job stories because they are a powerful tool for understanding customer needs and designing products that meet those needs. Here are a few reasons why job stories are useful:
- Focused on customer needs. Job stories shift the focus away from the product and towards the customer’s desired outcome. This can help product teams create solutions that better meet real customer needs.
- Provides context. Job stories provide context around why a customer is trying to achieve a specific goal, which can help product teams better understand customer motivation and design products that address underlying needs.
- Easy to understand. Job stories use simple and clear language to describe a customer’s goal and the context in which they are trying to achieve it. This makes them easy to understand and communicate to other members of the product team.
- Aligns the team on context, motivation, and research. By creating a shared understanding of customer needs, job stories can help product teams align around a common goal and work towards creating solutions that meet those needs.
- Avoids feature-based thinking. Job stories focus on the customer’s desired outcome, not specific product features. This can help product teams avoid feature-based thinking and instead focus on creating solutions that address underlying customer needs.
Job stories enable a customer-centric approach to product design. By focusing on customer needs and providing context around those needs, job stories can help product teams create solutions that better meet customer needs and create lasting value.
The format of a Job Story
A job story typically includes three main parts:
- The trigger (or situation)
- The motivation
- The desired outcome.
Here is a template for a job story:
When [trigger], I want to [motivation], so I can [outcome].
Let’s break down each part:
- Trigger. This is the situation that causes the customer to want to complete the task or achieve the goal. It should be specific and contextual.
- Motivation. This describes the customer’s underlying need or desire for completing the task. It should be focused on the customer’s emotional and functional needs.
- Outcome. This is the desired result or benefit that the customer is trying to achieve. It should be specific and measurable.
Putting it all together, here is an example of a job story using the template:
When I have an important meeting, I want to easily access my presentation materials on my phone, so I can deliver a polished and professional presentation.
In this example, the trigger is an important meeting, the motivation is the desire to be polished and professional, and the outcome is the ability to easily access presentation materials on a phone.
Other examples are:
- When I start a new project, I want to be able to easily collaborate with my team and track our progress, So that we can stay organized and meet our deadlines
- When I need to find a specific file on my computer, I want to be able to find it quickly and easily, So that I can be more productive and efficient with my work
- When I receive an email with an attachment, I want to be able to save the attachment to the correct folder, So that I can stay organized and easily access the file later
The trigger represents the customer’s starting point, or the reason they need to complete the task. The motivation represents the customer’s reason they want to complete the task. The desired outcome represents the end result that the customer is trying to achieve, or the benefit they will receive from completing the task.
What is the difference between a job story and a user story?
Job stories and user stories are two different frameworks used in product development, but they both can work effectively in an agile setting. The main difference between them is in their approach to describing user needs and requirements.
Job stories, which are part of the Jobs-to-be-Done (JTBD) framework, are a way to describe a customer’s goal or need in a specific situation. They focus on the outcome the customer is trying to achieve, rather than the specific product features they need. Job stories are often used during the discovery phase of product development to better understand customer needs and design effective solutions.
Job stories are rooted in research and specific context, allowing for a deeper understanding of the user’s situation and the job they are trying to accomplish. By focusing on the user’s specific circumstances and the tasks they need to complete, job stories provide a clearer picture of the user’s needs and allow for more targeted solutions than user stories afford.
User stories, on the other hand, are a technique used in agile development to describe a feature or requirement from the perspective of the end user. User stories typically follow a “As a [user], I want [goal], so that [benefit]” format and are used to help define the scope of a project and prioritize work during development.
User stories are commonly written based on assumptions and generalizations about the user, such as their goals, preferences, and behaviors. While this approach can be useful in developing a basic understanding of the user, it can also result in a lack of specificity and relevance to the user’s actual needs.
Both job stories and user stories can work in an agile setting, and it’s up to the product team to decide which approach is better for their needs. Job stories can be used throughout the product lifecycle, but if there would be a time where they are particular helpful, it would be in the discovery phase of a project when the team is trying to understand customer needs and design effective solutions. User stories, on the other hand, are more task focused and therefor work well for more mature products with existing problem-solution fit or for more immature environments where product owners and stakeholders are more task and output focused than outcome focused.
Job stories tend to provide a more nuanced and detailed understanding of the user’s needs and goals, while user stories may rely more on assumptions and generalizations. This is why job stories are often preferred in product development, as they lead to more effective and relevant solutions for the user.
However, the research practices of the product team must follow with the use of job stories. Job stories without research is not just represent assumptions, but untested hypotheseses.
Who writes Job Stories?
Job stories are written in collaboration by the product team, which typcially include a product manager, lead designer, and a lead engineer. If possible, stakeholders should join in as well. The product team is responsible for understanding customer needs, developing solutions to meet those needs, and bringing the product to market.
The product team may work together to identify specific customer needs and develop job stories to guide product development. Product managers may lead this effort by working with the team to understand customer needs, prioritize product features, and develop a roadmap for product development, but it’s a collaborative effort where everyone within the product team and outside the product team can suggest stories.
Designers may be responsible for creating user interface designs that support the job story and make it easy for customers to achieve their desired outcome. Engineers may work to build the product and ensure that it meets the technical requirements necessary to support the job story.
Crafting testable hypotheseses from Job Stories
The trigger in a job story describes the situation and context that prompts the user to perform a particular job or task. This is exactly what we need to craft a testable hypothesis.
Hypothesis:
If [trigger happens] then [desired outcome will happen].
For example, if the trigger in a job story is a customer needing to purchase a product quickly before leaving for vacation, a testable hypothesis could be that customers are more likely to make a purchase if they are presented with a time-sensitive offer or discount at checkout.
To test this hypothesis, the product team could implement a feature that presents a time-limited offer to customers at checkout, and measure the impact on the conversion rate. By tracking the number of customers who take advantage of the offer, the team can determine if the hypothesis is correct and whether the feature should be retained.
In this way, the trigger in a job story can be transformed into a specific, testable hypothesis that allows product teams to validate assumptions and make data-driven decisions about product development.
Mapping Job Story assumptions with Assumptions Mapping
David Bland’s assumptions mapping exercise is a technique used in Lean Startup methodology to identify and test assumptions made during product discovery. Job stories can be a valuable input for this exercise, as they provide a clear understanding of the user’s specific needs and tasks, which can help to identify and validate the assumptions being made about the user.
In the assumptions mapping exercise, assumptions are categorized based on their level of risk and uncertainty, and are then validated through a process of testing and experimentation. Job stories can help to inform this process by providing a specific scenario in which to test the assumptions.
For example, a job story might describe a user’s need to quickly find and purchase a specific item on an e-commerce website. Based on this job story, assumptions might be made about the user’s preferences for search functionality, the layout of the website, and the checkout process. These assumptions can then be tested through user testing and experimentation, using the job story as a basis for the testing scenario.
In this way, job stories can help to guide the assumptions mapping exercise by providing a specific context in which to test and validate assumptions about the user. By using job stories in combination with assumptions mapping, product teams can develop more effective and targeted solutions that are based on a deep understanding of the user’s needs and goals.
- What is the purpose of the job story?
- Who is the target audience for the job story?
- What are the key elements of the job story?
- How does the job story relate to the overall goals of the organization?
- What are the potential benefits of using a job story in this context?
- What are the potential drawbacks or limitations of using a job story in this context?
- How will the job story be used and shared within the organization?
- What resources will be needed to create and implement the job story?
- How will the success of the job story be measured?
- What are the potential risks of not using a job story in this context?
You might also be interested in reading up on:
- Alan Klement @AlanKlement
- Bob Moesta @bmoesta
- Tony Ulwick @tonyulwick
- Eric White @eric_white
- Jim Kalbach @jimkalbach
- When Coffee and Kale Compete: Become Great at Making Products People Will Buy by Alan Klement (2014)
- The Innovator's Solution: Creating and Sustaining Successful Growth by Clayton Christensen and Michael E. Raynor (2003)
- Jobs to be Done: Theory to Practice by Stephen Wunker (2018)
- Jobs to Be Done: A Roadmap for CustomerCentric Innovation by Anthony Ulwick (2020)
Want to learn more?
Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.
No spam! Unsubscribe with a single click at any time.
Community events
Product Loop
Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.
Join our communityMade with in Copenhagen, Denmark
Want to learn more about about good product development, then browse our product playbooks.