Software Engineering: A Modern Approach

Marco Tulio Valente

1 Jobs to Be Done (JTBD) Applied to Software Products

1.1 Introduction

Jobs to Be Done (JTBD) is a theory developed by Clayton Christensen and colleagues in the mid-2000s to explain why customers choose to buy certain products or services. The idea is that people do not consider every feature of a product when making a purchasing decision. Instead, they have a job that needs to be done and they hire the best product capable of helping them complete that job successfully.

Therefore, according to JTBD, the key questions we must answer when designing and developing any product, digital or not, are:

Why do customers hire our products? Under which circumstances?
Which problems in their lives do they want to solve with our products?
What kind of progress do they hope to achieve by purchasing our products?

JTBD is thus a theory that focuses on the origins of purchasing decisions—that is, on the mechanisms that explain why a person decides to introduce a product or service into their life. For this reason, the authors of the theory emphasize that JTBD seeks to understand the causal mechanisms underlying the adoption of products, services, or innovations.

Example: Morning Milkshakes

A well-known example for explaining JTBD refers to consumers of milkshakes from a large fast-food chain in the United States. While consulting for the company, the authors discovered that a significant number of milkshake sales occurred early in the morning.

After interviewing customers, they concluded that customers hired those milkshakes to solve a specific job: to make long commutes to work less tedious.

As this example illustrates, it is not always easy for companies to discover the jobs for which their products are hired. In particular, this hiring can occur under specific circumstances. And the jobs may evolve over time, and unexpected ones may also emerge.

Why is it important to understand the “jobs” that motivate customers to hire our products?

By doing so, companies can prepare to serve their customers better. In the case of the fast-food chain, they could open their drive-thru earlier, preventing customers from having to park and enter the store. Another option would be to create a special type of milkshake designed for morning commutes, possibly with less sugar and greater viscosity.

By thinking through the lens of JTBD, we also better understand who our product’s competitors are. For example, the competitors of a software system may include not only systems from other companies but also a spreadsheet or even a notebook.

1.2 What Does JTBD Have to Do With Software?

The answer is: everything. Software is increasingly treated as a product. When software is viewed this way, development never truly ends, as the system is constantly evolving and must continually incorporate new features to retain and gain markets and customers. This product-oriented mindset is particularly common in digital companies whose business depends on one or more software apps.

For this reason, when developing and evolving a software product, it is important to keep in mind the jobs for which it is being hired. Otherwise, we risk building a system full of features that do not help customers on the jobs they need to accomplish.

The tweet below, by the founder of Gumroad—a website for selling digital products—illustrates the importance of JTBD in the context of software.

People don't want to use your software.

They want to lose weight, laugh, be entertained, get smarter, spend time with loved ones, go home on time, sleep adequately, eat good food, be happy.

Your product is only as good as the experiences it enables people to have.
— Sahil Lavingia (@shl) August 15, 2019

Example: QuickBooks

In the book introducing JTBD, Christensen and colleagues mention the case of QuickBooks, an accounting software for small businesses developed by a company called Intuit.

This company had a very popular personal finance system in the U.S. called Quicken. They then realized that some Quicken users were improvising and using the system to manage the accounting of their small businesses.

In other words, they preferred Quicken over existing accounting systems, which were complex and aimed at professional accountants.

Intuit then decided to launch its own accounting system, QuickBooks, designed for small businesses and it became a major success. Its price was even higher than that of competitors with more features.

Christensen and colleagues summarize the case as follows:

Competitors were focused on producing the best accounting software possible. On the other hand, Cook [Intuits CEO] and his team focused on the job customers were trying to complete […] And when customers find the right product to meet the job they need to accomplish, they are usually willing to pay more.

Example: Twitter

In 2021, Twitters CEO at the time stated that they planned to focus the evolution of the social network on three strategic jobs for users: discovering what is happening, conversing online, and receiving financial compensation for their tweets. Interestingly, he did not use the term requirements or features, but rather jobs. For more details, see this Harvard Business Review article.

1.3 Discovering the Jobs

To discover the jobs for which customers hire your software products, you must observe them and talk to them. In the milkshake example, the authors explain that they did exactly this: They went to the restaurants early in the morning and asked customers why they were buying milkshakes at that hour.

Thus, when defining user stories, it is important to clarify with customers why they are requesting certain stories. That is, their underlying motivation and context.

To make this motivation behind user stories clearer, there is the concept of job stories, an alternative template for writing stories in the following format:

When [situation], I like to [motivation] so that [benefit].

For example: when I drive to work, I like to drink a milkshake so that the trip becomes more pleasant and I dont feel hungry when I start working.

However, this template should be used only for less common situations. For many user stories, the motivation is already clear, so the template adds little value.

Another useful technique is asking the customer how they currently solve the problem, i.e., before the system includes the requested story. This helps clarify the context and motivation.

1.4 Conclusion

When designing a software product, we should think about the supply (the product’s features) and the demand (the customers’ actual needs). Often, we start from supply and try to connect it to demand. JTBD, however, advocates the opposite direction—from demand to supply—which tends to work better, as illustrated in the figure below.

In software, JTBD stands out along with other theories (such as Design Thinking) in systems whose requirements are emergent, meaning they are not clear to any customer. In such cases, it is worthwhile to begin by understanding customers’ real demands. That is, the jobs that matter most to them, and only then decide what should actually be implemented.

Ultimately, theories like JTBD help us avoid implementing systems filled with features that deliver little progress for customers and therefore end up not being used.