Competing Against Luck: The Story of Innovation and Customer Choice

by Clayton M. Christensen

First, if you or a colleague describes a Job to Be Done in adjectives and adverbs, it is not a valid job. It might describe an experience that a customer needs to have in order to do the job, but it is not a job, as we have defined it here. For example, “convenience” is not a Job to Be Done. It might be an experience that might cause a customer to choose your product rather than a competitor’s product, but it is not a job. A well-defined Job to Be Done is expressed in verbs and nouns—such as, “I need to ‘write’ books verbally, obviating the need to type or edit by hand.” In contrast, the sentence “We should aspire to be more honest” is a noble goal, but it’s not a job. Second, defining a job at the right level of abstraction is critical to ensuring that the theory is useful. This can be more art than science, but there is a good rule of thumb: if the architecture of the system or product can only be met by products within the same product class, the concept of the Job to Be Done does not apply. If only products in the same class can solve the problem, you’re not uncovering a job. A couple of examples: “I need to have a chocolate milk shake that is in a twelve-ounce disposable container” is not a job. The possible candidates that I could hire to do this are all in the milk shake product category. I could call this a need or a preference—but it isn’t a job. We need to go up another level of abstraction in order to discover the job. “I need something that will keep me occupie...

Pitfalls with JTBD