Jobs to be Done Should Not Lie

Building software services and products people want to use can be challenging. The challenge boils down to:

1. Since it is often not obvious, how do you know about potential customers’ unmet needs?
2. Since people can readily describe their needs but not the associated solutions, how do you decide what (if anything) software can do about these unmet needs?
3. Since it takes time and coordination of several team members with different skills to build software, how do you ensure that the end product doesn’t drift over time from the original unmet needs of customers?

There are many methods and models for doing this work, from taking educated guesses and building something and seeing what happens vs. approaches that incorporate user experience research early and try to ship something viable in a first release.

Without laying out all the options, I’ll just say that I’m interested in the Jobs to be Done (JTBD) framework for understanding people’s unmet needs and the Agile method for delivering software early in usable increments.

JTBD provides a powerful lens for understanding customer needs. It recognizes that people ‘hire,’ disregard, or ‘fire’ products based on how well they address their requirements. At its core, if you’re unaware of your target market’s goals or can’t build software that meets those needs, why would customers choose your product when their concerns don’t match yours?

A lot has been said about Agile, and its reputation is mixed. It’s an excellent approach when it facilitates teamwork and delivers predictable software that aligns with the original customer insights. Still, it can quickly deteriorate without continuous attention to its purpose.

JTBD’s Job Stories are great for discovering customer insights, and Agile’s User Stories are great for specifying a unit of work that describes how a person would engage with software. Structurally, these two descriptive tools are similar, but to maximize their benefit, I recommend:

1. The scope of Job Stories and User Stories should reflect their different intents.
2. User Stories should be derived from a process of synthesizing and translating Job Stories into potential features.
3. As such, Job Stories do not inherently replace User Stories, and User Stories can never replace Job Stories.

Let’s consider an example where a Job Story and User Story are essentially the same, just rephrased.

The User Story above is valid, and implementation work based on this story will align with the customer’s needs. The Job Story could be substituted for the User Story, and the outcome would be the same, but this misses most of the potential of Job Stories. In the Job Story above, we are gaining little customer insight. There is an argument that this form of an implementation story allows for more creativity in implementation work. Job Stories tend to be less prescriptive than User Stories—fair—some teams might benefit from Job Stories over User Stories in their implementation work, but this is likely a tiny gain.

On a product team, we often lack documentation describing people’s goals, which they would use as criteria to choose or reject our product. When a team swaps Job Stories for User Stories as an implementation tactic but does not create Job Stories at a higher level of user insight detached from a product’s implementation, much of the enduring value of user experience research may be lost.

From this perspective, I might argue that there are:

• Discovery Job Stories
• Implementation Job Stories
• User Stories (always for implementation)

While there is a case for replacing User Stories with Job Stories, one odd characteristic of Implementation Job Stories is they often read like lies from the perspective of the principles of JTBD. In the earlier example, the person is not hiring your app because of detail that prevents order duplication. Yes, they do not want to be double-charged, but their goal here is not avoiding double-charging; it is buying things they want. If your team starts seeing customer goals as avoiding all the ways your product could harm them, this is a warped perspective!

Here is another example of stories in this configuration:

The great thing about the Job Story above is that it provides deep insight into the way many people feel, in this case, about participating as an interviewer. With this insight, we can determine potentially surprising ways our software can help interviewers achieve their goals. Arguably, this is such a compelling benefit that organizations would “hire” this product based in part on a feature set that addressed this concern and “fire” other tools that didn’t handle it or somehow made it worse.