Craft Job Statements

Learning Objectives

After completing this unit, you’ll be able to:

• Compare effective and ineffective job statements.
• Define two methods for writing job statements.
• Discuss the altitude of jobs.

Job Statements 101

Now that you understand the key elements of the Jobs to Be Done framework, let’s see how you can put them into practice. 

Before you can start taking action based on customer jobs, you need to translate what you hear from your customers into actionable job and outcome statements. The structure of a job statement is what helps to bring alignment across organizations and roles. 

Important: Once you have finished talking to your customers about their jobs, it’s helpful to debrief with your cross-functional team and work through interview notes to help to identify patterns, surface common motivations, and articulate the three dimensions—functional, emotional, and social—in the jobs. 

While there are a few different approaches to writing job statements, the approaches share common principles for effective statements. In the table below, you can compare the characteristics found in effective and ineffective job statements.

Here are some examples of job statements to show why the wording is important.

Job Story and Outcome-Driven Methods

Job statements are written using two common methods. In the following section, you take a deep dive into each method and explain which method would fit certain situations. 

Job Story Method 

The job story method focuses on three aspects: a triggering event or situation, the need or motivation, and the desired outcome. This approach helps you understand why someone would hire a particular product to complete a job and how you can get the job done better. Let’s look at some examples in the table below.

Outcome-Driven Method 

The outcome-driven method identifies the main jobs and defines a comprehensive list of desired outcomes for each job. This approach helps you understand all the possible needs and outcomes when you are developing a new product or redefining our market.

Customer needs can be defined by desired outcome statements, which have four key components. They are:

• Direction of change: How does the job performer want to make progress on the job?
• Unit of measure: What metric of success has the job performer defined? This could be time, effort, skill, likelihood, ability, and so on.
• Object of the need: What is the need about? What will be affected by doing the job?
• Clarifier: Any other context needed to frame the desired outcome

Job Stories vs. User Stories

But wait, what about user stories? Aren’t they the same thing as job stories? Good question! 

Some teams confuse job stories from Jobs to Be Done with User Stories from the Agile methodology. Our premise is that Jobs to Be Done and Agile (epics, user stories, acceptance criteria) are complementary. While user stories specify the solution features that are being built, job stories are the briefs that frame the challenge to be solved. In this way, a well-crafted job story can be used as a brief for multiple teams and functions across your company—marketing, engineering, business ops, sales, and so on—helping to align those teams in the process. A single job story can, and often does, result in many user stories. 

One technique for crafting job stories, popularized by Alan Klement, frames design problems by focusing on the triggering event or situation, the motivation and goal, and the intended outcome.

When _____ , I want to _____ , so I can _____ .

Going back to our original question about shovels and holes, a job story might go like this:

When the ground is thawed, I want to make a hole, so I can plant seeds that will bloom in Spring.

It’s important to understand that it’s possible for a hundred user stories to fall under a single job story as individual steps. The intended outcome in this example is for seeds to bloom. This main job, growing things, can then be broken down into multiple jobs that enable a user to complete the main job from start to finish. One user might buy a shovel. Another might hire a hole digger. And so on.

Knowing a user’s Jobs to Be Done is the first step in the process. Keeping the big picture in mind helps inform the user stories that are developed later on in the process. Using both user stories and job stories is critical to overall customer success. 

You can read more of Klement’s thoughts on crafting job stories via the link in the Resources section. 

Next, let’s talk about how to determine the appropriate altitude for the main job!

Job Altitude

One of the most challenging parts of crafting a job statement is determining the appropriate altitude for a job. The job altitude is the scope of the job and helps us gauge whether a job is too broad or narrow. Defining a job too broadly can prevent the job from being actionable, while defining the job too narrowly can limit the scope of innovation. 

Here are a few guiding questions to keep in mind when determining the appropriate altitude for your main job. Remember, main jobs can be broken down into multiple smaller jobs, but it’s important to align on an appropriate altitude for the main job in order to define the scope of innovation for your solution.

• Has the job been stable over time? If not, your job may possibly include a modern-day solution.
• Could you imagine your job performer waking up in the morning and saying, “I need to do ‘x job’ today?” If not, your main job may be referencing a narrow or granular task
• Would solving this job align with our company’s capabilities and business objectives? If not, your job may be too abstract or ineffective at informing product decisions.

By asking “how” a user accomplishes a certain job, you move down in the hierarchy of jobs. By asking “why” a user wants to accomplish a job, you move up in the hierarchy of jobs. Determining job altitudes can be a little tricky—you need to experiment with your cross-functional team to align on the appropriate altitude for main jobs.

Take a look at an example that explores various job altitudes for marketing specialists. 

 

Summary

Once you’ve crafted your job statements, it’s time to kick their tires, so to speak. “Pressure test” your job statements by going back to your original interviewees, and ask yourself whether or not each statement sounds like something they would agree with. Better still, ask them directly! But if you can’t, you should be able to imagine their responses pretty easily.

Congratulations! You made it to the end of the module, but there’s still much to be learned about Jobs to Be Done. Remember, like the perfect cake, the approach you take to Jobs to Be Done will need to fit your use case. We encourage you to use the resources throughout this module to help with effectively applying the Jobs to Be Done framework to drive success.

Resources

• Blog: 5 Tips for Writing Job Stories
• Blog: Outcome-Driven Innovation